OpenVPN Howto

General Guideline to OpenVPN  Linux/Ubuntu  

OpenVPN rocks. It's super easy to install and use. This HOWTO will demonstrate how to configure an OpenVPN server on GNU/Linux in either bridged or routed mode, and will provide working examples for client configurations on GNU/Linux, Mac OSX, and Microsoft Windows.

Server

OpenVPN supports either bridged or routed modes of operation. From the official documentation:

Overall, routing is probably a better choice for most people, as it is more efficient and 
easier to set up (as far as the OpenVPN configuration itself) than bridging. Routing also
provides a greater ability to selectively control access rights on a client-specific basis.

OpenVPN in bridge mode uses the tap virtual device driver; and OpenVPN in routed mode uses the tun virtual device driver.

Regardless of which mode of operation you choose, you will need to dedicate a computer to act as the OpenVPN server. You can run OpenVPN on your firewall if you like (or need), but this is not encouraged. Firewalls should be limited-purpose systems with as little complexity as possible. Running OpenVPN on your firewall complicates the firewall, and presents a possible attack vector for malicious activity. Consider what happens if your firewall host is compromised, and it's running OpenVPN: the attacker gains access to your VPN configuration, and could conceivably construct a man-in-the-middle attack against all your VPN clients.

REPEAT: Please do not run OpenVPN on your firewall unless you bloody well know what you're doing'''

For our examples, this server will live inside the LAN, with an address of 192.168.0.13.

Configure your firewall

Because the OpenVPN server lives inside the LAN, you will need to port-forward (or Destination NAT) the VPN connection. VPN clients will try to connect to your firewall's public IP address, on UDP port 1194, and your firewall will DNAT the connection in to your OpenVPN server.

The specifics of accomplishing this will vary wildly, depending on your firewall.

If you're using the excellent Shorewall firewall, the following entry in /etc/shorewall/rules will work:

# DNAT incoming OpenVPN requests
DNAT net loc:192.168.0.13 udp 1194 - 66.93.81.185

Replace 66.93.81.185 with your firewall's public IP address.

This iptables rule should do the same thing:

iptables -t nat -A PREROUTING -p udp --dport 1194 -d 66.93.81.185 -j DNAT --to-destination 192.168.0.13

Restart your firewall, as needed, to make the changes take effect. (Shorewall users, type shorewall restart)

Bridged Mode

Bridging is necessary if you want to use protocols that rely on broadcast traffic. For example, I use a bridged OpenVPN connection so that I can play Starcraft with a buddy without using battle.net: Starcraft finds LAN games by use of UDP broadcasts. Another use of bridging would be to support browsing for shared folders in a Windows network without need for a WINS server. Bridging makes it easy for clients to connect to LAN resources, because there are (usually) no routing issues involved: the VPN clients are for all intents and purposes on the local LAN.

From the official OpenVPN documentation:

Bridging and routing are functionally very similar, with the major difference being that a routed VPN 
will not pass IP broadcasts while a bridged VPN will.

And this overview, also from the official OpenVPN documentation:

Bridging advantages
* Broadcasts traverse the VPN -- this allows software that depends on LAN broadcasts such as Windows
NetBIOS file sharing and network neighborhood browsing to work.
* No route statements to configure.
* Works with any protocol that can function over ethernet, including IPv4, IPv6, Netware IPX, AppleTalk, etc.
* Relatively easy-to-configure solution for road warriors.

Bridging disadvantages
* Less efficient than routing, and does not scale well.

Bridge Configuration

Next, configure this computer to support ethernet bridging. This may require compiling a custom kernel, enabling the following:

  • BRIDGE
  • BRIDGE_NETFILTER
  • BRIDGE_NF_EBTABLES (if you want ebtables)

If you do recompile, be sure to also select the TUN option, to build the TUN/TAP driver.

Or just try loading the proper kernel modules (bridge.ko on 2.6 kernels).

Configure this server's network configuration to use a bridge as it's primary interface. You do this by bridging the physical ethX and virtual tapX interfaces into one logical br0 interface. The br0 interface will be assigned an IP address, and not the physical or virtual interfaces.

In Debian GNU/Linux, edit /etc/network/interfaces to look something like this:

