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?

[Anonymous Coward]

Of course leto has!

http://freshmeat.net/~letoii/

He in on the projects, just an ad for his company.

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?

[Shoten]

Don't forget about the arrogance one encountered when asking for help, either. I've sucked up and dealt with some amazing Napoleonic complexes when using software before, but these guys were such bastards I actually chose a commercial solution over them in the end. I draw the line at accepting condescending remarks from people who don't know how to keep a listserv running properly while failing to address the question asked of them.

Re:user friendly?

[Jacco de Leeuw]

I disagree. The support mailinglist has been great. For instance, FreeS/WAN team member Sam Sgro provided commercial quality support. One issue is that they deliberately did not filter for viruses and spam. But other filtered mailinglists sprung up so that was not really an issue.

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

[/dev/trash]

France? Has freedoms? Care to discuss Nazi's and the like on a french based website?

Re:At Lazt ...

[Odin's Raven]

...ze French Bastardz...

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

Re:At Lazt ...

[AftanGustur]

France? Has freedoms? Care to discuss Nazi's and the like on a french based website?

Although I agree with you that banning discussions about a topic is not the best way, the French view is that the Nazi ideology is so far off, that it's simply off-topic..

Like if you would put up a site anywhere in the world about the pros, cons and pleasures of Phedophily. I'm pretty sure it wouldn't stay up very long.

Or, try to put up a website in the USA, that justifies the 3000 dead in the twin towers ...
You would be lucky not to be killed...

And that's just the internet.. Try to show some French commercials on American TV and they would be X-rated for nudity..

Think about it, normal breasts and legs.... And The first thing that pops into the mind of Americans is "Porn", "Sex" and "Censorship" ..

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:Debian packages now avalible for freeswan

[Anonymous Coward]

somebody please mod the parent down. it links to some gay picture.

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!

Re:Debian packages now avalible for freeswan

[velkro]

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

Yup, I'm in EST, so it's morning now. Imagine my surprise with a 5.6mbit /. for a wakeup call!

WHy is this marked YRO?

[Anonymous Coward]

Does open source now automatically mean YRO? Does security mean YRO, even when it's not homeland security? How do the editors make these decisions^H^H^H. . .^H^HWhat are the editors smoking?

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

[Anonymous Coward]

And what was KAME's response when you reported this bug?

What, you didn't do that?

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.

Plz Mod Parent DOWN

[bangular]

I don't know how a post that has a pic of a man about to eat another mans ass with a giant fork got modded up. This one has to go down in slashdot history. Nice use of debian redirect cgi though, I was actually expecting a debian package page.

Swansong

[Alain Williams]

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

Re:Swansong

[Jon_E]

It was for that other FreeBird (with apologies to Lynyrd Skynyrd and the late VanZant)

"If I leave here tomorrow,
will you still remember OE?"
[*groan*]

Free Swan?!

[Anonymous Coward]

that redhead is freakin HOT!

apploaded

[Anonymous Coward]

We applauded when the apploaded

or is it?

app + exploded = apploaded

openvpn

[Anonymous Coward]

From what I've seen, ipsec is FAR too complicated. It's too low level, it screws up routing.

It looks to me that openvpn is MUCH simpler, and just as useful. I think ipsec should die.

Does It Support Single DES?

[Glug]

If it wants to interoperate with any IPSec implementation other than itself, it will need to support negotiation through single DES (even if the tunnel doesn't wind up using it).

Refusal to support single DES was what made FreeS/WAN virtually useless, even for those who muddled through the endpoint configurations and could put up with ip:port combos occasionally being hung out to dry due to dropped connects until the next rekey.

Re:Problems with OpenSwan

[mwood]

"Router MTBF increased by 50%"

So, at least something improved. :-)

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?

700% savings?

[Ungrounded Lightning]

We chose the MTSEC security from Bizland Consultants inc instead, and it saved us over 700%

I see.

Not only did your maintainence budget go to zero but Bizland Consultants paid YOU six times your former budget.

Where do I sign up for THAT deal? B-)

= = = =

On second thought, forget it. TANSTAFFL, so they must be getting something from you that's worth even more.

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.

Re:Man this stories fucking boring...

[Anonymous Coward]

Agreed. This is why we need to replace "interesting" with +1 Sexy, among other things.

"Cygnus style" business model

[RedPhoenix]

Or, based on the fact that this project is an offspring of freeswan, should that be "Cygnet style" ? ;) ... ok, back in my box.

Red.

Follow the BSDs

[Anonymous Coward]

FreeS/WAN and now OpenSwan.....

is NetS/WAN next?

Re:Follow the BSDs

[DA-MAN]

You must have forgot about 386 S/WAN 4.4-Lite to which FreeS/WAN was based upon.

Re:Opportunistic Encryption - on by default

[jimboid]

In Openswan OE is on by default and you have to edit your config file to turn it off. Fortunately - it's easy to disable.