Routing refers to the interconnection of separate and independent "sub-networks" (subnets) which have non-overlapping ranges of IP addresses. Upon receiving a packet sent to it, a network "router" examines the destination IP address to determine which of several connected networks should receive it, after which that packet is forwarded to the proper network.

 Bridging, by comparison, is much simpler. A network "bridge" is simply an electrical interconnection between separate physical networks that are all carrying the same ranges of IP addresses. Standard dumb network "hubs" and "switches" are examples of network bridges. With a hub, packets arriving at any port are "bridged" and sent out to every other port. A switch is a bit smarter, since it is able to adaptively learn which network interface cards (NICs) are attached to which ports. But a switch is still interconnecting network segments carrying the same ranges of IP addresses.

Making the choice for OpenVPN

Although "routed" connections are the most common and straightforward to configure, they suffer from significant operational limitations which we examine below. By comparison, "bridged" connections are generally much trickier to configure, and are not even natively available under all operating systems, so they are not the default connection type. But when bridging is properly setup it correctly does everything that we want.

How Packets Travel

Ethernet protocol networks, which have become the universal network 'glue' for interconnecting local groups of machines, act like a single 'wire' that everyone on the same network shares:

Every computer on a simple Ethernet LAN can directly "see" and contact every other computer on the LAN. Any packet addressed to another computer on the LAN which is placed onto the local network segment will be received by the computer that packet is addressed to. So packets can be sent directly back and forth between machines.

When this little LAN network is connected to any other network, such as the global Internet, a "Gateway" is designated to receive any Ethernet LAN packets that are not addressed to any of the local computers:

Every computer on the LAN knows it's own IP address. It uses it's own IP and the LAN's "subnet mask" to determine whether any packet it is sending to another machine is addressed to another computer on its own LAN, or to some computer lying outside of the LAN's local IP range.

If the packet is being sent to a local computer, the packet is addressed directly to that machine — since, as we've seen, every machine on the local LAN can directly receive anything seen by any other local machine.

But if the packet is being sent to a non-local destination, the packet is sent to the LAN's designated Gateway for subsequent "routing" outside of the LAN and toward the packet's own home network.

OpenVPN Routing

When OpenVPN's virtual adapter is configured for "Routing" of virtual VPN connections, its adapter is given an IP address outside of the range of the local LAN and a separate "virtual subnet" is created for connecting to any remote VPN computers. Those remotely connected computers receive IP addresses within this newly created separate subnet.

This virtual subnet must have a separate IP range from the physical LAN so that the computer running OpenVPN knows whether to "route" packets out to the virtual subnet, or to another machine on the local LAN, or out to the LAN's gateway:

OpenVPN in "routing mode" creates a private network shared by the machines connecting to it through secure VPN tunnels. This is a great solution if the remotely connecting VPN user(s) only wish to have a connection to machine running OpenVPN, but trouble arises if the remote VPN user wants to access any other resources of the local LAN network, or to securely access the Internet through this LAN.

The problem arises because none of the other computers on the local LAN, including the LAN's gateway, have any way of knowing about the new virtual subnet that was created by OpenVPN. Essentially, OpenVPN is the "gateway" for the virtual subnet, but all of the machines on the main physical LAN already have a "gateway" defined for non-local packet destinations. So if the OpenVPN machine were to send a packet on behalf of one of its remote VPN users to one of the other local machines on the LAN, that machine would see that the packet came from an IP address outside of its own local LAN . . . and would direct any reply packets to the LAN's gateway rather than back to the OpenVPN machine for forwarding to the remote VPN user.

The upshot of this is the big "gotcha" that hits and deeply frustrates most first-time users of OpenVPN. They can connect to the OpenVPN machine itself, but they can't reach any other resources on the LAN, nor the Internet through their LAN.

