Deploying a Demand-Dial Router-to-Router Configuration
Although
the concept of demand-dial routing is simple, implementing demand-dial
routing is relatively complex because of the number of features
requiring configuration. The following sections describe these features.
Connection Endpoint Addressing
The connection must
be made over public data networks, such as the public switched telephone
network (PSTN). The endpoint of the connection must be identified by a
phone number or other endpoint identifier.
Authenticating and Authorizing the Calling Router
Demand-dial routing in
Windows Server 2003 networks requires a calling router and a called
router, each running Routing And Remote Access. Each router can be
configured to act as both a calling and called router, but during every
connection attempt, the router acting as the calling router must be
authenticated and authorized.
Authentication is
based on the calling router’s set of credentials that are passed during
the connection establishment process. The credentials that are passed
must correspond to a user account. Authorization is granted based on the
dial-in permission of the user account and remote access policies. You
can configure authentication and authorization by using the Routing And
Remote Access Wizard.
Differentiating Between Remote Access Clients and Routers
Both routing and remote
access services coexist on the same server running Routing And Remote
Access. Both remote access clients and routers can call the same phone
number. The server running Routing And Remote Access that answers the
call must be able to distinguish a remote access client from a router
that is calling to create a demand-dial connection.
To differentiate
a remote access client from a demand-dial router, the user name in the
authentication credentials sent by the calling router must exactly match
the name of a demand-dial interface on the answering router. Otherwise,
the incoming connection is assumed to be a remote access connection.
Configuring Both Ends of the Connection
You must configure both
ends of the connection even if only one end of the connection is
initiating a demand-dial connection. Configuring only one side of the
connection allows packets to be routed in only one direction; normal
communication, however, requires that information travel in both
directions.
Configuring Static Routes
Although
you can use dynamic routing protocols with persistent dial-up
connections, you cannot use them effectively over temporary
dial-on-demand connections. For these connections, routes to network IDs
that require the use of the demand-dial interface must be added to the
routing table as static routes.
Also note that you
must choose one static route to initiate the dial-on-demand connection.
To achieve this task, verify that the Use This Route To Initiate
Demand-Dial Connections check box is selected in the properties of the
appropriate static route, as shown in Figure 8.
Troubleshooting Demand-Dial Routing
The following
list provides a conceptual summary of the configuration requirements for
a demand-dial routing deployment and of the associated potential points
of failure. Review this summary and refer back to it as needed to help
you troubleshoot routing through demand-dial interfaces.
A
number of basic features must be enabled on both ends of the connection
for demand-dial routing to function. First, verify that Routing And
Remote Access is configured and enabled on both servers. Second, make
sure both servers have been enabled for LAN and demand-dial routing in
the Routing And Remote Access console. Next, make sure IP routing is
enabled. Finally, verify that the necessary demand-dial interfaces are
not in a disabled state.
Demand-dial
routing requires that static routes be configured for both ends of the
demand-dial connection. Verify that these routes are correctly
configured. For dial-on-demand routing, verify that the Use This Route
To Initiate Demand-Dial Connections check box is selected.
For
the connection to function as a link in a routed network, the
demand-dial connection must not be interpreted as a remote access
connection. To ensure that the connection is interpreted correctly,
verify that the user name of the calling router’s credentials match the
name of a demand-dial interface configured on the answering router.
Verify that the calling router’s credentials consisting of user name,
password, and domain name are correct and can be validated by the
answering router.
Answering
routers must be authorized to function in Active Directory domains. For
an answering router that is a member of an Active Directory domain,
verify that the computer account of the answering router computer is a
member of the RAS And IAS Servers security group.
Routed connections are both authenticated and encrypted.
To ensure that a demand-dial routed connection can be established,
verify that in conjunction with a remote access policy, the calling
router and the answering router are enabled to use at least one common
authentication method and one common encryption method.
Restrictions
can be configured for each demand-dial interface in the form of
dial-out hours and demand-dial filters. For each interface, verify that
the dial-out hours or demand-dial filters for the demand-dial interface
on the calling router are not preventing the connection attempt.
Demand-dial
interfaces communicate through ports, which can be disabled in the
Routing And Remote Access console for inbound or outbound traffic. If a
connection fails to be established at either end of a demand-dial
routing connection, verify that the dial-up ports being used are
configured to allow demand-dial routing (inbound and outbound).
Packet
filters can block access beyond a connection endpoint. If you cannot
connect to resources beyond the answering router, verify that no packet
filters on either demand-dial interface are preventing the flow of
wanted traffic. Each demand-dial interface can be configured with IP
input and output filters that allow you to control the exact nature of
TCP/IP traffic allowed into and out of the demand-dial interface.
