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

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.

Talk about lacking in content

[pinkUZI]

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

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: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: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!

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?