Introduction

Troubleshooting OpenVPN: Routing

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

Getting ready

We use the following network layout:

Install OpenVPN 2.0 or higher on two computers. Make sure the computers are connected over a network. 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 5 Linux and OpenVPN 2.1.1. The client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the configuration file, basic-udp-server.conf, from the Chapter 2 recipe Server-side

routing at hand, as well as the client configuration file, basic-udp-client.conf, from the same recipe.

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

208

Chapter 8

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 192.168.200.1

PING 192.168.200.1 (192.168.200.1) 56(84) bytes of data.

64 bytes from 192.168.200.1: icmp_seq=1 ttl=64 time=25.2 ms 64 bytes from 192.168.200.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' fail, 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 Chapter 2 recipe, Server-side routing):

[gateway]> ip route add 192.168.200.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 IP = 192.168.200.2: this address is the VPN tunnel's IP address

Destination IP = IP of the host we're trying to contact

209

Troubleshooting OpenVPN: Routing

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

192.168.200.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 they are crucial 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 Chapter 2 recipe Server-side routing. In the There's More... section of that recipe, masquerading 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

Chapter 2's recipe, Server-side routing, which contains the basic setup for routing the traffic from the server-side LAN.

210