auto br0
iface br0 inet static
address 192.168.0.13
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
bridge_ports eth0 tap0
pre-up /usr/local/sbin/openvpn --mktun --dev tap0
pre-up ifconfig eth0 0.0.0.0 up
pre-up ifconfig tap0 0.0.0.0 up
pre-up brctl addbr br0
pre-up brctl addif br0 eth0
pre-up brctl addif br0 tap0
post-down ifconfig eth0 0.0.0.0 down
post-down ifconfig tap0 0.0.0.0 down
post-down brctl delif br0 eth0
post-down brctl delif br0 tap0
post-down brctl delbr br0

Red Hat / Fedora users want something like this:

/etc/sysconfig/network-scripts/ifcfg-br0:

DEVICE=br0
TYPE=Bridge
IPADDR=192.168.0.13
NETMASK=255.255.255.0
ONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0
TYPE=ETHER
BRIDGE=br0
ONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-eth1:

DEVICE=tap0
TYPE=ETHER
BRIDGE=br0
ONBOOT=yes

Additional links to bridge examples:

Make sure the bridge interface works:

# /sbin/ifdown eth0
# /etc/init.d/networking stop
# /etc/init.d/networking start
Setting up IP spoofing protection: rp_filter.
Enabling packet forwarding...done.
Configuring network interfaces...ifup: interface lo already configured
Fri Apr 15 21:07:12 2005 TUN/TAP device tap0 opened
Fri Apr 15 21:07:12 2005 Persist state set to: ON
device br0 already exists; can't create bridge with the same name

Waiting for br0 to get ready (MAXWAIT is 30 seconds).

# /sbin/ifconfig
br0 Link encap:Ethernet HWaddr 00:30:1B:AF:48:00
inet addr:192.168.0.13 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:67 errors:0 dropped:0 overruns:0 frame:0
TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:61966 (60.5 KiB) TX bytes:12689 (12.3 KiB)

eth0 Link encap:Ethernet HWaddr 00:30:1B:AF:48:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2891 errors:0 dropped:0 overruns:0 frame:0
TX packets:3306 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1845611 (1.7 MiB) TX bytes:446827 (436.3 KiB)
Interrupt:18 Base address:0x9000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:240 errors:0 dropped:0 overruns:0 frame:0
TX packets:240 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:19358 (18.9 KiB) TX bytes:19358 (18.9 KiB)

tap0 Link encap:Ethernet HWaddr 00:FF:53:B0:5E:0E
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:3 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Great! br0 has an IP address of 192.168.0.13; while eth0 and tap0 do not have IP addresses. Do some network stuff to make sure everything works as expected. Ping other LAN workstations, ping google, send email -- whatever.

OpenVPN Server Configuration

Now configure OpenVPN to use the bridge. Create (or edit) /etc/openvpn/server.conf:

local 192.168.0.13
port 1194
proto udp
dev tap0
ca /etc/openvpn/cacert.pem
cert /etc/openvpn/this_server.pem
# This file should be kept secret
key /etc/openvpn/this_server.key
dh /etc/openvpn/dh.pem
server-bridge 192.168.0.13 255.255.255.0 192.168.0.200 192.168.0.220
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 4
mute 20

The file above tells OpenVPN the following:

  • listen on local IP 192.168.0.13 for incoming connections
  • use UDP port 1194
  • bind incoming connections to the virtual tap0 interface
  • where to find the certificate files necessary to encrypt/decrypt traffic
  • set aside 20 IP address, from 192.168.0.200 through 192.168.0.220, which will be assigned to VPN clients.
  • send keepalive packets once every 10 seconds; and assume the link is down if no response occurs for 120 seconds
  • drop privileges after spawning
  • try to avoid accessing certain resources on restart that may no longer be accessible because of the privilege downgrade.
  • log status messages somewhere

Make sure the IP addresses you assign to VPN clients are not being used by other hosts on your LAN! Make sure that the block of addresses you assign in server-bridge above are not in the block of addresses assigned by your DHCP server!

http://www.skippy.net/images/openvpn/OpenVPN-bridged-2.png

Routed Mode

OpenVPN in routed mode offers more flexibility for traffic control. It also doesn't involve any kernel jiggery-pokery.

From the official OpenVPN documentation:

