FreeS/WAN Continues As Openswan

leto writes "It seems some of the developers and volunteers of the (recently deceased) FreeS/WAN project have started a new company to develop and support the successor of the Linux IPsec code under the name of Openswan in a "Cygnus style" business model. They announced the new version at CeBIT which fully supports the new Linux 2.6 native IPsec stack. According to the Openswan website, it was started 'by a few of the developers who were growing frustrated with the politics surrounding the FreeS/WAN project.' There is a FAQ that explains how the various parts of IPsec on Linux work together. I guess that means US citizens can finally submit patches, and that distributions like RedHat/Fedora can now include it in their distribution. FreeS/WAN has always had the most features and most the most user-friendly configuration. It is good to see that will continue. And their mailing list finally seems to refuse spam too."

Comments

Comment removed

[account_deleted]

Comment removed based on user account deletion

user friendly?

[Kryptolus]

I guess you never personally configured it...

Re:user friendly?

[arivanov]

Ahem.

The most horrible IPSEC out there. Broken by design, absolutely incompatible with any routing protocol software, broken in operation and utter nightmare to configure and get working.

One of the things I apploaded most when reading the 2.6 kernel changelogs was the port of KAME IPSEC and utilities. They work (TM). They are missing some features that were in FreeSwan that made it useable as a amateur VPN access point (email ID in shared keys, x509 CRL and a few others), but I do not see these as a reason to revive freeswan instead of fixing the omissions.

Re:user friendly?

[jamesh]

Openswan works fine with 2.6 ipsec, as did freeswan. With the 2.6 Kernel, openswan just does isakmp and then tells the kernel what to do. imho, openswan is more flexible than any of the other isakmp implementations i've seen available for linux.

For certain values of 'nice', one of the nice things about klips was that there was a virtual interface for the decrypted traffic. Stuff for encryption went out ipsecN, then the encrypted packet (proto 50/51) went out the real interface. Made firewalling and routing easier, or harder, depending on how you like to do things. But you could instantly say 'accept encrypted traffic on tcp/123' without having to muck around with firewall marks etc.

btw, you can get a 2.4 linux kernel with 2.6 ipsec backported, if you don't like klips. Debian does this.

Re:user friendly?

[arivanov]

For certain values of 'nice', one of the nice things about klips was that there was a virtual interface for the decrypted traffic.

Nice for manual kludge on a small office VPN setups - agree 100%.

Absolutely disagree for a larger network with dynamic routing. For any network with these it was THE NIGHTMARE DESIGN (TM). Reason is that nearly any routing protocol carries either IP or IP/NETMASK information and no interface information (neither name, nor ifIndex). It is obvious that in the presence of two interfaces with exactly the same netmasks and ip addresses the information content of a routing protocol becomes highly ambigous. This is something BSDs have got right - they define a separate address family for IPSEC and handle it completely separately. As a result you can happily use them both.

Not the only IPSec stack

[The-Pheon]

Don't forget about KAME. It isn't just for IPv6, and also supports IPSec for both ipv4 and ipv6.

Re:Not the only IPSec stack

[Anonymous Coward]

Yes, and it's under a very liberal license too.
Even better, it is VERY portable, which means that as an administrator you just have to care to know about KAME and not a gazillion halfbaked inconsistent implementations.

At Lazt ...

[AftanGustur]

I guess that means US citizens can finally submit patches, and that distributions like RedHat/Fedora can now include it in their distribution.

Ahh, u mean ze citisenz of ze USA can finally have ze same freedom as ze French Bastardz have had for yearz ?

Re:At Lazt ...

[Odin's Raven]

...ze French Bastardz...

Excuse me, but here in the US the politically-correct term is Freedom Bastardz. ;-)

Talk about lacking in content

[pinkUZI]

There was more content in the article on slashdot than on the entire Openswan website!

Re:no but maybe the better one...

[pacman on prozac]

The problem with KAME is that IPSec packets between two hosts can bypass the packet filters.

That is, with KAME on Linux and FreeBSD, packets are not decrypted until after iptables/ipfw has looked at them. That means you cannot packet filter on anything other than IP & MAC Address as you can't read anything else, its all encrypted :)

Apparently FreeS/WAN had a separate device to read from that gave unencrypted packets for filtering.

This only applies to transport IPSec between two complete hosts. You can use tunnel mode onto a tun device and filter from that, and you can also just encrypt traffic based on port.

Either way, I'm kind of relieved that FreeS/WAN has not gone completely and that the above situation still has a fix. A security protocol seems kinda useless when it allows firewall bypassing, especially when it could happen automatically if you have IKE setup and open to the world.

Strongswan

[gvdkamp]

There is yet another project. Andreas Steffen (Creator and maintainer of the X509 patches for FreeS/WAN) has started its own version as well. Check out www.strongswan.org for differences between openswan and strongswan.

2.6 IPsec still problematic

[valentyn]

I've been testing with 2.6 IPsec, but I'm not convinced that it's production ready. Especially the MTU handling gives me the creeps:

valentijn:~# ping -s 1435 host21
PING host21.wireless.palmgracht.nl (10.15.67.21): 1435 data bytes
ping: sendto: Message too long
ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
ping: sendto: Message too long
ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1

Resetting the MTU on the network interface helps:

valentijn:~# ifconfig eth1 mtu 1400
valentijn:~# ping -s 1417 host21
PING host21.wireless.palmgracht.nl (10.15.67.21): 1417 data bytes
1425 bytes from 10.15.67.21: icmp_seq=0 ttl=64 time=93.0 ms
1425 bytes from 10.15.67.21: icmp_seq=1 ttl=64 time=78.2 ms

