« previous 1 2 3 4 5 next »

Building bridges

In its standard configuration, OpenVPN operates in routing mode. That means that VPN uses its own transfer network -- the default is 10.8.0.0/24. In this case, the tunnel endpoints all have addresses from this network and all of the VPN packets are routed through this tunnel. To do this, OpenVPN uses virtual TUN interfaces to enable a point-to-point connection on the IP level.

By default, all VPN packets are routed over the 10.8.0.0/24 transfer network.

In some situations this workaround can be a hindrance; for example, if you are using OpenVPN to perform remote maintenance on a small company network. In this case, the OpenVPN server is often behind a simple router directly in the company network, which is able to perform the necessary port forwarding for the OpenVPN traffic. But it cannot set the necessary routes on all the client systems in the network. In addition, it would be useful for diagnostic purposes to be directly in the local network instead of only being able to access it via routed packets as is the case in the standard configuration.

For such purposes, OpenVPN can connect networks, acting as a bridge. To do this, it creates virtual network cards, or "TAP devices". A bridge interfaces between the TAP devices and the LAN interface such that, for all of the parties involved, it appears that there is an additional network card directly connected to the Ethernet. As a result, the TAP interface gets an IP address from the company network range, for example 192.168.10.0/24. There are a number of advantages to this. For one, all of the network broadcasts are also received by the VPN client. This makes it possible to browse Windows file permissions even without a WINS or Samba server. It also makes it possible to use non-IP protocols like IPX or Appletalk over the VPN. That said, this is less efficient than routing, is not easily scalable, and on the server side at least, somewhat more difficult to set up.

In a simple setup, a range from the LAN network address block, e.g. 192.168.10.230-250, is reserved for the VPN client that is off-limits to the local DHCP server. In server.conf, comment out the dev tun and server directives and activate the dev tap0 and server-bridge directives instead:

dev tap0
;dev tun
;server 10.8.0.0 255.255.255.0
server-bridge 192.168.10.2 255.255.255.0 192.168.10.230 192.168.10.250

In this example, 192.168.10.2 is the address of the server in the LAN -- the server assigns dynamic addresses to the VPN clients from its private pool. Windows finds the appropriate TAP device itself, which means you only need to enter tap in this case without the 0. Now the only thing left to do is activate bridging. This is comparatively easy under Windows XP; you just select the network card and the TAP interface from the list of network connections and select "bridge connections".

Under Linux, you have to create the bridge manually as described in the documentation. If you are running a c't Debian server you simply have to create an additional TAP device in /etc/networks/interfaces and enter it in br0 under bridge_ports. It is important to use dev tap in client.conf as well since TUN and TAP modes do not get along.

« previous 1 2 3 4 5 next »