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 with it, 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 Server-side routing recipe from the previous chapter.
Set up the client and server certificates using the first recipe from Chapter 2, Client-server IP-only Networks. For this recipe, both the server computer and the client computer were running CentOS 6 Linux and OpenVPN 2.3.10.
We use the following network layout:
- Create the server configuration file:
tls-server proto udp port 1194 dev tap server 192.168.99.0 255.255.255.0 tls-auth /etc/openvpn/cookbook/ta.key 0 ca /etc/openvpn/cookbook/ca.crt cert /etc/openvpn/cookbook/server.crt key /etc/openvpn/cookbook/server.key dh /etc/openvpn/cookbook/dh2048.pem persist-key persist-tun keepalive 10 60 push "route 10.198.0.0 255.255.0.0" user nobody group nobody # use "group nogroup" on some distros 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 remote-cert-tls server tls-auth /etc/openvpn/cookbook/ta.key 1 ca /etc/openvpn/cookbook/ca.crt cert /etc/openvpn/cookbook/client1.crt key /etc/openvpn/cookbook/client1.key
Save it as
example-3-1-client.conf. - Start the client:
[root@client]# openvpn --config example3-1-client.confThe output generated is shown as follows:
- After the connection is established, we can verify that it is working. First, we ping 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 ms
Second, we 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 the IP address 192.168.99.1. After that, the server listens on the UDP port 1194 for incoming connections, which serves as an 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 this, the VPN is established.
Apart from the OpenVPN configuration, this recipe also uses an iptables command to enable the client to reach Site B's LAN without having to set up additional routes on Site B's LAN gateway. The following command instructs the Linux kernel to rewrite all of the traffic coming from the subnet 192.168.99.0/24 (which 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. The iptables module 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 would not be possible to distinguish traffic on 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 a few things to keep in mind when setting up a TAP-style network.
The differences between this setup and the Server-side routing recipe 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 be easily converted to use the TCP protocol by changing the following line:
proto udp
Change this 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 such cases, the TCP protocol often does work.
- The Server-side routing recipe from Chapter 2, Client-server IP-only Networks, in which a basic TUN-style setup is explained