Then, resetting it to 1500 again does this:
valentijn:~# ifconfig eth1 mtu 1500
valentijn:~# ping -s 1435 host21
PING host21.wireless.palmgracht.nl (10.15.67.21): 1435 data bytes
ping: sendto: Message too long
ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
1443 bytes from 10.15.67.21: icmp_seq=1 ttl=64 time=89.0 ms

So only the first packet is blocked, after that the kernel adjusts to the right MTU. And please note: this is internally, the first packet doesn't leave the machine.

I had no time to test further, but what I found so far doesn't encourage me a lot to use 2.6 IPsec in production.

Re:2.6 IPsec still problematic

[sachar]

Strange I've implemented kame yesterday on a 2.6.4 kernel and just tested this and have no problems what so ever. The ping times are a bit higher (3 ms on a local 100mbit network), but no error messages.

Re:2.6 IPsec still problematic

[valentyn]

Ping the host (with large IP) without IPsec, then activate IPsec and ping again. Now as you've seen, the 2.6 kernel accomodates to the new MTU size. The bad thing is that the 2.4 backport of the 2.6 IPsec doesn't do that, which results in "too large" messages but no traffic.

I've seen NFS mounts come to a grinding halt because of this.

My setup is special in the sense that a 2.6 machine in between runs two tunnels: one to my office, one to a WiFi host (with a 2.4 kernel). I haven't found time yet to test a setup where the workstation runs 2.6 as well.

Re:no but maybe the better one...

[arivanov]

That means you cannot packet filter on anything other than IP & MAC Address as you can't read anything else, its all encrypted

Used to be correct as of ipfw 1. No longer the case as of ipfw2, though some cases do not work fully yet. See the ipsec qualifier for rules.

Dunno about Linux though. I use KAME extensively only on BSD.

Re:Debian packages now avalible for freeswan

[arivanov]

As someone who have had to deal with this minor horror (on debian actually) I would not call that works. Works from time to time and very sporadically usually in tunnel mode. There was only one release which had transport mode working correctly and ineroperating versus both BSD and Windoze. All other either failed completely or did not rekey correctly.

Re:Debian packages now avalible for freeswan

[Bi()hazard]

There's a discussion about which type of linux is best for running it here on the mailing list. They like both Debian and SuSe.

That said, it should work well enough on most things-from their site, "Standards Compliant: Openswan conforms to nearly all IPsec + IKE RFCs, and has one of the based interoperability track records of any IPsec implementation. It is compatible with products from Microsoft, Cisco, Nortel, Netscreen, Checkpoint, and many others vendors."
And "Platforms: x86, IA64, PPC, PPC64, MIPS, Alpha, StrongArm"

Openswan should work for just about anyone who isn't satisfied with KAME or Racoon (though it might be hard to set up, see this thread...

The front page summary makes it sound like the company they're starting exists solely for openswan, but it's worth noting Xelerance is producing some other stuff including freeRadius, think about your breathing-you have to manually control your breathing or suffocate, DNSSec, and Asterisk. The changeover will likely mean an increase in the quality of support available for (paying) swan users, since they provide an array of consulting services.

That also gives them an incentive to spread adoption. Unlike FreeS/WAN-one of the problems with FreeS/WAN was that it would not work with low-bit encryption. This was done to promote their political goal. But it also had the side effect of inhibiting adoption at the places where for whatever reason people had to interoperate with low-bit encryption applications or setups. According to their FAQ, "As we see it, it is more important to deliver real security than to comply with a standard which has been subverted into allowing use of inadequate methods." For example, they went out of their way to avoid allowing any handling of single DES.

And if you've got any more questions about openswan, the guy to ask is on slashdot with user id #11! He'll probably be posting in here when it's morning in that part of the world.

Who would win? Flying Shark or Flying Croc?? Croc all the way, fools!

Swansong

[Alain Williams]

So that earlier noise about it closing was not it's SwanSong after all.

Opportunistic Encryption?

[SiliconEntity]

Ironically, the original goal of FreeS/WAN was not support of VPNs. It was to implement John "Suspected Terrorist" Gilmore's goal of "encrypting 5% of the Internet by Christmas". The idea was that if two systems went to talk to each other with an ordinary net connection, and both happened to be running FreeS/WAN or compatible software, they would automatically and transparently negotiate IPSec encryption and use that for the connection. This is what they called Opportunistic Encryption. The goal of the project was to get some substantial fraction of internet traffic to be encrypted by this mechanism, thereby increasing privacy and decreasing the effectiveness of net-wide surveillance and monitoring tools.

Sounds like a good idea to me. Are either of these new FreeS/WAN offshoots, or any other comparable project, trying to achieve Opportunistic Encryption? Or are they just for VPNs?

Yes, Opportunistic Encryption?

[billstewart]

OE is still one of the goals; VPNs have been easy for a few years. One problem has been that their method for doing OE requires Reverse DNS support for DNSSEC, which makes it impractical for most potential users. In some sense it's still the Right Thing to do, because an IPSEC gateway only has a source and destination IP address to work from and needs some method for getting authentication keying information to prevent man-in-the-middle attacks, so it either needs Reverse DNSSEC or something very much like it, and preventing MITM is the Right Thing To Do.

If Gilmore was willing to risk MITM attacks in return for protecting a much higher fraction of the network users from passive eavesdroppers, the alternative was to use "shared secret" mode with a publicly known "secret", such as "open secret" or something proposed in a draft rfc. But that would have meant that the people who most needed OE would be using a method that wasn't secure against governments or motivated crackers, and a false sense of security is arguably much more dangerous than known insecurity - if you know you're not secure, you're forced to use PGP to encrypt your email instead.