Routing advantages
* Efficiency and scalability.
* Allows better tuning of MTU for efficiency.

Routing disadvantages
* Clients must use a WINS server (such as samba) to allow cross-VPN network browsing to work.
* Routes must be set up linking each subnet.
* Software that depends on broadcasts will not "see" machines on the other side of the VPN.
* Works only with IPv4 in general, and IPv6 in cases where tun drivers on both ends of the
connection support it explicitly.

Routing Configuration

OpenVPN will create a private subnet for each connected client. By default clients will not be able to see one another; though this can be enabled if needed. You choose the address and subnet for the VPN connections. It's recommended to use both RFC1918 non-routable addresses and addresses or subnets that are not part of your LAN. If your LAN is 192.168.0.0/24, you could assign 10.8.0.0/24 for VPN connections, for example. But if your LAN actually used 10.8.0.0/24, you'd have to use something different for your VPN connections.

Unlike bridged mode, routed mode doesn't necessarily provide any immediate access to the VPN server's LAN. The client will need to be told to route all packats for the LAN over the VPN connection, instead of through the client's default gateway. Likewise, the VPN server may need to be told how to route packets back to VPN clients. If the VPN client is another LAN, and not just one desktop or laptop computer, both sides will need to know how to route packets back and forth.

The OpenVPN server can push routing information to clients when they connect; or clients can be configured to execute scripts after they connection, and these scripts can then adjust routes as needed.

Using OpenVPN in routed mode can introduce some challenges. For example, if the VPN client is on a network that uses the same IP addressing scheme as that used in the VPN server's network, things will be confusing. There are ways to deal with this situation, but they are beyond the scope of this HOWTO.

OpenVPN Server Configuration

The following example OpenVPN server configuration is suitable for a routed environment:

#local 192.168.0.13
port 1194
proto udp
dev tun
ca /etc/openvpn/cacert.pem
cert /etc/openvpn/this_server.pem
# This file should be kept secret
key /etc/openvpn/this_server.key
dh /etc/openvpn/dh1024.pem
server 10.8.0.0 255.255.255.0
max-clients 5
push "route 192.168.0.0 255.255.255.0"
;push "redirect-gateway def1"
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3
mute 20

The file above tells OpenVPN the following:

  • listen on all local interfaces
    • if you want to restrict OpenVPN to listen only on a specific address, uncomment the local line
  • use UDP port 1194
  • bind incoming connections to the virtual tunX interfaces
    • The server will use a seperate tunX interface (tun0, tun1, tun2...) for each client connection
  • where to find the certificate files necessary to encrypt/decrypt traffic
  • use IPs in the range 10.8.0.0 for each OpenVPN client connection.
    • make sure these addresses are completely bogus for your network.
  • allow at most 5 concurrent client connections
  • tell clients to use the OpenVPN server as the gateway to the 192.168.0.0/24 network
  • send keepalive packets once every 10 seconds; and assume the link is down if no response occurs for 120 seconds
  • drop privileges after spawning
  • try to avoid accessing certain resources on restart that may no longer be accessible because of the privilege downgrade.
  • log status messages somewhere
  • suppress lots of duplicate messages

The push "redirect-gateway def1" command, commented out in the example, instructs the OpenVPN server to send additional routing details to connecting clients. Specifically, this sends two new routes which are just slightly more specific than the normal default route. Due to the way routing works (more specific before less specific), the result is that these new routes effectively become the new default routes for all client traffic. This means that the VPN server effectively becomes the default gateway for all VPN traffic. This may or may not be what you want.

Remember that pushing a route to the client(s) may not be sufficient. The VPN clients will know how to access the LAN, but LAN hosts may not know how to access VPN clients. You could add specific routing rules on each LAN host, as needed, or simply add a route to your LAN's default gateway pointing to the VPN server.

http://www.skippy.net/images/openvpn/OpenVPN-routed-1.png

Start the VPN

To automatically start the OpenVPN daemon when the server starts, use the following example init script, /etc/init.d/openvpn:

#!/bin/sh
#
# Original version by Robert Leslie
# <rob@mars.org>, edited by iwj and cs
# Modified for openvpn by Alberto Gonzalez Iniesta <agi@agi.as>
# modified for openvpn 2.0 by Martin Hejl <hejl@bering-uclibc.de>
# using additions by Douglas Keller <doug@voidstar.dyndns.org>

