This recipe will demonstrate how to set up a TAP-based connection in client or server mode using certificates. It also uses masquerading to allow the OpenVPN clients to reach all the machines behind the OpenVPN server. The advantage of masquerading is that no special routes are needed on the server LAN. Masquerading for OpenVPN servers is available only on the Linux and UNIX variants. This recipe is similar to the recipe Server-side routing from the previous chapter.
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 5 Linux and OpenVPN 2.1.1. The first client was running Fedora 12 Linux and OpenVPN 2.1.1.
- Create the server configuration file:
tls-server proto udp port 1194 dev tap server 192.168.99.0 255.255.255.0 ca /etc/openvpn/cookbook/ca.crt cert /etc/openvpn/cookbook/server.crt key /etc/openvpn/cookbook/server.key dh /etc/openvpn/cookbook/dp024.pem tls-auth /etc/openvpn/cookbook/ta.key 0 persist-key persist-tun keepalive 10 60 push "route 10.198.0.0 255.255.0.0" user nobody group nobody daemon log-append /var/log/openvpn.log
Save it as
example-3-1-server.conf. Note that on some Linux distributions, the groupnogroupis used instead ofnobody. - Start the server:
[root@server]# openvpn --config example3-1-server.conf - Set up IP forwarding and an
iptablesmasquerading rule:[root@server]# sysctl -w net.ipv4.ip_forward=1 [root@server]# iptables -t nat -I POSTROUTING -i tap+ -o eth0 \ -s 192.168.99.0/24 -j MASQUERADE
- Next, create the client configuration file:
client proto udp remote openvpnserver.example.com port 1194 dev tap nobind ca /etc/openvpn/cookbook/ca.crt cert /etc/openvpn/cookbook/client1.crt key /etc/openvpn/cookbook/client1.key tls-auth /etc/openvpn/cookbook/ta.key 1 ns-cert-type server
Save it as
example-3-1-client.conf. - Start the client:
[root@client]# openvpn --config example3-1-client.conf
- After the connection is established, we can verify that it is working by pinging the server:
[client]$ ping -c 2 192.168.99.1 PING 192.168.99.1 (192.168.99.1) 56(84) bytes of data. 64 bytes from 192.168.99.1: icmp_seq=1 ttl=64 time=25.3 ms 64 bytes from 192.168.99.1: icmp_seq=2 ttl=64 time=25.2 msAnd that we can ping a host on the server-side LAN:
[client]$ ping -c 2 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=29.2 ms 64 bytes from 10.198.0.1: icmp_seq=2 ttl=63 time=25.3 ms
When the server starts, it configures the first available TAP interface with IP address 192.168.99.1. After that, the server listens on the UDP port 1194 for incoming connections that serves as a OpenVPN default.
The client connects to the server on this port. After the initial TLS handshake using both the client and server certificates, the client is assigned the IP address 192.168.99.2. The client configures its first available TAP interface using this information, after which the VPN is established.
Apart from the OpenVPN configuration, this recipe also uses an iptables command to enable the client to reach the Site B's LAN without having to set up additional routes on the Site B's LAN gateway. The following command instructs the Linux kernel to rewrite all the traffic that is coming from the subnet 192.168.99.0/24 (that is our OpenVPN subnet) and that is leaving the Ethernet interface eth0:
[root@server]# iptables -t nat -I POSTROUTING -i tap+ -o eth0 \ -s 192.168.99.0/24 -j MASQUERADE
Each of these packets has its source address rewritten so that it appears as if it is coming from the OpenVPN server itself instead of coming from the OpenVPN client. iptables keeps track of these rewritten packets so that when a return packet is received, the reverse is done and the packets are forwarded back to the OpenVPN client again. This is an easy method to enable routing to work, but there is a drawback when many clients are used: it is no longer possible to distinguish traffic on the Site B's LAN if it is coming from the OpenVPN server itself, from client1via the VPN tunnel or from clientN via the VPN tunnel.
There are several pitfalls to watch out for when using the 'client-to-client' directive. A few of the most common ones are outlined here.
The differences between this setup and the recipe Server-side routing of the previous chapter are minimal. There are a few subtle differences, however, which can lead to unforeseen effects if you are not aware of them:
- When using a TAP adapter, the full Ethernet frame is encapsulated. This causes a slightly larger overhead.
- All the machines that are connected to a TAP-style network form a single broadcast domain. The effects of this will become clearer in the next recipe.
- If bridging is needed, a TAP-style tunnel is required.
In this example, we chose the UDP protocol. The configuration files in this recipe can easily be converted to use TCP protocol by changing the line:
proto udp
Change it to:
proto tcp
Do this in both the client and server configuration files.
The UDP protocol normally gives optimal performance, but some routers and firewalls have problems forwarding UDP traffic. In that case, the TCP protocol often does work.
- Chapter 2's recipe, Server-side routing, in which a basic TUN-style setup is explained.