Determining Routing for VPN Remote Access Clients

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Because VPN remote access clients typically do not support routing protocols such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF), the clients often have very simple routing tables. Your remote access design must provide a method for routing packets from the remote access clients to the intranet and the Internet — in some cases simultaneously, depending on the needs of the remote user.

For example, a computer on a small local area network (LAN) has a route to its own subnet on the LAN, and it might have a default route to a gateway router on the LAN for all other traffic. Without routing protocol support, remote access clients cannot automatically determine the best route to a destination.

Choosing Between Routing Approaches

The preferred method for directing packets to a remote network is to create a default route on the remote access client that directs packets to the remote network (the default configuration for VPN remote access clients). Any packet that is not intended for the neighboring LAN segment is sent to the remote network. When a connection is made, the remote access client by default adds a default route to its routing table and increases the metric of the existing default route to ensure that the newest default route is used. The newest default route points to the new connection, which ensures that any packets that are not addressed to the local LAN segment are sent to the remote network.

Under this configuration, when a VPN client connects and creates a new default route, Internet sites that have been accessible are no longer accessible. This poses no problem for VPN remote access users who only require access to the organization’s network. However, it is not acceptable for remote users who need access to the Internet while they are connected to the organization’s network.

Based on whether or not the default route is added, the client has broad access either to Internet locations or to locations on the intranet, but not to both:

  • If the default gateway on the remote network is not being used, Internet locations are reachable, but only intranet locations matching the address class of the assigned IP address can be reached.

  • If the default gateway on the remote network is being used, all intranet locations are reachable, but only the IP address of the VPN server and locations available through other routes can be reached on the Internet.

For most VPN clients with an Internet connection, this does not present a problem, because the client is typically engaged in either intranet communication or Internet communication, but not both.

To work around this problem, instead of having the client create a new default route when a connection is made, you can configure the client’s routing table with specific routes that direct packets to the organization’s network over the VPN connection. While connected to the intranet, the client can obtain Internet access using the existing default route over the connection to the ISP. This configuration is known as split tunneling.

Choosing Among Split Tunneling Options

The VPN client can obtain the routes needed for split tunneling in several ways:

  • If the VPN client has a configured connection without a default route, the client adds a route that it infers from the class of the IP address assigned to it for the current connection. For a simple target network, such as a small office, this one route is sufficient to allow packets to be routed to the target network. However, for a complex network, you need to configure multiple routes to successfully direct packets to the remote network.

  • A client running the Microsoft® Windows® XP or Windows Server 2003 operating systems uses a DHCPINFORM message after the connection to obtain additional information about the connection, such as a DNS name or a set of routes for the target network. This additional information is only available if the DHCP server has been configured to provide the DHCP Classless Static Routes option, and if the remote access server has been configured to relay the DHCPINFORM message to the DHCP server.

  • If the remote access client is managed using the Connection Manager component of Windows Server 2003, the network administrator can prepare a routing table for the remote access client and associate a post-connect action with the managed connection to update the client’s routing table when a connection is made. For more information about using Connection Manager, see "Deploying Remote Access Clients Using Connection Manager" in this book.

  • If none of the above approaches meets your needs, the end user or network administrator can write a program or batch file that updates the routing table on the client with the necessary routes to the remote network.

Security considerations for split tunneling

Some network administrators consider split tunneling to be a needless security risk. Their concern is that an attacker might be able to compromise the network by enabling traffic to be routed between the Internet and the network using the remote access client. To prevent this, you can add packet filters to the remote access policy profile settings for the VPN connection to allow only inbound traffic that originates from remote access clients. The default remote access policy named Connections to Microsoft Routing and Remote Access server has these packet filters already configured.

Obtaining IP Addresses for Remote Access Clients

Use either of the following methods to obtain IP addresses to assign to remote access clients:

  • Let Routing and Remote Access assign IP addresses obtained from a DHCP server to remote access clients.

  • Configure a static pool of IP addresses to assign to remote access clients. You can specify either an on-subnet or off-subnet range of IP addresses for the static pool.