RCDLINKS="0,K20 1,K20 2,S20 3,S20 4,S20 5,S20 6,K20"

DAEMON=/usr/local/sbin/openvpn
CONFIG_DIR=/etc/openvpn
PIDDIR="/var/run"

test -x $DAEMON || exit 0
test -d $CONFIG_DIR || exit 0


case "$1" in
start)
echo -n "Starting openvpn: "

for CONFIG in `cd $CONFIG_DIR; ls *.conf 2> /dev/null`; do
NAME=${CONFIG%%.conf}
echo -n "$NAME "
$DAEMON --daemon --writepid $PIDDIR/openvpn.$NAME.pid \
--config $CONFIG_DIR/$NAME.conf --cd $CONFIG_DIR || echo "FAILED "
done
echo ""
;;
stop)
echo -n "Stopping openvpn: "
for PIDFILE in `ls $PIDDIR/openvpn.*.pid 2> /dev/null`; do
NAME=${PIDFILE##$PIDDIR/openvpn.}
NAME=${NAME%%.pid}

if [ -s $PIDFILE ]; then
echo -n "$NAME "
kill `cat $PIDFILE` >/dev/null 2>&1
fi
rm -f $PIDFILE
done
echo ""
;;
# send SUGHUP to all running instances
reload)
echo -n "Reloading openvpn: "
for PIDFILE in `ls $PIDDIR/openvpn.*.pid 2> /dev/null`; do
NAME=${PIDFILE##$PIDDIR/openvpn.}
NAME=${NAME%%.pid}

if [ -s $PIDFILE ]; then
echo -n "$NAME "
kill -HUP `cat $PIDFILE` >/dev/null 2>&1
fi
done
echo ""
;;
#
restart)
$0 stop
sleep 2
$0 start
;;
# send SIGUSR1 to all running instances
reopen)
echo -n "Reopening openvpn: "
for PIDFILE in `ls $PIDDIR/openvpn.*.pid 2> /dev/null`; do
if [ -s $PIDFILE ]; then
NAME=${PIDFILE##$PIDDIR/openvpn.}
NAME=${NAME%%.pid}
echo -n "$NAME "
kill -USR1 `cat $PIDFILE` >/dev/null 2>&1

fi
done
echo ""
;;

status)
echo -n "Writing status to /var/log/daemon.log: "
for PIDFILE in `ls $PIDDIR/openvpn.*.pid 2> /dev/null`; do
if [ -s $PIDFILE ]; then
NAME=${PIDFILE##$PIDDIR/openvpn.}
NAME=${NAME%%.pid}
echo -n "$NAME "
kill -USR2 `cat $PIDFILE` >/dev/null 2>&1
fi
done
echo ""
;;
*)
echo "Usage: $0 {start|stop|reload|restart|reopen|status}" >&2
exit 1
;;
esac

exit 0

NOTE: That script should work on Debian-based systems. Other GNU/Linux distributions may or may not be able to use that.

Clients

In general, OpenVPN client connections are pretty much the same across all three supported platforms: install the software, create a configuration file somewhere, and collect the necessary SSL certificate files. For simplicity, we will keep the OpenVPN configuration file and the SSL certificate files in the same directory. You may (justifiably) decide not to do this. Edit the config file as necessary to point to your certificate files.

It is crucial that OpenVPN clients use the same tunnel device as used by the server. If the server is using the tap device, the clients must use the tap device. If the server is using the tun device, the clients must use the tun device.

For these examples, we'll assume we're connecting to OpenVPN running on a GNU/Linux server in routed mode, using the tun device. That server lives at 66.93.81.185 -- change this to the IP address of your OpenVPN server.

NOTE: regardless of whether you're using bridged or routed mode for your VPN server, your VPN clients will need to know how to access LAN resources. OpenVPN supports several push directives to tell VPN clients to use DNS servers and WINS servers. These commands are not included in the examples below. If you don't use push directives, you'll need to add LAN host addresses to your VPN clients' hosts and lmhosts files as necessary. For example, GNU/Linux systems use /etc/hosts, while Windows XP systems use C:\Windows\System32\Config\Etc\Hosts</code> and <code>C:\Windows\System32\Config\Etc\LMHosts.

