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.
I'm sure some corp will pick up the project... I know a lot of people use it.. so i dont really see any reason for it to die
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.
This is rather bad news for the not insignificant FreeS/WAN install base out there. The company I worked for last year, for instance, poured a significant quantity of time and money into a corporate VPN based on FreeS/WAN, and even bundled it into products. They don't have the resources or experience to support FreeS/WAN in house themselves, so they'll be in for an intersting ride if problems are discovered. AFAIK, they were hoping not to have to upgrade to Linux 2.6 for at least a year, but that may have to change now. Who all out there is getting left in the lurch by this?
As I understand it, they wanted to use opptunistic encryption to do the "common man" encryption of the 5% of the internet. Has this actually become standard yet? If so, it's only been within the last couple of years I think (since I've stopped dealing with VPN).
Also, aren't there other problems inherant with OE? IE: the need to have secure DNS before this can really happen, or a PKI infrastructure or public key escrow or something? I'd love to just install freeswan on my firewall and have encrypted connections happen, but a) would it really help things and b) would it be like being the first one on the block to have a videophone?
It's not triple-DES, but it's double-rot-13. Sounds safe enough.
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.
It is a shame and a loss that the community will have lost such a valubale resource. It's new versions will be missed sorely. A noble goal indeed.
Keep the faith, share the code
Just to bad, as I'm still trying to get the thing to work, and been trying for some time now,
I guess I will never find the support or help now, I just feel bad for the guys in Vietnam that
Now will get all data traffic looked at I'm still looking for some help to get it to work.
I just hate bit SPAM, (www.netnoise.com.kh)
You mean my talk sessions through ssh aren't secure any more?!?
/me puts on his tin foil hat.
MOUNT TAPE U1439 ON B3, NO RING
Too Funny. I almost shot coffee out my nose.
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.
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
My project for 1996 was to secure 5% of the Internet traffic against passive wiretapping. It didn't happen in 1996, so I'm still working on it in 1999! If we get 5% in 1999 or 2000, we can secure 20% the next year, against both active and passive attacks; and 80% the following year. Soon the whole Internet will be private and secure. The project is called S/WAN or S/Wan or Swan for Secure Wide Area Network; since it's free software, we call it FreeS/WAN to distinguish it from various commercial implementations. RSA came up with the term "S/WAN". Our main web site is at http://www.freeswan.org. Want to help? The idea is to deploy PC-based boxes that will sit between your local area network and the Internet (near your firewall or router) which opportunistically encrypt your Internet packets. Whenever you talk to a machine (like a Web site) that doesn't support encryption, your traffic goes out "in the clear" as usual. Whenever you connect to a machine that does support this kind of encryption, this box automatically encrypts all your packets, and decrypts the ones that come in. In effect, each packet gets put into an "envelope" on one side of the net, and removed from the envelope when it reaches its destination. This works for all kinds of Internet traffic, including Web access, Telnet, FTP, email, IRC, Usenet, etc. The encryption boxes are standard PC's that use freely available Linux software that you can download over the Internet, or install from a cheap CDROM. This wasn't just my idea; lots of people have been working on it for years. The encryption protocols for these boxes are called IPSEC (IP Security). They have been developed by the IP Security Working Group of the Internet Engineering Task Force, and will be a standard part of the next major version of the Internet protocols (IPv6). For today's (IP version 4) Internet, they are an option. The Internet Architecture Board and Internet Engineering Steering Group have taken a strong stand that the Internet should use powerful encryption to provide security and privacy. I think these protocols are the best chance to do that, because they can be deployed very easily, without changing your hardware or software or retraining your users. They offer the best security we know how to build, using the Triple-DES, RSA, and Diffie-Hellman algorithms. This "opportunistic encryption box" offers the "fax effect". As each person installs one for their own use, it becomes more valuable for their neighbors to install one too, because there's one more person to use it with. The software automatically notices each newly installed box, and doesn't require a network administrator to reconfigure it. Instead of "virtual private networks" we have a "REAL private network"; we add privacy to the real network instead of layering a manually-maintained virtual network on top of an insecure Internet. programmers working all over the world and coordinating over the Internet. Linux is distributed under the GNU Public License, which gives everyone the right to copy it, improve it, give it to their friends, sell it commercially, or do just about anything else with it, without paying anyone for the privilege. Organizations that want to secure their network will be able to put two Ethernet cards into an IBM PC, install Linux on it from a $30 CDROM or by downloading it over the net, and plug it in between their Ethernet and their Internet link or firewall. That's all they'll have to do to encrypt their Internet traffic everywhere outside their own local area network. Travelers will be able to run Linux on their laptops, to secure their connection back to their home network (and to everywhere else that they connect to, such as customer sites). Anyone who runs Linux on a standalone PC will also be able to secure their network connections, without changing their application software or how they operate their computer from day to day. There are already numerous commercially available hardware and software products that use the IPSEC technology. The FreeS/WAN team regularly participates in intero
GENERATION O98346: The first time you see this, copy it into your sig and remove a random number from the generation. T
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
It seems that FreeS/WAN's goals of opportunistic encryption were in opposition to the complexity that their implementation required (DNS changes, etc.)
PGP.net (oh, where have you gone) provided opportunistic encryption with no infrastructure requirements other than the two machines communicating use the PGP.net software.
Controlling the two endpoints seems a lot easier than trying to control them plus the DNS servers to exchange info.
Anyone know what happened to PGP.net?
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.
i don't think i'm alone in not getting that one.
What's wrong with implementing OpenVPN- the SSL approach? I suppose it may be difficult for some companies to upgrade . . . but if they require it, and it is a viable alternative- why not?
Would it really be that difficult for somebody to take over the development? Maybe their role could be more to administer the operation rather than code a lot of it.
Also, this (google's cache) or the PDF version of the above claims that FreeS/WAN does not support PKI.
...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
No I'm not trolling I'm asking a question here. Outside of admins, how many people really care whether their connection is secure or not. I always reference this out regarding IPSec and the likes, so I'll point out eBay as an example. Now a company such as eBay in my opinion should have SSL based log on by default, period. It's optional. Why? Because most users outside of the geekrealm, and system admin realm don't understand the escape key from their space bar. So when it comes to things like... "Will you accept this certificate?" and the likes, they don't know, and they certainly don't care. Same goes for VPN's. Why should the people care if Freeswan "was not making much progress with its political goals of encrypting a significant portion of all Internet communications" when the typical user doesn't know about Freeswan, and more than likely wouldn't care.
MoFscker
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.
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.
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.
Actually, zealotry had little or nothing to do with Hurds non-progression. Remember that Hurd was the first big GNU package that RMS did *not* work on. If zealotry was a problem, GCC, Emacs, GDB, and many of the GNU command line utils would have failed long ago. (GNU Libc was mostly Richard-less, but he did have a hand in it.)
The failure of the Hurd was a bad gamble. Possibly encouraged by the fact that they had written almost an entire operating system (using tried-and-true designs), the GNU projecteers decided to try a latest-and-greatest (fad) design for the GNU kernel - it didn't work out as it was meant to, but luckily Linus had worked on this same project from the conventional angle, so we still ended up with a completely free software OS.
Please help publicise swpat.org - the software patents wiki
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 run an ISP and was not aware of this product, and now it's more or less gone.
:(
I would have used and backed this to teh hilt had I known.
Karma: Chameleon (mostly due to the fact that you come and go).
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
I've spent so many weekends playing with connecting FreeS/WAN to my OpenBSD router. Every time I'd end up with some insanely cryptic error message (on both ends, openbsd isn't much better). This weekend I downloaded KAME for the 2.6 kernel, and had it working within half an hour, including the time to recompile my kernel.
FreeS/WAN is an unfortunate example of a project too focused on a far out goal (OE) to make the simple foundations work.
This is just one more example how wrongheaded it is to place politics at the forefront of a project, instead of technical achievements.
Most people don't give a flying fuck what political goals your project has. Only the code, and the software matter. All else is gravy.
You can add this to the graveyard of noble goals brought down by zealotry.
I find this particular outlook sad and disturbing, especially when that outlook is probably more than a little true. It's the nature of the human animal to push boulders up hills, and then become resigned, cynical, and despairing when the effort seems to be overshadowed by the results (or lack thereof.) It's also part of the human animal that a room full of us passionately engaged (or for that matter enraged), will just as likely pull in twenty different directions as a single useful or meaningful one. That said, we can be certain that nothing lasting or important will ever get done if we can't put our own egos, and personal agendas aside for the greater good.
In any project that seems to be as much social engineering as software generation, the two arms must be separate, distinct, and managed tightly by a group of wise men that can be trusted to steer that project. The code heads must be safe, and cozy, whacking away at the bits, while the political engineers are busy spreading memes and building coalition in legistative circles. All the while, cool heads, men and women selected for their integrity and sanity, must guide and nuture the process with patience and forebearance.
Protecting the security, and anonymity of people, is an important endeavor. It deserves bringing to bear, people with moral distinction and the skills needed to manage the long haul, because we live in a world that doesn't do the logical thing, and this will certainly be a long haul. I hope that the software finds a new home, and people with the fortitude to take it to it's logical conclusion. As well, I hope that OSS projects like this can begin to create operational structures that insure the realization of their goals, even in the face of great political/social resistance, and internal conflict. In the end, being a part of an OSS project is ultimately about making a contribution to the human condition... when it becomes something else, projects fail and we all lose.
Genda
"A business man can pull a phone out of his pocket and talk at length to someone halfway around the world. The same man, will sit in a dark room with his wife and childen all evening and never say a word.. clearly something isn't working." -- Dave Cunningham
How many commercial applications are not in that list? I would say quite a large number. Simply because they aren't big names doesn't mean that they are not proprietary. That same goes with open source; many open source projects are quite successful, but not all are. However, it is quite easy to pick up the pieces when an OSS projects is abandoned than when a proprietary project is abandoned.
And start coding! If you don't have the skills, donate to someone who is willing to code. Just because the project is ending doesn't mean you can't use the software any more! And, just because the project is ending doesn't mean others cannot develop it!
Then we can throw freeswan/superfreeswan/openswan in the trash.
sorry.
Not if they go out of business, change business models, or decide that a particular product is no longer profitable.
In all of these cases, if you depended on access to and updates for their software, you would be SOL.
No kidding, I've been waiting forever for an upgrade to my BeOS install.
Oh Well.
Wider available of the SSL based VPNs including a OpenSource implementation might be the cause.
Consensus is good, but informed dictatorship is better
And I can say that it the most obtuse, cryptic product I have ever had to wrestle with.
There was absolutely no way that 'normal' users were ever going to be able to make use of this product for the 'opportunistic encryption' the project aimed for, I honestly don't think you could design a more opaque and confusing piece of software if you were actually trying.
That being said, once you get over the configuration hurdles and realise you will have to employ script-based kludges to do simple things e.g. get it to route packets though multiple tunnels terminating on the same local IP address, it mostly works quite well.
I gots ta ding a ding dang my dang a long ling long
> Hurd was the first big GNU package that RMS did *not* work
> on. If zealotry was a problem, GCC, Emacs, GDB, and many of
> the GNU command line utils would have failed long ago
But did Richards zealotry make the other projects work, or did his programming prowess make them work in spite of his zealotry?
Either way, that's a pretty weird observation
Expert in software patents or patent law? Contribute to the ESP wiki!
FreeSWAN is friggin impossible to configure. So no wonder nobody wants to use it...
Oh well, what the hell...
The KAME guys got it right... they support only the BSDs :-P
Which userland tools do you use to maintain the IPSec configuration and network interfaces?
No, I did not read the f***ing article!
I tried to set up OE. In fact, I did have it working, sort of. The problem is that a box running OE presently needs to use another machine as it's nameserver (or at least, use another machine's nameserver in preference to a local process). There was talk of fixing this through a port 53 passthrough, but I don't think this ever happened.
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.
However, I hope that Ken Bantoff will be successful with Openswan. My company uses FreeS/WAN for a VPN solution to provide secure WAN access between international sites.
I suspect the SSL-based alternatives may have problems with the tcp-over-tcp problem is the link is not good.
The real "Libtards" are the Libertarians!
... 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.
what exactly is frees/wan?
I spoke to the maintainer at OLS and he mentioned that some work with the native IPSec was in the works and some other neat functionality (to be merged into 2.6+ eventually [?]) Check out The Other FreeSWAN (fork)
Everyone wants a Tux in their life.
I guess you could say this was its freeSWAN song...
Long time ago there was an awsome program called ecco pro. This program was always highly rated by magazines and users and had a devoted following. Netmanage bought this program from the original company (arabasque) and shortly thereafter shelved it for mysterious reasons (many people suspected MS foul play).
That was a very long time ago and today there is still a vibrant community of ecco users who swear up and down that no other product even comes close. They beg Netmanage to sell the code to them or to open up the source code but Netmanage just ignores their requests. Oddly enough Netmanage does let people download the binary.
To me what netmanage is doing is just cruel. They are not making money off of it, they don't support it and yet they refuse to sell it or open it up. Why did they buy this program for so much money just to mothball it?
Companies are like that. They sometimes suck.
The best way to support the US war effort is to continue buying American products.
OE, or oppertunistic encryption, which is a good thing, in the sense of
providing seamless ipsec without configuration, depends on having control of
your reverse dns. A lot of ISPs won't allow you to change or won't change for
you the reverse, as this is often encoded with useful info for the ISP, such as
node id, and geographic location. This has had as big an effect at slowing
down the spread of it as anything else. Some are cool, and I am actually very
disappointed cause I recommended it to a friend of mine, and even tho I know
it'll be useful for more time to come, I am planning on installing it on all my
boxes, (I have control of the reverse for my lan, if not for my dsl ip, which I
will inquire about).
SealBeater
-- Its survival of the fittest...and we got the fucking guns!!!
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.
Security is directly related to the skill of the admin implementing it. The skill of an admin is directly related to how well that admin understands that tool. Not necessaraly the actual protocols and server bits that make it work, but at least its configuration. My point in experiementing was not to get a single link up, but to eventualy use it for securing WiFi users. Per customer config? No way. The config should be:
RADIUS server: x.x.x.x
RADIUS shared secret: xxxxxx
IP Range: x.x.x.x-x.x.x.x
I don't understand why it can't be that simple. Even if I was prepared to invest a few days in getting it working, it would be all but impossible to actualy USE it, getting normal people to also invest a few days in learning it. Thus, me spending a few days learning it would have been useless as it would never be used.
Their documentation is some of the worst I have ever seen for a project of its size. left/right; WTF? client/server.
It is unclear to me the distinction beteween freeswan.org, freeswan.ca, and superfreeswan, and what (if any) downside there is to using the only usefull one, superfreeswan. While there were hundreds to choose from, no prebuilt RPMs for my kernel version, and the srpm I happend to find via google produced a kernel module that had symbol mismatches.
This is like passwords. If you force people to choose long passwords with weird characters in them, they WILL write them down. The solution, if your realy concerned with password-level security, is to change to something else. Biometrics; smart cards, whatever. If security is too hard to use, people will circumvent it. Freeswan is just too fucking hard to use, so I won't use it at all.
Why is it corporations kill products so you have to buy their news ones?
Open Source projects get killed since the main developers/supporters seem to get bored (as most nerds tend to do) without serious motivation (cash).
It seems open source these days has so much competition with itself that things get abandoned too easily.
Competition is supposed to be good. But when for profit software competition has none and free software ( beer and speech ) is competing with itself people lose out.
A simple example is me trying to choose Gnome or KDE... ugh! Really! The winner would be nice... if someone would tell me who it will be please. Sounds ignorant, but honestly... am I alone on this?
I struggled briefly with FreeS/WAN before getting a flawless working setup between my home net and the PIX at my office. It's exceedingly easy to configure, once you "get it". Never have been able to make it play with a Contivity though.
If anyone takes over development, I will definitely be testing each new version, at least as it pertains to my setup.
I like music
Opportunistic Encryption does it mostly correctly, but not in a way that's very practical, because most people don't have control of their reverse DNS space and will therefore never deploy it. Also virtual hosting means that a given IP address can have lots of domain names behind it, and therefore potentially lots of different keys.
One alternative, "Open Secret", is to use a default preshared key that everybody knows, e.g. "Open Secret", so if you don't have anything better to use, you can still encrypt your conversations even though you're susceptible to Man-In-The-Middle attacks. The FreeSWAN crowd viewed that as too risky to bother adopting, even though it would have led to much better security for most users.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
IPSec is decidedly peer-to-peer. With IPSec, there simply is no client and no server. If you had actually read and understood the documentation, you would have much less trouble seeing that shared secrets won't get you anywhere and that most of the complexities in IPSec are fundamental to the security of the system. Ignorance in security matters isn't luxury, it's foolish.
No, it doesn't. 2.6 IPsec has all sorts of problems with MTU, and 2.4 with 2.6 backport doesn't even understand it's own behaviour. You'll end up with situations like this:
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
The 2.6 native IPsec does have some MTU issues as well, but I haven't had time to research them well enough. However, from what I've seen, I think that having a 2.6 machine routing between two tunnels will most likely give you a headache, as larger IP fragments will not come through and 2.6 doesn't cut them to adjust to the new 1442 MTU. Besides, the 2.6 IPsec implementation doesn't handle IPsec in combination with iptables too well as there's no well defined way the packets travel through the tables. Encryption is handled somewhere between OUTPUT and POSTROUTING, which, for example, eliminates the possibility to use NAT. IPsec 2.6 works, but only in theory, so to say.
my other sig is a 500 page novel
A Webmin module
Try here. A FreeS/WAN webmin module is standard in the latest release of Webmin. Unfortunately, it does little to unobfuscate FreeS/WAN. I have been looking into FS for the last couple of weeks and was planning on implementing it this weekend at a client's office. Now, I will look at alternatives - lord knows they can't be any more complicated to configure that FS.
RedHat on the other hand preferred to distribute CIPE (which turns out to be insecure)instead of FreeS/WAN, so you had to compile your own kernel or use binary modules from the FreeS/WAN site. Unfortunately these binary RPMs only contain the X.509 patch and no extra features like SuperFreeS/WAN.
I believe Debian required some compiling too.
-------
Warning: Slashdot may contain traces of nuts.
I tried for years (since mid 90's) to try to generate an interest in my email client, Emailmax. I tried many different ways of "selling" it but my main arguement for Emailmax was it's security--the ability to encrypt email etc... My experiences has led me to believe that encryption just doesnt denote positive reactions in the general public.
I would get many responses but I think it could be summed up with: I dont need encryption I got nothing to hide.
I think this a big problem. The general public has drawn the conclusion that only criminals need encryption to hide malicious behaviors. They believe that internet is safe enough without it and that governments would never "spy" on them.
Some of you who have tried to use my product may say my product suffered from product quality. I would agree, as that was big challenge. But, much of the feedback I got was from people that never ever tried my product....
WEP is known to be insecure.
It's why I just disabled it on my OpenBSD gateway that is also the wifi access point, and I'm using IPsec instead.
It works beautifully with a laptop running Linux (thanks, Freeswan), with the same laptop running Windows (thanks, Windows XP) and with another laptop running MacOS X (thanks, Racoon).
IPsec is a defacto standard. It's a bit complicated to set up (especially with different implementations), but implementations are interoperable, that's very nice.
{{.sig}}
The reason acceptance is realtively minimal is, quite simply, FreeSWAN is a bitch to set up and get working properly.
The configuration is complex, the initial knowledge required to do it is high, and the documentation explaining how FreeSWAN works is negligible - at best. If the documentation had been enough to shake a stick at, then maybe - maybe - we'd have seen significant adoption of it. But it's not.
Too bad I don't have more time. I've been meaning to tackle FreeSWAN and write up some useable documentation for it, too.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
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.
I screwed up. PGPnet was the software I was thinking of, not PGP.net, the website.
Anyway, I can't hardly find any info on it anymore...I used it back in the day...
http://www.macintouch.com/pgpnet.html
The ALSA guy recently incorporated new drivers for the Vortex2-based soundcards. They work well and are completely open source. They even support the hardware mixing and 3D sound matrix operations.
And, if that's not enough, you can buy new cards which are clones of the AU series using the same chips.
SSH is vulnerable to it also, but it takes the approach of recording a key the first time it connects to a destination and then complaining loudly if the key changes. You could adapt that to the "Open Secret" model if you wanted, though IPSEC doesn't usually have a user interface that you can use to get the user's attention.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
take it, FreeS/WAN.
i've suffered under your boot, and KAME is way better than you. Fuck off, politically biased software.
i had a sig, once..