Now . . . networking technology is powerful enough that it is possible for the various machines on the local LAN to be "informed" about the private virtual subnet created by the OpenVPN machine so that they will direct any outbound packets to the OpenVPN machine instead of the LAN's gateway. The process is known as defining "static routes" which would be placed into every other network machine on the LAN. But this requires manual configuration of network routing tables, and many simple network appliances such as networked printers, gateway routers, and other devices lack any provision for this sort of advanced packet routing.

Routed OpenVPN configurations are useful if the machine running the OpenVPN server is the same machine which is serving as the LAN's gateway. Then all of the machines on the LAN will send their packets back to the gateway machine, which OpenVPN will route back out to the remote user(s). Advanced users who are already running a Linux or Unix machine as their network gateway may wish to explore this configuration. But this GRC guide is focusing upon the more common configuration of using an existing Windows 2000 or XP machine as the OpenVPN server where it is not also the network's gateway.

OpenVPN Bridging to the Rescue

For our purposes, the alternative and superior solution is to setup OpenVPN's virtual adapter in a "bridging" configuration. As the diagram below highlights, this has the effect of placing any remotely connecting users directly onto the main physical LAN:

Remote users receive an IP address that is within the same IP range as the other computers on the LAN. The computer running the OpenVPN server not only responds to its own address, but also any others belonging to the connected VPN users. Since remotely-connected users are effectively connected to and "on" their home LAN, their remotely connected computers receive a home LAN IP address, and they are able to transparently access any resources that are present on the LAN – exactly as if their computer was plugged directly into their home router or hub.

Another significant benefit of bridging over routing is that Ethernet bridging passes all Ethernet network traffic whereas IP routing only handles "directed" IP packet traffic. Network wide "broadcasts" are inherently local in scope. Broadcasts are passed along by hubs, switches, and bridges, but not by routers. This is crucial, otherwise the global Internet would be swamped with "broadcasts" and the world would end. But the Windows "Network Neighborhood" file and printer browsing depends upon network broadcasts to allow locally connected machines to find each other on the LAN. This important and useful functionality continues to function perfectly over bridged OpenVPN connections, but is not available over OpenVPN's routed connections. This is another common source of frustration for first-time OpenVPN users.

The bridging problem

All IP-capable operating systems inherently understand and are able to perform some degree of IP routing. They must be able to in order to function within an IP network. But bridging is so seldom needed that it is often not available at all, or quite obscure if offered. Windows XP is the first Microsoft operating system to support network bridging. So even though OpenVPN runs under Windows 2000, bridging has never before been possible on Windows platforms.

Linux and all of the many various flavors of Unix support network interface bridging, but because bridging operates at a low level within the operating system, its implementation is heavily influenced by each operating system's low level architecture. As a result, every one of those many operating systems has implemented bridging in their own different and incompatible way.

GRC's Bridging solutions

 For Windows 2000: Unfortunately, Windows 2000 does not support ethernet interface bridging natively. So this is a problem we will need to solve for deployment of bridging under Win2k.

 For Windows XP: Fortunately, Windows XP (and all subsequent) operating systems does offer built-in Ethernet bridging, so we'll describe the process of using Windows XP native interface bridging to create the optimal solution under Windows XP.

 For FreeBSD: FreeBSD is my personal favorite flavor of the Unix operating system. Whereas Linux is, of course, the wildly popular "Unix-like" operating system, FreeBSD is actually real Unix. Since I am using FreeBSD as my OpenVPN server in several locations — and on Unix machines which are not my network gateways — I needed to unravel and figure out how to smoothly create network interface bridges under FreeBSD. It was a nightmare, but I have it working perfectly. So I have carefully documented that rather complex and initially mystifying process for anyone who wishes to use FreeBSD as their OpenVPN server platform.

 For Linux??: This guide does not provide instructions for implementing bridging under Linux or any other operating systems (and it wouldn't have for FreeBSD if I had not needed to figure it out for my own purposes). But there are plenty of resources and HowTo's available on the Internet for Linux and other operating systems. The official OpenVPN web site has a page dedicated to Ethernet Bridging with ample coverage and examples for setting up bridging under Linux.