Checking broadcast and non-IP traffic

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.

Getting ready

For this recipe, we use the setup from the Bridging - Linux recipe of this chapter. We use the following network layout:

Getting ready

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).

How to do it...

  1. 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
    
  2. Start the OpenVPN server:
          [root@server]# openvpn --config example3-3-server.conf
    
  3. Start the OpenVPN clients:
          [WinClient1]C:> cd program filesopenvpnconfig
          [WinClient1]C:> ..inopenvpn --config example3-2-
              client2.ovpn
    

    Start Client 2 using the OpenVPN GUI:

    How to do it...

    In this recipe, the Windows 7 client was assigned 192.168.4.64. The Windows XP client was assigned 192.168.4.128.

  4. After the client has successfully connected, we first check for ARP messages. On the server, run the tcpdump command and listen for traffic on the bridge interface br0:
    How to do it...

    In this output, 192.168.4.254 is 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.

  5. 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:
    How to do it...

    In this output, we see a lot of Netbios broadcast traffic when the OpenVPN client first connects to the network.

  6. As a final example, we look for IPX traffic:
    How to do it...

    This shows that non-IP traffic is also forwarded over the bridge.

How it works...

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.138.34.75