GNU/Linux

Command Line

Download, compile and install the OpenVPN source code. The OpenVPN binary will be installed in /usr/local/sbin/ by default. If you use a packaged version for your GNU/Linux distribution, the location of files may be different (for example, the Debian GNU/Linux package places the executable in /usr/sbin/).

Because OpenVPN does some nitty-gritty low-level network stuff, it requires root privileges to start. This means that you need to be the root user to initiate a VPN connection. Alternately you could make the OpenVPN binary setuid (discouraged), or use sudo. For these examples we'll use sudo.

Create a directory somewhere to store your OpenVPN configuration files. You can use your home directory, or someplace like /etc/openvpn. In this directory, create a file, client.conf, that looks something like this:

client
remote 66.93.81.185
port 1194
proto udp
dev tun
ca /etc/openvpn/cacert.crt
cert /etc/openvpn/this_client.pem
# This file should be kept secret
key /etc/openvpn/this_client.key
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3
mute 20

Adjust the certificate lines as needed.

Start the VPN client like so:

sudo /usr/local/sbin/openvpn --config /etc/openvpn/client.conf

You should see a bunch of status messages scroll past, eventually ending with "Initialization Sequence Completed". You should now have a secured connection. Test it out.

To disconnect from the VPN, simply press CTRL-C to break out of the process.

Graphical User Interface

GoVPN is a GUI for OpenVPN on GNU/Linux. It is written in the Gambas programming language, so you'll need to install that first. For most people, it's probably easier to just use the OpenVPN command line.

Mac OSX

TUN/TAP Driver

In order to use OpenVPN on Mac OSX you will need the Mac OSX TUN/TAP driver. If you're compiling OpenVPN from source, download the package from the link above. If you're going to use Tunnelblick, the Mac OSX OpenVPN GUI, skip ahead to that section, as the tun/tap driver is bundled with the GUI.

Download the tup/tap driver to some place convenient, say your desktop. The archive should automatically be expanded, giving you a tuntap folder. Double click on this. Inside the folder are a few files. Feel free to read the README. Then simply double-click on <tt>tuntap-installer.mpkg</tt> and follow the prompts. This will install the necessary kernel modules.

NOTE: At this time, the Mac OSX tun/tap driver may not be fully stable on multiprocessor systems. If you have a dual-CPU PowerMac?, you may experience trouble. You have been warned.

Command Line

Download, compile and install the OpenVPN source code. The OpenVPN binary will be installed in /usr/local/sbin/ by default.

Select a safe place to store the OpenVPN configuration files, say /Users/&lt;username&gt;/Library/openvpn. Create this directory, if it does not exist, and in it create a file, openvpn.conf, that looks something like this:

client
remote 66.93.81.185
port 1194
proto udp
dev tun
ca /Users/&lt;username&gt;/Library/openvpn/cacert.crt
cert /Users/&lt;username&gt;/Library/openvpn/this_client.pem
# This file should be kept secret
key /Users/&lt;username&gt;/Library/openvpn/this_client.key
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
status /Users/&lt;username&gt;/Library/openvpn/openvpn-status.log
verb 3
mute 20

Adjust the certificate lines as needed.

Launch OpenVPN from a terminal window, like so:

/usr/local/sbin/openvpn --config /Users/&lt;username&gt;/Library/openvpn/openvpn.conf

You should see a bunch of status messages scroll past, eventually ending with "Initialization Sequence Completed". You should now have a secured connection. Test it out.

Graphical User Interface

Mac OSX users can do the command-line compilation, if they so choose, but there's no compelling reason to do so. Tunnelblick, the Mac OSX OpenVPN GUI, is a slick, easy-to-use all-in-one package.

Download the Tunnelblick disk image, saving it to someplace convenient like your desktop. Double-click to mount the image. Inside will be several files. Feel free to read the README. Double-click the Tunnelblick-Complete.mpkg package and follow the prompts. This will install the tun/tap driver, the OpenVPN program, and the Tunnelblick front-end. When the installer is finished, click the "Go" menu in your finder menu bar, and select "Applications". Double-click on the Tunnelblick icon.

