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
Well, "Openswan is an implementation of IPsec for Linux."
IPsec is basically authentication/encryption for packets at the IP level.
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!)
Openswan is a good example of a patent hurting an Open Source app. I *need* LZS compression for my company's VPN, but Openswan won't work cuz of IPCP LZS compression. I was offered an internal version of super-freeswan with the LZS code but refuse to use it cuz it's not Free. i'm stupid that way
If thou see a fair woman pay court to her, for thus thou wilt obtain love
Again, you're mixing up your history. Sure Novell was slow to adopt TCP/IP but that's because IPX/SPX was always routable. Microsoft held onto NetBEUI (ptooie!) for far longer and still won the war. Sure Microsoft competitors made some mis-steps, but no more so than Microsoft. Unfortunately they didn't have an endless supply of cash to help them recover.
Ok fine after mocking you mercilessly I will explain why you are such a funny guy.
;-)
1. Microsoft was only involved in OS/2 up until version 1.3
2. OS/2 was widely criticized because it did not have built-in networking. So Microsoft certainly didn't introduce TCP/IP in the 80's with OS/2.
3. The first version of OS/2 with built-in networking was OS/2 WARP, which was after OS/2 2.1. This was many years after the IBM/Microsoft rift.
So.... yeah. This is what any decent research will tell you. Rebuttals are welcome, I'm kind of enjoying teaching a new generation about how the 80's played out.
Sorry but you are falling into "retard" status. LAN Manager was based on NetBIOS and NetBEUI was the transport protocol. Neither were routable, and had nothing to do with TCP/IP. In fact, LAN Manager was licensed technology to begin with! Sure, you could run TCP/IP under LANMAN, but you could also run IPX/SPX. This doesn't mean Microsoft "went" TCP/IP any more so than they "went" IPX/SPX. Your memory of the time is passable at best and totally flawed at worst.
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
A complete VPN solution is more than just an IPsec module (Kame) or an IKE module (Racoon). So it's not a question of Openswan vs. 2.6 kernel IPsec. Openswan moves up the stack with added functionality and intends to continue doing so. And it can use either the FreeS/WAN IPsec engine (which is being carried forward for use on pre-Linux 2.6 machines) *or* the 2.6 kernel IPsec (Kame).
(Btw, the 2.6 kernel hasn't exactly been official "for some time now" -- even SuSE is just now shipping it in their 9.1 release.)
In fact, with Novell now involved in Openswan (which means IBM is likely involved as well but less publicly), we will probably see Openswan work with IPsec hardware too (IBM makes some).
"A Virtual Private Network, or VPN, is a private communications network usually used within a company, or by several different companies or organisations, communicating over a public network. VPN message traffic is carried on public networking infrastructure (ie, the Internet) using standard (possibly unsecure) protocols.
VPNs use cryptographic tunneling protocols to provide the necessary confidentiality (preventing snooping), sender authentication (preventing identity spoofing), and message integrity (preventing message alteration) to achieve the privacy intended. When properly chosen, implemented, and used, such techniques can indeed provide secure communications over unsecure networks.
Note that such choice, implementation, and use are not trivial and there are many unsecure VPN schemes on the market. Users are cautioned to investigate products they propose to use very carefully. 'VPN' is a label which, by itself, provides little except a marketing tag.
VPN technologies may also be used to enhance security as a 'security overlay' within dedicated networking infrastructures.
VPN protocols include:
* IPSec (IP security), an obligatory part of IPv6.
* PPTP (point-to-point tunneling protocol), developed by Microsoft.
* L2F (Layer 2 Forwarding), developed by Cisco.
* L2TP (Layer 2 Tunnelling Protocol), including work by both Microsoft and Cisco.
Multi-protocol label switching can be used to build VPNs."
___
internet, productivity blog
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
Slight correction: redhat 7.0 shipped with a snapshot towards gcc-3.0 they called gcc-2.96. It is true that this compiler version miscompiled the kernel, but it is also true that they provided a gcc version that was the recommended compiler for the kernel at that time. (they called it kgcc).
It is also true hat "gcc-2.96" did not have the quality of a proper gcc release. However, this step proved very valuable for gcc 3.0 development, because of the huge user base acting as testers. Of course, 99 percent of redhat users would never have bothered to install a development snapshot of gcc. (and the rest would not have used in a production environment...)
sig intentionally left blank
OpenVPN (http://openvpn.sf.net/) is an excellent alternative to IPSec. It's using UDP or TCP as transport layer and doesn't care about NAT. You can have NAT on the both sides. The client and server share the same code and can be used on WIN32 or GNU/Linux (and more). The version 2.0 can handle routing per X.509 certificate... and much more.
Novell-Suse-... should sponsor this excellent project instead of the brain damaged(tm) IPSec.
Granted, IPSEC can be a pain to configure.
However, if you are implementing a VPN between Linux and a device such as a Cisco PIX, you can't use OpenVPN.
The fact of the matter is - Openswan implements an industry standard VPN implementation, OpenVPN does not.
Not that it is a cause for great concern, but OpenVPN connections are also vulnerable to connection cutting (see the many, many recent stories about TCP/IP connection cutting DoS attacks), IPSEC is not.
Maybe because strongswan is a class project with no QA. Easy to get enhancements in when you don't need to bother testing them...