Road Warrior Setup: OpenVPN

I've finally settled on using a VPN technology, and my choice was OpenVPN.   OpenVPN is an open source, cross platform, SSL-based VPN solution, and thus far, is extremely flexible, NAT friendly, and capable of filling a wide variety of requirements.  Although some may say otherwise, setting it up is much more difficult than other solutions (particularly, PPTP and SSH); however, much of this is simply a learning curve and once you're up and running, it's all self explanatory and very little "magic."  The goal of this post, then, is to document my own efforts so if you're trying to configure or considering OpenVPN for a road warrior scenario, the information here may help you out.

The first thing to understand about OpenVPN is that it can run in one of two ways: bridged or tunneled. 

Running in bridged mode is analogous to taking your machine that is otherwise offline, and plugging it in to a network switch on your network -- albeit, it's done virtually.  When set up correctly, your machine gets an IP address from the same subnet (typically something like 192.168.x.x), and it's wonderfully easy to feel like your connected to (in my case) the home network.  The downside of bridged mode is that configuring this can be a bit tricky depending on the platform, and strictly speaking, it's not as scalable as a tunneled (imagine a large network with everyone on the same subnet -- it would generate a lot of traffic).  For me, this isn't an issue.  In fact, it's a strength -- my network shares work, printers work, and applications that rely on broadcasts work.

A tunneled connection is generally a tad easier to set up, and clients connect in a dedicated subnet.  In essence, think of this like a network behind your network.  Very often, you'll see OpenVPN use 10.8.x.x as the default range (10.x is a private range, along with 192.168.x.).  Speaking of IP addressing, let me offer this tip: consider keeping your private networks on infrequently used address ranges.  Why?  Virtually every home router is in the 192.168.0.x or 192.168.1.x range.  If you are attached to another private network, and it's using the same range, it's possible to have routing conflicts.   One of the big disadvantages to a tunneled connection is that accessing resources on your home LAN may require some special considerations around DNS/WINS, depending on your configuration, and if you're relying on broadcasts, you're going to struggle.

In either case, in additional to installing OpenVPN, we'll leverage RRAS (routing and remote access) on the server side to handle routing and, if necessary, NAT.  There's also a little bit of a "bug" either in OpenVPN, RRAS, or some combination thereof, that causes RRAS to go down and stop working.  Although we'd still be able to connect, packets won't get routed anywhere.  So far, I've only noticed this problem on tunneled connections, and the fix is to simply restart RRAS.  Since tunneling requires NAT, I believe this is somehow related to the TAP driver or RRAS' ability to NAT the two interfaces (TAP for VPN, and presumably the NIC for internet).

To get started, we'll download and install the latest release from the OpenVPN site.  I highly recommend one of the latest releases -- it includes the core application as well as the Windows GUI.  As of this writing, the latest release is 2.1 RC4, released in April, 2007.  If you're running Vista x64, you must use this version!  Vista x64 requires digitally signed drivers, and this has been done in this version.  (This was done in x64 as a way to provide accountability to software/hardware OEMs, so faults can always be traced back to the vendor.  The end result is greater reliability.)

Generate the Certificates, Keys, and CA

OpenVPN comes packaged with a number of helper applications and we'll use those to generate the RSA keys and certificates needed for both the server and clients.  The full instructions for doing this is on the OpenVPN site, but I'll paraphrase them here with the raw commands.  On the server, open a command prompt in the "c:\program files\openvpn\easy-rsa\" folder:

> init-config

This will set up the parameters file and OpenSSL configuration file.  Edit the vars.bat to set the default values, such as Country, Province, City, and E-Mail parameters.  This will make generating certificates later easier.  Next:

> vars
> clean-all
> build-ca

Use something like "[servername]-CA" for the Common Name when prompted.  With the Certificate Authority in place, we can build the server key:

> build-key-server server

Here, enter the server name or other logical name for the Common Name when prompted.  Sign and certify the certificates when prompted.  Now build client certs and keys, generally one for each client, using a unique Common Name for each certificate...

> build-key client1
> build-key client2
...

Now generate the Diffie-Hellman parameters:

> build-dh

At this point, any client files (the .crt and .key files) need to be copied to the client machines.  If you're setting this up on your home LAN, you can just copy them any way you'd like, however, copying the .key files should always be done over a secure channel.  While you can place certificates and keys in any folder, I put them in the OpenVPN's config folder for simplicity.  My config files below assume that -- you'll need to alter this if you copy the keys elsewhere.

Now we need to configure our home router to forward port 1194 UDP (by default) to our server.   Configuring port forwarding is pretty straight forward -- consult the firmware vendor's instructions for setting this up, however, it's typically done via the administration web interface.

