So, I finally decided to get rid of the dodgy port forward rule on my home firewall that allowed me to RDP into one of my servers, and roll out a full VPN solution instead. Since I’ve used OpenVPN before, and happen to really like it I thought I’d do the same at home. I’ve got an existing VMware vSphere infrastructure so I don’t need any more hardware to stand it up on, and OpenVPN has a completely free version, which is always a plus.

If you’ve ever set up OpenVPN before, or maybe even if you haven’t you may know there are essentially two connectivity modes you can use, routed or bridged, although you may not know which option is best for you. Let’s talk a little about this below.

Routed mode

Routing is something you do to traffic when you want to send between different IP networks. These networks are on what we refer to as completely independent subnets, that is to say that they have completely different ranges of IPs. When a network device tries to send traffic to a network other than it’s own it sends the packets to it’s own network default gateway (usually a router or firewall) which essentially has a list of other networks it knows about and how to send the packets on to that network (it knows “the route”). For successful complete communication there also needs to be a “route back” from the destination network back to the local one containing the sending device, otherwise the communication just gets lost. (more on the significance of this later).

In the context of OpenVPN, when your clients connect to the VPN running in routed mode, the IP address they are given is on a completely different private subnet to the main network on which your OpenVPN server resides. The OpenVPN server essentially acts as a router, and any traffic from your client destined to your main office network (or other known networks beyond) is “routed” between this different private subnet and those networks through the OpenVPN server.

Bridged mode

Ethernet Bridging in this context is basically the combining of a physical network adaptor with a virtual software adaptor (a TAP device) into one single virtual “bridged” interface. This interface operates similarly to a layer 2 switch which combined with the virtual TAP adaptors on the OpenVPN client software allows multiple client connections to this single interface, while still providing them with their own unique IP address, on the same subnet as the OpenVPN server and the rest of your network.

So in practise what are the differences?

Well, bridged mode is a little harder to get going because it relies on another layer of functionality which needs to be provided at the OS level, ie, the bridging. This is possible in newer versions of Windows or on Linux you need to install the bridge-utils package beforehand, after which you have to create a bridged tap interface connected to one of your physical NICs, and only then can OpenVPN be started. The OpenVPN documentation suggests that overall routing is probably a better choice for most people, however personally I believe bridged is the way to go.

The main advantage of bridged mode is that it puts you clients onto the same subnet as your VPN servers main interface, as opposed to a separate private subnet. The main thing you are going to notice here is that you’ll still be able to browse to NetBIOS based Windows shares. This is not possible in a routed network (unless you use a WINs proxy which I would imagine most people don’t nowadays) because NetBIOS is a broadcast based protocol. This means that it only works on the local network, and as explained above in routed mode your client will not be on the local network, it will be in it’s own separate subnet. So, if you need to access Windows shares then use bridged mode.

Now for two common gotchas, one for each mode. So, you’ve have set up your OpenVPN server, issued yourself a set of keys and installed your OpenVPN client on your computer. You’ve initiated a connection and the client says you are connected but you can’t access anything on your network. Everything looks right, but its just not working. What gives? Well obviously the list of what could be wrong is endless, but assuming you are in routed mode…

Gotcha 1 – routed mode

As explained above, in a routed network it is the responsibility of the networks default gateway to route non-local traffic down the correct path to the destination network, and for a successful complete conversation to take place it is just as important for there to be a valid working route back to the initiating device. The problem is that the network you’ve connected your new OpenVPN server to almost certainly already has a default gateway. So consider the conversation between you as the VPN client and just for example your main file server on the network which goes something like this;

1. Your VPN client PC makes a request to connect to the file server on your network, realises it’s not on the local subnet (remember you’re on your own separate subnet when connecting to the VPN in routed mode) and so looks up the route to the required network in its routing table. (OpenVPN adds a static route to your clients routing table on connection which you configure in the OpenVPN server.conf file).
2. Route found, your client PC sends the connection request packet down your TAP adaptor connection, to the VPN server, acting as your gateway for the file servers network, and passes it through to the file server, which accepts the packet.
3. The file server in responding to the packet realises it’s destination (you) is not on the local subnet, and so looks up the route to the required network, doesn’t find a route in it’s local routing table and so sends the packet off to it’s default gateway.

At this point the packet is just lost, because the file servers default gateway is not the OpenVPN server, which needs to be the next hop for the packet in order to reach you. From your point of view the connection just times out. You may try to ping the server to see if it’s alive, but the same issue will occur. The server will receive your ping packet but the response packet will get lost in the ether, since it will be sent to the wrong place.

One solution to this would be to add a static route to the file server that specifies that any traffic destined for the VPN client subnet should be routed to the IP address of the OpenVPN server which is the gateway for that subnet, although that would be quite cumbersome to do for all devices on the network. The better solution is to add the static route to your networks existing default gateway router. Traffic would still be sent this way as before but instead of being routed out the default route, usually the Internet, the router would route it back through the VPN server and hey presto your pong packet would be received.

Gotcha 2 – bridged mode

In bridged mode this routing problem simply goes away, since you’ll be given an IP address on the same subnet as your OpenVPN server, and so all existing gateways and routes will already be valid. The most common problem with the VPN not working while in bridged mode is to do with the operation of your network card and something called “Promiscuous mode”.

Promiscuous mode is a specific network adaptor mode that results in all traffic the card receives being passed through to the next layer of the stack rather than only the traffic that is specifically addressed to it. This is required in bridged mode because remember the virtual bridged interface (which relies on the physical adaptor) is actually supporting multiple virtual network connections, one for each VPN client. As a result the adaptor is responsible for receiving and forwarding of packets for each of those clients, and without promiscuous mode, those packets would just get dropped.

If, like me, you are running your OpenVPN server on a virtualization platform such as VMware ESX then you have to consider not only the capability of the physical adaptor(s) in your ESX server, but also the abilities of the virtualized hardware inside your virtualization platform. In the security settings of a VMware vSwitch there is an option to accept or reject requests to drop a vNIC into promiscuous mode, and this can be set either on a port, port-group or vSwitch level. If yours is set to reject (and bear in mind this is the default setting) then bridged mode just isn’t going to work. To fix this just set the port, port-group or vSwitch to accept requests to promiscuous mode (whichever level you feel comfortable setting it at), and providing the rest of your set up is correct you should find you can communicate with your network after that.

So after a bit of mucking around with the various options I’m now happily accessing my entire network over a secure TLS connection and don’t have any naughty open rules on my firewall, and what with carrying the OpenVPN client and required certificate files with me on my password protected and encrypted USB flash keyring, I can now get into my home network where ever I am so long as I can get to a PC.

OpenVPN can be downloaded from http://openvpn.net/index.php/open-source/downloads.html or installed automatically using the package manager native to your system.