In this recipe, we will demonstrate how to troubleshoot a common issue related to bridging. OpenVPN bridging can be tricky to configure, as the warning and error messages can be confusing. In this recipe, we will make one of the common misconfigurations and then show how to troubleshoot it.
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 6 Linux and OpenVPN 2.3.11, and the client was running Fedora 22 Linux and OpenVPN 2.3.11. Keep the scripts, example3-3-bridge-start and example3-3-bridge-stop, from the Bridging - Linux recipe from Chapter 3, Client-server Ethernet-style Networks, handy along with the client configuration file, example-3-2-client2.ovpn, from the Enabling client-to-client traffic recipe, from Chapter 3, Client-server Ethernet-style Networks.
- Create the server configuration file:
proto udp port 1194 dev tap 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
Note that we did not explicitly specify the adapter name (tap0). Save it as
example-6-9-server.conf. - 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 example6-9-server.conf - Start the client:
- Now, try to reach the server:
[WinClient]C:> ping 192.168.4.65Even though the connection is established, the client will fail to reach the server.
Remember to shut down the Ethernet bridge after stopping the OpenVPN server process.
The connection failures in this example are due to the fact that the OpenVPN server opened a new tap adapter at startup instead of connecting to the bridge. A hint is given in the server log file:
... TUN/TAP device tap1 opened
When checking the tap interfaces on the server, we see that there are now two tap interfaces:
[root@server]# ip addr show ... 39: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 00:25:90:c0:3e:d0 brd ff:ff:ff:ff:ff:ff inet 192.168.4.65/24 brd 192.168.4.255 scope global br0 inet6 fe80::225:90ff:fec0:3ed0/64 scope link valid_lft forever preferred_lft forever 40: tap1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 100 link/ether ae:9f:3e:ae:93:ba brd ff:ff:ff:ff:ff:ff
The second tap interface, tap1, is the one in use by OpenVPN, and it does not have an IP address assigned!
To solve this issue, the correct tap adapter needs to be specified in the server configuration file.
- The Linux - bridging recipe, from Chapter 3, Client-server Ethernet-style Networks, which explains in detail how to set up bridging on Linux in detail