The Cable Guy - August 2003

IP Address Assignment and the Routing and Remote Access Service

By The Cable Guy

Remote access clients, when using either a dial-up or virtual private network (VPN) connection, are assigned an IP address through the Internet Protocol Control Protocol (IPCP) IP Address option (RFC 1332) during the negotiation of the Point-to-Point (PPP) connection. The remote access server obtains the IP addresses that are assigned to remote access clients from either a DHCP server or a static pool of IP addresses configured locally.

There are different types of addresses that can be assigned to a remote access client by the Routing and Remote Access service: either an on-subnet address or an off-subnet address. The type of address that is used can have an impact on reachability, unless additional changes are made to the routing infrastructure.

Note   This article only describes the IP address assignment behavior of the Routing and Remote Access service when the remote access client is configured to obtain an IP address automatically, when the remote access policies for remote access connections are configured to allow the remote access server to supply an address, and when the dial-in properties of the user account are not configured to use a static IP address.

Types of IP addresses assigned to remote access clients

The IP addresses assigned to remote access clients can be from an:

• On-subnet address range

  An address range of an intranet subnet to which the remote access server is attached. It is used whenever the remote access server obtains IP addresses for remote access clients from a DHCP server or when the manually configured static pool contains IP addresses that are within the range of addresses of an attached subnet.

  The advantage to using on-subnet addresses is that no changes to routing infrastructure are required.

• Off-subnet address range

  An address range that represents a different subnet that is logically attached to the remote access server. It is used when the static pool contains IP addresses that are located on a separate subnet.

  The advantage to using off-subnet addresses is that the IP addresses of remote access clients are more easily identified.

The type of address determines how traffic is forwarded from intranet nodes to connected remote access clients.

When a connected remote access client sends a packet, the following occurs:

1. The packet is sent across the PPP link to the remote access server.
2. The remote access server uses the IP forwarding process to forward the packet to either a neighboring host on an attached subnet or, more likely, a neighboring router on an attached intranet subnet. For more information about the IP forwarding process, see Understanding the IP Routing Table (the December 2001 The Cable Guy article).

When traffic is sent to remote access clients, the process of delivering it to the remote access server is different, depending on whether the remote access client has been assigned an on-subnet or off-subnet address.

Packet delivery for on-subnet addresses

For an on-subnet address, the remote access server acts as a proxy Address Resolution Protocol (ARP) device, responding to ARP Request frames for the IP addresses assigned to connected remote access clients. The remote access server maintains a list of IP addresses assigned to remote access clients and responds to ARP requests on their behalf.

The process for delivering a packet to a remote access client that is using an on-subnet address is the following:

1. A node on an intranet subnet (to which the remote access server is attached) sends an ARP Request frame requesting the MAC address of the node that is assigned the IP address of the remote access client.
2. The remote access server receives the ARP request, checks its table of connected remote access clients and, finding a match, responds to the ARP request with an ARP Reply message containing its own MAC address.
3. The node on the intranet subnet forwards the packet to the remote access server.
4. The remote access server receives the packet, checks the destination IP address, determines the corresponding PPP connection, and then forwards the packet over the PPP connection.

For on-subnet addresses, the neighboring node performs a direct delivery as if the remote access client is directly attached to the subnet of the neighboring node. The neighboring node is not aware that the destination is actually available across the remote access server.

Packet delivery for off-subnet addresses

For off-subnet addresses, the remote access server acts as a router, forwarding the packet between a neighboring node on an attached subnet (typically a router) and a connected remote access client. The process for delivering a packet to a remote access client that is using an off-subnet address is the following:

1. A node on an intranet subnet (to which the remote access server is attached) sends an ARP Request frame requesting the MAC address corresponding to the IP address of the remote access server.
2. The remote access server responds to the ARP request with an ARP Reply message containing its own MAC address.
3. The node on the intranet subnet forwards the packet to the remote access server.
4. The remote access server receives the packet, checks the destination IP address, determines the corresponding PPP connection, and then forwards the packet over the PPP connection.

For off-subnet addresses, the neighboring node performs an indirect delivery, treating the remote access server as a router.

In order for remote access clients that are assigned an off-subnet address to be reachable by nodes on the intranet, the routing infrastructure must contain routes that match the off-subnet address ranges and point to an intranet interface of the remote access server. To add these routes, you can do one of the following:

• Because the routes corresponding to the off-subnet address ranges are automatically added to the routing table of the remote access server, you can configure the remote access server with a routing protocol, such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF), to propagate the off-subnet routes to neighboring routers.
• Add the routes that correspond to the off-subnet address ranges as static routes to a neighboring router, and configure the router to propagate the routes to its neighboring routers.

For a small network that does not use a routing protocol such as RIP or OSPF, you can also manually add the routes that correspond to the off-subnet address ranges to each of your routers.

Methods of obtaining IP addresses

