Chapter 2
Routing: subnets on both sides
This recipe will demonstrate how to set up server-side and client-side routing in client/server mode. With this setup, the OpenVPN client will be able to reach all machines behind the OpenVPN server and the server will be able to reach all machines behind the client.
Getting ready
We use the following network layout:
This recipe uses the PKI files created in the first recipe of this chapter. For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1 and the client was
running Fedora 13 Linux and OpenVPN 2.1.1. Keep the server configuration file, basic-udp- server.conf, as well as the client configuration file, basic-udp-client.conf, from
the recipe Server-side routing at hand.
How to do it...
1. Modify the server configuration file, basic-udp-server.conf, by adding the lines:
client-config-dir /etc/openvpn/cookbook/clients route 192.168.4.0 255.255.255.0 192.168.200.1
Then save it as example2-5-server.conf.
2.Next, create the directory for the client configuration files:
[root@server]# mkdir -m 755 /etc/openvpn/cookbook/clients
49 
Client-server IP-only Networks
3.Place a file in this directory with the name of the client certificate as openvpnclient1 containing:
iroute 192.168.4.0 255.255.255.0
This name can be retrieved from the client certificate file using: $ openssl x509 -subject -noout -in client1.crt
subject= /C=NL/O=Cookbook/CN=openvpnclient1/emailAddress=…
4. Start the server:
[root@server]# openvpn --config example2-5-server.conf
5. Start the client:
[root@client]# openvpn --config basic-udp-client.conf
6.After the VPN is established, we need to set up routing on both sides. Enable the
IP traffic forwarding on the server:
[root@server]# sysctl -w net.ipv4.ip_forward=1
7.Add a route to the LAN B's Gateway to point to the OpenVPN server itself:
[siteB-gw]> ip route add 192.168.4.0/24 via 10.198.1.1 [siteB-gw]> ip route add 192.168.200.0/24 via 10.198.1.1
Here, 10.198.1.1 is the LAN IP address of the OpenVPN server used in this recipe. 8. On the client side:
[client]$ sysctl -w net.ipv4.ip_forward=1
9. And similarly, for the LAN A Gateway:
[siteA-gw]> ip route add 10.198.0.0/16 via 192.168.4.5 [siteA-gw]> ip route add 192.168.200.0/24 via 192.168.4.5
Here, 192.168.4.5 is the LAN IP address of the OpenVPN client used in this recipe. 10. Now, we verify that we can ping a machine on the remote server LAN:
[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=63 time=31.1 ms 64 bytes from 10.198.0.10: icmp_seq=2 ttl=63 time=30.0 ms
And vice versa:
[server]$ ping -c 2 192.168.4.164
PING 192.168.4.164 (192.168.4.164) 56(84) bytes of data.
64 bytes from 192.168.4.164: icmp_seq=1 ttl=64 time=30.2 ms 64 bytes from 192.168.4.164: icmp_seq=2 ttl=64 time=29.7 ms
50
Chapter 2
How it works...
When a client connects to the server with its certificate and with the certificate's common name, openvpnclient1, the OpenVPN server reads the client configuration file (also known as a CCD file) in the client-config-dir directory. The following directive in this file
tells the OpenVPN server that the subnet 192.168.4.0/24 is reachable through the client openvpnclient1:
iroute 192.168.4.0 255.255.255.0
This directive has nothing to do with a kernel routing table, and is only used internally by the OpenVPN server process.
The following server directive is used by OpenVPN to configure the routing table of the operating system so that all the traffic intended for the subnet 192.168.4.0/24 is forwarded to the interface with IP address 192.168.200.1, which is the VPN IP of the server:
route 192.168.4.0 255.255.255.0 192.168.200.1
With the appropriate routing set up on both ends, site-to-site routing is now possible.
There's more...
Masquerading
We could have used masquerading on both ends as well, but with multiple clients, it becomes very hard to keep track of the network traffic.
Client-to-client subnet routing
If another VPN client needs to reach the subnet 192.168.4.0/24 behind client openvpnclient1, the server configuration file needs to extended with the following:
push "route 192.168.4.0 255.255.255.0"
This instructs all clients that subnet 192.168.4.0/24 is reachable through the VPN tunnel, except for client openvpnclient1. The client openvpnclient1 itself is excluded due to the matching iroute entry.
See also
Chapter 1's recipe, Complete site-to-site setup, where it is explained how to connect two remote LANs via a VPN tunnel using a point-to-point setup
51 
Client-server IP-only Networks
Redirecting the default gateway
A very common use of a VPN is to route all the traffic over a secure tunnel. This allows one to safely access a network or even the Internet itself from within a "hostile" environment (for example, a poorly protected, but properly trojaned Internet caféteria).
In this recipe, we will set up OpenVPN to do exactly this. This recipe is very similar to the
Server-side routing recipe, but there are some pitfalls when redirecting all the traffic over a VPN tunnel.
Getting ready
The network layout used in this recipe is the same as in the recipe Server-side routing.
This recipe uses the PKI files created in the first recipe of this chapter. 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 recipe Server-side routing at hand, as well as the client configuration file,
basic-udp-client.conf.
How to do it...
1.Create the server configuration file by adding a line to the basic-udp-server. conf file:
push "redirect-gateway def1"
Save it as example2-6-server.conf. 2. Start the server:
[root@server]# openvpn --config example2-6-server.conf
3.In another server terminal, enable IP-traffic forwarding:
[root@server]# sysctl -w net.ipv4.ip_forward=1
4.Start the client:
[root@client]# openvpn --config basic-udp-client.conf
0
52
Chapter 2
5. After the VPN is established, verify that all traffic is going over the tunnel:
I
The first address in the traceroute output is the address of the OpenVPN server, hence all the traffic is routed over the tunnel.
How it works...
When the client connects to the OpenVPN server, a special route is pushed out by the server to the OpenVPN client:
push "redirect-gateway def1"
The configuration option def1 tells the OpenVPN client to add three routes to the client operating system:
10.198.1.1 via 192.168.4.254 dev eth0 0.0.0.0/1 via 192.168.200.1 dev tun0 128.0.0.0/1 via 192.168.200.1 dev tun0
The first route is an explicit route from the client to the OpenVPN server via the LAN interface. This route is needed as otherwise all the traffic for the OpenVPN server itself would go through the tunnel.
The other two routes are a clever trick to overrule the default route so that all the traffic is sent through the tunnel instead of to the default LAN gateway. The existing default route to the LAN gateway is not deleted due to the def1 parameter.
There's more...
Redirect-gateway parameters
Originally, OpenVPN supported only the directive:
push "redirect-gateway"
This is used to delete the original default route and replace it with a route to the OpenVPN server. This may seem like a clean solution, but in some cases, OpenVPN was unable to determine the existing default route. This often happened to clients connecting through UMTS.
This also used to create routing lockups, where all traffic was routed through the tunnel, including the packets sent by the OpenVPN client itself.
53 