Chapter 3

Bridging—Windows

This recipe will demonstrate how to set up a bridged OpenVPN server on Windows. Bridging on Windows is slightly different from Linux or UNIX, but the concept is the same.

This recipe is very similar to the previous recipe, apart from the different methods used to set up bridging.

Getting ready

We use the following network layout:

Set up the client and server certificates using the first recipe from Chapter 2, Client-server IPonly networks.

For this recipe, the server computer was running Windows XP and OpenVPN 2.1.1. The client computer was running Fedora 12 Linux and OpenVPN 2.1.1. For the Linux client, keep the client configuration file example3-1-client.conf at hand.

How to do it...

1.Create the server configuration file:

proto udp port 1194 dev tap

dev-node tap-bridge

server-bridge 172.30.0.50 255.255.255.0 172.30.0.80 170.32.0.250

83

Client-server Ethernet-style Networks

tls-auth "c:/program files/openvpn/config/ta.key" 0 push "route 172.30.0.0 255.255.255.0"

persist-key persist-tun keepalive 10 60

Save it as example-3-4-server.conf.

2.Next, create the network bridge:

Each TAP-Win32 adapter on Windows is assigned a name like Local Area Connection 2. Go to the Network Connections control panel and rename it to tap-bridge.

Next, select tap-bridge and your Ethernet adapter with the mouse, right click, and then select Bridge Connections:

This will create a new bridge adapter icon in the control panel, usually named

Network Bridge (…).

84

Chapter 3

3. The network bridge is now ready to be configured:

4. In a command window, verify that the bridge is configured correctly:

[winserver]C:> netsh interface ip show address "Network Bridge"

Configuration for interface "Network Bridge"

5. Start the OpenVPN server:

[winserver]C:> cd \program files\openvpn\config [winserver]C:> ..\bin\openvpn --config example3-4-server.ovpn

85

Client-server Ethernet-style Networks

6. Start the client:

[root@client]# openvpn --config example3-1-client.conf

7.Now, check the assigned VPN address and verify that we can ping a machine on the remote server LAN:

[client]$ /sbin/ifconfig tap1

tap1 Link encap:Ethernet HWaddr A2:F4:D4:E7:99:CF inet addr:172.30.0.80 Bcast:172.30.0.255 Mask:255.255.255.0

[…]

[client]$ ping -c 2 172.30.0.12

How it works...

Apart from the way the bridge is created and configured, this recipe is very similar to the previous one. The one thing to keep in mind is how the adapter is selected in the server configuration file:

dev tap

dev-node tap-bridge

On Linux and other UNIX variants, this could be achieved using a single line:

dev tap0

But the naming scheme for the TAP adapters on Windows is different. To overcome this, the dev-node directive needs to be added.

See also

The previous recipe, where bridging on Linux is explained.

Checking broadcast and non-IP traffic

The main reason for a bridged setup is to create a single broadcast domain for all 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.

86

Chapter 3

Getting ready

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

For this recipe, the server computer was running Fedora 12 Linux and OpenVPN 2.1.1. For the server, keep the server configuration file example3-3-server.conf from the recipe Bridging—Linux ready. The first client computer was running Windows 2000 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 recipe Enabling client-to-client traffic at hand.

Make sure that the Appletalk and IPX protocols are installed on both 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

87

Client-server Ethernet-style Networks

2. Start the OpenVPN server:

[root@server]# openvpn --config example3-3-server.conf

3. Start the OpenVPN clients:

[WinClient1]C:> cd \program files\openvpn\config [WinClient1]C:> ..\bin\openvpn --config example3-2-client2.ovpn

Client 2:

In this recipe, the Windows 2000 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 tcpdump and listen for traffic on the bridge interface br0:

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.

88

Chapter 3

5.Next, on the Windows 2000 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 Wireshark to capture all the traffic from the

Ethernet adapter.

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

89