VPNs - A Routing Warning

VPNs are great things.  They allow secure remote access to your resources, either for your home or your job.  At work the solution is simple to use because typically someone else sets it up for you.  But if you are that person that does the setup (either at home or if you're the "network person" at work), VPNs can be complex.  I'd like to cover a quick thing to watch out for targeted at small VPNs, especially since I talked about VPNs in a previous ZoneMinder article.

In a previous article, I talked about using OpenVPN as a VPN solution if your router doesn't serve VPN connections directly.  OpenVPN is great for small VPN rollouts.  Once you get to larger numbers of users, OpenVPNs viability becomes questionable and it may be best to go to a larger enterprise system.  In this post, I'm going to cover small VPN rollouts, with the target audience being the one "IT person" or "network person", or even the person who maintains the network at home.

A great way to rollout a small OpenVPN footprint is using PiVPN (http://www.pivpn.io/).  This is basically a pre-canned deployment for turning a Raspberry Pi into a VPN server.  This is fantastic for homes, and even small offices that have less then 10 people using the VPN.  For larger setups you'd want to use OpenVPN on more robust hardware.  No matter what hardware you run it on, successful deployment of a VPN server/endpoint requires some deeper considerations about how the existing network works in order to be successful.

A very small network (home or small office) typically is one big flat network, consisting of one router/firewall between the network and the Internet.  Many times device even acts as the wireless access point for the network.  Going a step deeper, by "one big flat network" I also mean one IP subnet.  For example, 192.168.0.xxx, which is more properly referred to as the 192.168.0.0/24 subnet (for this example).

A VPN solution (typically one that does not run on the router itself) usually creates a new subnet for the remote users.  As an example, my desktop at home may have the address of 192.168.0.101, but when I connect with the VPN from my phone it may be assigned the address of 10.0.0.101 .  It's the VPN server's and the router's job to make these two different networks talk to each other.  Without going too deep, something on the 10.0.0.xxx network cannot talk to anything on the 192.168.0.xxx network without a router and without the other devices knowing how to get to get to it.

In our OpenVPN example, the OpenVPN server is a router between 192.168.0.xxx and the 10.0.0.xxx network that it creates for the VPN users.  However, the 192.168.0.xxx network needs to know about the 10.0.0.xxx network in order to return traffic back to the VPN clients.  The simplest way to do that is to create a static route in the "main router" on your network.  The static route tells the router that the 10.0.0.xxx can be accessed by a certain host, which would be the 192.168.0.xxx address of the OpenVPN server.  Once that route is in place, when a device on the 192.168.0.xxx network tries to reply to a 10.0.0.xxx VPN client, it will send the traffic to the main router, which will send the traffic to the OpenVPN server for processing.

While that solution may work, it's not ideal.  It creates something called asymmetric routing.  Here's what will happen step by step with that setup when something on the VPN tries to connect to something on the LAN:

1. Remote device (on VPN, addressed as 10.0.0.100) wants to connect to ZoneMinder (at 192.168.0.100)
2. Remote device sends the connection request to it's default gateway (OpenVPN Server, which has addresses of 10.0.0.2 and 192.168.0.2)
3. The OpenVPN server sits on the 192.168.0.0/24 network, so it sends the connection request directly to the ZoneMinder server.
4. The ZoneMinder server gets the request, processes it, and sends the reply message.  Since the ZoneMinder server is on the 192.168.0.0/24 network and doesn't know anything about the 10.0.0.0/24 network, it sends the reply message to it's default gateway, the "main router" at 192.168.0.1
5. The main router gets the reply message and needs to figure out where to send it.  It looks in it's routing table and sees that 10.0.0.0/24 is behind the OpenVPN server at 192.168.0.2, so it sends the reply message to the OpenVPN server to handle.
6. The OpenVPN server gets the reply message.  It sees it's addressed to a client at 10.0.0.100, which is connected to it via VPN, so it sends the reply message back to the client.

You can see the path that the initial request took is different then the path the reply message took.  This is bad for several reasons.

1. It's inefficient.
2. It's often not predictable, which can cause performance issues in the network design.
3. Firewalls don't like it.  Asymmetric routing looks suspicious, like someone is hijacking the traffic.  So firewalls often either block the traffic or perform deeper inspection on it.  This slows down the traffic, or causes it to stop all together.

The reason this is asymmetric is because the OpenVPN server can get to the LAN devices, but the LAN devices cannot get directly back to the VPN clients.

This is fixable.  You can do one of several different things to make the connections more efficient and run smoothly:

• You could of course ignore the problem, and put up with any performance problems it causes.
• If you only have a few select devices that you'd ever connect to using the VPN (ie, the only reason you setup a VPN was to connect to ZoneMinder), you could create static routes on each of those devices to point it to the 10.0.0.0/24 network via the OpenVPN server directly, instead of going back to the main router.
• If you have many devices you'd connect to over the VPN, or want something more centrally controlled, you can create a new subnet off of your main router if it has the ability to.  You would move the LAN side of the OpenVPN server to this subnet.  For example, if your router has a "LAN2" port, you could create a network for that port of 192.168.1.0/24, and put the OpenVPN server in that network instead of 192.168.0.0/24.  What this does is remove all other devices from being local to OpenVPN, and forces all traffic through that main router.  This method also allows you to put additional protections on your LAN devices since you can implement firewall rules to block some of the LAN devices from being accessed via the VPN

As with all things in IT, there's the "quick and dirty" way, and there's the "right and efficient" way.  Often times quick and dirty is good enough for homes, and sometimes it's good enough for small businesses.  But with a little extra effort and planning, a home or small business network can run as good as the big enterprises.