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.
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 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 the IP address 192.168.2.13 by default. The secondary gateway had the IP address 192.168.4.1. The client was running Windows 7 64bit and OpenVPN 2.3.11. The client IP address was 192.168.2.10 with default route 192.168.2.1. Keep the configuration file basic-udp-server.conf from the Server-side routing recipe from Chapter 2, Client-server IP-only Networks, as well as the client configuration file basic-udp-client.ovpn from the Using an ifconfig-pool block recipe from Chapter 2, Client-server IP-only Networks.
- Start the server using the configuration file
basic-udp-server.conf:[root@server]# openvpn --config basic-udp-server.conf - Next, start the client:
- In this configuration, the remote server address
openvpnserver.example.comresolves to192.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) - 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 subnet192.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.
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
100and set the default gateway device for this table toeth0, which has the IP address192.168.4.65 - Create a routing rule that any traffic which comes from client
192.168.2.10is redirected to the routing table - Create a routing rule that any traffic which wants to leave client
192.168.2.10is 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.