The first time Tunnelblick is executed it will realize that there is no config file, and ask you what to do. If you click "Continue", Tunnelblick will create a sample (non-usable) config file for you. Feel free to edit that, or copy an existing configuration file, to /Users/&lt;username&gt;/Library/openvpn/openvpn.conf:

client
remote 66.93.81.185
port 1194
proto udp
dev tun
ca /Users/&lt;username&gt;/Library/openvpn/cacert.crt
cert /Users/&lt;username&gt;/Library/openvpn/this_client.pem
# This file should be kept secret
key /Users/&lt;username&gt;/Library/openvpn/this_client.key
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
status /Users/&lt;username&gt;/Library/openvpn/openvpn-status.log
verb 3
mute 20

Adjust the certificate lines as needed.

Tunnelblick creates a small icon to the right of the clock in your menu bar. Click this icon to access the Tunnelblick menu. Options include "Edit config file", "Connect", "Disconnect" and "Quit". Select "Connect" to start an OpenVPN session; and select "Disconnect" when you're finsihed.

Microsoft Windows

To install and use OpenVPN on Microsoft Windows, you will likely need Administrator level access to the computer.

You can install OpenVPN as a Windows service, which can be configured to connect every time the sysem boots. This is fairly easy to do, but is outside the scope of this HOWTO.

Command Line

Download and install the Windows Installer package. It is safe to accept the default values for the installation (just keep clicking "Next"!). The installer will also install the Windows TAP32 driver, for which Windows may present a security warning. When prompted, tell Windows to please install the unsigned device driver.

Select a location to store OpenVPN configuration files. You can use C:\Documents and Settings\&lt;username&gt;>\OpenVPN\ if you want, though I generally prefer to use C:\Program Files\OpenVPN\config\. Create in this directory a file, client.ovpn, similar to the following:

client
remote 66.93.81.185
port 1194
proto udp
dev tun
dev-node MyTap
ca C:\Program Files\OpenVPN\config\cacert.crt
cert C:\Program Files\OpenVPN\config\this_client.pem
# This file should be kept secret
key C:\Program Files\OpenVPN\config\this_client.key
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
status C:\Program Files\OpenVPN\log\openvpn-status.log
verb 3
mute 20

Adjust the certificate lines as needed.

(Sample configuration files for client and server operation can be found in C:\Program Files\OpenVPN\Examples\.)

To start OpenVPN on Windows, you can simply right-click on an OpenVPN configuration file and select "Launch OpenVPN with this configuration". So right-click on your client.ovpn and select to launch it.

To make things extra easy, right-click on the client.ovpn file and select "Copy". Then minimize all windows and right-click on your desktop. Select "Create Shortcut Here". You now have a shortcut to your client.ovpn file. Give this shortcut a helpful name, like "VPN - RIGHT CLICK". Right-click on the shortcut and select "Launch OpenVPN with this configuration" to start OpenVPN!

Once launched, a command prompt window will open, and you should see a bunch of status messages scroll past, eventually ending with "Initialization Sequence Completed". You should now have a secured connection. Test it out. If you like, minimize the OpenVPN status window.

When you're finished with the OpenVPN session, simply close the OpenVPN status window.

Graphical User Interface

The OpenVPN GUI for Windows provides a more convenient means of managing OpenVPN, without all the desktop clutter that OpenVPN usually creates. The OpenVPN GUI helpfully provides two different versions for download: a "complete" package which installs OpenVPN itself and the GUI application; and an "application only" package, which is just the OpenVPN GUI executable application.

First time users are encouraged to use the complete package. If you've already installed OpenVPN for Windows, then simply download the application and save it in your OpenVPN directory (typically C:\Program Files\OpenVPN\).

The OpenVPN GUI, when executed, will add an icon to the Windows System Tray, near the clock on the taskbar. Right clicking on this icon will bring up a menu. Note: If you have not yet created a config file, the OpenVPN GUI menu will not be very useful: it will show "Edit Proxy Settings", "About", and "Exit". You will need to create (or copy) an OpenVPN configuration file. By default, the OpenVPN GUI expects this file to reside in C:\Program Files\OpenVPN\config\. Sample configuration files for client and server operation can be found in C:\Program Files\OpenVPN\Examples\. Copy one of these, or use the example below, to C:\Program Files\OpenVPN\config\client.ovpn.

