From the author of

From the author of

VPN client software must work within the constraints of host computers'
operating systems, whether the software is deeply integrated with the operating
system or runs as an application. An overwhelming number of computers run the
Microsoft Windows operating systems, but there are other widely used host
operating systems of interest to VPN users. These include various UNIX 1
varieties and the Apple MacOS X.

Because networking is a major function of today's computers, almost all
modern operating systems have built-in networking functionality. However, few
have strong support for VPN capabilities integrated into the operating system.
As a result, separate VPN client software must be written for those operating
systems that lack the VPN functionality. Furthermore, the same VPN client
software may need to be ported to different operating systems, even for
different release versions of the same operating system.

Because networking capabilities are usually built into the operating system,
the VPN client software cannot avoid making changes to a computer's
operating system. Such OS-level changes are usually difficult to make, and
unless the software developer has the full knowledge of the internals of the OS,
making these changes may inadvertently affect the other operating system
functions.

Usually, a host computer's networking functions are relatively simple.
The philosophy is that sophisticated network layer processing is best left to
the network gateways. RFC 1122 specifies the communication layer requirements
for an Internet host. For outgoing IP packets, RFC 1122 requires that the
host's IP layer do the following:

Set any fields not set by the transport layer

Select the correct first hop on the connected network
(routing)

Fragment the datagram if necessary or if intentional fragmentation is
implemented

Pass the packet(s) to the appropriate link layer driver

Clearly, these simple requirements are no longer adequate to satisfy the
demand for VPN security.

However, to add VPN functionality to the IP or TCP/UDP layer adds substantial
complexity to the networking stack of a computer host. Furthermore, to achieve
all this within the constraints of an existing host operating system is more
demanding.

Windows Network Architecture

The Windows networking architecture is layered, as shown in Figure
1. Physical devices, such as Ethernet cards and modems, are controlled by
device drivers. The device drivers are implemented according to Microsoft's
Network Driver Interface Specification (NDIS). Each device driver is responsible
for accepting a network layer protocol packet and then delivering it to the
network interface device it controls.

DNS server (this is usually a global variable for the host but can be
obtained through the adapter at configuration time)

DHCP servers (if any)

Above the network adapters are the protocol-specific modules, such as TCP/IP
or NetBEUI. Protocol modules bind with adapters according to the specified
configuration at setup time.

VPN Intercept Driver

To provide VPN functions for the Windows operating system, two approaches can
be adopted. First, a software module can be inserted between the protocol layer
and the network adapters. This is usually called a shim or intercept
driver (see Figure
2). In this way, the existing binding between the TCP/IP protocol and the
existing adapters is broken, and the TCP/IP module now binds with the shim module,
which presents itself as a network adapter for the TCP/IP protocol.

The shim module then creates a new series of bindings with the real network
adapters and presents itself as a new network protocol (not TCP/IP). In breaking
all the original bindings between TCP/IP and the real adapters, the shim-based
approach forces all traffic to be routed through the VPN software. This means
that no traffic can bypass the VPN client software, and no change to the host
computer's routing table is necessary. However, it requires that VPN client
software be reinstalled every time a new adapter is created because, when a new
adapter is created, it also creates a new binding between that adapter and the
TCP/IP protocol. This new binding must also be broken if the VPN client is to
function correctly. (Windows NT does provide a mechanism for the intermediate
driver to reexamine the protocol-adapter binding when new driver is installed.
However, implementing this feature has proven to be difficult for many VPN
vendors. Therefore, reinstallation of the VPN software is still preferred.)

A variant of the first approach is to not create a new adapter in the shim
layer. Instead, the shim works within an existing adapter driver chosen at
configuration time. The appropriate properties of the chosen adapter are
modified when the VPN software is in operation. Because the shim is not expected
to change the IP address of the existing adapter, separate address translation
operations must be carried out.

VPN Virtual Adapter

The second approach is to create a new virtual adapter, as shown in Figure
3. Instead of breaking the existing protocol and adapter bindings, it allows
all the original bindings to remain intact. This approach avoids the problem
of having to reinstall the software each time a new adapter is created. However,
for the VPN client to function properly, it must change the routing table so
that all traffic is routed to the new VPN adapter. This approach also allows
the traffic to bypass the VPN adapter if necessary, but in other cases it creates
security vulnerabilities.

Figure 3 Adding
a VPN virtual adapter between TCP/IP and the real adapters.

Creating a shim above the TCP/IP layer is problematic because applications
generally require visibility of the TCP/IP protocol features. If a shim were
placed above TCP/IP, the shim would have to be an entirely new TCP/IP
implementation within the Windows OS.