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

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.

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