The main reason for a bridged setup is to create a single broadcast domain for all the clients connected, both via the VPN and via a regular network connection.
Another reason is the ability to route or forward non-IP based traffic, such as the older Novell IPX and Appletalk protocols.
This recipe focuses on the use of tools such as tcpdump and wireshark to detect whether the broadcast domain is functioning and if non-IP traffic is flowing in the correct manner.
For this recipe, we use the setup from the Bridging - Linux recipe of this chapter. We use the following network layout:
For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.9. For the server, keep the server configuration file example3-3-server.conf from the Bridging - Linux recipe ready. The first client computer was running Windows 7 64 bit and OpenVPN 2.3.10 and was in the same LAN segment as the OpenVPN server. The second client was running Windows XP and OpenVPN 2.1.1. For this client, keep the client configuration file example3-2-client2.ovpn from the Enabling client-to-client traffic recipe at hand.
Make sure that the AppleTalk and IPX protocols are installed on both the Windows machines. Bind the protocols to the Local Area Network adapters (this is the default setting).
- 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 OpenVPN clients:
[WinClient1]C:> cd program filesopenvpnconfig [WinClient1]C:> ..inopenvpn --config example3-2- client2.ovpn
Start Client 2 using the OpenVPN GUI:
In this recipe, the Windows 7 client was assigned
192.168.4.64. The Windows XP client was assigned192.168.4.128. - After the client has successfully connected, we first check for ARP messages. On the server, run the
tcpdumpcommand and listen for traffic on the bridge interfacebr0:
In this output,
192.168.4.254is the address of the server-side gateway. So the gateway is asking for ARP information and the ARP replies are coming from both the OpenVPN server and the OpenVPN client itself. This can only happen if the ARP request is forwarded over the bridge to the OpenVPN client. - Next, on the Windows 7 client, check for the broadcast traffic coming from the Windows XP client. For this, we use Wireshark. Wireshark is available for both Linux and Windows. Configure it to capture all of the traffic from the Ethernet adapter. Here's an example of it:
In this output, we see a lot of Netbios broadcast traffic when the OpenVPN client first connects to the network.
- As a final example, we look for IPX traffic:
This shows that non-IP traffic is also forwarded over the bridge.
All of the traffic that is forwarded over the bridge is intercepted by programs such as Wireshark. By filtering for certain types of traffic, it is easy to show that in a bridged setup, traffic from the OpenVPN clients is indeed flowing over the server-side LAN. This is very important when troubleshooting an almost-working setup.