The VPN Client and the Windows Operating System
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.
){kind=link}
Figure 1 Windows network architecture.
The following parameters are associated with each device driver:
Adapter hardware MAC address
Adapter IP address and netmask
Default gateway associated with this adapter
Windows Internet Service (WINS) servers
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.
){kind=link}
Figure 2 Adding a shim between TCP/IP and the adapters.
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.
){kind=link}
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.