This recipe is again a continuation of the previous one. The previous recipe explained how to troubleshoot routing issues when connecting a client-side LAN (or subnet) to a server-side LAN. However, in the previous recipe, an omission in the routing configuration was made on purpose. In this recipe, we will focus on troubleshooting this quite common omission.
We use the following network layout:
Set up the client and server certificates using the first 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 example2-5-server.conf from the Routing: subnets on both sides from Chapter 2, Client-server IP-only Networks, at hand, as well as the client configuration, basic-udp-client.conf, from the Server-side routing recipe from Chapter 2, Client-server IP-only Networks.
- Start the server:
[root@server]# openvpn --config example2-5-server.conf - Next, start the client:
[root@client]# openvpn --config basic-udp-client.conf ... ... Initialization Sequence Completed
- Add the appropriate routes on the gateways at both the sides:
[gateway1]> ip route add 192.168.4.0/24 via 10.198.0.10 [gateway2]> ip route add 10.198.0.0/16 via 192.168.4.64
After this, all the hosts on the LANs can reach each other.
- We verify this by pinging various machines on the LANs on either of the sides:
[client]$ ping -c 2 10.198.0.10 [server]$ ping -c 2 192.168.4.64 [siteA-host]$ ping -c 2 10.198.0.1 [siteB-host]$ ping -c 2 192.168.4.66
All of them work. However, when the VPN server tries to ping a host on the client-side LAN, it fails:
[server]$ ping -c 2 192.168.4.66 PING 192.168.4.66 (192.168.4.66) 56(84) bytes of data. --- 192.168.4.66 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1009ms
Similarly, the client can only reach the LAN IP of the server and none of the other hosts.
- On Linux and UNIX hosts, it is possible to explicitly specify the source IP address:
[server]$ ping -I 10.198.0.10 -c 2 192.168.4.66 PING 192.168.4.66 (192.168.4.66) 56(84) bytes of data. 64 bytes from 192.168.4.66: icmp_seq=1 ttl=63 time=25.5 ms 64 bytes from 192.168.4.66: icmp_seq=2 ttl=63 time=24.3 ms
That works! So, there is a problem with the source address of the packets.
- By adding an extra route for the VPN subnet itself, to the gateways on both the ends, this issue is resolved:
[gateway1]> ip route add 10.200.0.0/24 via 10.198.0.10 [gateway2]> ip route add 10.200.0.0/24 via 192.168.4.64
- Now, the VPN server can reach all the hosts on the client's subnet and vice versa:
[server]$ ping -c 2 192.168.4.66 PING 192.168.4.66 (192.168.4.66) 56(84) bytes of data. 64 bytes from 192.168.4.66: icmp_seq=1 ttl=63 time=25.3 ms 64 bytes from 192.168.4.66: icmp_seq=2 ttl=63 time=24.9 ms
To troubleshoot issues like these, it is very handy to write out all the source addresses and the destination addresses of the LANs involved. In this case, the problem occurs when the VPN server wants to connect to a host on the client-side LAN. On the VPN server, the packet that is sent to the client-side host is sent out of the VPN interface directly. Therefore, the source address of this packet is set to the IP address of the VPN interface itself. Thus, the packet has the following IP addresses:
- Source IP =
10.200.0.1: VPN server's IP address - Destination IP =
192.168.4.66: Site A's LAN address
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 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.
This problem occurs only on the VPN server and VPN client. On all other hosts on the client-side and server-side LAN, the LAN IP address is used and routing works as configured in the previous recipe.
By adding the appropriate routes on both the sides the problem is resolved.
A good use of NAT'ing in this recipe would be to remove any references to the VPN IP range from the routing tables. This can be done by just masquerading the VPN endpoint addresses. If this is done, the extra routes are no longer needed on the gateways on both the LANs. For example, by adding a NAT'ing rule on the server and a similar one on the client, the extra routes on the gateways are no longer needed.
[root@server]# iptables -t nat -I POSTROUTING -i tun0 -o eth0 -s 10.200.0.0/24 -j MASQUERADE [root@client]# iptables -t nat -I POSTROUTING -i tun0 -o eth0 -s 10.200.0.0/24 -j MASQUERADE
Note that this is easily done on Linux and UNIX-based operating systems but it requires more effort on Windows.
- The Routing: subnets on both sides recipe from Chapter 2, Client-server IP-only Networks, which explains in detail how to set up routing on both the client and the server side