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.
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
.
#!/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.
#!/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 bridge-start
and bridge-stop
examples, which are part of the OpenVPN distribution.
[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
[root@server]# openvpn --config example3-3-server.conf
[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
[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
[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.
3.22.66.140