Chapter 8

Missing return routes when 'iroute' is used

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 Chapter 2 recipe Routing: subnets on both sides. 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.

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, example2-5-server.conf, from the Chapter 2 recipe, Routing: subnets on both sides, at hand, as well as the client configuration, basic-udp-client.conf, from the

Chapter 2 recipe Server-side routing.

How to do it...

1.Start the server:

[root@server]# openvpn --config example2-5-server.conf

2.Next, start the client:

[root@client]# openvpn --config basic-udp-client.conf

…Initialization Sequence Completed

211

Troubleshooting OpenVPN: Routing

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

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

64 bytes from 192.168.200.2: icmp_seq=1 ttl=64 time=25.0 ms 64 bytes from 192.168.200.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

4.The routing table on the server shows that the remote network is routed correctly:

[server]$ netstat -rn | grep tun0

192.168.4.0 192.168.200.1 255.255.255.0 UG 0 0 0 tun0

5.When we try to ping a remote host on the server-side LAN it fails, as it 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

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

Here, 10.198.0.10 is the LAN IP address of the VPN server.

212

Chapter 8

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

How it works...

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

There's more...

Again, a quick and a dirty solution to the above issue is outlined in the Chapter 2's recipe

Server-side routing. In that recipe, masquerading is used to make it appear as if all the traffic is coming from the OpenVPN server itself. Especially, 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.

213

Troubleshooting OpenVPN: Routing

See also

Chapter 2's recipe, Routing: subnets on both sides, which explains in detail how to set up routing on both the client and the server side.

All clients function except the

OpenVPN endpoints

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.

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, example2-5-server.conf, from the Chapter 2 recipe Routing: subnets on both sides at hand, as well as the client configuration, basic-udp-client.conf, from the

Chapter 2 recipe Server-side routing.

How to do it...

1.Start the server:

[root@server]# openvpn --config example2-5-server.conf

214

Chapter 8

2.Next, start the client:

[root@client]# openvpn --config basic-udp-client.conf

…Initialization Sequence Completed

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

4.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 not any of the other hosts.

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

6.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 192.168.200.0/24 via 10.198.0.10 [gateway2]> ip route add 192.168.200.0/24 via 192.168.4.64

215

Troubleshooting OpenVPN: Routing

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

How it works...

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

There's more...

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:

[root@server]# iptables -t nat -I POSTROUTING -i tun0 -o eth0 \

-s 192.168.200.0/24 -j MASQUERADE

216