The Routing and Remote Access service can be configured to obtain IP addresses for remote access clients either automatically or from a static IP address pool. This configuration occurs when you use the Routing and Remote Access Server Setup Wizard, and you can make changes from the IP tab for the properties of a remote access server in the Routing and Remote Access snap-in.

Obtaining IP addresses automatically

When configured to obtain IP addresses automatically, the Routing and Remote Access service instructs the DHCP client component of the TCP/IP protocol to use DHCP to obtain 10 IP addresses at a time.

The Routing and Remote Access service attempts to obtain the first set of 10 IP addresses when the first remote access client connects, rather than when the Routing and Remote Access service starts. The Routing and Remote Access service uses the first IP address obtained from DHCP for the Internal interface (as viewed from the IP Routing\General node in the Routing and Remote Access snap-in). Subsequent addresses are allocated to IP-based remote access clients as they connect. Any IP addresses recovered when remote access clients disconnect are reused.

When all 10 of the initial set of DHCP-obtained IP addresses are being concurrently used and another remote access client attempts a connection, the Routing and Remote Access service uses the DHCP client component to obtain 10 more addresses. You can modify the number of IP addresses obtained at a time by changing the value of the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Parameters\Ip\InitialAddressPoolSize registry entry (DWORD).

If a DHCP server cannot be contacted, the DHCP client component returns addresses in the Automatic Private IP Addressing (APIPA) range from 169.254.0.1 through 169.254.255.254. APIPA addresses are off-subnet addresses that have no corresponding route in the intranet routing infrastructure. Remote access clients are assigned an APIPA address, but are unable to communicate beyond the remote access server.

Note   There are ways to allow the use of APIPA addresses as either on-subnet or off-subnet addresses; however, the existence of APIPA addresses implies either a configuration error, connectivity problems reaching the DHCP server, or a lack of IP addresses in the scope on the DHCP server for the subnet to which the remote access server is attached. These issues should be corrected, instead of configuring methods to use APIPA addresses for remote access clients.

The Routing and Remote Access service attempts to obtain DHCP-allocated addresses using the interface selected in Adapter on the IP tab for the properties of the Routing and Remote Access server, as shown in the following figure.

If your browser does not support inline frames, click here to view on a separate page.

This adapter is normally selected on the Network Selection page of the Routing and Remote Access Server Setup Wizard. If the wrong adapter is selected (for example, the Internet interface is selected), then attempts to contact the DHCP server using that adapter fail and APIPA addresses are returned. If Allow RAS to select adapter is selected, the Routing and Remote Access service randomly picks a LAN interface to use at startup, which could result in the use of the wrong adapter.

When the Routing and Remote Access service is stopped, it sends DHCPRelease messages to release all of the IP addresses obtained through DHCP.

Static IP Address Pool

A static address pool is one or more address ranges. When a static IP address pool is configured, the remote access server uses the first IP address in the first address range for the Internal interface. Subsequent addresses are allocated to TCP/IP-based remote access clients as they connect. Any IP addresses recovered when remote access clients disconnect are reused.

An address range in the static IP address pool can be an on-subnet range, an off-subnet range, or a mixture of on-subnet and off-subnet addresses.

If any of the addresses in any of the address ranges are off-subnet, you must add the route(s) that summarize the off-subnet addresses to the intranet routing infrastructure so that traffic destined to remote access clients are forwarded to the remote access server, and then forwarded by the remote access server to the appropriate remote access client. To provide the best summarization of address ranges for routes, choose address ranges that can be expressed using a single prefix and subnet mask. For example, the address range 192.168.2.1 through 192.168.3.254 can be expressed as 192.168.2.0 with the subnet mask 255.255.254.0 (192.168.2.0/23).

Running out of addresses

It is possible to run out of addresses when using either method to obtain addresses.

When obtaining IP addresses automatically, the DHCP server can sometimes run out of addresses for the subnet to which the remote access server is attached. When that happens, the DHCP server no longer responds to requests for addresses for the subnet and the DHCP client component returns APIPA addresses. The remote access clients can connect, but cannot communicate on the intranet.

When you run out of addresses in the static pool, remote access clients cannot connect. Because the remote access server does not have an address to assign, the IPCP negotiation cannot be completed and the connection attempt is ended. For remote access clients running Windows 2000 or Windows XP, the message Error 736: The remote computer terminated the control protocol is displayed.

To keep from running out of addresses, do the following:

• When obtaining IP addresses automatically, ensure that the DHCP scope for the subnet to which the remote access server is attached includes enough addresses to assign to all the possible remote access clients that could be connected at one time.
• When obtaining IP addresses from a static pool, ensure that the pool has enough addresses to assign to all of the possible remote access clients that could be connected at one time.

For More Information

For more information about remote access connections, consult the following resources:

• Remote Access Overview for Windows Server 2003
• Remote Access Server chapter of the Windows 2000 Server Internetworking Guide

For a list of all The Cable Guy articles, click here.