This recipe is a continuation of the previous one. After ensuring that a single VPN client can reach the server-side LAN, the next step is to make sure that other hosts behind the VPN client can reach the hosts on the server-side LAN.
In this recipe, we will first set up a VPN as is done in the Routing: subnets on both sides recipe from Chapter 2, Client-Server IP-Only Networks. If no return routes are set up, then the hosts on the client-side LAN will not be able to reach the hosts on the server-side LAN and vice versa. By adding the appropriate routes, the issue is resolved.
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 recipe from Chapter 2, Client-server IP-only Networks, 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
- At this point, it is possible to ping the remote VPN IP and all the interfaces that are on the VPN server itself, and vice versa:
[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.1 (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 [server]$ ping -c 2 10.200.0.2 PING 10.200.0.2 (10.200.0.2) 56(84) bytes of data. 64 bytes from 10.200.0.2: icmp_seq=1 ttl=64 time=25.0 ms 64 bytes from 10.200.0.2: icmp_seq=2 ttl=64 time=24.6 ms [server]$ ping -c 2 192.168.4.64 PING 192.168.4.64 (192.168.4.64) 56(84) bytes of data. 64 bytes from 192.168.4.64: icmp_seq=1 ttl=64 time=25.2 ms 64 bytes from 192.168.4.64: icmp_seq=2 ttl=64 time=24.3 ms
- The routing table on the server shows that the remote network is routed correctly:
[server]$ netstat -rn | grep tun0 192.168.4.0 10.200.0.1 255.255.255.0 UG 0 0 0 tun0 10.200.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
- When we try to ping a remote host on the server-side LAN it fails, as was the case in the previous recipe. Vice versa, when we try to ping a client-side LAN host from a host on the server-side LAN, we see:
[siteB-host]$ 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 999ms
- By adding the appropriate routes on the gateways at both the sides, the routing is restored. First, the gateway on the server-side LAN:
[gateway1]> ip route add 192.168.4.0/24 via 10.198.0.10Here,
10.198.0.10is the LAN IP address of the VPN server.Next, the gateway/router on the client-side LAN:
[gateway2]> ip route add 10.198.0.0/16 via 192.168.4.64Here,
192.168.4.64is the LAN IP address of the VPN client.
After this, the hosts on the LANs can reach each other.
Similar to the previous recipe, when a host on the Site A's LAN attempts to make a connection to a host on the Site B's LAN packets that are sent with a source and destination IP address:
- Source IP =
192.168.4.64: Site A's LAN address - Destination IP =
10.198.1.12: Site B'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, then the router usually will decide to drop (throw away) the packets, causing the host to become unreachable.
A similar problem occurred in the previous recipe, but now the IP addresses of the packets are the actual Site A's and Site B's LAN IP addresses.
By adding the appropriate routes on both the sides, the problem is alleviated.
When troubleshooting this sort of routing issue, it is very important to start at the innermost network (the actual VPN, in this case) and then work your way outwards:
- First, make sure the VPN endpoints can see each other.
- Make sure the VPN client can reach the server LAN IP and vice versa.
- Make sure the VPN client can reach a host on the server-side LAN.
- Make sure a host on the server-side LAN can see the VPN client.
- Make sure a host on the client-side LAN can see the VPN server.
- Finally, make sure a host on the client-side LAN can see a host on the server-side LAN and vice versa.
Again, a quick and a dirty solution to the above issue is outlined in the Server-side routing recipe from Chapter 2, Client-server IP-only Networks. In that recipe, masquerading is used to make it appear as if all the traffic is coming from the OpenVPN server itself. In particular when connecting subnets over a VPN, this is not advisable, as masquerading makes it impossible to tell which client is connecting to which server and vice versa. Therefore, a fully-routed setup is preferred in this case.
- 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