Novell-SUSE Sponsors Openswan 132
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!"
Somewhat off-topic (Score:5, Informative)
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.
Nice project but documentation is lacking... (Score:5, Informative)
Re:Can someone explain this? (Score:3, Informative)
IPsec is basically authentication/encryption for packets at the IP level.
Re:Can someone explain this? (Score:5, Informative)
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.
Comment removed (Score:5, Informative)
Re:Nice project but documentation is lacking... (Score:3, Informative)
Re:and ? (Score:5, Informative)
Re:and ? (Score:5, Informative)
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!)
patents hurt openswan (Score:3, Informative)
Re:Novell fumbled the ball - again and again... (Score:3, Informative)
Re:patents hurt openswan (Score:1, Informative)
Openswan supports IPCOMP compression. It should interoperate with many IPsec implementations, if they support IPCOMP.
Re:Novell fumbled the ball - again and again... (Score:5, Informative)
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.
Re:Novell fumbled the ball - again and again... (Score:3, Informative)
IPX on large networks (Score:5, Informative)
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.
Re:Why? (Score:5, Informative)
(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).
Re:Can someone explain this? (Score:3, Informative)
"A Virtual Private Network [wikipedia.org], or VPN, is a private communications network [wikipedia.org] 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 [wikipedia.org] tunneling [wikipedia.org] 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 [wikipedia.org] (IP security), an obligatory part of IPv6.
* PPTP [wikipedia.org] (point-to-point tunneling protocol), developed by Microsoft.
* L2F (Layer 2 Forwarding), developed by Cisco.
* L2TP [wikipedia.org] (Layer 2 Tunnelling Protocol), including work by both Microsoft and Cisco.
Multi-protocol label switching [wikipedia.org] can be used to build VPNs."
Re:Nice project but documentation is lacking... (Score:5, Informative)
I was the maintainer of Super FreeS/WAN, and am now the release manager of Openswan.
We're currently working on a whole new set of documentation, in DocBook/XML format to boot. It's slow, since we all know how much developers love to write documentation, but it's coming. For now, you can see The Wiki [openswan.org] which will probably get slashdotted.
Ken
Nativew IPsec Embedded in the Kernel (Score:3, Informative)
IP Encryption vs. TCP Encryption (Score:5, Informative)
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.
Re:SUSE (Score:2, Informative)
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...)
OpenVPN is an excellent alternative to IPSec... (Score:2, Informative)
Novell-Suse-... should sponsor this excellent project instead of the brain damaged(tm) IPSec.
Re:Nativew IPsec Embedded in the Kernel (Score:4, Informative)
2.6 has an IPsec kernel layer implementation. There are two part to IPsec - the kernel layer, and the key management (IKE) portion. The IKE daemons are userland, and without them, you don't have a complete IPsec implementation.
Thus, they have ported isakmpd/racoon to Linux, or you can run Openswan's userland tool (aka pluto).
Re:OpenVPN is an excellent alternative to IPSec... (Score:3, Informative)
Re:and ? (Score:3, Informative)
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.
Re:Why not Strongswan? (Score:2, Informative)