I’ve been trying to get ipsec to work correctly as a basic VPN between two CentOS 5 systems. I set up the ipsec devices according to the IPSEC section of the RHEL4 security guide [1] (which is the latest documentation available and it seems that nothing has changed since). The documentation is quite good, but getting IPSEC working is really difficult. One thing I really don’t like about IPSEC is the way that it doesn’t have a device, I prefer to have my VPN have it’s own device so that I can easily run tcpdump on the encrypted or the unencrypted stream (or two separate tcpdump sessions) if that’s necessary to discover the cause of the problem).
I’ve got IPSEC basically working, and I probably could get it working fully, but it doesn’t seem worth the effort.
While fighting with IPSEC at the more complex site (multiple offices which each have multiple networks, and switching paths to route around unreliable networks) I set up an IPSEC installation at a very simple site (two offices within 200 meters both with static public IP addresses, no dynamic routing or anything else complex). The simple site STILL doesn’t work as well as desired, one issue that still concerns me is the arbitrary MTU sizes in some routing gear which (for some reason I haven’t diagnosed yet) lose packets if I have an MTU over 1470 bytes.
So today I set up a test network with OpenVPN [2]. It was remarkably simple, the server config file (/etc/openvpn/server.conf) is as follows:
dev tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key
comp-lzo
This means that the IP address 10.8.0.1 will be used for the “server” end of the tunnel, and 10.8.0.2 is the “client” end. The secret is stored in /etc/openvpn/static.key (which is the same on both machines and is generated by “openvpn --genkey --secret static.key“).
The client config file (/etc/openvpn/client.conf) is as follows:
remote 10.5.0.2
dev tun
ifconfig 10.8.0.2 10.8.0.1
secret static.key
comp-lzo
Then I enable IP forwarding on both VPN machines, open UDP port 1194 (the command “lokkit -q -p 1194:udp” does this) and start the daemon on each end. The script /etc/init.d/openvpn (in Dag Wieers package for CentOS 5 – which I believe is the standard script) will just take every file matching /etc/openvpn/*.conf as a service to start.
The end result is a point to point link that I can easily route other packets to, I can easily get dynamic routing daemons to add routes pointing to it. Nothing like the IPSEC configuration where the config file needs to have the IP address range hard-coded, I can just add routes whenever I want.
This isn’t necessarily going to be the way I deploy it. The documentation notes that a disadvantage is “lack of perfect forward secrecy — key compromise results in total disclosure of previous sessions“. But what gives me confidence is the fact that it was so easy to get it going, if I have problems in adding further features to the configuration it should be easy to debug. As opposed to IPSEC where it’s all complex and if it doesn’t work then it’s all pain.
Also I tested this out with four Xen DomU’s, two running as VPN routers and two as clients on separate segments of the VPN. They were connected with three bridge devices. I’ll blog about how to set this up if there is interest.
You do not have to run daemons on both ends unless you really want both machines to initiate connects with each other (which may break routing, I suppose, if they opt to connect at the same time).
I’ve heard good things about openvpn, but continue to use IPSEC. It an be a pain to setup, but distros like m0n0wall and pfsense make it much easier. I *believe* with pfsense, IPSEC is an interface, you can route through it and create special firewall rules for it.
Use strongswan. It realy easy to set up (even with x509 certificates ;-)). Tested.
I would definitely agree with you. IPSec’s biggest downside, by far, is it’s complexity. A perfect example of ‘design by committee’. Configuring IPSec is complicated (regardless of what platform of IKE daemon you use), and troubleshooting connection problems can be even harder. OpenVPN usually “just works”, and is simple enough that troubleshooting is usually very easy.
At work, we make very heavy use of IPSec (over 300 Linux boxes connected over IPSec), but we’re in the process of migrating to OpenVPN due to it’s simplicity and convenience.
If you plan to use certificate based authentication, and I would recommend it, the easy-rsa scripts included with OpenVPN make it trivial to setup. With no cert experience, you can have it ready to go in about 5 minutes.
Another advantage, in my mind, to having a separate network device for the VPN connection (as in OpenVPN) is the ease of using iptables to add restrictions to that interface.
Konstantin: Are you referring to OpenVPN or IPSEC? OpenVPN is a user-space system, it can’t run without a daemon at each end.
Albert: Thanks for the suggestion, but learning a new OS alone is a reason to make me avoid pfsense – maybe some of the other readers will find it appropriate though. The systems that I’m installing mostly end up not being just firewalls/VPNs, they run mail servers, web servers, and whatever new ideas the clients have so a dedicated firewall device isn’t going to do the job.
http://www.strongswan.org/
yZZuF: The feature list of Strongswan seems quite impressive. I’ll keep that in mind for future use.
Christopher: Those 300 machines, are they 300 IPSEC connections or 300 machines going over a single VPN link? I was under the impression that IPSEC had advantages for the 300 connections case.
As for iptables, I find that difficult at the best of times and don’t need IPSEC to make it harder!
I refer to OpenVPN. The thing is that a daemon (a program that constantly runs in background and listens for *incoming* connections) is needed only on one end and so only on “accepting” box you need to open 1194. The other end just connects (and gets its UDP endpoint created by the system on arbitrary port).
May be I just misread your post, but if I needed to set up OpenVPN *daemon* on each client machine I install OpenVPN on, this would greatly complicate things. So the fact client part runs no different from any other networking client applications (such as web browser) is a real win.
By the way, another thing not mentioned by anyone in this thread is that IPsec has serious complications when it comes to working through NATP-devices. This almost defeats the “roadrunner” usage (when clients connect from their notebooks via crappy links), and with two NATP devices (when both client and server are behind NATP, IPsec just doesn’t work even in theory. Clearly this is not your case, but after dealing with all this stuff, I escaped to OpenVPN and never looked back.
Yeah, IPSEC is a pain if all you want to do is to set up a VPN link. However, it’s important to realize that IPSEC can do a lot more than just VPN stuff; it can do authentication too, and transparant encryption without tunnels as well (so that, say, you can safely use XDMCP or telnet with the knowledge that nobody on the network can sniff your password). But for VPNs, OpenVPN rocks IPSEC’s pants off.
I feel I should also note that OpenVPN has multiple options for authentication. One of the options is to use a CA; the OpenVPN source (and the Debian packages, too) come with example scripts to easily set up a CA. With this option, the loss of the secret key is no problem, since you could just revoke that particular key without loss of the entire VPN.
Oh, right: additionally, an IPSEC VPN tunnel uses its own protocol, whereas OpenVPN uses a “normal” TCP or UDP connection; as a result, setting up an OpenVPN link through a firewall that does NAT is far, far easier than doing the same with IPSEC.
russell, hi,
first thing i did with openvpn was write a program which auto-generated the keys _and_ the client-side configuration file, packed it up into a tarball and return it to you as a CGI response, over HTTPS.
i have connected several people to my vpn, now: it’s a simple matter of wget https://mywebsite/cgi-bin/generate_configuration.tgz?name=fredscomputer
if fredscomputer gets wiped, the configuration can be regenerated – including the correct IP address, because the ip address goes into a little text file, which, i suppose if i really wanted to, could also go into some DNS records as well.
so, as i go round people’s houses, and install linux on it, i offer to join their computer to my VPN so that i can help them out if they get into difficulties, or if they need an upgrade. etc. etc.
lemme know if you’re interested in the program. it also generates rsync secrets and also configures backuppc but i never got round to finishing that bit off.
We’re using IPSec for (approximately) 300 separately connected machines, each over it’s own VPN (though some of them do have additional machines behind them that are also tunneled through).
There are some claimed theoretical advantages with IPSec over OpenVPN with the high number of connections, such as efficiency. It’s often pointed out that IPSec is faster than OpenVPN due to it’s in-kernel implementation. However, we’ve found OpenVPN to be more than up to the task (and OpenVPN’s compression has given us a lot less trouble than in IPSec). Our load testing has shown that a moderate modern box can easily handle a few hundred connections and multi-Mb/sec traffic. It may use a little more CPU than IPSec, but I’d consider easily good enough for all but the most extreme cases. Add in cert based authentication, and the convenient scripts provided with OpenVPN, and OpenVPN is a very viable option.
Then you add in the convenience of single port, over UDP *or* TCP, and OpenVPN starts to pull ahead. Yes, IPSec has NAT-T, but we’ve had a lot of problems with version incompatibilities, if it’s supported at all, with NAT-T, and a number of the boxes in the field are older ones. And, with most of the remote boxes located on customer networks, being able to use a single TCP port has dramatically reduced the number of problems we’ve had with customer firewall (mis-)configurations.
Lastly, we’ve found troubleshooting connection problems to be a lot easier with OpenVPN. The vast majority of the time, it just works. And when it doesn’t, the logs (along with it’s simpler configuration) usually provide enough information to rapidly track down the problem. With IPSec, a lot of our less experienced techs had trouble understanding the complexity of IPSec and the low-level networking.
Luke: I don’t have an immediate need for that, thanks for the offer. I think it would be good if you were to publish it on your own blog though so that other interested people could get it.
I work in a company where the main VPN hub (it is a fail-over cluster of two servers) serves almost 600 IPSec tunnels (we use Strongswan here on 2.4 linux kernel with klips) and about 150 OpenVPN tunnels.
I can say that OpenVPN daemon is very easy to setup and it’s perfect for road-warriors but we’ve noticed that from time to time it is very hard to establish connection when you used GPRS/UMTS/HSDPA link (and it is very hard to diagnose problem). Another advantage of OpenVPN is that you can use it even when you are behind proxy server or restrict firewall (just setup OpenVPN to use port 443/tcp and connection will look like regular SSL connection to secure website).
IPSec is a standard and when you are forced to make VPN between you and for example network equipment made by Cisco or any other vendor you can be sure that IPSec will work and OpenVPN will not.
In the past setting up IPSec in Linux was pain in the ass (patching Linux kernel with klips etc.) but now it is easy (native IPSec stack in linux kernel) – only what you have to do is install IKE daemon (ex. pluto, charon for IKEv2). Lack of separate network interfaces in this case is disadvantage only for the first sight – firewall rules you can based on a source address in FORWARD chain or you can setup policy in IPSec configuration for your connections.
Yes, it was easy to setup, but the ipsec-code was probably tested and audited by multiple people versed with such software. How do you know that openvpn really is as secure? And I’m not just talking about finding buffer overflows, the debian-openssl dsa has shown that checking cryptography code is very difficult indeed.
Wilfred: That is a reasonable point, however the counter point is that code which is simpler and easier to audit has benefits in terms of security.
Wilfred: Another point, going on what Russel said, is that there are many different IPSec implementations, not all of which are open source, and many of which are likely less tested and less securely written than OpenVPN. Some might even say there’s more potential risk with IPSec since it’s implemented in-kernel. Regardless, there’s no apples-to-apples comparison on code quality and security between IPSec and OpenVPN, there’s just too many variables.
You are absolutely correct that cryptography code is very hard, though, as is computer security in general. OpenVPN does a good job of building on top of well known and relatively secure and well reviewed software, such as OpenSSL, and ideas such as TLS certificate based authentication and IPSec (technically there’s no relationship between OpenVPN and IPSec, but go look at the payload data packet format that OpenVPN uses, and then go read the IPSec spec for NAT-T and UDP encapsulated payloads. . . OpenVPN recognizes existing research, and borrows very heavily from it).