The next step is to configure OpenVPN.  In doing so, we need to decide if we'd like to use bridged or tunneled mode, as explained above.  The configuration files, as well as RRAS setup, will be different for each.  In addition, we'll change some DNS settings on our router if we're using tunneled mode.

Before we dive into configuration options, there's one final consideration.  Do you want *all* network traffic routed through the VPN, or just traffic intended for the VPN?   Consider this:  you're working in a coffee shop, and VPN into your home network.  You do this so you can have access to your file shares, but otherwise, browsing the internet and what not shouldn't go across the VPN as it's slow and resource intensive.  In this case, you only want traffic destined for the private network directed across the VPN.

Alternatively, suppose you connect to a network and for paranoia or uber-privacy concerns, you'd like all traffic to go through the VPN, including internet-bound traffic.  You don't care about the perf hit in this instance, you're more concerned about preserving your privacy.

This is specified through the "redirect-gateway" option, and we'll configure two separate config files for each situation.  Although this can be specified by the server using the "push" command, I want this option client-side, giving me the option to do connect how I'd like.

Setting up OpenVPN in Bridged Mode

The first thing we need to do is bridge the two ethernet connections -- one is the physical LAN, likely named "Local Area Connection," the other is the OpenVPN TAP driver.  In Windows Server 2003, this is very easy to do.  Simply highlight both interfaces on the Network Connections screen, and select 'Bridge Connections':



Tip:  It's recommended that you use statically assigned IP addresses (I use Static DHCP, actually).  The caveat here is that when bridging the two network connections, you will ultimately have only a single, virtual connection.   If you were using DHCP (even static DHCP), the MAC address on the virtual interface is different, and your server will get a different IP address as a result.  If you're doing this remotely, you may lose connectivity unless you are using static assignments.

On the server, open RRAS from the Control Panel > Administrative Tools menu.   Right click on the computer and select, "Configure this machine ...".   Select Custom Configuration when the following screen opens up:



And select LAN Routing:



Viola, that's it for Windows!  Windows has bridged the two connections and RRAS will handle the LAN routing as needed.

Now, let's configure the OpenVPN settings.  On the server, place (or edit) a file named server.ovpn in the OpenVPN config folder.  Your config file should look something like this, edited as necessary (note that pound (#) and semicolons (;) are used to indicate comments):

# server.ovpn bridge #

#address, port, and protocol
local 192.168.73.2   ; EDIT THIS LINE
port 1194
proto udp

#needed for bridge mode
dev tap

ca ca.crt
cert mycert.crt   ; EDIT THIS LINE
key mykey.key  ; EDIT THIS LINE
dh dh1024.pem

; EDIT THIS LINE BELOW
server-bridge 192.168.73.2 255.255.255.0 192.168.73.190 192.168.73.199

# enable compression
comp-lzo

# status file showing current connections
status openvpn-status.log

# logging options
log         openvpn.log
verb 3

You'll need to change the IP address, and certificate and key names.  The server-bridge command configures OpenVPN for the bridge, and will assign an IP address in the 192.168.73.190 to 192.168.73.199 range.

On the client, I'm going to create two .ovpn files -- one with the "full gateway" option I discussed above, and one without.  I'll paste the "Full Gateway" configuration below.  We'll just copy this to another config, which I'll just call "VPN Tap", and comment out the two last lines:

# fullgateway.ovpn #

remote myservername.com 1194 ; EDIT THIS LINE

client
proto udp
dev tap

ca ca.crt        ; EDIT THIS LINE
cert client.crt  ; EDIT THIS LINE
key client.key ; EDIT THIS LINE

resolv-retry infinite
nobind
persist-key
persist-tun

comp-lzo
verb 3

; REDIRECTS ALL TRAFFIC ACROSS VPN 
; COMMENT OUT THESE TWO LINES IF THIS IS NOT DESIRED
redirect-gateway def1
dhcp-option DNS 192.168.73.1 ; EDIT THIS LINE

Notice that if we're specifying the redirect-gateway option, we need to always use the home LAN's DNS server.  This is typically the address of your home router.

We should now have two configuration files, the second one has the bottom two lines removed or commented out.

If the OpenVPN GUI is not running, launch it now.  On Vista with UAC enabled, it must be run with administrator privileges.  This can be done by right-clicking the GUI exe and selecting "Run as administrator..." or by changing the properties on the file to always prompt for elevation.

With the GUI running, you can simply right-click the icon, and see the two configurations in the popup menu, allowing you to connect to your home network. 

Setting up OpenVPN in Tunneled Mode

