Determining Routing for VPN Remote Access Clients
Applies To: Windows Server 2008, Windows Server 2008 R2
Because VPN remote access clients typically do not support routing protocols such as Routing Information Protocol (RIP), 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 all packets to the remote network. This is the default configuration for VPN remote access clients. Any packet for which an explicit route is not found is sent to the remote network. Typically, the only route on a client is a route to the subnet to which the local network adapter is attached. There is one of these routes for each network adapter. All other traffic is sent to the default gateway.
By default when a connection is made, the remote access client 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 new default route points to the new connection, which ensures that any packets that are not addressed to a 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 directly 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 organization’s intranet, but not to both:
If the default route to the gateway for the remote network is not being used, Internet locations are reachable, but only intranet locations matching the subnet address of the assigned IP address can be reached through the VPN. Addresses on the other side of routers on the intranet cannot be reached.
If the default route to the gateway for 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 defined routes in the routing table can be reached on the Internet through the VPN. All Internet-destined traffic is sent across the VPN connection to the VPN server and must be routed to the Internet through the organizations network by using routes defined on the VPN server.
To work around this problem, instead of having the client create a new default route when a connection is made, you can configure the routing table on the client with specific routes that direct packets to the organization’s network over the VPN connection. While connected to the intranet, the client can still obtain Internet access by using the existing default route over the connection to the ISP. This configuration is known as split tunneling.
Split tunneling has several benefits:
Performance for the client is improved, since only traffic that must go to the VPN server actually does. Traffic destined for the Internet goes directly to the clients ISP instead of being routed through the organization’s intranet.
Network traffic on the VPN server and corporate network is reduced because the only traffic coming to the VPN server is traffic destined for the corporate intranet. No traffic destined for the Internet is sent through the VPN server.
Security considerations for split tunneling
Some network administrators consider split tunneling to be a 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 by using the remote access client. This risk is easily mitigated by blocking all inbound traffic to the VPN server that does not originate on the remote access client. To do this, add packet filters to the remote access network policy on the VPN server by using the Settings tab that force the VPN connection to allow only inbound traffic that originates from remote access clients. The default remote access network policy named Connections to Microsoft Routing and Remote Access server has these packet filters already configured.
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 automatically adds a single route that it infers from the class of the IP address assigned to it for the VPN connection. For a simple target network, such as a small office, this one route is often 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 all of the subnets on the remote network.
A client running Windows 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 remote access server has been configured to relay the DHCPINFORM message to the DHCP server, and if the DHCP server has been configured to provide the DHCP Classless Static Routes option.
If the remote access client is managed by using Connection Manager Administration Kit (CMAK), 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 CMAK, see Connection Manager Administration Kit.
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.
Obtaining IP addresses for remote access clients
Use either of the following methods to obtain IP addresses to assign to remote access clients:
Let RRAS assign IP addresses obtained from a DHCP server to remote access clients.
In RRAS, 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.