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."
Dear FreeS/WAN Community,
After more than five years of active development, the FreeS/WAN project will be coming to an end.
The initial goal of the project was ambitious -- to secure the Internet using opportunisitically negotiated encryption, invisible and convenient to the user. For more, see our history page. A secondary goal was to challenge then-current US export regulations, which prohibited the export of strong cryptography (such as triple DES encryption) of US origin or authorship.
Since the project's inception, there has been limited success on the political front. After the watershed Bernstein case, US export regulations were relaxed. Since then, many US companies have exported strong cryptography, without seeming restriction other than having to notify the Bureau of Export Administration for tracking purposes.
This comfortable situation has perhaps created a false sense of security. The catch? Export regulations are not laws. The US government still reserves the right to change its export regulations on short notice, and there is no facility to challenge them directly in a court of law. This leaves the US crypto community and US Linux distributions in a position which seems safe, but is not legally protected -- where the US government might at any time *retroactively* regulate previously released code, by prohibiting its future export. This is why FreeS/WAN has always been developed outside the US (in Canada and in Greece), and why it has never (to the best of our knowledge) accepted US patches.
If FreeS/WAN has neither secured the Internet, nor secured the right of US citizens to export software that could do so, it has still had positive benefit.
With version 1.x, the FreeS/WAN team created a mature, well-tested IPsec VPN (Virtual Private Network) product for Linux. The Linux community has relied on it for some time, and it (or a patched variant) has shipped with several Linux distributions.
With version 2.x, FreeS/WAN development efforts focussed on increasing the usability of Opportunistic Encryption (OE), IPSec encryption without prearrangement. Configuration was simplified, FreeS/WAN's cryptographic offerings were streamlined, and the team promoted OE through talks and outreach.
However, nine months after the release of FreeS/WAN 2.00, OE has not caught on as we'd hoped. The Linux user community demands feature-rich VPNs for corporate clients, and while folks genuinely enjoy FreeS/WAN and its derivatives, the ways they use FreeS/WAN don't seem to be getting us any closer to the project's goal: widespread deployment of OE. For its part, OE requires more testing and community feedback before it is ready to be used without second thought. The project's funders have therefore chosen to withdraw their funding.
Anywhere you stop, a little of the road ahead is visible. FreeS/WAN 2.x might have developed further, for example to include ipv6 support.
Before the project stops, the team plans to do at least one more release. Release 2.06 will see FreeS/WAN making a late step toward its goal of being a simple, secure OE product with the removal of Transport Mode. This in keeping with one of Neils Fergusson's and Bruce Schneier's security recommendations, in A Cryptographic Evaluation of IPsec. 2.06 will also feature KLIPS (FreeS/WAN's Kernel Layer IPsec machinery) changes to faciliate use with the 2.6 kernel series.
After Release 2.06, FreeS/WAN code will continue to be available for public use and tinkering. Our website will stay up, and our mailing lists at lists.freeswan.org will continue to provide a forum for users to support one another. We expect that FreeS/WAN and its derivatives will be widely deployed for some time to come.
It is our hope that the public will one day be ready for, and demand, transparent, opportunistic encryption. Perhaps then some adventurous folks pick up FreeS/WAN 2.x and continue its development, making the project's original goal a reality.
Important info:
http://www.lifeaftertheoilcrash.net
http://dieoff.org/synopsis.htm
http://www.peakoil.net
Openswan is an Open Source implementation of IPsec for the Linux operating system. Is it a code fork of the FreeS/WAN project, started by a few of the developers who were growing frustrated with the politics surrounding the FreeS/WAN project.
The Army reading list
Ressurection is an eventuality, and in the article he states that it's not finished, it's just the end of major comabat operations.
Mod "Overrated" instead of replying "I disagree with you," you coward.
I've taken my Super FreeS/WAN tree, and formed a company with some other ex-FreeS/WAN folks.
Openswan is new name of the project, you can already get code from www.openswan.org.
Commercial support + services from us via Xelerance
Ken
To say that "KAME" was picked is wrong.
Either it means, that *YET AGAIN* Linux can't play
nicely, and has to import code from the BSD world
to make things work.
Or, it means nothing, because KAME wasn't imported
to the kernel. Only one or two libraries, and the pfkey code was. And, the userspace KAME tools leave so much to be desired, that nobody would want to
run them.
Openswan lives.
As people have mentioned... the Openswan project is picking up the slack, and commercial support is also available, directly from current Openswan and ex-FreeS/WAN project folks via Xelerance.
In classic Linux fashion, I found FreeSwan complicated and hard to use. It had incredibly obtuse error messages. I couldn't figure out how to configure it (configuring it may be simple, but I couldn't actually figure out _what_ needed to be configured). All I wanted to do was talk to our corporate Sonicwall. All in all a very unpleasant experience.
I fought with it for a week - did tons of google research, and still couldn't get Phase2 to work. I eventually caved in and bought a Linksys VPN endpoint router that comes with a simple web administration tool. I had it up and running in 15 minutes. I'm just sorry I wasted that week on FreeSwan.
I'm afraid that this is going to be the course of all good free/open source software projects. I work in an envioronment that uses Free software for our servers because the schools can't afford others. We've been using Mitel's SME Server (E-Smith for you old-schoolers) for quite a while. Recently Mitel is dropping support for this. This announcement came right after Redhat's shakeup a while back. Free/swan is an excellent tool that we've been using to connect schools and homes. Anyway, I'm afraid that education will suffer, which in turn will lead to everyone's suffering.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
"First things first -- but not necessarily in that order"
-- The Doctor, "Doctor
Are Microsoft still supporting Windows 98?
No.
ummm - I have win 98 at home, and when I do a "Windows Update" I see that they are still supporting it. They turned around on their plan to abandon win98 for 12 months I think it was.
so what exactly was your point?
From the announcement itself:
That the original group of developers is bowing out has, really, little to no implications for your ability to find support.
the people in #openswan on irc.freenode.net are pretty helpful.
FreeSWAN sucks.
I have to look after a large network of VPNs across a small country and a lot of things about FreeSWAN bite bad wind.
For one thing, not only does it encrypt network traffic; it encrypts its error messages as well. They are all but unintelligible, even after looking at the sourcecode.
Actually, after looking at the sourcecode one is frequently more confused than ever.
And googling for the error messages often seems to find threads where the FreeSWAN developers burble to the effect of "yeah its confusing but I can't be bothered fixing it".
I'm not a developer, but my (highly competent) developer colleague assures me that its 'spaghetti code'.
For another thing, running it over ADSL is a pain in the proverbial; it seems highly intolerant of the so-called 'micro-outages' that pervades ADSL.
Good riddance.
I just hope that we can shift everything over to KAME before the next gaping security hole in FreeSWAN makes its appearance.
In the free world the media isn't government run; the government is media run.
and this is the link i was looking for http://support.microsoft.com/default.aspx?pr=LifeA n1 specifically this part here
"Windows 98 and Windows 98 Second Edition support was scheduled to end on January 16, 2004. However, continual evaluation of the Support Lifecycle policy revealed that customers in the smaller and the emerging markets needed additional time to upgrade their product. Therefore, Windows 98, Windows 98 Second Edition, and Windows Me will continue to be supported after January 16, 2004."
I've used FreeS/WAN... it wasn't a bad project or bad software, but was just too much 99% of the time. I usually only need to encrypt data between under 5 ports. I can set up an ssh tunnel almost instantly which does the job just as well. If ssh is already set up (which it usually is more often than not these days) you can have an ssh tunnel going in a few seconds. FreeS/WAN needed kernel patches and took much longer to set up and besides that, the development didn't seem very fast.
rot-13 was an simple cypher used to 'encrypt' spoilers and possibly offensive material in Usenet posts. It worked by converting each letter of the (latin) alphabet to it's numerical equivalent (a=1, b=2, ... ,z=26), adding 13, subtracting 26 if the result was larger than 26, then converting back to a letter. (ROTating the letter thirteen 'spaces').
"Hello World" -> "Uryyb Jbeyq"
triple-DES is a more modern encryption scheme still in use today.
The humor comes from the fact that applying rot-13 twice results in the exact original text, so saying that the Internet uses 'double rot-13 by default' is just noting that it's completely unencrypted but in a way that makes it sound like a real encryption scheme.
It really was quite an amusing post... unlike this one.
Good news - you don't need 2.6 to do native IPSEC.
I've done a couple FreeS/WAN installs on 2.4 and they were kind of difficult to set up. Not too bad - just painful enough to appreciate them.
However, the other day I decided to try the Linux kernel's new native IPSEC modules (that have been backported to at least 2.4.24). Using 2.4.24 and KAME it was an absolute pleasure to set up. Works beatifully, and no more patching. You couldn't pay me to return to FreeS/WAN.
my statement wasn't about the number of abandoned developments. i assumed there'll be more abandoned OSS than CSS, mainly due to that fact that not all CSS are publicised, especially a failed one. and honestly, not all OSS are good ones.
but that's not the point, i was actually talking about the ability for others to pick up a OSS and continue it. simply put, OSS may sleep, but it'll never die completely.
if no one picks it up, that probably means that particular software isn't worth nothing. this is by no mean the end of that software, it's been abandoned, by the source is still open, and maybe in another 50 years, this worthless abandoned source might become useful because of the change in our society.
In the corporate world its huge huge huge. Without encrypted VPN none of the engineers would be able to do any work from home. Too much IP exposed to the world, as well as protecting the corporate network form hostiles!
Note that IPSec is doing a lot more than your ebay example, it allows you to connect two networks together at the IP level. When I VPN into work from home, my computer is actually inside the corporate network, past all the firewalls and security measure. I might as well be sitting at my desk at work...
After futzing for the better part of an afternoon trying to get OSX and FreeS/WAN working together, I said "screw it". I downloaded OpenVPN and had it running in literally ten minutes.
Why the heck can't IPSec have a set of "must implement" specs so that there could be a standard default config that works with every single ipsec vpn?
Plus, it all runs in userspace, and it works on every single operating system ever, can be port forwarded, natted, mangled in just about every which-way and still works.
What a pleasure to use. Try it. You'll like it.
Wider available of the SSL based VPNs including a OpenSource implementation might be the cause.
Consensus is good, but informed dictatorship is better
And 2.1.0rc1 was released a few minutes ago. Need to update website again
Ken
If you're in a hurry, check out PoPToP or PPTPClient (both accessible on sourceforge.net). While not as sophisticated or robust, both actually compile correctly without spraining anything, have good checklists, easy dependencies to work from, and also interoperate with MS-Windows VPN tools to get your Windows users into a more managed and managable VPN environment without excruciating personal pain.
ipsec-tools
The idea you mention always reminds me of one of my favourite Free Software companies: Eazel
When they were in business, they wrote Nautilus, and when they died they left Nautilus as a legacy. Bad economics can kill a company - but it can't kill a good piece of free software.
That said, much of my favourite software was written by zealots not companies. (link to other comment on this page, possible scored too low for many people to see.)
Expert in software patents or patent law? Contribute to the ESP wiki!
For those of you who say "freeswan was so hard to configure so kame's better freeswan sucks bla bla" or even "kame sucks freeswan is king because kame tools are hard to understand" I have this to say: IPSEC in general is hard to configure... you've got tons of different parameters, hash algs, enc algs, id's, tunnels, ah, esp bla bla bla and if you don't understand the protocol in general then you have no business saying either is hard to configure because you got lucky with one of them and it just worked and now you're married to it and consider it superior. I have used both kame and freeswan and can say with authority, hacking for weeks at a time on custom patchs for freeswan, that they are both good products. I LIKE freeswan more because of it's overall feel of higher quality for managing large numbers of connections and it's general tollerance of other devices that have slightly broken behaiour. For instance, you can turn off rekeying on a connection and let the other side always initiate keying. That is handy. Now I don't agree with their politics and I really could do without them -- I can't say that I much care. Freeswan, in the spirit of open source allowed others to modify it as they see fit. I DID, others did, it worked. Saying the project was worthless without really looking at what it's existance has done and only looking at the fact that some of the politics were bad is most disturbing. I would hate to hear even one of you say BSD sucks because of some configuration issue you had on 386 bsd back in the day.
/var/log/auth.log is your friend, as is ipsec auto --status | grep connectionname | grep esp (shows active tunnels)... OH one other thing... if you cant figure out what the other side is configured to when it does phase 1 and phase 2 negotiation, ipsec whack --name connectionname --debug-parsing ; tail -f /var/log/auth.log to tell you EVERY SINGLE ipsec parameter the other side sends you.
.. for a plain old ipsec implementation, it's pretty much done so who can blame em!?
And just for the record, tail -f
For those who hated freeswan because error messages sucked, try the above. For those who say it sucked because of politics, welcome to open source!
To me it seems obvious that freeswan will still deployed and maintained -- it's just too good of a thing to let go. Try to think of this as a releasing -- openswan and the rest are not going anywhere. Freeswan's active development is done... since their main goal was OE. Since I didn't want OE, I don't care. It's not like freeswan doesn't support some IPSEC feature or that its behind the times. What else needs to be done? Maintenance I would gather
Considering the responses i've seen here, it's going to be maintained. I'm glad we're in opensource land and I don't HAVE to use kame if I don't want to or have some reason where freeswan is slightly better for my situation.
These websites may be helpful:
. sourceforge.net/
http://www.ipsec-howto.org/
http://ipsec-tools
No argument on the other two, but I really want to know why NFS is better than SMB.
I mean, really. From a personal file-sharing standpoint, NFS is retarded.
"Here, connect to my computer. Have a magic cookie or two. Let's cram a stateless protocol into a state-filled paradigm. While we're at it, I trust your computer has not been compromised, and will do all proper authentication. It's only polite, after all."
NFS sort-of works for a pack of servers operating in a firewalled area of the network, but putting one in the DMZ is suicide. When you want to share files from your workstation to mine, it absolutely fails.
± 29 dB
Well, basically I just followed the directions on these sites:
http://lartc.org/howto/lartc.ipsec.html
http://www.ipsec-howto.org/t1.html
Get yourself a late model 2.4 kernel and follow the directions for 2.6. Everything works the same. If you use Debian 'testing' or 'unstable' the other packages you'll need are ipsec-tools and then racoon (KAME) or isakmpd.
It's actually pretty easy if you just follow the examples.