client
remote 66.93.81.185
port 1194
proto udp
dev tun
dev-node MyTap
ca C:\Program Files\OpenVPN\config\cacert.crt
cert C:\Program Files\OpenVPN\config\this_client.pem
# This file should be kept secret
key C:\Program Files\OpenVPN\config\this_client.key
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
status C:\Program Files\OpenVPN\log\openvpn-status.log
verb 3
mute 20

Adjust the certificate lines as needed.

Now right-click on the OpenVPN GUI icon and select "Connect". Once connected, you can select "View Log" to see what OpenVPN has been doing behind the scenes, or "Disconnect". The OpenVPN GUI also provides an option to edit the config file, which is a handy feature to say the least.

Advanced Topics

So now you know the basics of using OpenVPN. Here are some additional tips and tricks.

Client Configuration Directory

The OpenVPN server configuration defines settings that are applied for all incoming connections. If you want to override some settings for certain clients, you have several choice. First, you could run a seperate instance of the OpenVPN server, listening on a different port. This can quickly get unwieldy. That's why OpenVPN servers support the following directive in the configuration file:

client-config-dir ccd

ccd is the name of a directory inside the directory that holds the OpenVPN server configuration. For example, on GNU/Linux servers this would be /etc/openvpn/ccd/.

Inside this directory you can create configuration files that modify the server's default settings for individual clients.

The OpenVPN server associates specific clients to specific configuration files through the CommonName field in the client certificate. If the connecting client's certificate has "Scott Merrill" as the CommonName?, the OpenVPN server would look for /etc/openvpn/ccd/Scott Merrill.

$ openssl x509 -in scott_merrill.pem -text |grepCN |grep Scott
Subject: C=US, ST=Ohio, L=Columbus, O=skippy.net, CN=Scott Merrill/emailAddress=skippy@skippy.net

If I wanted to assign a specific VPN IP address to my laptop, I could create the file /etc/openvpn/ccd/Scott Merrill with the following:

ifconfig-push 10.8.1.1 10.8.1.2

Whenever my laptop connects (using my client certificate), it will be assigned a VPN IP address of 10.8.1.1, and the VPN server will use 10.8.1.2 for the IP address of the tun interface on the server.

See the end of the official OpenVPN HOWTO for more details about this.

Residential Wireless

I use OpenVPN in routed mode to protect my wireless LAN traffic at home. My laptop connects to the OpenVPN service on my router's wlan0 interface, and uses the tunnel as the default gateway. In this way, I don't need to muck around with WEP or WPA, and I can safely deny all wireless -&gt; internet traffic, and only permit VPN -&gt; internet traffic. My router performs IP masquerading on the all VPN -&gt; internet traffic, so outgoing connections appear to originate from my router's public IP address. VPN -&gt; LAN traffic is not masqueraded.

See also this page for using OpenVPN with a LinkSys? WRT54G.

Coffee-shop Security

I also tunnel OpenVPN traffic through the public interface of my home router; also in routed mode. I do this so that I can always have a secured connection to a trusted host, through which I can route my traffic. Then, when I'm at a coffee shop (or conference, or hotel room), I can safely do whatever I need to do without worrying about people sniffing my packets.

The OpenVPN server configuration includes the line

push "redirect-gateway def1"

which tells the OpenVPN client (my laptop) to use the OpenVPN server as the default gateway for all traffic.

By using the tunnel as my default gateway, I not only shield my packets from any prying eyes, I also nicely side-step any attempts to block certain kinds of traffic on whatever network I'm using: all my traffic gets routed over the tunnel. Finally, I run dnsmasq on my laptop, which also uses the OpenVPN tunnel. Doing so ensures that all my traffic is blocked from snooping eyes.

Consider what happens without a local DNS resolver:

  • your laptop obtains an IP address from the coffeeshop via DHCP
  • along with the IP address, it also receives a local DNS server to use for hostname lookups
  • you connect to your OpenVPN server, safely encrypting all outbound traffic
  • EXCEPT DNS hostname lookups: your laptop sees that the coffeeshop DNS server is in the same LAN, and thus has a more specific route than the OpenVPN default route
    • so your laptop makes an unencrypted query to the coffeeshop DNS server

The end result is that while no one will know what you're doing, anyone can see where you're going.