Chapter 8

And, similarly on the following client:

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

-s 192.168.200.0/24 -j MASQUERADE

The extra routes on the gateways are no longer needed.

Note that this is easily done on Linux and UNIX-based operating systems but it requires more effort on Windows.

See also

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

Source routing

As the network configurations grow more complex, the requirement for more advanced features such as the source routing features, increases. Source routing is typically used whenever a server is connected to a network (or the Internet) using two network interfaces (see the following image). In this case, it is important to ensure that the connections that are started on one of the interfaces are kept to that interface. If the incoming traffic for a (VPN) connection is made on the first interface but the return traffic is sent back over the second interface, then VPN connections, amongst others, will fail, as we shall see in this recipe.

Source routing is an advanced feature of most of the modern operating systems. In this recipe, we will show how to set up source routing using the Linux iproute2 tools, but the same can be achieved on other operating systems using similar tools.

Getting ready

We use the following network layout:

217

Troubleshooting OpenVPN: Routing

Install OpenVPN 2.0 or higher on two computers. Make sure the computers are connected over a network. Make sure the server has two separate network connections to a router or to the Internet. 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 and was connected to a router with two IP addresses: 192.168.4.65 and 192.168.2.13; the default gateway for the system was 192.168.2.1, which means that the traffic will leave the interface with IP address 192.168.2.13 by default. The secondary gateway had IP address 192.168.4.1. Keep the configuration file, basic-udp-server.conf, from the Chapter 2 recipe Server-side routing at hand. The client was running Windows XP SP3 and OpenVPN 2.1.1. Keep the client configuration file, basic-udp-client.ovpn, from the Chapter 2 recipe Using an 'ifconfig-pool' block at hand. The client IP address was 192.168.2.10 with default route 192.168.2.1.

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.

(In this configuration, the remote server address openvpnserver.example.com resolves to 192.168.4.65.)

The connection will fail to start and the client OpenVPN log file will show the following message repeated a few times:

Wed Aug 25 16:24:28 2010 TCP/UDP: Incoming packet rejected from 192.168.2.13:1194[2], expected peer address: 192.168.4.65:1194 (allow this incoming source address/port by removing --remote or adding --float)

218

Chapter 8

3.By adding a source routing rule to return all the traffic, which:

Comes in on one interface (192.168.4.65) from a host on the other interface (the subnet '192.168.2.0/24')

Wants to leave the interface (192.168.2.0/24)

to the router associated with the incoming subnet (192.168.4.1), the connection is restored:

[root@server]# ip route add to default table 100 dev eth0 \ via 192.168.4.1

[root@server]# ip rule add from 192.168.2.10 priority 50 \ table 100

[root@server]# ip rule add to 192.168.2.10 priority 50 \ table 100

Now, the client can successfully connect to the VPN server.

How it works...

When a connection is made from the client 192.168.2.10 to the VPN server 192.168.4.65, the return route is chosen to be the shortest one possible, which in the setup described here is 192.168.2.1. The server operating system will set the return IP address of the packets to 192.168.2.13, as that is the IP address of the interface associated with that network. This confuses the OpenVPN client, as it connects to host

192.168.4.65 but gets return traffic from 192.168.2.13. By explicitly forcing traffic to go out the other interface (192.168.4.65), this asymmetric routing issue is resolved.

The exact syntax of the source routing rules is highly dependent on the exact network configuration, but the general idea of the three commands outlined in the section

How to do it is to:

Create a routing table with ID 100 and set the default gateway device for this table to eth0, which has IP address 192.168.4.65

Create a routing rule that any traffic which comes from client 192.168.2.10 is redirected to the routing table

Create a routing rule that any traffic which wants to leave to client 192.168.2.10 is redirected to the routing table

The routing rules would need to be tweaked for a live situation, as these rules block out certain other types of network traffic, but the principle is correct.

219

Troubleshooting OpenVPN: Routing

There's more...

More advanced routing control can be done using LARTC ( Linux Advanced Routing and Traffic Control). A better approach would be to mark packets coming on the interface and only redirect the marked packets to the correct outgoing interface.

Routing and permissions on Windows

In this recipe, we will focus on the common error experienced by the users when the VPN client machine is running Windows without full privileges. Under certain circumstances, the OpenVPN client can connect successfully but the routes that are pushed out by the remote server are not correctly set up. This recipe will focus on how to troubleshoot and correct this error. This misconfiguration applies mostly to Windows XP and Windows 2003, as on Windows

Vista/7 other privilege problems may occur.

Getting ready

Install OpenVPN 2.0 or higher on two computers. Make sure the computers are connected over a network. Make sure the server has two separate network connections to a router or to the Internet. 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. Keep the configuration file basic-udp-server.conf from the

Chapter 2 recipe Server-side routing at hand. The client was running Windows XP SP3 and

OpenVPN 2.1.1. Keep the client configuration file, basic-udp-client.ovpn, from the Chapter 2 recipe Using an ifconfig-pool block at hand.

How to do it...

1.Log in as a non-privileged user, being a user without Power User or

Administrator privileges.

2.Start the server using the configuration file basic-udp-server.conf:

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

3.Finally, start the client.

220

Chapter 8

The connection will start and the OpenVPN GUI light will turn green. However, the client

OpenVPN log file will show the following messages:

…C:\WINDOWS\system32\route.exe ADD 10.198.0.0 MASK 255.255.0.0 192.168.200.1

…ROUTE: route addition failed using CreateIpForwardEntry: Network access is denied. [status=65 if_index=2]

…Route addition via IPAPI failed [adaptive]

Thu Aug 26 16:47:53 2010 us=187000 Route addition fallback to route. exe

If you attempt to reach a host on the server-side LAN, it will fail:

[WinClient]C:\>ping 10.198.0.1

Pinging 10.198.0.1 with 32 bytes of data: Request timed out.

Ping statistics for 10.198.0.1:

Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

The solution to this issue is to give the proper networking rights to the user. On Windows XP, this can be done by either adding the user to the group Administrators or by adding the user to the group's Network Administrators. The latter is preferred, as it gives the user the right to only modify some network settings and not the entire system configuration.

How it works...

The OpenVPN client tries to open the TAP-Win32 adapter, which is allowed in a default installation. However, when the server pushes out a route to the client using:

push "route 10.198.0.0 255.255.0.0"

Then, the OpenVPN client will not be able to actually add this route to the system routing tables. However, the VPN connection is successfully established and the GUI client shows a successful connection.

Note that even without the push route statement, the Windows OpenVPN GUI showed a green icon, suggesting the connection had started. Technically speaking, it is true that the connection has been established, but this should still be considered as a bug. However, the current OpenVPN GUI for Microsoft Windows is not actively maintained. The new GUI is currently under development and will hopefully address this issue.

221