Client-server Ethernet-style Networks
4.The server decrypts the reply packet and determines that the packet needs to be forwarded to first client. Therefore, the packet is not forwarded to the kernel routing modules but is encrypted again and is forwarded to the original client.
There's more...
Broadcast traffic may affect scalability
All machines that are connected to a TAP-style network form a single broadcast domain. When client-to-client is enabled, this means that all the broadcast traffic from all the clients is forwarded to all other clients. Wireshark running on client2 indeed shows a lot of broadcast packets from client1, all of which passed through the OpenVPN server. This can lead to a scalability problem when a large number of clients are connected.
Filtering traffic
In the current version of OpenVPN, it is not possible to filter the traffic between VPN clients when the client-to-client directive is used. A future version of OpenVPN will have this functionality. It is also possible to enable client-to-client communications without the client-to-client directive, but this requires some iptables rules. The advantage is that you can then use the normal iptables commands to filter the client-to-client traffic. The downside is that it is less efficient.
TUN-style networks
The client-to-client directive can also be used in TUN-style networks. It works in exactly the same manner as in this recipe, except that the OpenVPN clients do not form a single broadcast domain.
Bridging—Linux
This recipe will demonstrate how to set up a bridged OpenVPN server. In this mode, the local network and the VPN network are bridged, which means that all the traffic from one network is forwarded to the other and vice versa.
This setup is often used to securely connect remote clients to a Windows-based LAN, but it is quite hard to get it right. In almost all cases, it suffices to use a TUN-style network with a local
WINS server on the OpenVPN server itself. A bridged VPN does have its advantages, however, that will become apparent in the next few recipes.
However, there are also disadvantages to using bridging, especially in terms of performance: the performance of a bridged 100 Mbps Ethernet adapter is about half the performance of a non-bridged adapter.
78
Chapter 3
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 Fedora 12 Linux and OpenVPN 2.1.1. The client computer was running Windows XP and OpenVPN 2.1.1. For the
Windows client, keep the client configuration file example3-2-client2.ovpn at hand.
How to do it...
1.Create the server configuration file:
proto udp port 1194
dev tap0 ## the '0' is extremely important
server-bridge 192.168.4.65 255.255.255.0 192.168.4.128 192.168.4.200
push "route 192.168.4.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/dh1024.pem |
tls-auth /etc/openvpn/cookbook/ta.key 0
persist-key persist-tun keepalive 10 60
user nobody group nobody
daemon
log-append /var/log/openvpn.log
Save it as example-3-3-server.conf.
79 
Client-server Ethernet-style Networks
2.Next, create a script to start the network bridge:
#!/bin/bash
br="br0"
tap="tap0"
eth="eth0" eth_ip="192.168.4.65" eth_netmask="255.255.255.0" eth_broadcast="192.168.4.255"
openvpn --mktun --dev $tap
brctl addbr $br brctl addif $br $eth brctl addif $br $tap
ifconfig $tap 0.0.0.0 promisc up ifconfig $eth 0.0.0.0 promisc up
ifconfig $br $eth_ip netmask $eth_netmask \ broadcast $eth_broadcast
Save this script as example3-3-bridge-start file.
3.And, similarly, use a script for stopping the Ethernet bridge:
#!/bin/bash
br="br0"
tap="tap0"
ifconfig $br down brctl delbr $br
openvpn --rmtun --dev $tap
Save this script as example3-3-bridge-stop file. These scripts are based on the example bridge-start and bridge-stop that are part of the OpenVPN distribution.
4.Create the network bridge and verify that it is working:
[root@server]# bash example3-3-bridge-start
TUN/TAP device tap0 opened Persist state set to: ON
[root@server]# brctl show
bridge name bridge id |
STP enabled interfaces |
||
br0 |
8000.00219bd2d422 no |
eth0 |
|
|
tap0 |
|
|
80
Chapter 3
5. Start the OpenVPN server:
[root@server]# openvpn --config example3-3-server.conf
6. Start the client:
7. Check the assigned VPN address:
[WinClient]C:> ipconfig /all
[…]
Ethernet adapter tun0: Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TAP-Win32 Adapter V9 Physical Address. . . . . . . . . : 00-FF-17-82-55-DB Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.4.128 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . : 192.168.4.0
8. Now, verify that we can ping a machine on the remote server LAN:
[WinClient]C:> ping 192.168.4.164
Pinging 192.168.4.164 with 32 bytes of data:
Reply from 192.168.4.164: bytes=32 time=3ms TTL=64
Reply from 192.168.4.164: bytes=32 time=1ms TTL=64
Reply from 192.168.4.164: bytes=32 time=1ms TTL=64
Reply from 192.168.4.164: bytes=32 time<1ms TTL=64
81 
Client-server Ethernet-style Networks
9. Remember to tear down the network bridge after stopping the OpenVPN server:
[root@server]# bash example3-3-bridge-stop
TUN/TAP device tap0 opened Persist state set to: OFF
How it works...
The bridge-start script forges a bond between two network adapters: on the one side, the LAN adapter eth0 and on the other side, the VPN adapter tap0. The main property of a network bridge is that all the traffic is copied from one side to the other and vice versa. This allows us to set up a VPN where the client almost truly becomes a part of the server-side LAN.
The downside of a bridged network is the increased overhead and the performance penalty on the OpenVPN server itself: if there is a lot of broadcast traffic from many clients on either side, the bridge can become overloaded.
There's more...
Fixed addresses & the default gateway
In this recipe, the OpenVPN server is assigned a fixed address on the server LAN, as is done most often for a bridged interface. The difficulty with assigning a dynamic address to a network bridge is that it is not clear from which network the dynamic address should be chosen. This also enables us to specify a fixed server-bridge address in the server configuration file.
When using bridges, it is also important to check that the default route is available after the bridge is started. In most setups, eth0 is assigned a dynamic address, including a default gateway. When the bridge-start script is executed, br0 is assigned a fixed address, but as a side affect, the default gateway is often lost.
Name resolution
One of the difficulties in setting up a bridged network in the proper fashion is related to name resolution. OpenVPN only does Ethernet (Layer2) or IP-based routing. Setting up a proper name resolution system (for example, a Domain Controller and/or a WINS server in a Windows network) can also be tricky in a bridged environment.
See also
The next recipe in this chapter, in which bridging on a Windows server is explained.
82