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.
[root@server]# openvpn --config example2-5-server.conf
[root@client]# openvpn --config basic-udp-client.conf ... ... Initialization Sequence Completed
[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
[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
[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
[gateway1]> ip route add 192.168.4.0/24 via 10.198.0.10
Here, 10.198.0.10
is 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.64
Here, 192.168.4.64
is 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:
192.168.4.64
: Site A's LAN address10.198.1.12
: Site B's LAN addressThe 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:
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.
3.146.176.172