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

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.

Debian packages now avalible for freeswan

[Anonymous Coward]

Yes, it works with Debian! This debian certified package is avalible for alpha, arm, i386, ia64, m68k, mipsel, and G5 (unoffically).

So download it today!

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

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

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.

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.