To set up the network in tunneled mode, follow these steps.  First, we'll set up RRAS to do NAT.   In RRAS, right click the computer name, and select Configure RRAS.  Select NAT from the following screen:



On the next screen, select the network interface that has access to the internet, typically the "Local Area Connection" interface:



That's about all we need to do for RRAS.  If the connection persists but there's no network access, it may be necessary to stop and restart RRAS.

In the server.ovpn configuration file, we'll make a few changes from the configuration above:

# server.ovpn tunnel #

local 192.168.73.3
port 1194
proto udp

dev tun

ca ca.crt
cert home.crt
key home.key  
dh dh1024.pem

server 10.8.0.0 255.255.255.0

comp-lzo
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
verb 3

The key difference with this configuration is 'dev tun' command, used for specifying a tunnel connection, and the server command instead of the server-bridge command.  We'll be issuing clients a 10.8.0.x address, instead of the LAN using a 192.168.73.x address.

# tunnel.ovpn #

remote myservername.com 1194 ; EDIT THIS LINE

client
proto udp
dev tun

ca ca.crt        ; EDIT THIS LINE
cert client.crt  ; EDIT THIS LINE
key client.key ; EDIT THIS LINE

resolv-retry infinite
nobind
persist-key
persist-tun

comp-lzo
verb 3

; REDIRECTS ALL TRAFFIC ACROSS VPN 
; COMMENT OUT THESE TWO LINES IF THIS IS NOT DESIRED
redirect-gateway def1
dhcp-option DNS 192.168.73.1 ; EDIT THIS LINE

Notice the only change in the client configuration is the "dev tun" command.  The redirect-gateway command works the same in the above example -- if you'd like, you can make two configurations.  (The def1 parameter, by the way, specifies that the default gateway setting is only temporary, so when you disconnect from the VPN, the previous gateway is reassigned.)  When clients connect, instead of getting an IP address in the same subnet, they'll be reassigned an address in the 10.8.0.x address range.

We're not out of the woods yet!  You may notice that while connected through the tunnel you can ping machines on your home network by IP address, but you probably can't by computer name (NetBIOS or DNS).  This may be troublesome for applications and shares that don't use the fully-qualified name to resolve the name.  To solve this, we need to make sure our machines have a FQDN (fully qualified domain name).   The situation gets a tad more complicated if you use WINS, but that's beyond the scope of this article.

So, if I have a machine named Poseidon, and I have a DNS or DDNS name for my home router called myhomenetwork.mydomain.com, the FQDN for that machine is poseidon.myhome.mydomain.com.   While this setup is typical in most corporations, it's often not done on home LANs.

In the router web administration, if you don't have one already, we can specify a DNS suffix to be passed out to each machine.  It still requires clients use the FQDN when accessing resources, but it's a lot better than remembering IP addresses.

To do this within Tomato, we can simply add our home domain to the configuration page:



If we did this right, the machines will have the domain applied when they renew their IP addresses, and you can verify this by typing ipconfig /all from a command prompt:



Ultimately, we'll be able to resolve names across the VPN, however, we need to provide the FQDN:



There's one more tiny (and optional) thing.  If we want machines on the home LAN to be able to connect to VPN-based machines, we need to do some additional routing.  This is because machines on the home LAN have no idea how to get "in touch with" machines on the 10.8.x.x address.  We can do this by adding a static route the the router, redirecting traffic back to the OpenVPN server.  Otherwise, the router will just route this data over the internet and ultimately time out.  Having said this, you'd be better off using bridged mode if you need this two-way connectivity.

So, there you go.  Three posts, three ways to connect securely to your home network!  I'll be playing around with setting up a similar connection with Windows 2008, and I'll
post information on that once completed.

Comments (3) -

Stan
Stan
4/22/2008 12:48:13 AM #

Hi- Just wanted to extend my thanks to the author for writing such an excellent How-to document to allow me to setup OpenVPN in Bridging mode. It works flawlessly. Thank you!

Anonymous
Anonymous
6/29/2008 1:30:22 AM #

Hello,

I would like to know if you can just enable routing only with OpenVPN to bridge the traffic from the Virtual network to your private network.

Thanks,

Mike

Brian
Brian
6/29/2008 2:30:31 PM #

Hi Mike -- Not exactly sure -- since VPN clients would be assigned a range, I suppose you could put a routing rule in place that would accomplish that, but I haven't tried it.

Comments are closed

My Apps

Dark Skies Astrophotography Journal Vol 1 Explore The Moon
Mars Explorer Moons of Jupiter Messier Object Explorer
Brew Finder Earthquake Explorer Venus Explorer  

My Worldmap

Month List