Meet OpenVPN
December 15th, 2004 by Hans-Cees Speel in
If your company has people on the road, such as sales or technical people, a VPN is a good method for letting them access data on the company network. Many different VPN solutions can be bought, but many are free. Here, I discuss only solutions you can set up without buying a commercial VPN product.
The main VPN solution used for more complex tasks is IPsec; some people use PPTP. Although PPTP is usable, security flaws have occurred in its past, and it simply does not match up to IPsec.
IPsec in tunnel mode would be a much better solution, were it not for the crippled Windows-client implementation: Windows XP/2000 clients can't use IPsec in tunnel mode without using L2TP. There is nothing wrong with L2TP security-wise, but it increases latency--through the need for both PPP and L2TP processes--and increases packet-overhead, slowing down connections. Open-source servers have not had much experience with L2TP yet, so using open source for it is problematic at this time.
A disadvantage of plain IPsec is its notorious complexity: many, many things can and do go wrong. To the rescue, then, comes OpenVPN, a full-blown open-source VPN solution based on SSL. OpenVPN offers the same functionality as IPsec in tunnel mode; you can tunnel entire networks through it. In this article, I focus on using OpenVPN as a road warrior's VPN solution.
Every VPN approach has its list of pros and cons. The pros of OpenVPN are:
Same functionality as IPsec in tunnel mode: you can tunnel entire networks (IP tunnel or bridging tunnel).
A Windows XP/2000 install.exe file with a GUI is available for starting the tunnel. The config files are text based.
The OpenVPN server can push routes, DNS server IP addresses and other configuration details to the clients. This makes OpenVPN well suited for road-warrior setups, because you can modify the setup without touching far-away laptops.
You can use a bridging or routing setup.
The server/client code is the same: the config determines the role.
SSL is as solidly proven as security protocols get, using RSA public key cryptography if you want. See this paper for more information on its security setup.
OpenVPN costs you nothing in terms of money--a server, an Internet connection and know-how is all you need).
Plenty of man pageand HOWTOs are available to get you going.
All encryption processes are handled in userland, meaning it is easy to install--much less complicated than IPsec.
The list of cons includes:
The setup uses TUN/TAP devices. This can make things complicated to figure out when things go wrong. If Microsoft changes its code, it also might just break.
The OpenVPN process is executed in userland and, thus, is relatively slow. TUN/TAP devices combine together with a userland-process to create a setup in which traffic has to cross userland/kernel borders relatively often. This setup might create rather high latency on connections.
A packet overhead is present because IP/Ethernet is encapsulated in SSL and SSL in UDP/TCP.
The latest version OpenVPN is beta; earlier versions have further drawbacks.
Who can you call when things go wrong? Some companies want to pay to get support.
Considering these arguments, OpenVPN should be a serious option if you are setting up a VPN. The days when only money could get you a decent VPN definitely are over.
The rest of this article is a guide to setting up a road-warrior scenario using routing, not bridging, with TUN devices. Its aim is to make sure laptops on the Internet can connect safely to companies' networks, using internal servers and data.
The basic HOWTO I drew on when writing this article can be found here. It is a HOWTO for setting up OpenVPN in bridging mode on a Linux SME-server. My setup is slightly different, because I do not use a bridging setup. Another good source is the OpenVPN HOWTO.
The Security Setup
Anyone setting up a VPN without considering the different kinds of security risks one faces is a fool. Therefore, you should start any VPN setup doing exactly that--considering security.
Connection Security
OpenVPN traffic flowing over the Internet is protected by TLS. The setup here uses public key exchange; computer authentication is done by RSA-based public/private key-pairs (public keys also are called certificates). In this setup we make our own root certificate; that is, for our VPN scheme, we are our own Verisign, so to speak. We are the root of the Web of trust here. We make a server key pair and multiple client-key pairs. We sign those with our own root certificate. This setup is this basic cryptography design of OpenVPN.
The SSL/TLS connection is set up up with those keys. After authentication is done, Diffie-Hellmann encryption is used to exchange keys to set up the connection. New keys are negotiated every hour using perfect forward secrecy, or PFS--the next key used is not derived by using the former key. By default, the connection uses 128-bit Blowfish in Cipher Block Chaining mode, with SHA1 message digests.
Server Security
The OpenVPN server itself, of course, could be attacked. You can minimize that risk by:
Using shared keys with the tls-auth option before public key exchange occurs. Doing so keeps people from exploiting the SSL setup, should this be possible.
Setting options user nobody and group nobody. This makes sure the server does not run as root. You also can use a chroot-jail.
Using a separate box in a DMZ. This way a successful hack is slowed down by the firewall protecting the internal network from the DMZ. Strange connects can be noticed in the firewall logging.
By using iptables firewall rules on the OpenVPN server that prevent traffic from tunnel hosts entering the server, as well as all traffic from the Internet except for the need UDP traffic.
Authentication of Users
The security setup of your client laptops is critical. If your road warriors are using laptops and can access your company's network, your data may become public in the future. No matter how good the SSL crypto, this is a separate risk. If a laptop can connect through an OpenVPN tunnel directly into your networks, you have a problem. To avoid this, you need to establish authentication of the user to the laptop or to the SSL keys.
Many ways exist to do this authentication. You can password-protect the SSL keys of the client, which is recommended. But if workers have the habit of writing down passwords near their laptops, password protection is not sufficient. An option is to get USB-based iKeys with a pincode that holds the client keys. Pincodes are easier to remember, so the need to write them down is smaller. Of course, the iKey should be carried on a keychain and not with the laptop itself. You should establish an AUP (acceptable user policy) to make sure all users understand this. Doing so may prevent a stolen laptop from becoming a disaster. In addition, you might use encrypted filesystems on laptops.
Another option is to set up your own custom authentication scheme. For instance, you can use strong authentication with hardware tokens, coupled with a Kerberos server. OpenVPN has the script hooks to do that. You also can use the server password file.
Network Setup
The network setup my configuration files is aiming for is this:
The OpenVPN server at 65.66.45.x.
The client is somewhere on the Internet.
The client/server P2P network is 192.168.100.0/24 or, rather, a /32 network in that network.
The company-network behind the OpenVPN server is 172.16.1.0/24.
So, the internal mailserver of this company might be at 172.16.1.3, the DC at 172.16.1.5 and the fileserver at 172.16.1.6. Schematically, this setup looks like this:
CLIENT -> [modem/adsl-router] -> Internet <-UDP-> OpenVPNserver CLIENT - TUNInterFace <=tunnel=> TUNInterFace ==> Internal network CLIENT - 192.168.100.6 <=======> 192.168.100.5 <==> 172.16.1.0
I am using a Linux SME-server, which basically is a Red Hat system stripped down to what a file/printer/firewall/e-mail server needs, with a Perl/HTTP-based config panel. After being a problematic open-source project for a while, Linux SME-server is being developed further by Lycoris. I have used Linux SME-server for years and will migrate only if forced to--it is extremely easy to use.
Installing OpenVPN is easy to do. On the Linux server side, you must install one or two RPMs. On SME these RPMs are lzo.xxx.rpm and openvpn-2.0_beta17-1.i386.rpm. Most systems already include lzo. Your kernel should include TUN devices, most kernels do. If you run openvpn from /usr/sbin/openvpn, you should find a TUN device. With the settings we are going to use, it has a P2P connection.
The config file on my box is saved at /etc/openvpn/server.conf, but yours may be stored somewhere else. My server configuration file looks like the output shown below; see the man page to see what all the items reference. they mean):
###OpenVPN server config routing TUN setup######## port 1194 dev tun tls-server mode server dh dh1024.pem ca ca.crt cert SERVER.crt key SERVER.key duplicate-cn ifconfig 192.168.100.1 192.168.100.2 ifconfig-pool 192.168.100.5 192.168.100.200 # IP range clients mtu-test tun-mtu 1500 tun-mtu-extra 32 mssfix 1450 #keep tunnel open by ping push "ping 10" push "ping-restart 60" ping 10 ping-restart 120 #route to be established on the server route-up "route delete -net 192.168.100.0/24" route-up "route add -net 192.168.100.0/24 tun0" #route to push to clients push "route 172.16.1.0 255.255.255.0" #route to company network push "dhcp-option DOMAIN hansceess.net" #push the DNS domain suffix push "dhcp-option DNS 172.16.1.7" #push DNS entries to client push "route 192.168.100.1" # add route to protected network comp-lzo status-version 2 status openvpn-status.log verb 5 ####################### end server config ##############
On the Windows client side, you should download the Windows installer and run it. The normal installer is available on the OpenVPN Web site, while and the GUI version can be found here. I recommend using the latter: it gives you a tray-icon with which you can start the OpenVPN service. In the Network connections window under Settings, you should find a tap win32 adapter. You also should see that adapter in your routing table when you type route print in a DOSBox.
After the setup has installed everything, you should adjust the config settings in D:/Program Files/OpenVPN/config/*.ovpn to those you want. You might want to tune your personal firewall as well, if it sees the interface at all--mine didn't. My adjusted settings file looks like this:
####################client.ovpn###### port 1194 #udp by default dev tun ##remote is the openvpn-server remote 65.66.45.x tls-client ca ca.crt cert CLIENT.crt key CLIENT.key mtu-test tun-mtu 1500 tun-mtu-extra 32 mssfix 1450 pull #ip-win32 ipapi|manual|dynamic|netsh (see man page, use #when ip address on interface does not appear, but dhcp server #is visible in ipconfig /all) #ip-win32 ipapi comp-lzo verb 4 ##############################end########
The OpenVPN process on the client is a Windows service you can start with a script or with the GUI, if you want. The TAP device (in tun-modus) can be tcpdumped, as can any interface, which makes it nice when troubleshooting. The rest of the configuration comes from the server.
You can make keys for OpenVPN in the same way as you would make them for OpenSSL. But for those who like comfort, OpenVPN has an easy RSA set of scripts to help you out. You first must edit some variables in the vars file for the keys: names for server/clients keys, your company name, e-mail and so on. Next, run ./build-ca to build your root private key. Then, run ./build-key server to build the server key pair. Build the client key(s) with ./build-key client. In this client step, you can add a passphrase in the keys for key-authentication, as discussed above. Finally, you must run ./build-dh to generate the Diffie-Hellmann .pem file that the server needs. This file holds a large prime number and another parameter (see this article for details). Using these numbers, the server can generate new keys quickly, which it does every hour by default for standing connections.
You also need to copy the server keys, root certificate and *.pem file to /openvpn. The client needs the client keys and the root certificate. These should be transported over a secure medium, such as winscp.
There is one thing left to do: get the firewall iptables rules on the server. The rules I added were:
# internet interface eth1 let OpenVPN udp port in
/sbin/iptables --append INPUT -p udp --dport 1194 -m state --state NEW -i eth1 -j ACCEPT
#block anything into the server from tun interface
/sbin/iptables --append INPUT -i tun0 -j DROP
#tun0 debugging
#/sbin/iptables --append INPUT -i tun0 -j LOG --log-prefix tun0-input
#/sbin/iptables --append OUTPUT -o tun0 -j LOG --log-prefix tun0-output
#/sbin/iptables --append FORWARD -i tun0 -j LOG --log-prefix Forward-ComingFrom-Tunnel
#/sbin/iptables --append FORWARD -o tun0 -j LOG --log-prefix Forward-OutTo-Tunnel
#OpenVPN Forward chain: if you have a Tun-device, the forward chain
#screens traffic from networks/hosts outside the tunnel, going to
#internal networks and back. we want this traffic to go through,
#default but first we might want to block some things: remember, the
#other side of the tunnel is not safe by default: he could be routing
#so we should log syns at least coming in
/sbin/iptables --append FORWARD -i tun0 -m state --state NEW --jump LOG --log-prefix Tunnel_into_intranet
#you should know the networks allowed in and out through the tunnel
#let client network in.
/sbin/iptables --append FORWARD -i tun0 --source 192.168.0.0/16 -j ACCEPT
#let company network out
/sbin/iptables --append FORWARD -o tun0 --source 172.16.0.0/16
-j ACCEPT
##troubleshoot: let all through
# /sbin/iptables --append FORWARD -i tun0 -j ACCEPT
# /sbin/iptables --append FORWARD -o tun0 -j ACCEPT
#you might want to allow some, but not all
# /sbin/iptables --append FORWARD -i tun0 -p tcp --dport 25 -j ACCEPT
##drop the rest
/sbin/iptables --append FORWARD -i tun0 -j DROP
/sbin/iptables --append FORWARD -o tun+ -j DROP
Once you have installed OpenVPN, it is time to test it. Make sure the server process is started with service openvpn [re]start. You should see the TUN device with ifconfig. With my config, it shows:
Link: encap:Point-to-Point Protocol Inet addr:192.168.100.1 P-t-P 192.168.100.2.
Now, start up the client OpenVPN service. A file found at D:/Program Files/Openvpn/*.log contains debugging information. With the verb setting, you can elaborate the logging. When you start the client service, the icon in your tray shouts it is connected. Ipconfig /all in a DOSBox shows an IP address on the tap interface, for instance, 192.168.100.10
Ethernet adapter Local Area Connection 8: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : TAP-Win32 Adapter V8 Physical Address. . . . . . . . . : 00-FF-CF-10-9F-A6 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.100.10 Subnet Mask . . . . . . . . . . . : 255.255.255.252 Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 192.168.100.5
print route gives you some routes:
192.168.100.1 255.255.255.255 192.168.100.9 4 1 192.168.100.8 255.255.255.252 192.168.100.10 4 1 192.168.100.10 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.100.255 255.255.255.255 192.168.100.10 4
Although this all may look quite odd, it works. You now can ping 192.168.100.1; if that succeeds the tunnel is okay. On the server you can see the pings coming in with tcpdump -nlpi tun0. Also, tail -f /var/log/messages supplies some information.
The routes on the server look something like this (netstat -rn) kernel IP routing table:
Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.100.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 65.66.45.2 0.0.0.0 255.255.255.0 U 0 0 0 eth1 172.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 65.66.45.1 0.0.0.0 UG 0 0 0 eth1
If all goes well, your connection should be there. If not, check the server routing table and tcpdump the TUN interfaces. You also can use the iptables debug rules.
In this article I have shown a simple setup for a OpenVPN. In real life, the setup will not be much more complex. Although the security implications of any VPN should be well thought-out, setting up OpenVPN turned out to be rather easy. If you do get into trouble, plenty of helping hands can be found on the mailing lists.
OpenVPN is a serious VPN product. It can contend with IPsec in many ways. It certainly is cheap--try buying a Cisco concentrator--easy to install and, in the open-source tradition, tinkerable.
If OpenVPN has a disadvantage, it might be latency. However, no real-life data exists yet to back up that claim.
Special Magazine Offer -- Free Gift with Subscription
Receive a free digital copy of Linux Journal's System Administration Special Edition as well as instant online access to current and past issues. CLICK HERE for offer
Linux Journal: delivering readers the advice and inspiration they need to get the most out of their Linux systems since 1994.
Subscribe now!
The Latest
Newsletter
Tech Tip Videos
- Nov-04-09
- Oct-29-09
- Oct-26-09
Recently Popular
From the Magazine
December 2009, #188
If last month's Infrastrucuture issue was too "big" for you then try on this month's Embedded issue. Find out how to use Player for programming mobile robots, build a humidity controller for your root cellar, find out how to reduce the boot time of your embedded system, and if you're new to embedded systems find out the basics that go into one. You can also read about the Beagle Board, the Mesh Potato and a spate of other interestingly named items. And along with our regular columns don't miss our new monthly column: Economy Size Geek.
Delicious
Digg
StumbleUpon
Reddit
Facebook








NeoRouter - the zero-config VPN solution
On January 22nd, 2009 Anonymous (not verified) says:
I found a better VPN solution - NeoRouter (www.neorouter.com). It's much simpler to setup than OpenVPN and does better job than OpenVPN. It can create unlimited nodes in a virtual network and it uses P2P technology as well. It support not only Linux, Window, but also router firmwares like OpenWrt and Tomato.
Highly suggest GUI version of OpenVPN
On February 16th, 2008 Anonymous (not verified) says:
I love OpenVPN, with my VPN provider http://www.strongvpn.com they offered it to me since the regular VPN account they sold me the port was blocked. I installed the non GUI version of OpenVPN and I didn't like the way it would disconnect when I closed the window. The lastest GUI window one is sweet, and makes it easy to reconnect. I went to Openvpn.net and made a donation, please help the developers improve it!
I think anonymous vpn, i
On February 14th, 2008 anonymous vpn (not verified) says:
I think anonymous vpn, i mean pptp vpn, is simply for regular user then openvpn setup for anonymous surfing.
This article doesn't
On July 27th, 2007 smartcgi (not verified) says:
This article doesn't describe one problem. Sometimes DHCP is disabled on PC and OpenVPN fails to get IP.
You'll see "Requesting IP address" running constantly on this OpenVPN connection.
Solution was taken from http://av5.com/docs/running_openvpn_client_on_windows_xp.html and shown below:
open "Control Panel / Administrative Tools / Services", make sure that the "DHCP Client Service" is started.
This is Linux Journal
On April 15th, 2006 Anonymous (not verified) says:
This is Linux Journal, there's no mention of a linux side GUI client or how to set this up on a Linux client side.
Do you expect me to read something and then use a command line?
Linux GUI
On November 6th, 2006 Anonymous (not verified) says:
haha right. its about setting up a server, reinstall windows and go home to mommy.
openvpn ikey
On February 14th, 2005 D. rodic (not verified) says:
How do i setup an OpenVPN connection using smartcard (ikey) features?
Openvpn as a way to secure domain logins over internet
On December 22nd, 2004 Anonymous (not verified) says:
I'm interested in openvpn as a service on a win2k/xp client machine. I would like the vpn to connect before/during the user trying to login to a windows domain account while traveling(their domain login's are not cached).
Is this a capability of openvpn ? Any resouces you can point me at ?
Thanks
Yes, There are many sources
On March 4th, 2009 Hank Freid (not verified) says:
Yes, There are many sources from where you can use this openvpn, also many certifications available for this at TestKing and VCP-310.
the howto mentioned above: h
On December 23rd, 2004 Anonymous (not verified) says:
the howto mentioned above:
http://sme.swerts-knudsen.dk/index.html?frame=http%3A//sme.swerts-knudsen.dk/howtos/howto_30.htm
does something like that. But I am not sure what you mean exactly. The vpn is a service under windows.
Cool Article
On December 19th, 2004 Freak (not verified) says:
Thanks for a cool article!
Discussion about OpenVPN @ OpenVPN-Forum.de
Web layout
On December 16th, 2004 Anonymous (not verified) says:
On my browser and monitor (Firefox, all defaults) the first line of this story is 141 characters.
People read text best at a width of 40-60 characters.
Even if you don't have to horizontal scroll, this layout is ridiculously hard to read.
The article was excellent - w
On December 22nd, 2004 Anonymous (not verified) says:
The article was excellent - why don't you chill with your comment on web settings?
Wow! What's this business
On December 31st, 2004 Anonymous (not verified) says:
Wow!
What's this business with "why don't you chill with your comment on web settings?"?
Are you referring to the comments about line width? Man, that kind of stuff needs to be fixed--it's just a royal pain trying to read articles like that.
For RoadWarrior there's a goo
On December 16th, 2004 Anonymous (not verified) says:
For RoadWarrior there's a good option you put in clients. It's the
redirect-gateway option.
# man openvpn
...
--redirect-gateway
Automatically execute routing commands to cause all outgoing
IP traffic to be redirected over the VPN. Currently imple-
mented only on Linux and Windows.
This option performs three steps:
(1) Create a static route for the --remote address which for-
wards to the pre-existing default gateway. This is done so
that (3) will not create a routing loop.
(2) Delete the default gateway route.
(3) Set the new default gateway to be the VPN endpoint address
(derived either from --route-gateway or the second parameter
to --ifconfig when --dev tun is specified).
When the tunnel is torn down, all of the above steps are re-
versed so that the original default route is restored.
...
How well does this scale for multiple road-warriors?
On December 16th, 2004 SwedishChef (not verified) says:
Thanks for your excellent article. It's always a pleasure to see something that is well documented and complete. However, I have a question about scaling clients that wasn't covered in the article.
I have implemented openVPN for a local organization that has offices in other nearby towns. Each office has access to bandwidth; one via DSL and the other via FTTH (fiber-to-the-home). I configured two separate openVPN servers on the home office router because I couldn't see - from the documentation - whether one openVPN server can monitor two ports; and two separate connections. So I built one server to watch port 5000 and another to watch port 5001 and used shared keys. The other end of both networks is another Linux box that is an openVPN client routing the entire complement of machines in to the home office. Interestingly enough, both client machines are behind a NAT router yet both connect to the VPN well. The openVPN server is the router/firewall (Shorewall) at the central office. Routing to the Internet is accomplished through a separate firewall in both cases.
So I guess my main question is: "How would two (or more) road warriors access your VPN?" I notice that you have a range of IP addresses in the server config file. Does this work for multiple remote clients?
I might add that I have also configured open-VPN in bridging mode for a client who had an IPX network running across a T-1 routed by two Livingston routers. This was all implemented on an old Novel 3x system that the client was reluctant to change but the $700-per-month T-1 costs were killing him. He had a FTTH connection at his main office and connected a DSL connection to his remote office. I installed two Linux boxes running openVPN in bridging mode; one client on the DSL and the one server at the other end on the fiber. The latency was incredible! IPX apparently broadcasts so much packet traffic that the DSL link was buried under it. However, even when we implemented a TCP Novell system as a test, the DSL was not capable of handling the traffic (although DSL in that same town does handle the SMB traffic of the network I described earlier). We ended up using a wireless connection to a location in the remote town that did have FTTH and then simply creating a VLAN to route traffic back to the home office. So the availability of bandwidth for some protocols is critical.
OpenVPN 2.0, which is in beta
On December 16th, 2004 Anonymous (not verified) says:
OpenVPN 2.0, which is in beta does not require a separate port for each connection such as the 1.x branch did. The article above is specific to 2.0 and only requires port 1194 for multiple remote connections.
Thanks for such a well-writte
On December 15th, 2004 Anonymous (not verified) says:
Thanks for such a well-written article!
One problem though: in the server config file, you have two route-up lines. The route-up lines are not stackable, i.e. the second will wipe out the first. Why not just use the "route" option?
In my setup a wring route app
On December 17th, 2004 hanscees (not verified) says:
In my setup a wring route appeared automagically. The first line deltes that.
vpen in ubuntu festy 7.04
On June 3rd, 2007 krax (not verified) says:
hello masters
great deaads have encountered to set a vpn connection to INERNET with UBUNTU desktop ver 7.04 festy but any result was out-come.
plz help me t set up this vpn on debian base genome UBUNTU festy 7.04
Email me at kraxadmin[@]gmail.com
waiting with possible awaite
bon rester
thatnks
Post new comment