The missing return route

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 2Client-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.

Getting ready

We use the following network layout:

Getting ready

Set up the client and server certificates using the Setting up the public and private keys recipe from Chapter 2Client-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 2Client-server IP-only Networks, as well as the client configuration file basic-udp-client.conf.

How to do it...

  1. Start the server using the configuration file basic-udp-server.conf:
    [root@server]# openvpn --config basic-udp-server.conf
    
  2. Next, start the client:
    [root@client]# openvpn --config basic-udp-client.conf
    ...
    ... Initialization Sequence Completed
    
  3. 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.

  4. If no routes have been added to the server-side gateway, then all other hosts on the remote 10.198.0.0/16 network 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
    
  5. 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 2Client-server IP-only Networks):
            [gateway]> ip route add 10.200.0.0/24 via 10.198.0.10
    

    Here, 10.198.1.1 is 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.

  6. 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
    

How it works...

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 IP10.200.0.2: This address is the VPN tunnel's IP address
  • Destination IPIP: 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.

There's more...

In this section, we will focus on different solutions to the problem described in this recipe.

Masquerading

A quick and dirty solution to the above issue is outlined in the Server-side routing recipe from Chapter 2Client-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.

Adding routes on the LAN hosts

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.

See also

  • The Server-side routing recipe from Chapter 2Client-server IP-only Networks, which contains the basic setup for routing the traffic from the server-side LAN
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.117.119.7