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 of 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, as 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.
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 was running CentOS 6 Linux and OpenVPN 2.3.10. The client computer was running Windows 7 64 bit and OpenVPN 2.3.10. For the client, keep the client configuration file example3-2-client2.ovpn at hand.
- 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" 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 user nobody group nobody # use "group nogroup" on some distros daemon log-append /var/log/openvpn.log
Save it as
example-3-3-server.conf. - 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_broadcastSave this script as
example3-3-bridge-startfile. - Similarly, use a script to stop 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-stopfile. These scripts are based on thebridge-startandbridge-stopexamples, which are part of the OpenVPN distribution. - 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
- Start the OpenVPN server:
[root@server]# openvpn --config example3-3-server.conf - Start the client:
- 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
- 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
- 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
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 of 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.
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 effect, the default gateway is often lost.
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 be tricky in a bridged environment as well.