After setting up OpenVPN successfully for the very first time, it is very common to misconfigure the network routes for the VPN. In this recipe, we will first set up a basic TUN-style VPN as is done in Chapter 2, Client-server IP-only Networks. At first, routing will not work until the right routes are added. The purpose of this recipe is to describe how to troubleshoot such a routing error.
We use the following network layout:
Set up the client and server certificates using the Setting up the public and private keys recipe from Chapter 2, Client-server IP-only Networks. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.11. The client was running Fedora 22 Linux and OpenVPN 2.3.11. Keep the configuration file basic-udp-server.conf from the Server-side routing recipe from Chapter 2, Client-server IP-only Networks, as well as the client configuration file basic-udp-client.conf.
- Start the server using the configuration file
basic-udp-server.conf:[root@server]# openvpn --config basic-udp-server.conf - Next, start the client:
[root@client]# openvpn --config basic-udp-client.conf ... ... Initialization Sequence Completed
- At this point, it is possible to ping the remote VPN IP and all the interfaces that are on the VPN server themselves:
[client]$ ping -c 2 10.200.0.1 PING 10.200.0.1 (10.200.0.1) 56(84) bytes of data. 64 bytes from 10.200.0.1: icmp_seq=1 ttl=64 time=25.2 ms 64 bytes from 10.200.0.1: icmp_seq=2 ttl=64 time=25.1 ms [client]$ ping -c 2 10.198.0.10 PING 10.198.0.10 (10.198.0.10) 56(84) bytes of data. 64 bytes from 10.198.0.10: icmp_seq=1 ttl=64 time=24.7 ms 64 bytes from 10.198.0.10: icmp_seq=2 ttl=64 time=25.0 ms
If either of these pings fails, then the VPN connection has not been established successfully and there is no need to continue.
- If no routes have been added to the server-side gateway, then all other hosts on the remote
10.198.0.0/16network will be unavailable:[client]$ ping 10.198.0.1 PING 10.198.0.1 (10.198.0.1) 56(84) bytes of data. ^C --- 10.198.0.1 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 764ms
- If we add a route on the LAN gateway of the remote network to explicitly forward all the VPN traffic to the VPN server, then we can reach all machines on the remote LAN (like it was done in the Server-side routing recipe from Chapter 2, Client-server IP-only Networks):
[gateway]> ip route add 10.200.0.0/24 via 10.198.0.10Here,
10.198.1.1is the LAN IP address of the VPN server. In this case, the remote LAN gateway is running Linux. The exact syntax for adding a static route to the gateway will vary with the model and operating system of the gateway. - Now, all the machines are reachable:
[client]$ ping 10.198.0.1 PING 10.198.0.1 (10.198.0.1) 56(84) bytes of data. 64 bytes from 10.198.0.1: icmp_seq=1 ttl=63 time=27.1 ms 64 bytes from 10.198.0.1: icmp_seq=2 ttl=63 time=25.0 ms
When the VPN client attempts to make a connection to a host on the server-side LAN, packets are sent with a source and destination IP address:
- Source IP =
10.200.0.2: This address is the VPN tunnel's IP address - Destination IP = IP: This is the IP of the host we're trying to contact
The remote host will want to reply with a packet, with the source and destination IP addresses swapped. When the remote host wants to send the packet, it does not know where to send it to, as the address 10.200.0.2 is our private VPN address. It then forwards the packet to the LAN gateway. However, the LAN gateway also does not know where to return the packets to, and will forward them out to its default gateway. When the packets reach a router that is connected directly to the Internet, that router usually will decide to drop (throw away) the packets, causing the host to become unreachable.
By adding a route on the remote LAN gateway - telling it that all the traffic for the network 10.200.0.0/24 should be forwarded to the VPN server - the packets are sent back to the right machine. The VPN server will forward the packets back to the VPN client and the connection is established.
The step to ping the remote VPN endpoint first and then the server-LAN IP (10.198.0.10) may seem superfluous at first but these are crucial steps when troubleshooting routing issues. If these steps already fail, then there is no need to look at the missing routes.
In this section, we will focus on different solutions to the problem described in this recipe.
A quick and dirty solution to the above issue is outlined in the Server-side routing recipe from Chapter 2, Client-server IP-only Networks. In the There's More... section of that recipe, masquerading (a form of NAT'ing) is used to make it appear as if all the traffic is coming from the OpenVPN server itself. This is perfect if you have no control over the remote LAN gateway, but it is not a very clean routing solution. Certain applications do not behave very well when NAT'ted. Also, from a security logging point of view, it is sometimes better to avoid NAT'ting, as you are mapping multiple IP addresses onto a single one, thereby losing information.
Instead of adding a route to the remote LAN gateway, it is also possible to add a route on each of the remote LAN hosts that the VPN client needs to reach. This solution is perfect if the VPN client only needs to be able to reach a limited set of server-side hosts, but it does not scale very well.
- The Server-side routing recipe from Chapter 2, Client-server IP-only Networks, which contains the basic setup for routing the traffic from the server-side LAN