3
Client-server Ethernet-style Networks
In this chapter, we will cover:
Simple configuration—non bridged
Enabling client-to-client traffic
Bridging—Linux
Bridging—Windows
Checking broadcast and non-IP traffic
External DHCP
Using the status file
Management interface
Introduction
The recipes in this chapter will cover the deployment model of a single server with multiple remote clients capable of forwarding Ethernet traffic.
We will look at several common configurations, including bridging, the use of an external DHCP server, and also the use of the OpenVPN status file.
Please note that bridging should only be used as a last resort. Most of functionality provided by bridging can be achieved through other methods. Moreover, there are many disadvantages to using bridging, especially in terms of performance and security.
Client-server Ethernet-style Networks
Simple configuration—non-bridged
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.
Getting ready
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.
How to do it...
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 |
70
Chapter 3
dh /etc/openvpn/cookbook/dh1024.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 group nogroup is used instead of nobody.
2. Start the server:
[root@server]# openvpn --config example3-1-server.conf
3.Set up IP forwarding and an iptables masquerading 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
4.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.
71 
Client-server Ethernet-style Networks
5. Start the client:
[root@client]# openvpn --config example3-1-client.conf
6.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 ms
And 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
How it works...
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.
72
Chapter 3
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's more...
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.
Differences between TUN and TAP
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.
Using the TCP protocol
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
73 