Slashdot Mirror
Novell-SUSE Sponsors Openswan
hsjones writes "Concerned about the demise of FreeS/WAN? Well, looks like Openswan is going to be a good, strong open source IPsec project going forward. Novell and SUSE have jumped in with Astaro to back the project and move it along. See the press release. The Openswan project is at http://www.openswan.org. SUSE Linux and Astaro Security Linux both use FreeS/WAN in their current releases. It will be very interesting to watch what they do now with Openswan!"
Building on its contributions to the open source community and commitment to interoperability
As one of many people who vividly remembers the success of NetWare 3.x, the current situation seems very alien. Novell virtually died when the fact of the matter is their product was by far the best. Today they have good products, yet they really can't claim an enormous technological edge. Their second coming is, instead, based on commitment to a thriving community, and feeds off anti-Microsoft sentiment. If best-of-breed products didn't work, will this perhaps be the strategy that finally works for them? I don't know, but I certainly wouldn't complain to see Novell take back a sizeable bite of the business that was stolen from them.
Even since FreeS/WAN gave up on changing the world to Opportunistic Encryption (not my favorite idea, but I suppose if I feel too strongly I can write my own damn implementation :) ), I've been looking into alternatives, and obviously OpenS/WAN is the first choice. A frustration I had when looking into it was that I couldn't find any documentation describing the differences between the two projects. I didn't do any diffs on the documentations, but from a brief perusal it looks pretty much like the FreeS/WAN docs. Does anyone out there have a list of specific differences between the projects - other than the included patches for things like x.509 NAT traversal, etc that are also included in Super FreeS/WAN (I'm kind of assuming that there are more changes)?
Help save the critically endangered Blue Iguana
What's more, unlike other Linux-based solutions, I don't think there have ever been any serious questions raised over its security.
Free/OpenSWAN also interoperates with a wide variety of commercial (soft and hard) VPNs. Authentication can be by RSA secrets or X509 certificates.
The real "Libtards" are the Libertarians!
IPSEC, of which FreeSWAN is one implementation, doesn't require that you set up a point-to-point tunnel like VPN's do. It encrypts any traffic between any machines that implement it.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Help save the critically endangered Blue Iguana
The *SWANs are IPsec. OpenVPN is not. IPsec is cross platform and cross-vendor (hang on, before you get excited, let me finish) and is a (series of) RFCs. IPsec also gets you plenty of perks such as kernel-space (fast, secure, etc).
Now for the "reply" trigger-happy, OpenVPN does do SSL/TLS, is all in user-space, and does neat things, yes. However, with the *SWANs, you can also get x509, nat-t, dpd, foo, and bar. And yes, OpenVPN is cross-platform.
The problem lies in not being cross-vendor. And you also have to realize that there is a very large inter-web out there and not everyone uses the same platforms and vendors, etc.
For example, as a security engineer, I often have to build VPNs between disparate vendors, devices, and software versions. Even with IPsec/IKE it's difficult enough. And they've all pretty much agreed on how to speak IKE well enough to at least have a meet-and-greet among each other. Unfortunately, there is plenty of room for interpretation, so each vendor has a slightly different dialect.
The point being, OpenVPN isn't a "standards-based VPN" whereas an IKE-based VPN is. I know it's not necessarily a great answer to the question, but it is the truth. (Besides, OpenVPN even says so on their site...it does not do IKE.)
(whoa, poet and didn't know it)
(woops, i did it again!)
There has been a working and tested IPSec implementation from Kame Project in the vanilla Linux kernel for some time now. Why go with a competing and conflicting IPSec implementation that was once formed because the official Linus tree lacked the support. Diversity is a richness etc. on but in this case I feel like these efforts seem fruitless. But big companies such as Novell don't do things because they just can so maybe there's something I don't quite get. I'd love to be englightened, though.
Novell got complacent, made some dumb moves (eg, buying WordPerfect) and hit some real competition when Microsoft started muscling in on their traditional turf. Whilst the competition was coming right at it, Novell just looked on, doe-eyed.
A littany of bad management decisions is why they are where they are today. Maybe Novell can regain some of its lost market share but you'll have to wait a very long time if you want to see it regain market dominance.
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
However, with the *SWANs, you can also get x509, nat-t, dpd, foo, and bar.
x509 is certs right ? OpenVPN can do em. nat-t ? OpenVPN doesnt need that kludge. It uses one port that can be redirected through multiple Nats if need be. Dead peer detection ? OpenVPN is self healing. Link goes down, comes back up and OpenVPN reconnects.
Now before I get too carried away, I dont know shit about vpn, but SWAN looks like a bitch (based on my IPCop machine) and OpenVPN is very easy.
I'm so very pleased by this news. My biggest concern from Novell's acquistion of SuSE and Ximian was whether or not they would continue to support Free Software. With other major Linux vendors (well, vendor) seemingly moving more and more toward closing their software, and locking users into their products, it's refreshing to see Novell opening more software up and supporting community projects.
We've seen it now with their support of OpenSWAN, the open-sourcing of YaST and iFolder, and the continuing free releases of SuSE 9.1.
As I said, I'm very pleased to see this, and I suspect we'll see even more support of the open source and free software community from the reborn phoenix that is Novell.
"Adventure? Excitement? A Jedi craves not these things."
But the real performance killer on lots of networks was all the chatty SAP announcements - even on a medium-sized network, all the printers advertising themselves can clog up any useful bandwidth, which often meant 56kbps back when this sort of networking was common for users like banks, retail stores, and branch offices of big companies. Yes, we learned how to do SAP filtering, and eventually Novell came out with NLSP which helped a lot.
The more important problems were pricing - upgrading to Netware 5 which could use TCP/IP instead of IPX tended to cost too much for the types of companies that were big Netware users back in mumblety-95, so they stayed with IPX way past its prime, around the time that Microsoft was figuring out how to make NetBIOS-over-IP perform badly over long distances (as opposed to NetBIOS-over-NETBEUI.) While Microsoft _still_ doesn't have a clue about decent networking, they were good enough to beat Netware in the market, and small networks of either Netware or NetBEUI could both be self-configuring, a lesson we're trying to relearn for IPv6.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The real difference is that IPSEC is encrypting at the IP layer of the protocol stack, aka Layer 3 in OSI terms, while OpenVPN is creating a TCP Layer 4 tunnel. Inside the tunnel, IPSEC normally puts Layer 3 IP packets, while OpenVPN does something with a TUN/TAP driver on the ends, so they could be doing Layer 3 IP packets or Layer 2 Ethernet packets, and I haven't read the docs enough to know which they did. Layer 4 has more overhead, but has a potentially easier time going through NAT.
For both of these applications, you have to create an association between two endpoints, and then tell your endpoints' packet handlers to use that association when they want to get packets somewhere. The choice of protocol layers for the inside and outside of the crypto tunnel has a major impact on how you get the routing mechanisms (or whatever) to decide to set up a tunnel and send packets through it.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks