Slashdot Mirror
FreeS/WAN Project Bows Out
V. Mole writes "After five years, the FreeS/WAN project has decided to end development. The main reason seems to be that although the project was technically successful, it was not making much progress with its political goals of encrypting a significant portion of all Internet communications, although one might guess that the selection of KAME for the standard Linux IPSEC implementation might also have influenced this decision. And don't panic, the software will remain available, and of course some other group is free to continue development."
And don't panic, the software will remain available, and of course some other group is free to continue development
this is probably one of the reason why OSS is A Good Thing.
How many commercial products are there that were started over five years ago that are still in current development? There are quite a handful still in current development--but vastly more that have been abandoned completely.
Both in the open source world and in the commercial world, the vast majority of projects die. The difference is that in the open source world, the dead projects can still be put to good use in a new reincarnation down the line.
Dlugar
Computer Go: Writing Software to Play the Ancient Game of Go
OE doesn't *need* DNSSEC.
It just benefits from it. Without it, you are vulnerable to *ACTIVE* attacks against the DNS. With DNSSEC, you are totally immune.
The real thing that bones up OE is that you need a static, public IP (since OE isn't defined for NAT'ed IPsec). If you want to do full OE, then you access to the reverse map too. How many have that? Well, if you don't, you probably don't have static IP or an AUP that even lets you sneeze.
But, it could be made to work with NAT'ed IPsec, and it could also do enrollment in the reverse map via DHCP.
...this project would be a little better of a choice for VPN than FreeSWAN? I've been looking it over and it looks pretty cool. I still have to actually try it though.
Un-news
You know what's funny? Recent Linksys VPN routers (ie: WRV54G) use FreeS/WAN for IPsec (they are built on the OpenRG platform).
So you might be using it anyways
to be learned here. The stated goal of the project was to increase the amount of traffic that is encrypted on the internet. While this does not directly conflict with the goal of making as much software as possible "free" (as in beer), it does set a different goal.
Why the hell am I bringing this up? Well, 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. The last time I checked (which I have to admit was over 2 years ago) the FreeS/WAN project explicitly stated that they would refuse to cooperate with anyone who tried "subvert" the project by building-in interoperation with low-bit encryption.
So what is this lesson to be learned that I am talking about? When fighting an uphill battle (which a volunteer project challenging for-profit institutions always does), it may not be wise to make it more difficult for people on the sidelines to agree with your cause.
Linux was built on much better technology than Windows (nfs vs smb, ext vs fat, separate windowing subsystem vs windowing system as part of the kernel, etc), but it didn't gain in popularity because it decided it replace all the Windows boxen. The technical decision was made to cooperate with them. The fundamental decision on priorities was to hold interoperability above politics. FreeS/Wan took the other road.
Any guest worker system is indistinguishable from indentured servitude.
The 2.6 implementation is not as mature, but it has excellent success factors. It was written by an alpha kernel hacker, it's in the mainline, and it's open in the Linux tradition. An influx of former FreeS/WAN users may be just what it needs to work out the kinks. FreeS/WAN has done a great service, and is now doing another by throwing its momentum behind an implementation with better long-term prospects.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
I've been a Linux user for 10 years, and a Unix System Administrator for 3 years, but Freeswan was among the most challenging things I've ever installed. I found that nothing less than reading the documentation from cover to cover is sufficient to understand it. I'm not suprised that it never caught with any sort of mainstream. Don't get me wrong, I am all for the vision of a secure-by-default internet. But unfortunately, it's so tough to install that only die hard security buffs have the patience to figure it out. Where is the ncurses-based "kernel setup wizard" script with forward and backward buttons? A checklist-based helper to point out what is missing next in getting the damn thing installed properly? A webmin module? A gui based connection configurator, called, say, [g|k]freeswan-conf? ESR has it dead on: without a thick slathering of user friendliness, this sort of project cannot succeed on any widespread level. Them's the breaks. I wish things were diffrent, believe me.
As a long time freeswan user I have to say this sucks pretty hard. Having used isakmpd and racoon on openbsd and freebsd respectivly, I've always thought freeswan was easier to configure (but not always easier to get working)
:)
Hopefully openswan will be a good replacement
... not making much progress with its political goals of encrypting a significant portion of all Internet communications ...
Part of the problem with the FreeS/WAN group was that they DIDN'T WANT TO INTEROPERATE. Their attitude toward single DES was that they refused to support it because it wasn't sufficiently secure. As I recall, they wouldn't even accept patches that provided it as an ifdef with the default turned off. So, they were a pain in the ass to use for any serious interoperative commercial development, which obviously requires stooping to single DES.
This quote from the FAQ at freeswan.org sums up their attitude regarding interoperability:
"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."
FreeS/WAN saw it wrong. Sure, single DES is not macho enough, but interoperating is pretty damned important, even if that means supporting a protocol that is beneath your 'leetness.
I don't think you're alone there. I myself have tried FreeS/wan several times over the years and have always found it a frustrating experience. I think the documentation should take a lot of the blame for the problem. It was never too clear and gave only a few wildly different (and sometimes conflicting) examples. Left side? Right side? They would often switch the left/right-side convention for no apparent reason. And it I found it wasn't always clear what configuration settings were required and how they interacted. Because of this it was hard to condense a working configuration out of the few examples they did give.
Many years ago I was trying to connect my network with my familys' network (linux to linux) I eventually went with vtun. It worked fairly well. More recently I went with OpenVPN when I needed to connect my dads' Win2K laptop back to the family network over a dial-up line. In both these examples I originally tried using FreeS/wan on the linux side(s). I thought it would be easier (especially with W2K in the second case) because IPsec is a standard. Nope. Now I'll go look at this new Kame port in the 2.6 kernel and IPsec-tools. Hopefully it's fairly easy to setup.
>There was talk of fixing this through a port 53 passthrough, but I don't think this ever happened.
I think this is being fixed in 2.06, so we'll assimilate that chunk of code if it works correctly.
>Also, OE requires the use of the TXT field. There are many other projects also proposing to use this field (well, a few anti-SPAM proposals), so conflicts could arise in the future.
You can have multiple TXT records, just like MX, A and other DNS records, so this shouldn't be a problem.
>However, I hope that Ken Bantoft will be successful with Openswan. My company uses FreeS/WAN for a VPN solution to provide secure WAN access between international sites.
Thanks!
Ken
Maybe there's a lesson to learn in that.
With all the man-hours that went into FreeS/WAN, couldn't they have come up with some sort of decent configuration method?? Either simplify the configuration, or create a perl script or web form to walk people through common configurations.
I know that for the developers, who know it inside & out, it all seems logical and obvious. But, for anyone just wanting to set up a simple VPN it was MUCH harder than it needed to be.
Last time I looked at FreeS/WAN, it had config statements like "leftSubnet" and "rightSubnet".. Couldn't they think of config options that gave users less of a clue as to what the intended purpose was?? Nah.. local and remote, or my and peer, or any of a dozen other logical options would be too easy.
And, I hope this has changed.. but when I last looked at it, you had to define the next-hop-address that packets would route through! I have no clue what the limitation was that required that to be configured, but come on.. either determine it dynamically, or fix the root problem.
Okay.. sorry to vent like that.. An open implementation of IPSec is an incredible accomplishment. Especially back when these guys first started, when interoperability was a bitch, and the spec was still in question. But the configuration really is unusually poor.
It might be an instance of Linux developers failing to produce software that is as good or better than the BSD-licensed alternative (and I don't know either KAME nor FreeS/Wan good enough to say if that's the case), but there is nothing morally wrong about it. Using the best tools available, whereever they come from, is certainly more important than a pissing match between FLOSS sub-communities.
Programming can be fun again. Film at 11.
I chose not to use F/Swan because they refused to even evaluate development kernels and didn't even consider migrating their code to 2..X until X was several releases old. Their reasoning? They were aiming at boxed sets sitting on the shelf as their target for versioning.
.5 or higher...AND...they won't accept patches to support current code because I happen to live in the US.
In actuality, this means that those boxed sets never got F/Swan because by the time the F/Swan community migrated their code to the newer kernel versions, the boxed sets had been on the shelf for a long time already.
I don't use boxed sets, but this attitude of being a year or more behind current development pretty much frustrated the heck out of me. So when the LK folk picked something else to include by default in the kernel, I was more than happy.
It's akin to a widget driver group who's last version only works on 2.4.x; refusing to support 2.6.x until it's been out for half a year and x is
They shot themselves in their own foot repeatedly with this attitude, it's no surprise that F/Swan never gained widespread share.