Router vs. Remote Access Client

Remote Access Client

Router

Router vs. Remote Access Client

If the user name credential does not match the name of an appropriate demand-dial interface, the calling entity is identified as a remote access client, which can result in routing problems.

For example, if Router 1 uses DialUpRouter1 as its user name credential, then Router 1 is identified as a remote access client rather than a router (assuming DialUpRouter1 is a valid account with dial-in permissions). Packets are routed from the user at 172.16.1.10 to the user at 172.16.2.20, as described earlier.

However, response packets from 172.16.2.20 to 172.16.1.10 are forwarded to Router 2 which, upon inspecting its routing table, determines that the interface to use is DD_Seattle. DD_Seattle is in a disconnected state. Based on the configuration for DD_Seattle, COM2 should be used. However, COM2 is currently being used for a remote access client (Router 2). Router 2 then tries to locate a modem that is not being used. If found, Router 2 dials Router 1 and forwards the packet after the connection has been established. If another modem cannot be found, the response packets from 172.16.2.20 to 172.16.1.10 are dropped.
Example of a One-Way Initiated Demand-Dial Connection

The following is an example of the process by which a one-way initiated connection takes place. For more information about one-way initiated connections, see “What Is Demand Dial Routing?”

When the user at 172.16.1.10 tries to connect to a resource at 172.16.2.20, the following events occur:
Packets from 172.16.1.10 destined for 172.16.2.20 are forwarded to Router 1.

Router 1 receives the packet from 172.16.1.10 and checks its routing table. It finds a route to 172.16.2.20 by using the DD_NewYork interface.

Router 1 checks the state of the DD_NewYork interface and finds it is in a disconnected state.

Router 1 retrieves the configuration of the DD_NewYork demand-dial interface.

Based on the DD_NewYork configuration, Router 1 uses the modem on COM1 to dial the number 555-0122.

Router 2 answers the incoming call.

Router 2 requests authentication credentials from the incoming caller.

Router 1 sends the user name, DD_Seattle, with its associated password.

Upon receiving the authentication credentials, Router 2 checks the user name and password against the security features of Windows Server 2003 and verifies that Router 1 has dial-in permission through the dial-in properties of the DD_Seattle user account and the configured remote access policies.

Router 2 retrieves the static route (172.16.1.0 with the subnet mask of 255.255.255.0) that is configured on the DD_Seattle user account and creates a corresponding static route in its routing table. If Router 2 is configured with routing protocols, Router 2 uses routing protocols to communicate with neighboring routers so that the route to the Seattle network is propagated to all of the routers in the New York office.

Router 2 must now determine whether the incoming caller is a dial-up networking client or a router creating a demand-dial connection. Router 2 looks in its list of demand-dial interfaces and does not find one called DD_Seattle. Therefore, Router 2 considers the connection to the Seattle office to be a remote access connection.

Router 1 forwards the packet from the computer at 172.16.1.10 across the demand-dial connection to Router 2.

Router 2 receives the packet and forwards it to the computer at 172.16.2.20.

The response to the connection request by the computer at 172.16.1.10 is forwarded to Router 2 by the computer at 172.16.2.20.

Router 2 receives the packet destined for 172.16.1.10 and checks its routing table. A route to 172.16.1.10 is found by using the connection to Router 1.

Router 2 forwards the packet to Router 1.

Router 1 forwards the packet to the computer at 172.16.1.10.


Note
When the connection is made, the static routes on the user account of the calling router are added to the routing table of the answering router. If routing protocols are used to propagate the new static route, then there is a delay between the time the connection is made and the time when all of the routers on the intranet of the answering router are aware of the new route. Therefore, hosts on the intranet of the calling router might experience a delay between the time that the connection is made and the time when they begin to receive traffic from hosts on the intranet of the answering router.