Connecting Remote Sites

C H A P T E R 1 0
Connecting Remote
Sites
The Routing and Remote Access service in the Microsoft® Windows® Server 2003 operating system supports
remote site connectivity by using dial-up or virtual private network (VPN) connections. You can deploy either a
temporary or persistent site-to-site (also known as router-to-router) connectivity solution in your network to
achieve optimal scalability, security, and performance while reducing your connection costs.
In This Chapter
Overview of Remote Site Connectivity......................................... .......................220
Choosing the Remote Site Connection Type...................................... ..................225
Choosing Security Features...................................................................... ...........234
Integrating the Remote Site Connection into Your Network.................................251
Preparing for Server Configuration........................................................... ...........262
Deploying a Site-to-Site Connection............................................................ ........268
Additional Resources.............................................................................. .............299
Related Information
• For more information about name resolution, see “Deploying DNS” and “Deploying WINS” in
this book.
• For more information about IP address assignment, see “Deploying DHCP” in this book.
• For more information about the Active Directory® directory service replication between sites,
see “Designing the Site Topology” in Designing and Deploying Directory and Security Services
of this kit.
• For more information about creating hardware and software inventories and mapping your
existing network before deploying new features, see “Planning for Deployment” in Planning,
Testing, and Piloting Deployment Projects of this kit.
220 Chapter 10 Connecting Remote Sites
Overview of Remote Site

Connectivity
Many organizations have offices located in different geographical locations, requiring remote site connectivity.
You can use the Windows Server 2003 Routing and Remote Access service to deploy a cost-effective and secure
site-to-site solution.
Traditionally, organizations have used wide area network (WAN) site-to-site connection technologies, such as T-
Carrier or Frame Relay, to connect remote sites across a private data network. However, these private lines are
expensive. For example, the prices for T-Carrier services are based on both bandwidth and distance, which
makes the connections relatively costly. In addition, T-Carrier typically requires a dedicated infrastructure,
including a Channel Service Unit/Data Service Unit (CSU/DSU) and line-specific routers at each end of the
connection.
In contrast, you can integrate the Windows Server 2003 Routing and Remote Access service solution into your
organization’s current network by using existing servers. With the site-to-site connections provided by the
Routing and Remote Access service, you have two alternatives to conventional WAN links: a site-to-site dial-up
connection or a site-to-site VPN connection. If you deploy a Routing and Remote Access solution to replace an
existing WAN connection, or to implement a new connection, you can optimize cost savings by tailoring your
connection type to your traffic volume. You can also customize security to fit your organization’s requirements.
Note
The Routing and Remote Access service can support both site-to-site
connections between remote offices and remote access connections
for individual computers. This chapter focuses on site-to-site
connections.
Before you begin the design process to introduce a new site-to-site connection into your network, or modify an
existing connection, inventory your existing hardware and software, and create or update a map of your current
network. Updating your inventory and network configuration information facilitates both the design and the
deployment phases. For a guide to conducting inventories and creating a network map, see “Planning for
Deployment” in Planning, Testing, and Piloting Deployment Projects of this kit.
Additional Resources 221
Note
For a list of job aids that are available to assist you in deploying site-to-
site connection technology, see “Additional Resources” later in this
chapter.
Remote Site Connectivity Process

To begin the design process for deploying a site-to-site connection, choose the remote site connection type and
its configuration options that are most appropriate, and decide which security features to use to protect that
connection. Next, decide how you want to integrate the remote site connection into your existing network
infrastructure. Finally, prepare the servers that you plan to configure as routers. After you complete these design
decisions, you are ready to deploy your remote site connection. The flowchart in Figure 10.1 outlines this
process.
Figure 10.1 Connecting Remote Sites
Remote Site Connectivity Background

You can design and deploy a remote site connection that is optimal for your organizational and network
environment by using the connectivity, security, and network configuration options provided by the Routing and
Remote Access service.
The following sections describe three typical remote site connection solutions — a Point-to-Point Tunneling
Protocol (PPTP) VPN connection, a Layer Two Tunneling Protocol over Internet Protocol security
(L2TP/IPSec) VPN connection, and a dial-up connection. For detailed information about each connection type
and the range of available configuration and security options, see “Choosing the Remote Site Connection Type”
and “Choosing Security Features” later in this chapter.
PPTP VPN Solution

Organizations with moderate to heavy traffic between a branch office and a main office and existing connections
to the Internet might choose a PPTP–based site-to-site connection. In the example shown in Figure 10.2, a
firewall creates a perimeter network at each end of the Internet tunnel. Windows Server 2003 also supports VPN
functionality without the use of a firewall.
Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2), which provides a high-
security protocol for password authentication, is a highly recommended method for authentication and
encryption key generation for a site-to-site connection. Alternatively, you can use Extensible Authentication
Protocol-Transport Layer Security Protocol (EAP-TLS), which provides an even stronger user-level
authentication than the password-based MS-CHAP v2.
The main office site must have a permanent WAN link to its local Internet service provider (ISP), but the branch
office site can use a dial-up WAN link to its local ISP. An on-demand connection that disconnects when the
connection is idle ensures that the connection is not active when not in use. Reciprocal replication ensures that
replication between domain controllers in separate sites takes place over the one-way initiated on-demand
connection. Figure 10.2 depicts this solution.
Figure 10.2 One-Way Initiated On-Demand Dial-up PPTP VPN Solution
L2TP/IPSec VPN Solution

Organizations that need maximum security to support substantial two-way traffic between a large branch office
and a headquarters office might choose an L2TP/IPSec VPN solution. A firewall creates a perimeter network at
each end of the Internet tunnel. A persistent connection, enabled by a dedicated link to the ISP at both sites,
allows around-the-clock traffic.
The recommended method for the computer-level authentication provided by L2TP/IPSec is the exchange of
computer certificates by the calling and answering endpoints, which requires a certificate infrastructure
provided by the certification authority (CA) server. EAP-TLS provides stronger user-level authentication than
does the password-based MS-CHAP v2, because it requires a user certificate on the calling endpoint and a
computer certificate on the answering endpoint. L2TP/IPSec uses IPSec as its encryption method. For a
persistent connection, replication takes place across the site link at specified intervals — you do not need to
configure reciprocal replication as you do for a one-way initiated on-demand connection. The example in
Figure 10.3 depicts this solution.
Figure 10.3 Persistent Two-Way Initiated L2TP/IPSec VPN Solution
Dial-up Solution
Organizations with moderate traffic between a branch and a main office might choose to replace an existing
leased WAN link with a dial-up WAN link or use a dial-up WAN link to create a new connection. Figure 10.4
shows an example of a site-to-site connection that uses an ISDN dial-up link. One common situation in which
you might deploy a dial-up link is as a backup solution when a VPN link provides your primary connection. For
more information about when to use a dial-up connection, see “Choosing a Dial-up or VPN Connection” later in
this chapter.
A one-way initiated on-demand dial-up connection disconnects when the connection is idle for a specified
period of time and thus provides efficient access for branch office users who need only intermittent access to the
main office. A dial-up connection typically uses MS-CHAP v2as the user authentication method to authenticate
the calling router together with Microsoft Point-to-Point Encryption (MPPE) for data encryption. Configuring
reciprocal replication enables replication between domain controllers in separate sites over a one-way initiated
on-demand connection. Figure 10.4 depicts this solution.
Figure 10.4 One-Way Initiated On-Demand Dial-up Solution
Choosing the Remote Site

Connection Type
The first set of decisions that you need to make when designing remote site connectivity are about the
connection type. The flowchart in Figure 10.5 shows the tasks required when choosing connection type options.
Figure 10.5 Choosing a Remote Site Connection Type
Choosing a Dial-up or VPN Connection

When considering your connection type options, your first decision is whether to use a dial-up (non-VPN)
connection or a VPN connection.
Dial-up Connections
Routing and Remote Access connections that run over a physical device (such as an ISDN adapter or analog
modem) that is installed on both the calling and answering routers are known as dial-up connections. These
connections differ from traditional WAN links in that they use existing telephone lines instead of leased lines. A
dial-up connection differs from a VPN connection in that it does not cross the Internet.
Using existing phone lines can substantially reduce connection costs, especially where traffic volume between
sites is low. Instead of paying for a permanent WAN connection 24 hours a day, you can configure the link to
disconnect when no traffic crosses the connection for a specified period of time. For example, customers who
use ISDN typically pay by the minute or by the byte, so configuring the call to hang up when the connection is
idle reduces cost.
To keep data transmission secure, a dial-up connection uses private, dedicated lines or circuits across a carrier’s
network. In addition, the connection uses Point-to-Point Protocol (PPP) user authentication and MPPE for data
encryption.
An organization might choose to deploy a dial-up connection if it has a small branch office that needs an
occasional dial-up connection to a main office. For a dial-up link used as the main site-to-site connection, using
ISDN is a viable option.
A larger organization that uses a VPN connection might also deploy an ISDN dial-up connection as a backup
solution in case the Internet connection in either site is ever unavailable. You can use a Public Switched
Telephone Network (PSTN) dial-up link as the backup if the primary link is Frame Relay with a committed
information rate (CIR) of 56 Kbps. If the link for which you need a backup is faster than 56 Kbps CIR, using a
PSTN dial-up connection as the backup is not feasible, because users accustomed to a faster connection will
perceive the dial-up connection as too slow or inoperable. If the primary link is faster than 56 Kbps, instead use
a synchronous circuit solution, such as ISDN or a leased-line circuit, for the backup.
In either of these situations, a dial-up connection provides a solution that is easy to deploy and cost-effective.
VPN Connections
Routing and Remote Access connections that cross the Internet (or other shared network) are known as virtual
private network (VPN) connections. A VPN connection typically uses a physical link to a local ISP. A
VPN-based answering router always uses a permanent WAN link to an ISP, such as a T-Carrier, Frame Relay,
DSL, or cable modem link. The answering router’s permanent link to the Internet ensures that the router is
available whenever a calling router attempts to establish a connection. This link requires a static IP address,
which is assigned by your local ISP (or by InterNIC), on the answering router’s Internet-connected interface.
However, a VPN-based calling router might use a permanent WAN link to an ISP, or it might use a temporary
link (such as a modem or adapter) to the ISP.
When traffic volume is high or permanent connectivity across long distances is required, using a VPN
connection to transport data across the Internet is more cost-effective than using a dedicated WAN line or a
dial-up connection.
To keep data transmission secure, a VPN connection uses PPP user authentication, routes packets encapsulated
in a secure tunnel across the Internet, and uses MPPE or IPSec encryption to protect the data portion of the
packet. This virtual point-to-point connection emulates a dedicated, private, physical point-to-point connection
but lets you replace long-distance WAN links with local WAN links to your nearby ISP. The ISP does not install
any VPN software on its equipment, nor is any VPN software installed on the intermediate routers that a VPN
data packet crosses.
If you choose a VPN connection in which the calling router uses a temporary link to connect to its local ISP, the
temporary link can be either a dial-up link or a PPP over Ethernet (PPPoE) link. The calling router first
establishes the dial-up or PPPoE link to the ISP and then establishes the VPN tunnel across the Internet to the
answering router. Many broadband ISPs use PPPoE. PPPoE links to the ISP are faster than dial-up links.
An example of an organization that might choose to deploy a VPN connection is a large enterprise with several
large satellite offices that each need secure connection for high-volume traffic across the Internet to a
headquarters office.
Choosing PPTP or L2TP/IPSec

If you choose a VPN site-to-site connection, you must next decide whether to use PPTP or L2TP/IPSec as the
VPN technology. Table 10.1 lists some of the factors you need to consider in order to determine whether to
deploy a PPTP or an L2TP/IPSec solution. For more information about the security options (user authentication,
certificates, and encryption) described briefly in the table, see “Choosing Security Features” later in this chapter.
Table 10.1 Comparing a PPTP Solution with an L2TP/IPSec Solution
Factor Using PPTP Using L2TP/IPSec
Windows PPTP is supported by L2TP/IPSec is supported by
version Windows Server 2003, as well Windows Server 2003 and
as the Microsoft® Windows 2000 Server (with
Windows® 2000 Server the Routing and Remote
operating system, and the Access service). Most third-
Microsoft® Windows NT® party VPN routers also
version 4.0 operating system support L2TP/IPSec.
with the Routing and Remote
Access Service (RRAS). Most
third-party VPN routers also
support PPTP.
User EAP-TLS or MS-CHAP v2 is EAP-TLS or MS-CHAP v2 is
authentication recommended. recommended.
Certificates PPTP requires certificates only • Using EAP-TLS user
when using EAP-TLS for user authentication with
authentication, in which case a L2TP/IPSec requires a user
user certificate for the calling certificate for the calling
router and a computer router and a computer
certificate for the certificate for the
authenticating server of the authenticating server of the
answering router are required. calling router.
• For computer-level
authentication, L2TP/IPSec
supports computer
certificates or preshared
keys as the authentication
method for IPSec.
Computer certificate
authentication is
recommended and requires
a computer certificate on
both the calling and
answering routers.
(continued)
Table 10.1 Comparing a PPTP Solution with an L2TP/IPSec Solution (continued)

Factor Using PPTP Using L2TP/IPSec
Encryption For a PPTP-based VPN L2TP/IPSec generates its
connection, choosing either encryption keys by using
EAP-TLS or MS-CHAP v2 for IPSec. IPSec provides data
user authentication provides confidentiality (encryption),
MPPE for data encryption. replay protection, data
MPPE provides data integrity, and data origin
confidentiality (encryption); authentication.
that is, captured packets
cannot be interpreted without
the encryption key.
NATs In most cases, you can locate With Windows Server 2003–
PPTP-based calling routers based calling or answering
behind a network address routers, you can use IPSec
translator (NAT), so you can NAT traversal (NAT-T) to
configure a small or home create L2TP/IPSec
office (SOHO) network to share connections across NATs.
a single connection to the Using NAT-T requires running
Internet. Most NATs include a Windows Server 2003 on both
NAT editor that can accurately the calling and answering
translate PPTP-tunneled data. routers. With NAT-T, hosts
that are hidden behind a NAT
can use IPSec to connect to a
remote site.
Ease of When using MS-CHAP v2 (or • When you use computer
deployment MS-CHAP) for user certificates as the
authentication, PPTP is cost- authentication method,
effective and easier to deploy L2TP/IPSec requires a
than L2TP/IPSec with computer certificate infrastructure
certificates. and, therefore, requires
more administrative
overhead to deploy and
maintain than does PPTP
used with password-based
MS-CHAP v2. For optimal
security, using certificates is
the recommended method.
• Using preshared keys as
the authentication method,
L2TP/IPSec requires less
administrative overhead (for
initial setup but not for long-
term administration) than
using L2TP/IPSec with
certificates but more
administrative overhead
than using PPTP. To ensure
security, do not use
preshared keys.1
1. For more information about the advantages of computer certificates over preshared keys, see
“Choosing Computer Certificates or Preshared Keys for Computer-Level Authentication” later in this
chapter.
Using Both a PPTP Connection and an L2TP/IPSec Connection

You can deploy both a PPTP solution and an L2TP/IPSec solution at the same time. By default, a VPN router
running Windows Server 2003 simultaneously supports both connection types. A VPN router running
Windows 2000 Server supports both connection types if the router is not behind a NAT; however,
Windows 2000 Server supports only PPTP — but not L2TP/IPSec — across a NAT.
You might want to use PPTP for some site-to-site connections and L2TP/IPSec for others. Table 10.2 lists some
situations in which you might use PPTP or L2TP/IPSec for different connections on the same network.
Table 10.2 Using PPTP and L2TP/IPSec for Different VPN Connections on the Same Network
VPN Connection
Typical Uses
Type
PPTP • To connect from calling routers that are running Windows
NT 4.0 with RRAS.
• To connect from routers that are running Windows
Server 2003 or Windows 2000 Server that do not have an
installed computer certificate.
• To establish a VPN connection when you want to place
Windows 2000 Server–based routers behind a Routing and
Remote Access NAT or a third-party NAT.
L2TP/IPSec • To connect from calling routers running Windows
Server 2003 or Windows 2000 Server that have an installed
computer certificate.
• To enable hosts that are hidden behind a NAT (because they
use private addresses) to use IPSec to connect to a remote
site. This is possible because NAT-T, which is enabled by
default on Windows Server 2003–based computers, can
create L2TP/IPSec connections across a NAT.
• To provide the highest security solution available.
• To connect from calling routers running Windows
Server 2003 that use preshared keys (not recommended for
security reasons).
If you use both a PPTP and an L2TP/IPSec solution, you can create separate remote access policies that define
different connection parameters for each connection type. For example, if you have PPTP VPN connections to
two branch offices whose calling routers run Windows NT 4.0 with RRAS, you might want to create a more
restrictive remote access policy for those connections than the remote access policy that you create for an
L2TP/IPSec VPN connection to a branch office whose calling routers run Windows Server 2003 and use
computer-level authentication. For more information about creating remote access policies for a site-to-site
connection, see “Configure a Remote Access Policy” later in this chapter.
Choosing an On-Demand or
Persistent Connection
You can configure the calling router for any of the connection types — dial-up, PPTP VPN, or L2TP/IPSec
VPN — with either an on-demand or a persistent connection. Table 10.3 describes and compares these
connection type options.
Table 10.3 Comparing On-Demand and Persistent Connections
Connection Type Description Use
On-demand Establishes a Use an on-demand connection if
connection connection when using the communications link
traffic is forwarded, incurs per-minute charges.
and it terminates the For an on-demand VPN
connection when the connection, the initiating router
link is not used for a can use either a permanent or a
specified period of dial-up link to the Internet. The
time. answering router must have a
permanent link to the Internet to
ensure that it is available when a
calling router attempts to
establish a connection.
Persistent Sustains a connection Use a persistent connection in
connection for 24 hours a day. the following circumstances:
• When the cost of the connection
is based on a flat fee, such as
for a link to a local ISP for each
site when sites are located in
separate cities or for a
connection between different
sites within the same city.
• When data traffic is time-
sensitive. For example, if you
support mainframe terminal
connectivity between sites,
if the terminals must wait for an
on-demand VPN connection to
be activated, the connection
attempt will time out before the
session can be launched.
For a persistent VPN connection,
both the calling and the
answering router must use
a permanent link to the Internet.
For on-demand connections, to prevent the calling router from establishing unnecessary connections, you can
use demand-dial filtering and dial-out hours:
• Demand-dial filters. To prevent a VPN calling router from initiating unnecessary connections,
you can configure demand-dial filters to specify the types of IP traffic for which the router will
or will not create a demand-dial connection. You can identify traffic to accept or reject based on
source and destination addresses of incoming traffic and the protocol in use. It is recommended
that you match the demand-dial filters to the IP packet filters configured on the demand-dial
interface. If there is specific traffic that is not allowed across the demand-dial interface when it
is connected, that same traffic should not be allowed to initiate a demand-dial connection using
that interface. For example, if you have a packet filter that prevents ICMP traffic from being
sent across the demand-dial interface, then you should configure a demand-dial filter to prevent
ICMP traffic from initiating the demand-dial connection. For more information about matching
demand-dial filters to IP packet filters, see “Integrate the VPN Server into a Perimeter
Network” and “Configure IP Packet Filters and Demand-Dial Filters” later in this chapter.
• Dial-out hours. To prevent a dial-up or VPN calling router from initiating unnecessary
connections, you can configure dial-out hours to specify the hours during which a calling router
is either permitted to make a site-to-site connection or denied the connection. You can also
configure remote access policies on the answering router to restrict the time periods when
incoming demand-dial connections are allowed.
Choosing a One-Way or Two-Way

Initiated Connection
You can set up a site-to-site connection so that it can be initiated from only one location, or you can configure a
connection that can be initiated from either side of the dial-up or VPN connection. Table 10.4 describes and
compares these options.
Table 10.4 Comparing One-Way and Two-Way Initiated Connections
Connection Type Description Use
One-way initiated A one-way initiated Use an on-demand or
connection connection is one in persistent one-way initiated
which one site contains connection when users at a
only an answering branch office need to
router and the other connect to a headquarters
site contains only a office but not vice versa.
calling router. Use a persistent one-way
initiated connection when
you have 10 or more branch
offices and users at each site
need to access the other
sites. When you use a two-
way initiated connection for
10 or more connections,
performance is too slow.
Two-way initiated A two-way initiated Use a two-way initiated
connection connection is one in connection when users at
which a router at each both locations need to
site can function as access resources or people
both the answering in the other location and you
router and as the have 10 or fewer connections
calling router. (if you have 10 or more
connections, use a one-way
initiated persistent
connection).
For both a one-way and a two-way initiated connection, use the properties of the router in the Routing and
Remote Access snap-in to configure both the calling and the answering router as a local area network (LAN)
router and as a demand-dial router.
Choosing Security Features

As described in “Choosing the Remote Site Connection Type” earlier in this chapter, security is one of the
factors that you weigh when you choose a connection type. For all connection types, securing site-to-site
communications requires making decisions about several additional security features. The flowchart in
Figure 10.6 shows the tasks required when choosing these additional security features.
Figure 10.6 Choosing Security Features
Integrate the VPN Server into a

Perimeter Network
Windows Server 2003 supports VPN functionality without the use of a firewall. However, many organizations
use firewalls to implement a perimeter network (also known as a DMZ, demilitarized zone, and screened
subnet) to increase security by protecting their internal network from intrusion through the Internet.
Only servers that provide resources to users over the Internet, such as Proxy, Web, and FTP servers, are located
in the perimeter network. Traffic between dial-up routers does not cross the Internet. Therefore, you do not need
to locate dial-up routers in a perimeter network. However, placing VPN routers in a perimeter network helps
ensure that communications between sites are protected.
VPN Router Placement in Relation to Firewall

If your organization already uses a perimeter network, you can add your VPN router to the existing set of
servers on the perimeter network. If not, consider adding a perimeter network to your infrastructure when you
deploy a VPN site-to-site connection.
How you configure firewall filters and the filters on the VPN router depends on the position of the VPN router
relative to the firewall. Although it is possible to place the VPN router in front of the firewall (with the VPN
router attached to the Internet), the more common — and recommended — configuration for a site-to-site
connection is to place the VPN router behind the firewall (attaching the firewall to the Internet). When you place
the VPN router behind the firewall, you configure the firewall with input and output filters on the firewall’s
Internet and perimeter network interfaces to restrict traffic to the VPN server. These filters are configured the
same for a site-to-site VPN server as for a remote access VPN server. For a description of these filters and how
they function, see the instructions for configuring packet filters for a VPN server in “Deploying Dial-up and
VPN Remote Access Servers” in this book.
For more information about VPN servers and firewalls, including configuration of PPTP and L2TP/IPSec packet
filters both for VPN servers behind the firewall and for VPN servers in front of the firewall, see “VPN servers
and firewall configuration” in Help and Support Center for Windows Server 2003.
Match IP Packet Filters to Demand-Dial Filters

At the same time that you plan where to place your VPN router in relation to a firewall and how to configure
PPTP and L2TP/IPSec IP packet filters on the firewall, also plan how to configure demand-dial filters in
conjunction with the IP packet filters configured on the demand-dial interfaces. Although IP packet filters and
demand-dial filters serve different purposes, Microsoft recommends that you configure them together.
You use demand-dial filters, which are applied before a connection is made, to specify which types of traffic are
allowed to create a connection in the first place. You use IP packet filters, which are applied after a connection is
made, to specify what traffic is allowed into and out of an interface after a connection is established. To prevent
the demand-dial connection for traffic that will be discarded by the IP packet filters, you need to match your
demand-dial and IP packet filters.
For more information about configuring IP packet filters to match your demand-dial filters, see “Demand-dial
routing design considerations” in Help and Support Center for Windows Server 2003.
Choosing the Authentication Provider

Site-to-site connections between remote offices require an authentication and accounting provider for:
• Authentication of calling router credentials and authorization of the site-to-site connection.
• Accounting services that record the creation and termination of each site-to-site connection.
When a connection is attempted, the answering router authenticates the credentials of the calling router by using
one of two authentication providers: Windows or RADIUS. Your choice of authentication provider is
determined by whether your solution involves a site-to-site only connection or a combined site-to-site and
remote access connection:
• For a site-to-site only connection, choose Windows. When you choose Windows as the
authentication, authorization, and accounting provider, the same Windows authentication
process that validates user credentials when a user logs on also validates the calling router.
• For a combined site-to-site and remote access connection, choose either Windows or
RADIUS. If the same answering router will support both a site-to-site connection and remote
access users (such as home or mobile users), you can use either Windows or Remote
Authentication Dial-in User Service (RADIUS) as your authentication provider. Servers
running the Internet Authentication Service (IAS) component of Windows Server 2003 provide
an Internet standards–compliant RADIUS server and proxy.
If you have more than one answering router or other types of access servers (such as wireless access servers),
you can use a single RADIUS server to provide centralized authentication, authorization, and accounting for all
answering routers and access servers instead of administering each answering router and access server
separately. To simplify administration for a combined site-to-site and remote access connection, you can use
IAS to store both site-to-site and remote access information.
In an Active Directory domain, it is recommended that you use the Windows Server 2003 version of IAS as
your RADIUS server. The IAS RADIUS server is tightly integrated with Windows Server 2003, Active
Directory, and the Routing and Remote Access service. When you use RADIUS authentication, you configure
each of participating answering router as a RADIUS client. After you configure both the answering router and
the IAS server, the answering router uses remote access policies stored on the IAS server instead of those on the
answering router.
Although it is possible to use RADIUS as the authentication provider for a site-to-site only connection, you do
not need RADIUS. Deploying an IAS server is unnecessary administrative overhead for a demand-dial
connection that connects two sites but does not support remote access users.
The credentials that the calling router passes to the answering router for verification are those of a user account,
either in Active Directory or on the local computer. Authorization is granted based on the dial-in properties that
you specify in the user account and on remote access policies configured on the answering router (or on the
RADIUS server). For more information, see “Choosing Router User Accounts and Groups” and “Choosing a
Remote Access Policy Type” later in this chapter.
The authentication provider that you choose also functions as the authorization provider. However, the Routing
and Remote Access service does not require that you use the same provider for authentication and authorization
that you use for accounting. You can use Windows for authentication and RADIUS for accounting, or vice
versa. However, if you have multiple answering routers that support remote access users, consider using
RADIUS for integrated authentication, authorization, and accounting, and, if you use IAS, to manage remote
access policies.
For more information about RADIUS authentication, see “Checklist: Configuring IAS for dial-up and VPN
access” in Help and Support Center for Windows Server 2003. For more information about deploying IAS to
perform centralized authentication, authorization, and accounting, see “Deploying IAS” in this book.
Choosing an Authentication Method

For site-to-site connections, you must implement user-level authentication, and, for greater security, you might
decide to implement computer-level authentication as well:
• User-level authentication — for all site-to-site connection types.
• Computer-level authentication — for L2TP/IPSec connections only.
Choosing EAP-TLS or MS-CHAP v2 for User-Level

Authentication
All site-to-site connection technologies require user-level authentication. The “user” to be authenticated is the
calling router. To prevent a nonauthorized router from making a connection, the Routing and Remote Access
service requires that the calling router requesting the connection be authenticated by the answering router.
The Routing and Remote Access service can use any of several PPP authentication methods to provide user-
level authentication. For optimal security, choose one of the two strongest recommended PPP user
authentication methods — EAP-TLS or MS-CHAP v2.
For more information about the other PPP authentication protocols (in addition to EAP-TLS and MS-CHAP v2)
supported by Windows Server 2003, Windows 2000 Server, and Windows NT Server 4.0, see “Authentication
methods” in Help and Support Center for Windows Server 2003.
Certificate-based EAP-TLS
EAP-TLS is a more secure protocol than MS-CHAP v2 for user-level authentication on a dial-up, PPTP VPN, or
L2TP/IPSec VPN connection. EAP-TLS requires a certificate infrastructure, because it uses a user certificate for
the calling router and a computer certificate for the authenticating server of the answering router. The identity of
the authenticating server depends on the authentication provider:
• If Windows provides authentication, as is the case for a site-to-site only connection, the
computer certificate is installed on the answering router. The answering router must be joined to
the Active Directory domain.
• If RADIUS provides authentication, as might be the case if your answering router also supports
remote access users, the computer certificate is installed on the RADIUS server. If the RADIUS
server is an IAS server, it must be joined to the Active Directory domain. In this case, the
answering router does not need to belong to the domain.
EAP-TLS is recommended for all connection types both because it is the strongest method for user
authentication and because it provides mutual user authentication between calling and answering routers. The
calling router submits a user certificate for authentication, and the answering router (or RADIUS server)
submits a computer certificate for authentication. With EAP-TLS, the user account that the answering router
uses to authenticate and authorize the calling router must be an Active Directory user account.
If you plan to use certificate-based EAP-TLS, you can use a third-party CA if the conditions in Table 10.5 are
met.
Table 10.5 Requirements for Using a Third-Party CA
Certificates Installed on Authenticating
Server Certificates Installed on Calling Router
(Answering Router or RADIUS Server)
• Computer certificates must be • User certificates must have a
installed in the Local Computer corresponding private key.
certificate store. • User certificates must contain the
• Computer certificates must have a Client Authentication EKU (the
corresponding private key. 1.3.6.1.5.5.7.3.2 object identifier).
• The cryptographic service provider • User certificates must be installed in
for the certificates must support the Current User certificate store.
secure channel (Schannel). (If not, • User certificates must contain the
the authenticating server cannot use universal principal name (UPN) of the
the certificate and the certificate user account in the Subject
cannot be selected from the Alternative Name property.
properties of the Smart Card or Other
• The root CA certificates of the CAs
Certificate EAP type on the
that issued the authenticating server
Authentication tab in the properties of
computer certificates must be
a profile for a remote access policy.)
installed in the Trusted Root
• Computer certificates must contain Certification Authorities store.
the Server Authentication certificate
purpose (also known as an enhanced
key usage [EKU]). An EKU is
identified using an object identifier
(also known as an OID). The object
identifier 1.3.6.1.5.5.7.3.1 represents
Server Authentication.
• Computer certificates must contain
the fully qualified domain name
(FQDN) of the computer account of
the authenticating server computer in
the Subject Alternative Name
property.
• The root CA certificates of the CAs
that issued the calling router user
certificates must be installed in the
Trusted Root Certification Authorities
certificate store.
For examples of how to deploy EAP-TLS certificate-based user authentication for site-to-site connections, see
“Deploying certificate-based authentication for demand-dial routing” in Help and Support Center for Windows
Server 2003. For more information about certificate types and requirements, see “Certificate Services” in Help
and Support Center for Windows Server 2003, and see “Designing a Public Key Infrastructure” in Designing
and Deploying Directory and Security Services of this kit.
Password-based MS-CHAP v2
Like EAP-TLS, MS-CHAP v2 also provides mutual authentication between the calling router and the answering
router. MS-CHAP v2 is a password-based authentication method in which the answering router uses either an
Active Directory user account or a local user account to authenticate the calling router. MS-CHAP v2 is the
recommended method for user authentication if a certificate infrastructure is not available.
If you use a local user account for MS-CHAP v2 authentication, the demand-dial routers do not need to join the
Active Directory domain. Be sure to use strong passwords with MS-CHAP v2. In an Active Directory domain,
you can use Group Policy settings to enforce the use of strong passwords.
Advantages of EAP-TLS and MS-CHAP v2

Although several weaker PPP authentication protocols are also available for user authentication, EAP-TLS and
MS-CHAP v2 are the preferred methods because both provide the following benefits:
• Mutual authentication. With mutual authentication, the calling router is authenticated by the
answering router, and the answering router is then authenticated by the calling router. This
mutual authentication prevents an attacker from masquerading as the answering router, whereas
other types of authentication verify only the identity of the calling router.
• Encryption features. In addition, for a dial-up or PPTP connection, EAP-TLS and
MS-CHAP v2 provide the following encryption features. (L2TP/IPSec generates its encryption
keys using IPSec and therefore does not need EAP-TLS or MS-CHAP v2 for encryption keys.)
• Stronger initial encryption keys. MS-CHAP v2 uses both a unique session identifier and
user credentials to generate encryption keys. EAP-TLS uses user certificates to verify user
identity. (In contrast, MS-CHAP uses only the user name and password to create these
keys, making it easier for attackers to determine the keys in use.)
• Different keys for sending and receiving data. The calling router and answering router
use separate keys to encrypt data and to send data. Using different keys makes it more
difficult for attackers to determine which key is used for encryption.
• MPPE for encryption. MPPE uses Rivest-Shamir-Adleman (RSA) RC4 stream ciphering
with 40-bit, 56-bit, and 128-bit encryption keys. (RC4, developed by RSA Data Security, is
a secret key cryptographic method that uses a variable-length key.) Encryption key strength
is negotiated during connection establishment (as is authentication method). The client
(calling router) and server (answering router) negotiate the strongest mutually allowable
key size. If the answering router requires a larger key than that supported on the calling
router, the answering router rejects the connection.
For more information about encryption for site-to-site connections, see “Choosing MPPE or
IPSec Encryption” later in this chapter.
Choosing Computer Certificates or Preshared Keys for

Computer-Level Authentication
The only site-to-site connection technology that provides computer-level authentication is an L2TP/IPSec VPN
connection. Computer-level authentication occurs in one of two ways:
• Computer certificates: the exchange of computer certificates by the calling and answering
routers. Computer-level authentication requires that you deploy a public key infrastructure
(PKI). Although computer certificate authentication requires more administrative overhead for
initial setup than does the use of preshared keys, it is the recommended method because it
provides stronger computer authentication than the preshared keys method. Windows
Server 2003 supports the automatic enrollment of certificates, which makes certificate
deployment and management easier than using preshared keys over the long term.
• Preshared keys: the exchange of preshared keys during the establishment of the IPSec security
association (SA). Support for preshared keys is new with Windows Server 2003, and it requires
running Windows Server 2003 on both VPN routers. A preshared key is a text string that is
configured on both the calling and the answering router. Because a preshared key is a weaker
computer authentication method than certificate authentication, Microsoft recommends that you
use preshared key authentication only during the time you are deploying a PKI to enable the use
of certificates. Using preshared key authentication is not as secure as using computer
certificates, but it requires less administrative overhead.
The IPSec Internet Key Exchange (IKE) protocol can use either certificate-based or preshared key
authentication to negotiate security for the L2TP traffic.
For more information about creating a certificate infrastructure, see “Certificate Services” in Help and Support
Center for Windows Server 2003, and see “Designing a Public Key Infrastructure” in Designing and Deploying
Directory and Security Services of this kit. For more information about key exchange, see “Internet Key
Exchange” in Help and Support Center for Windows Server 2003.
Choosing MPPE or IPSec Encryption

For site-to-site connections, the connection type and the user authentication protocol that you choose to deploy
determine the data encryption method. Table 10.6 shows the available options.
Table 10.6 Choosing a Data Encryption Method
Recommended
Connection Type User Authentication Protoco Encryption Method
l
Dial-up connection EAP-TLS or MS-CHAP v2 MPPE
PPTP connection EAP-TLS or MS-CHAP v2 MPPE
L2TP connection EAP-TLS or MS-CHAP v2 IPSec
Understanding the following features can help you decide how you want to manage encryption:
• Link encryption versus end-to-end encryption. MPPE provides link encryption. Link
encryption encrypts data as it passes between the calling and answering routers. In addition to
providing computer-level authentication, IPSec provides end-to-end encryption for data that
passes between the sending and receiving nodes.
• Encryption method used if VPN connection type is Automatic. If you configure a VPN
connection for an Automatic server type (the default), the connection first tries to use PPTP
and its associated MPPE encryption, and then it tries to use L2TP and its associated IPSec
encryption. If you configure the VPN connection to connect to a PPTP server, only MPPE
encryption is used. If you configure the VPN connection to connect to an L2TP server, only
IPSec encryption is used.
• No encryption needed for link to ISP. For VPN connections, you do not need to use
encryption for the link between your site and the ISP, because no data is transmitted during the
process that establishes this connection. After the connection to the ISP is made, the data that
passes between the calling and answering routers is encrypted as it passes through the VPN
tunnel.
You configure MPPE and IPSec encryption strengths on the Encryption tab for the properties of a remote
access policy. For information about how to configure encryption in a remote access policy for a site-to-site
connection, see “Configure a Remote Access Policy” later in this chapter. For general information about
configuring encryption, see “Add a remote access policy” and “Remote access policy examples” in Help and
Support Center for Windows Server 2003.
Configure either MPPE or IPSec to use one of the encryption keys as shown in Table 10.7.
Table 10.7 Encryption Strength by Connection Type
Encryption Strength Dial-up or PPTP L2TP/IPSec
Basic 40-bit MPPE 56-bit DES
Strong 56-bit MPPE 56-bit DES
Strongest 128-bit MPPE 3DES (three 56-bit keys)
Note
Windows NT 4.0 with the 128-bit version of Service Pack 4 (SP4) can
support 128-bit MPPE, but it does not support 56-bit MPPE. Therefore,
any Windows operating system earlier than Windows NT 4.0 SP4 is not
recommended, because security enhancements for MS-CHAP and
MPPE are not included.
Choosing Router User Accounts and Groups

After a calling router is authenticated by using either Windows or RADIUS as the authentication provider, it
must be authorized: that is, it must be given permission to establish a connection with the answering router. You
use two interrelated sets of components to authorize access by the calling router: user accounts and (optionally)
groups, and remote access policies.
Before you can successfully configure either the router user accounts or remote access policies (both described
later in this chapter), you need to understand the relationship between the two. Configuring the router user
account includes the option of choosing whether to use remote access policies to grant the calling router access
to the answering router. You can grant or deny permission for the calling router to access the answering router
either at the user account level or at the remote access policies level. The permission specified in the user
account overrides the permission specified in a remote access policy. However, if you choose the Control
access through Remote Access Policy option in the user account that the answering router uses to authenticate
the calling router, the remote access policy permission specified on Properties page for the remote access policy
governs whether the user account of the calling router is granted or denied access. This option is available only
for accounts on stand-alone routers or members of a native mode Active Directory domain. For more
information about remote access policies, see “Choosing a Remote Access Policy Type” later in this chapter.
To allow or reject connection attempts according to a variety of criteria, you can specify several remote access
options in the user account of the calling router and multiple additional options by using remote access policies.
This granularity enhances the security of your site-to-site connection by providing great flexibility in how you
can control access to the answering router and its network resources.
You can configure router user accounts individually for each router or by adding router accounts to an Active
Directory group.
Configuring Router User Accounts

Successfully configuring the router’s user account includes the following tasks:
• Configure the router user account name to match the demand-dial interface name.
• Configure the authentication provider for the router.
• Choose an Active Directory user account or a local user account.
• Choose dial-in options for the router user account.
• Ensure that the calling router can establish a connection.
Configure the Router User Account Name to Match the Demand-Dial

Interface Name
The name of a demand-dial interface configured on the answering router must match the name of the user
account that the answering router uses to authenticate the calling router (unless, for a one-way initiated
connection, you do not create a demand-dial interface on the answering router, instead configuring static routes
in the calling router’s user account). For example, if you have one headquarters site and multiple branch offices,
on the headquarters answering router configure a separate demand-dial interface for the calling router at each
branch-office site. This creates a one-to-one relationship between each calling router’s user account name and
the name of its corresponding demand-dial interface on the answering router.
Caution
If the user account name does not match the name of the demand-dial
interface, the answering router identifies the calling router as a remote
access client rather than as a demand-dial router. In this case, the
connection might not work correctly. For this reason, do not change the
user account name without also changing the corresponding demand-
dial interface name.
Table 10.8 shows an example configuration of the demand-dial interfaces and user accounts for a two-way
initiated VPN connection. The example in Table 10.8 uses Active Directory user accounts for the routers. In
some cases, you can alternatively use a local user account.
Table 10.8 Example Configuration of Demand-Dial Interfaces and User Accounts for a Two-
Way Initiated VPN Connection
User Account
Router Demand-Dial Interface
for Calling Router
Router located in Interface Name: VPN_NewYork VPN_NewYork
Seattle Destination IP Address: PasswordTwo
(Functions as both a 131.107.0.1
calling and an Credentials: VPN_Seattle
answering router)
Password: PasswordOne
Router located in New Interface Name: VPN_Seattle VPN_Seattle
York Destination IP Address: PasswordOne
(Functions as both a 157.54.0.1
calling and an Credentials: VPN_NewYork
answering router)
Password: PasswordTwo
For a two-way initiated VPN connection, such as the example in Table 10.8, the name of the demand-dial
interface for each router must match the user name in the remote router’s user credentials so that each router
knows that a requested connection is for a site-to-site connection rather than for a remote access connection. The
destination address of the remote router is configured on the demand-dial interface so that each router knows
what address to connect to for the site-to-site connection. Each router uses the user account (the credentials and
password of the remote router) to authenticate the remote router when it attempts to establish a connection.
Table 10.9 shows an example configuration of the demand-dial interfaces and user accounts for a one-way
initiated dial-up connection in which two branch offices — Portland and Olympia — call the headquarters office
in Seattle. In this case, because the connection is a one-way initiated connection, no demand-dial interface is
required on the answering router. Therefore, the “rule” that the calling router’s user account name must match
the name of a demand-dial interface on the answering router does not apply. If you do not create a demand-dial
interface on the answering router, you use the calling router’s local or Active Directory user account to
configure static routes that identify the network IDs of the calling router’s site.
Table 10.9 Example Configuration for a Dial-up One-Way Initiated Connection
Calling Router User
Router Demand-Dial Interface
Accounts
Answering No demand-dial interface needed. DD_Olympia
router in If you do not configure a demand- PasswordOne
Seattle dial interface on the answering -and-
router, you must configure static
DD_Portland
routes specifying the network IDs
of the calling router’s site on the PasswordTwo
Dial-in tab of the calling router’s
user account.
Calling router Interface Name: DD_Seattle No user accounts needed,
in Olympia Modem or adapter: Modem on because the Seattle router
COM1 does not call the routers
in Olympia or Portland.
Phone number: 555-0111
Credentials: DD_Olympia /
PasswordOne
Calling router Interface Name: DD_Seattle No user accounts needed,
in Portland Modem or adapter: Modem on because the Seattle router
COM2 does not call the routers
in Olympia or Portland.
Phone number: 555-0111
Credentials: DD_Portland /
PasswordTwo
Configure the Authentication Provider for the Router

The answering router uses the calling router’s credentials to authenticate and authorize the calling router. As
described earlier, if the answering router is configured for Windows authentication, as is the case for a site-to-
site only connection, Windows security is used to authenticate the credentials of the calling router. If the
answering router is configured for RADIUS authentication, as might be the case if the same answering router is
used to support both a site-to-site connection and remote access users, the RADIUS server verifies the
credentials of the calling router.
The user accounts and groups that Windows and IAS can use to authenticate and authorize site-to-site dial-up or
VPN connection attempts are those available in Windows Server 2003 or Windows 2000 native-mode or mixed-
mode Active Directory domains and Windows NT 4.0 domains.
Choose an Active Directory User Account or a Local User Account

The answering router must be able to access an Active Directory user account or a local user account to verify
the calling router’s credentials. In either case, because demand-dial routers make connections automatically, the
user account that the answering router uses to authenticate and authorize the calling router must not prompt for
human intervention.
Active Directory user account
If your demand-dial routers belong to an Active Directory domain, you use the Active Directory Users and
Computers snap-in (rather than the Demand-Dial Interface Wizard) to create a user account for each calling
router before you deploy a dial-up or VPN connection. When you create the router account, be sure to clear the
User must change password at next logon check box and select the Password never expires check box.
If you use EAP-TLS user authentication with Windows as the authentication provider, the answering router
must belong to the Active Directory domain, and you must create an Active Directory user account for the
calling router. (If you use EAP-TLS user authentication with RADIUS as the authentication provider, you must
join the IAS server to the Active Directory domain.)
If you use RADIUS authentication, the RADIUS server can use either an Active Directory user account or a
local user account to authenticate the calling router. If you use a Windows Server 2003 IAS server as your
RADIUS server, Microsoft recommends that you use Active Directory accounts.
For information about how to create an Active Directory user account, see “Create a new user account” in Help
and Support Center for Windows Server 2003.
Local user account
If you use Windows authentication and your demand-dial routers do not belong to an Active Directory domain,
the answering router uses a local user account to authenticate the calling router. This user account is created
locally on the answering router.
Instead of creating the user account for the calling router manually, you use the Demand-Dial Interface Wizard
to create the account. When you run the Demand-Dial Interface Wizard on an answering router that is not joined
to an Active Directory domain, the wizard adds a local account for the calling router when you select Add a
user account so a remote router can dial in on the Protocols and Security page. The wizard clears the User
must change password at next logon check box and selects the Password never expires check box on the user
account object.
For information about using the Demand-Dial Interface Wizard, see “Configure the Routing and Remote Access
Service and Demand-Dial Interfaces” later in this chapter, and see “Add a demand-dial interface” in Help and
If you use a local account and password, you must use MS-CHAP v2 rather than EAP-TLS for user
authentication.
If you use RADIUS authentication, the RADIUS server can use a local user account to authenticate the calling
router. If you use a Windows Server 2003 IAS server as your RADIUS server, however, using Active Directory
accounts is recommended.
Choose Dial-in Options for the Router User Account

You use the Dial-in tab of the calling router’s user account to specify the remote access permission as follows:
• Allow access (for native-mode or mixed-mode domains). Allows access when a connection is
attempted. (When you use the Demand-Dial Interface Wizard to create a local account, the
remote access permission is set to Allow access by default.) This option overrides the grant or
deny remote access permission setting specified on the Properties page of any associated
remote access policy. The remote access permission on the associated remote access policy is
either Deny remote access permission or Grant remote access permission. Thus, for
example, if you select Allow access on the router user account, and if you select Deny remote
access permission on the remote access policy, the connection attempt succeeds.
• Deny access. Denies access when a connection is attempted. This option also overrides the
remote access permission configured on the remote access policy.
• Control access through Remote Access Policy (available only for native-mode domains).
With this option selected, the grant or deny remote access permission setting specified on the
Properties page of any associated remote access policy is used. Thus, for example, if you select
Control access through Remote Access Policy on the router user account, and if you select
Deny remote access permission on the remote access policy, the connection attempt is
blocked.
Note
If the user account is in a Windows Server 2003 or Windows 2000
mixed-mode domain, the Control access through Remote Access
Policy setting is not available, and you must set the remote access
permission in each calling router’s user account to Allow access.
Even when remote access permission is allowed, the connection attempt still can be denied on the basis of other
user account properties, such as callback options configured on the Dial-in tab, or it can be denied on the basis
of remote access policy conditions or profile settings. Authorization of the site-to-site connection is controlled
by a combination of the account dial-in properties (which includes the account remote access permission), the
policy remote access permission, and the profile constraints configured on the remote access policy.
You can configure the following settings on the user account Dial-in tab:
• Verify Caller ID (for dial-up router only). Typically, you use this option to increase security
when accepting dial-in connections from telecommuters, but you can also use it for a calling
router. Selecting this option requires that the calling router always call from the phone number
that you type. Windows Server 2003 uses the caller ID functionality of the modem and the
phone connection to verify that the dial-up router is in fact using the correct number; if the
number matches, the connection is allowed. This option is not available if the answering router
is in a Windows NT 4.0 domain or a Windows Server 2003 or Windows 2000 mixed-mode
domain.
Note
For caller ID verification to work, the calling router, the answering
router, and the phone system that connects them must all support
caller ID. In addition to supporting the caller ID feature, the calling and
answering routers must have the appropriate drivers to support the
transmission of caller ID information to the Routing and Remote Access
service.
• Callback Options. Typically, these options are used for managing individual dial-up remote
access users rather than demand-dial calling router user accounts. However, you can also
configure callback options for a dial-up demand-dial connection. For example, you can specify
that the main office router call the branch office router back if the main office has fixed or low-
cost long-distance rates and the branch office has higher long-distance rates.
• Assign a static IP address (for dial-up or VPN routers). Use this option to cause the remote
router to assign a static IP address to this router when a connection is made. For more
information about assigning IP addresses, see “IP Address Assignment for the Logical
Interface” later in this chapter. You can increase security by specifying which IP address the
router must use. This option is not available in a Windows NT 4.0 domain or a Windows
Server 2003 or Windows 2000 mixed-mode domain.
If the static IP address that you specify is not valid or is already in use by another calling router
or by a remote access user, the answering router assigns a dynamic IP address to the calling
router.
• Apply static routes (for dial-up or VPN routers). This option is designed for one-way
initiated site-to-site connections. You select Apply static routes to add static IP routes (network
IDs) for the calling router’s site to the routing table of the answering router when a connection
is made. This lets the answering router forward packets to all addresses on the calling router’s
intranet across the connection to the calling router. This option is not available if the answering
router is in a Windows NT 4.0 domain or a Windows 2000 mixed-mode domain.
Ensure That the Calling Router Can Establish a Connection

To ensure that the router user account is not prevented from establishing a site-to-site connection, verify that the
following options are configured as appropriate:
• When you create the calling router user account, clear the option User must change password
at next logon. If you select User must change password at next logon, the site-to-site
connection attempt fails, because changing the password while attempting to make the
connection is an interactive process. For information about how to create a user account, see
“Create a new user account” in Help and Support Center for Windows Server 2003.
• For a site-to-site connection, do not use the remote access account lockout feature. If the router
user account is disabled (locked out by using the remote access account lockout feature), the
connection attempt is rejected. For information about the remote access account lockout feature,
see “Remote access account lockout” in Help and Support Center for Windows Server 2003.
• If you block the calling router from establishing a connection during certain times, make sure
that the times specified are appropriate for your organization. If the router user account is not
permitted to log on during the time specified for the site-to-site connection, the connection
attempt is rejected. For information about how to use remote access policies to configure dial-in
hours on an answering router in order to block incoming connections from a calling router at
specific times of the day or week (such as at night or on weekends), see “Configure dial-in
constraints” in Help and Support Center for Windows Server 2003.
Configuring Router Groups

Adding demand-dial router user accounts to an Active Directory group reserved for demand-dial routers
simplifies administration by letting you centrally manage the list of demand-dial routers on your network. If you
decide to manage authorization by group rather than by each router’s individual user account, you must set the
remote access permission on each calling router’s user account to either Control access through Remote
Access Policy or Allow access and then create a remote access policy based on connection type and group
membership.
For example, if multiple calling routers will use a VPN connection, you can create an Active Directory global
group called VPN-Routers and add the user account of each calling router to that group.
Then, create a remote access policy with two conditions:
• Set NAS-Port-Type to Virtual (VPN). A network access server (NAS) is a server that accepts
point-to-point connections from a calling router, or other remote client, and then acts as a
gateway to the network for the calling router; the NAS-Port-Type is the media type that a
calling router uses to access the site of the answering router).
• Set Windows-Group to VPN-Routers.
Finally, configure the profile for the remote access policy, selecting an authentication method and encryption
strength.
Choosing a Remote Access Policy Type

You can use remote access policy settings to validate a variety of connection settings before a connection is
authorized and to specify a variety of connection restrictions after the connection is authorized. For example,
you can use remote access policies to allow or reject connection attempts based on membership in an Active
Directory group or by time of day or day of week; to require a specific authentication method and encryption
strength; or to limit the connection based on bandwidth.
The computer on which you create a remote access policy is determined by which authentication provider you
use for site-to-site connections. If you use Windows authentication, you create and manage remote access
policies on each answering router. If you use RADIUS authentication, as you might if your answering router
supports both a site-to-site connection and home or mobile users, you can configure and manage all remote
access policies centrally on the IAS server that provides RADIUS authentication for multiple answering routers.
If you use RADIUS as the authentication provider in Windows Server 2003, Standard Edition; Windows
Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition, you can configure a RADIUS
attribute to ignore the dial-in properties of a user account in the profile properties of a remote access policy. To
support the multiple types of connections for which IAS provides authentication and authorization, you might
need to disable the processing of user account dial-in properties. For more information about dial-in properties,
see “Dial-in properties of a user account” and “Add RADIUS attributes to a remote access policy” in Help and
You can use one of three types of remote access policies:
• Common policy. You can create a common policy, which uses typical settings for a particular
access method.
• Custom policy. You can create a custom policy, which lets you specify a detailed configuration
for a particular access method. If you want to manage authorization and connection parameters
other than by group or by type of connection, you must configure custom remote access
policies. For more information about each possible setting for remote access policy conditions
and profiles for a custom policy, see “Elements of a remote access policy” in Help and Support
Center for Windows Server 2003.
• Default policy. If enforcing a high level of security is not important for your organization, you
can use one of the existing default policies. Two default remote access policies are created
when you enable and configure the Routing and Remote Access service on a demand-dial router
or when you install IAS: The Connections to Microsoft Routing and Remote Access server
policy and the Connections to other access servers policy. To use the Connections to
Microsoft Routing and Remote Access server policy for a site-to-site connection, all you
have to do is change the remote access permission on the policy’s Properties page to Grant
remote access permission.
For more information about using Windows Server 2003 remote access policies, see “Remote access policies”
in Help and Support Center for Windows Server 2003. For more information about using remote access policies
with an Internet Authentication Service (IAS) server, see “Deploying IAS” in this book and see the Networking
Guide of the Microsoft® Windows® Server 2003 Resource Kit (or see the Networking Guide on the Web at
http://www.microsoft.com/reskit).
Integrating the Remote Site

Connection into Your Network
Before you can successfully deploy a dial-up or VPN remote site connection on your network, you must decide
how you want to integrate the connection into your existing network infrastructure. The flowchart in Figure 10.7
shows the tasks required to integrate the connection into your network.
Figure 10.7 Integrating the Remote Site Connection into Your Network
Designing the Routing Infrastructure

Integrating a remote site connection into your existing routing infrastructure requires that you decide which
choices you want to make about the following tasks:
• Adding static routes
• Using routing protocols
• Servicing Internet traffic
• Enabling multicast connectivity between sites
Adding Static Routes

In some cases, instead of using routing protocols to dynamically update routing tables, you must configure one
or more static routes on the intranet interfaces and demand-dial interfaces of the demand-dial routers in your
site-to-site deployment. A static route, which creates a specific path to a destination IP address in an IP network,
is one of a set of routes in a routing table that are permanent until changed by a network administrator or by an
automatically scheduled auto-static update.
The following topics provide the information that you need to manage static routes for a site-to-site connection:
• Static routes for a site-to-site connection
• Auto-static updates
• Using on-subnet or off-subnet address ranges
Static Routes for a Site-to-Site Connection

You might need to create one or more the following types of static routes for your site-to-site connection:
• LAN interface at both sites. On both the calling and the answering router, configure a static
route or routes on the LAN interface that connects the router to the local intranet. Include a
static route for each subnet on the local area network.
Alternatively, you can use a routing protocol instead of configuring static routes. For more
information about using routing protocols, see “Using Routing Protocols” later in this chapter.
• Demand-dial interface for the remote site. On the calling router, configure a static route or
routes on the demand-dial interface that connects the router to the remote site. Include a static
route for each subnet in the answering router’s network that you want users to be able to access
(or you can use the default route).
Alternatively, for a persistent site-to-site connection only, you can enable a routing protocol on
the demand-dial interface instead of configuring static routes. For more information about using
routing protocols, see “Using Routing Protocols” later in this chapter.
• Demand-dial interface for the local ISP. On the calling router — for a VPN connection in
which the branch office router uses a temporary link to a local ISP only — you must configure a
static host route on the demand-dial interface that connects to the local ISP. The destination that
you specify for this static host route is the IP address of the answering router’s Internet-
connected interface; this IP address is assigned to the answering router by its local ISP (or by
InterNIC).
• Router user account. For a one-way connection in which the answering router is a standalone
router or a member of a native-mode Active Directory domain, you can omit creating a
demand-dial interface on the answering router. In this case, you must configure a static route or
routes in the calling router’s user account that identify the network IDs of the calling router’s
site.
For information about how to configure these static routes, see “Configure Static Routes” later in this chapter.
For general information about the difference between using static routes or routing protocols, see the discussion
of developing routing strategies in “Designing a TCP/IP Network” in this book.
Auto-static Updates
You can add the static routes that correspond to the network IDs available across a demand-dial interface either
manually or by using auto-static updates. An auto-static update is a one-time, one-way transfer of routing
information. In contrast to the periodic announcements issued by routing protocols, an administrator must either
issue a command to initiate a manual auto-static update or must schedule auto-static updates by running the
update as a scheduled task.
When instructed, a demand-dial interface that is configured for auto-static updates sends a request across an
active connection to request all of the routes of the router on the other side of the connection. In response to the
request, all of the routes of the requested router are automatically entered as static routes in the routing table of
the requesting router.
Using On-Subnet or Off-Subnet Address Ranges

If any of the static address ranges that you configure in the IP properties of the answering router is an off-subnet
address range, you must add routes to the routing infrastructure in order for the logical interfaces of calling
routers to be reachable. During the PPP negotiation, each router typically assigns an IP address to the logical
interface of the other router. When a site-to-site connection is made, each router sends traffic to the other router
using the logical interface that corresponds to the dial-up, PPTP, or L2TP port of the connection. For more
information about how each router assigns an IP address to the other, see “IP Address Assignment for the
Logical Interface” later in this chapter.
The method used to ensure the reachability of the logical interfaces in a site-to-site connection depends on how
you configure each router to obtain IP addresses for calling routers (and for remote access clients, if your
network also supports them). You use either an on-subnet or an off-subnet address range for these IP addresses.
On-subnet address range

An on-subnet address range is an address range of the subnet to which the answering router is attached. An
on-subnet address range provides the IP address for a logical interface whenever the router is configured to use
Dynamic Host Configuration Protocol (DHCP) to obtain IP addresses, a DHCP server is available, and the
manually configured pool (or pools) of IP addresses are within the range of addresses of the attached subnet. If
you use an on-subnet address range, no additional routing configuration is required.
Off-subnet address range
An off-subnet address range is an address range that represents a different subnet than the subnet to which the
router is attached. Off-subnet addressing uses a separate subnet address space that is unique to the intranet. An
off-subnet address range provides the IP address for a logical interface whenever the router is manually
configured with a pool of IP addresses for a separate subnet.
If you use an off-subnet address range, you must add the route or routes that summarize the off-subnet address
range to the intranet routing infrastructure so that traffic destined to the logical interfaces of connected routers
are forwarded from the originating node to the local dial-up or VPN router and then sent by it to the appropriate
connected remote router. You can add the routes that summarize the off-subnet address range to the routing
infrastructure by using one of the following methods:
• Add static routes for the off-subnet address range that point to the dial-up or VPN router’s
intranet interface to the neighboring router. Configure the neighboring router to propagate this
static route to other routers in the site by using the dynamic routing protocol used in your site.
• If the dial-up or VPN router uses Open Shortest Path First (OSPF) and participates as a
dynamic router, you must configure the router as an autonomous system boundary router
(ASBR) so that the static routes of the off-subnet address range are propagated to the other
OSPF routers in the site.
If your site consists of a single subnet, and you use an off-subnet address range, you must do one of the
following:
• Configure each intranet host for a persistent route (or routes) that points to the dial-up or VPN
router’s intranet interface. The route (or routes) expresses the off-subnet address range.
In the Routing and Remote Access snap-in, you must configure address ranges with a starting
and ending address. To simplify the set of routes needed to express the off-subnet address
ranges, express each range as an IP address with a subnet mask. For more information about
using an IP address and a mask to express an address range, see “Expressing an IP address
range with a mask” in Help and Support Center for Windows Server 2003.
• Configure each intranet host with the IP address of the intranet-connected interface of the dial-
up or VPN router as its default gateway.
Therefore, if your site consists of a single subnet, it is more efficient to use an on-subnet address range.
Using Routing Protocols

If you use the Routing Information Protocol version 1 or 2 (RIPv1 or RIPv2) or the OSPF routing protocol in
your site, you can add and configure the RIP or OSPF routing protocol components of the Routing and Remote
Access service so that a demand-dial router participates in the propagation of routing information as a dynamic
router. As an efficient alternative to manually configuring static routes, you can use routing protocols on each
LAN interface and on each demand-dial interface that is used for a persistent site-to-site connection. You must
configure dynamic routing protocols for each new router so that it can participate in the dynamic routing
architecture and share its subnets.
If you use a routing protocol other than RIP or OSPF, such as the Cisco proprietary Interior Gateway Routing
Protocol (IGRP) or Enhanced Interior Gateway Routing Protocol (EIGRP), configure the neighboring Cisco
router for RIP or OSPF on the interface connected to the subnet that contains the dial-up or VPN router, and
then configure IGRP or EIGRP on all other interfaces. You must also configure the neighboring Cisco router to
redistribute the IGRP or EIGRP routes into the OSPF or RIP routing tables.
Do not use routing protocols across an on-demand site-to-site connection. The periodic announcements that
most routing protocols use to propagate routing information cause one demand-dial router to call another each
time an announcement occurs. For example, RIPv1, by default, announces routing information every
30 seconds. If your router incurs a long-distance charge every 30 seconds, the phone bill that results defeats the
cost savings that an on-demand link is designed to provide. Instead, add routes for network IDs that are
available across the demand-dial interface as static routes to the routing tables of demand-dial routers.
Servicing Internet Traffic

Depending on the immediate task at hand, users in an organization that includes more than one site might want
to access people or resources at the remote site, or they might want to access the Internet. You can use a
demand-dial router to handle both types of traffic. If you do use the demand-dial router to enable users to access
the Internet, you must decide whether you want users at a branch office to access the Internet through the main
office or to access the Internet directly from the branch office.
For security, route branch office Internet traffic through the main office
If you deploy Microsoft® Internet Security and Acceleration (ISA) Server at the main office, and you want
branch office Internet traffic to be protected by this system, configure branch office Internet traffic to go over
the dial-up or VPN connection to the ISA server at the main office. ISA Server is an integrated firewall and
Internet caching server that can also act as a VPN router to provide Internet access that is both secure and fast.
For information about deploying ISA Server, see “Deploying ISA Server” in this book.
For performance, route branch office Internet traffic directly to the

Internet
To give branch office users faster access to the Internet than is possible if the Internet traffic must travel to the
main office and back, configure branch office Internet traffic to go directly out to the Internet through the
demand-dial router. In addition, if you use an on-demand connection rather than a persistent connection, you
must provide direct access to the Internet through the demand-dial router rather than over the link to the main
office. Configuring client computers to allow users in the branch office to access the Internet directly through
the demand-dial router is known as split tunneling.
For information about handling each alternative, see “Configure Internet Access Through the Calling Router”
later in this chapter.
Enabling Multicast Connectivity Between Sites

An increasing number of organizations use multicast communication for such multiple-user applications as
video conferencing, collaborative computing, and distance learning. Computers running Windows Server 2003
can both send and receive IP multicast traffic. The Routing and Remote Access service includes the Windows
Server 2003 Internet Group Management Protocol (IGMP) routing protocol component, which you can
configure with IGMP router mode and IGMP proxy mode to enable the exchange of multicast packets between
remote sites. The IGMP Router and Proxy routing protocol is not itself a multicast routing protocol.
When you make your demand-dial routers multicast-capable, they can listen for all multicast traffic over all site-
to-site connections, they can listen for IGMP Membership Report messages, and they can update the TCP/IP
multicast forwarding table so that routers can determine where to forward incoming multicast traffic.
For a site-to-site connection, use the Routing and Remote Access snap-in to enable IGMP with IGMP proxy
mode on the demand-dial interface on both the calling router and the answering router, and to enable IGMP with
IGMP router mode on all other interfaces internal to the site.
For more information about IP multicasting, see “Designing a TCP/IP Network” in this book and the
Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at
http://www.microsoft.com/reskit). For more information about multiple supported multicast configurations, see
the Internetworking Guide of the Windows Server 2003 Resource Kit (or see the Internetworking Guide on the
Web at http://www.microsoft.com/reskit).
Planning IP Address Assignment and

Name Resolution
The DHCP and name resolution issues that you must consider when planning how to integrate a site-to-site
connection into your existing network include:
• Client IP address assignment
• IP address assignment for the logical interface
• Using IP addresses to avoid name resolution issues
• Using name resolution when accessing other services on a VPN router
Client IP Address Assignment

Typically, when you have slower WAN links or when you have dial-up links, you place a DHCP server on each
side of a remote site connection. Installing the DHCP service on a calling router or other server at a branch
office lets branch office clients obtain IP addresses from that server.
However, a DHCP server located in one subnet can support other subnets. If no DHCP server is located at the
branch office, when a client at the branch office requests an address, the calling router can forward the client’s
request across the dial-up or VPN link to the DHCP server in the main office, which then leases the client an
address. For this to work, ensure the following:
• The calling router contains the DHCP Relay Agent (the DHCP Relay Agent component is added
with the internal interface by default).
• The calling router is configured with the DHCP server’s IP address.
• The site-to-site connection is a persistent connection.
For an on-demand connection, if the DHCP Relay Agent is installed on a branch office router, this can cause the
router to dial the main office router (for a non-VPN dial-up connection) or the local ISP (for a VPN connection
that uses a dial-up link to the ISP) every time a DHCP packet is sent by a computer in the branch office network.
Therefore, if you deploy an on-demand connection, install the DHCP service in the branch office and uninstall
the DCHP Relay Agent on the calling router.
For more information about deploying DHCP, see “Deploying DHCP” in this book.
IP Address Assignment for the Logical Interface

When a calling router initiates a connection, the router creates a temporary logical interface (also known as a
virtual interface or a virtual network adapter) and requests that the answering router assign an IP address to this
logical interface. The answering router then creates a logical interface and requests an IP address for itself from
the calling router. The logical interface on the calling router connects to the logical interface on the answering
router to form the demand-dial connection. The IP address assignment for each demand-dial interface lasts for
the duration of the connection. These IP addresses can be either private or public IP addresses. If both requests
are successful, the logical interface on the PPP connection for each router is assigned an IP address from the
other router. This is known as a numbered connection. In the absence of a numbered connection, a site-to-site
connection can also use an unnumbered connection.
Numbered Connection
A numbered IP address assignment can occur in one of the following ways:
• Dynamic IP addresses allocated by a DHCP server. The answering router obtains the IP
address to assign to a calling router from a DHCP server. This is the default method for IP
address assignment. If no DHCP server is available, the router uses an address from the
Automatic Private IP Addressing (APIPA) range 169.254.0.1–169.254.255.254. You must
install a DHCP server on each network that contains an answering router.
• Dynamic IP addresses allocated from a static address pool configured on the answering
router. The answering router obtains the IP address from a static pool of addresses. If you
configure a static address pool, be sure to use only IP addresses that are not in a range that your
DHCP server might assign to another computer and that are not already assigned to specific
computers. The pool can be ranges of addresses that are a subset of addresses from the IP
network to which the server is attached or from a separate subnet. As described earlier, if the
static IP address pool address ranges represent a different subnet, ensure that routes to the
address ranges exist on the routers of your intranet so that traffic to the logical interface of a
calling router is forwarded to the remote server.
• Static IP address specified in the calling router user account. You configure a static IP
address on the router user account Dial-in tab for both the calling and the answering router. In
this case, when a calling router initiates a connection, creates a temporary logical interface, and
requests that the answering router assign an IP address to this logical interface, the answering
router assigns the IP address specified in the calling router’s user account. The answering router
then creates a logical interface and requests an IP address for itself from the calling router. The
calling router assigns the IP address specified in the answering router’s user account.
Unnumbered Connection
Site-to-site connections in Windows Server 2003 and Windows 2000 do not require a numbered connection
(Windows NT 4.0 RRAS connections do require a numbered connection). If one of the routers rejects the
request for an IP address during the connection establishment process between a calling and an answering router
(because no addresses are available to assign, probably due to a misconfiguration), a connection is still
established. In this case, the logical interface on the PPP connection does not have an assigned IP address. This
is known as an unnumbered connection.
The routing protocols provided with Routing and Remote Access cannot operate over unnumbered connections.
Therefore, you must use static routing if you use unnumbered connections.
Using IP Addresses to Avoid Name Resolution Issues

When you configure a demand-dial interface for a dial-up calling router, you provide the phone number of the
answering router with which this router establishes a connection. In this case, name resolution is not an issue.
For VPN connections, however, the corresponding entry on the demand-dial interface is the destination address
of the answering router. In this case, name resolution can be an issue, because you can provide either the
Domain Name System (DNS) name or the IP address of the answering router. Microsoft recommends that you
provide the IP address rather than the answering router name when you configure a demand-dial interface so
that resolution of the name to the IP address by means of a DNS or Windows Internet Name Service (WINS)
server is not needed.
If you do use names for demand-dial interfaces, make sure that an appropriate DNS record exists on the DNS
server that hosts the public namespace that is visible to Internet users and computers, or on the DNS server of
your ISP, so that the DNS names of your answering routers can be resolved.
Using Name Resolution When Accessing Other Services on a

VPN Router
In some organizations, you might want users to be able to access other services, such as file shares, on the
answering VPN router. For this type of configuration, if you specify the DNS name rather than the IP address in
the demand-dial interface, and the name resolves to the public IP address of the answering router, traffic sent to
the services running on the router is sent in clear text (unencrypted) across the Internet. It is not encapsulated,
encrypted, and sent using the VPN connection, which can compromise security.
A related problem is that if you configure packet filters on the answering router to allow only traffic over a VPN
connection, all other traffic is discarded. Attempts to connect to services running on the answering router fail in
this situation, because traffic attempting to connect to those services is not sent over the site-to-site VPN
connection.
If the site DNS and WINS servers do not contain a record mapping the name of the VPN router to its public IP
address, traffic to services running on the VPN router is always sent across the VPN connection. To ensure that
the name of the VPN router is always resolved to the private or site IP address of the VPN router, disable DNS
dynamic update and NetBIOS over TCP/IP (NetBT) on the Internet-connected interface (or interfaces) of the
VPN router from the properties of the Internet connection in Network Connections as follows:
• Prevent DNS name resolution. To prevent a VPN router from dynamically registering the
public IP address of its Internet interface on the site DNS servers, on the Internet interface of
the router, configure the properties of Internet Protocol (TCP/IP) by clicking the Advanced
button, selecting the DNS tab, and then clearing the Register this connection’s addresses in
DNS check box.
• Prevent WINS name resolution. To prevent a VPN router from dynamically registering the
public IP address of its Internet interface on the site WINS servers, on the Internet interface of
the router, configure the properties of Internet Protocol (TCP/IP) by clicking the Advanced
button, selecting the WINS tab, and then selecting the option Disable NetBIOS over TCP/IP.
Note
By default, the Routing and Remote Access Wizard clears Register
this connection’s addresses in DNS and selects Disable NetBIOS
over TCP/IP. Be sure not to change these defaults if you want users to
be able to access services such as file shares on the answering VPN
router.
For more information about name resolution, see “Deploying DNS” and “Deploying WINS” in this book.
Planning Active Directory Integration

Integrating a remote site connection into an Active Directory–based network requires you to decide which
choices you want to make about the following tasks:
• Put a domain controller at the branch office.
• Use one domain to include geographically remote sites.
• Use scheduled replication or reciprocal replication.
• Join demand-dial routers to the Active Directory domain.
Putting a Domain Controller at the Branch Office

If you deploy a persistent site-to-site connection between a branch office and a main office, you might not need
a domain controller at the branch office. Branch office users can access a domain controller in the main office
when they log on to their computers or use other Active Directory services.
For an on-demand connection, install a domain controller at the remote site.
Using One Domain to Include Geographically Remote Sites

You can include a main office and a branch office in one Active Directory domain. However, geographically
remote sites must not share the same address space and must have separate Active Directory sites. You must
create a separate Active Directory site for the branch office and create a child object for the branch office,
providing the appropriate network ID and subnet mask for the branch office site.
For more information about deploying Active Directory, see “Deploy Active Directory” later in this chapter.
Using Scheduled Replication or Reciprocal Replication

Typically, domain controllers have a constantly available connection so that all domain controllers obtain a
steady flow of updated directory information. If you have domain controllers in sites that are connected by a
site-to-site connection, you must ensure that replication takes place. Directory updates can be exchanged
through a site-to-site connection in one of two ways:
• Scheduled replication. On a persistent site-to-site connection, you can schedule replication to
take place at specified intervals.
• Reciprocal replication. For a one-way initiated on-demand connection in which no constantly
available connection exists between domain controllers in the two sites, you must enable
reciprocal replication. With reciprocal replication, all replication occurs simultaneously
between the domain controllers in the two sites, and the connection is closed when replication is
complete. Reciprocal replication maximizes the efficiency of directory information exchange
while minimizing connection time and eliminating timeout errors that can occur if the main site
domain controller requests changes from the branch site domain controller when the connection
is not available. You can configure reciprocal replication on a site link or on a connection.
For more information, see “Configure Replication” later in this chapter.
Joining Demand-Dial Routers to the Active Directory Domain

In an Active Directory domain, you can choose either to join a demand-dial router computer to the domain or
not to, based on the following factors:
• If your answering router uses Active Directory user accounts to authenticate and authorize a
calling router, you must join the answering and calling routers to the domain.
• If you use EAP-TLS user authentication with Windows as the authentication provider, you must
join the answering router (which is the authenticating server) to the Active Directory domain. If
you use EAP-TLS user authentication with RADIUS as the authentication provider, you must
join the IAS server (which is the authenticating server) to the Active Directory domain. With
RADIUS authentication, the answering router does not need to be joined to the domain. (Use
Windows authentication for a site-to-site only connection. You might use RADIUS
authentication for a site-to-site connection if the answering router also supports remote access
users.)
• If you use L2TP/IPSec with computer certificates, the demand-dial routers are not required to
join the Active Directory domain. However, the Windows Server 2003 PKI uses Active
Directory, if it is installed, to store certificates, certificate revocation lists, and delta certificate
revocation lists and to publish root CA certificates and cross-certificates. Using Active
Directory makes this information easy to locate from anywhere on the network. (If you use
L2TP/IPSec with preshared keys, you are not required to join the VPN routers to the Active
Directory domain.)
For more information about planning and deploying Active Directory for an organization with multiple branch
office sites, see the Active Directory Branch Office Planning Guide link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources.
For more information about deploying Active Directory domains and sites and Active Directory replication
between sites, see “Designing the Site Topology” in Designing and Deploying Directory and Security Services
of this kit.
Preparing for Server Configuration

If you have existing Windows NT 4.0 or Windows 2000 site-to-site connections, you must decide whether to
upgrade your routers to Windows Server 2003 and migrate to the Windows Server 2003 Routing and Remote
Access service, or whether to continue to support your current configuration. Before you install the Routing and
Remote Access service on your demand-dial routers, you must decide how many routers you need, and you
must make sure that the computers meet Windows Server 2003 requirements.
For more information about creating hardware and software inventories, see “Planning for Deployment” in
Planning, Testing, and Piloting Deployment Projects of this kit. The flowchart in Figure 10.8 shows the tasks
required when preparing to configure the router server.
Figure 10.8 Preparing for Server Configuration
Migrating Routers from Windows NT 4.0 or

Windows 2000
If you have an existing site-to-site connection between remote offices using Windows NT 4.0–based or
Windows 2000–based servers and plan to upgrade most of your network to Windows Server 2003, Windows
Server 2003 can support your existing Routing and Remote Access or RRAS servers. Alternatively, you can take
advantage of the new features in Windows Server 2003 by upgrading your demand-dial routers.
The following topics can help you decide whether to upgrade your demand-dial routers:
• New features
• Migrating router settings
New Features
In Windows NT Server 4.0, routing and remote access are separate services. In Windows 2000 Server and
Windows Server 2003, these functions are combined in the single Routing and Remote Access service.
Table 10.10 lists new features available in Windows Server 2003 and Windows Server 2000.
Table 10.10 New Features for Dial-up or VPN Site-to-Site Connections Since Windows NT
Server 4.0 RRAS
Windows
New Features
Release
Windows 2000 • L2TP/IPSec. An L2TP/IPSec VPN tunnel provides stronger
Server security than a PPTP VPN tunnel.
• Remote access policies. This feature gives administrators
more flexibility in setting remote access permissions and
connection restraints.
• MS-CHAP v2. This type of password–based user
authentication provides a stronger alternative to MS-CHAP.
(MS-CHAP v2 is also available in Windows NT 4.0 SP4.)
• EAP. Support for EAP lets you use installable authentication
methods, such as EAP-TLS certificate-based user
authentication, which is stronger than password-based user
authentication.
Windows • Improved wizards and snap-in. The Routing and Remote
Server 2003 Access and Demand-Dial Interface wizards and the Routing
and Remote Access snap-in are easier to use.
• Intranet and Internet-connected interface improvements.
By default, the Routing and Remote Access service now
disables dynamic DNS on the intranet interface and disables
dynamic DNS and NetBIOS over TCP/IP on the Internet-
connected interface to ensure correct name resolution of the
router and to ensure access to services running on the router.
• Preshared keys. Support for configuring preshared keys using
the Routing and Remote Access snap-in provides an
alternative to computer certificates in L2TP/IPSec
authentication.
• NAT/Basic Firewall configuration. You can use Manage Your
Server to configure the NAT/Basic Firewall component of
Routing and Remote Access. NAT integration with static and
dynamic packet filtering lets you configure NAT interfaces to
work with Basic Firewall or with incoming or outgoing static
packet filters.
• NAT-T. IPSec NAT traversal (NAT-T) lets you create
L2TP/IPSec connections from a calling or answering router
that is located behind one or more NATs.
• PPPoE. Support for PPPoE lets a small business use
NAT/Basic Firewall and their broadband Internet connection to
connect a branch office to their local ISP. Using PPPoE for an
on-demand connection is faster than using a dial-up link to
connect to the ISP.
Migrating Router Settings

When you upgrade from Windows NT 4.0 or Windows 2000 to Windows Server 2003, you retain all IP-based
routing configuration, including demand-dial, RIP, OSPF, and DHCP Relay Agent settings. However, Windows
Server 2003 does not support the NetWare routing protocol Internetwork Packet Exchange (IPX). If you
upgrade from Windows NT 4.0 to Windows Server 2003, and IPX settings are detected, you are provided the
option not to upgrade after all.
Planning Server Capacity

Table 10.11 provides capacity planning information that you can use to help determine how many demand-dial
servers you need to deploy and how much data throughput your site-to-site connection can support.
Table 10.11 Capacity Planning
Factor Capacity
Number of For two-way connections, one answering router supports 10
connections simultaneous calling router connections before performance
begins to degrade.
For one-way connections, one answering router supports 100
simultaneous calling router connections before performance
begins to degrade.
Data The amount of data throughput that a site-to-site connection
throughput can support depends, in part, on what resources the users are
using on the network. Other factors that affect data throughput
include:
• IPSec offload card. You can increase data throughput for
L2TP/IPSec by installing an IPSec offload card. Using an IPSec
offload card and a dual processor lets a server process more
than 50 Mbps of fully encrypted data. To install an IPSec offload
card, follow the manufacturer’s instructions.
• Compression. Using Microsoft Point-to-Point Compression
(MPPC) decreases data throughput. To increase data
throughput, turn off MPPC. You can turn off MPPC by using one
of the following methods:
• To clear compression on a specific demand-dial
interface. In Routing and Remote Access, in the console
tree, click Network Interfaces, right-click the demand-dial
interface on which you want to clear compression, and then
click Properties. On the demand-dial interface Properties
page, click the Networking tab, click Settings, and then in
the PPP Settings dialog box, clear the check box Enable
software compression.
• To clear compression for all types of PPP connections.
In Routing and Remote Access, in the console tree, right-
click the demand-dial server icon, click Properties, click the
PPP tab, and then clear the check box Software
compression. This disables compression both for site-to-
site connections and for remote access connections.
Planning Server Deployment

The following information can help you plan how to set up your server before you deploy the remote site
connection:
• Meeting server requirements
• Disabling unused services
• Planning physical and administrative security
Meeting Server Requirements

Table 10.12 lists the minimum hardware and software requirements for a demand-dial router.
Table 10.12 Hardware and Software Requirements for a Demand-Dial Router
Component Requirement
Processor Pentium 233 MHz processor (550 MHz recommended)
Memory 128 MB RAM (256 MB recommended)
Hard drive 4 GB hard drive
LAN adapter A network adapter connected to the intranet. The adapter must
have a driver that displays the Designed for Windows logo. The
server must have multiple network adapters or a single network
adapter configured with multiple IP addresses.
WAN • For a dial-up site-to-site connection: An ISDN adapter, analog
adapter modem, or other physical device that is connected to the line that
connects the two sites.
• For a VPN site-to-site connection: A network adapter that is
connected to the Internet, either directly or through a perimeter
network. Typically, this is a T-Carrier or Frame Relay adapter, or a
DSL or cable modem.
Software The Windows Server 2003 operating system. Windows
Server 2003 includes the Routing and Remote Access service,
which you must enable.
Before you deploy a dial-up or VPN router, install and configure the required hardware and the appropriate
drivers, and test whether each one functions properly. To determine if the hardware in your organization is
certified and compatible, see the Windows Catalog link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources.
Disabling Unused Services

Disabling services that you do not use on your demand-dial server has two advantages: It returns resources to
the server that other components can use, and it makes your backend network more secure by shutting off
services that are potential entry points for attackers trying to break into your network.
The following is a list of services that you might be able to disable on a server that you plan to use as a demand-
dial router:
• Distributed File System (DFS)
• Distributed Transaction Coordinator
• Fax Services
• File Replication service (FRS)
• Indexing Service
• Internet Connection Sharing (ICS)
• Intersite Messaging
• Kerberos Key Distribution Center
• License Logging Service
• Print Spooler
• Task Scheduler
• Telnet
• Windows Installer
Important
Do not disable the remote registry service. If you disable it, the
demand-dial router cannot operate correctly.
Planning Physical and Administrative Security

To prevent the intentional or unintentional modification of your router configuration, use the following
guidelines to secure your routers:
• Keep router computers physically secure from unauthorized users or intruders, for example, by
placing them in a locked room.
• Delegate administration rights and permissions for the Routing and Remote Access service to a
limited number of individuals.
• Assign administrator rights to an Active Directory group whose role is to administer remote site
connections, and add only authorized users to that group. You can easily update changes to the
group membership, whereas, if you do not use a group, you must administer each Administrator
account separately on each Routing and Remote Access server.
• On both the calling router and the answering router, rename the local Administrator account and
use strong passwords for the account.
Deploying a Site-to-Site
Connection
After you make all the necessary design decisions, you can deploy a remote site connection for your
organization. The flowchart in Figure 10.9 shows the tasks that can help you to successfully deploy a site-to-site
connection.
Figure 10.9 Deploying a Site-to-Site Connection
If you want to try a test deployment to prepare for your production deployment, see “Perform a Test
Deployment in Your Lab” later in this chapter. If you are ready to connect two sites in your production
environment now, see “Deploy a Remote Site Connection” later in this chapter.
Perform a Test Deployment in Your Lab

By reading the design sections earlier in this chapter, you can develop a good idea about which remote site
connectivity features are appropriate for your organization. However, before you deploy any technology in your
production network, it is a good practice to perform a test deployment in a lab first. Testing in a lab familiarizes
you with how the technology works and gives you the opportunity to experiment with different features when
alternatives are available.
When testing how to deploy a remote site connection, evaluate the following key issues in a lab setting before
deciding how to deploy the technology in your production environment:
• Whether to deploy a dial-up connection, a PPTP VPN, or an L2TP/IPSec VPN.
• Whether to deploy an on-demand connection or a persistent connection.
• Whether to deploy a one-way initiated connection or a two-way initiated connection.
• If you plan to deploy a VPN connection, what type of perimeter network you want to use.
• Whether to use certificate-based EAP-TLS or password-based MS-CHAP v2 for user-level
authentication.
• If you plan to deploy an L2TP/IPSec VPN connection (the only connection type that offers
computer-level authentication), whether to use computer certificates or preshared keys.
• Whether the encryption method, such as a dial-up or PPTP VPN connection using MPPE
encryption or an L2TP/IPSec VPN using IPSec for encryption, influences your decision about
which connection type to use.
• Whether to use an Active Directory account (and join your routers to the Active Directory
domain) or use a local account for your router user accounts.
• Which dial-up options to set in the router user account.
• Whether to use a default remote access policy, a common policy, or a custom policy.
• Which static IP addresses and which static routes are needed.
• Which routing protocol or protocols are needed.
• Whether your demand-dial routers will support Internet traffic.
• Whether to enable multicast connectivity between your sites.
• Whether to deploy a DHCP server in each site.
• Whether to deploy a domain controller in each site.
For a tool to assist you in evaluating some of the remote connectivity features presented in this list, see
“Example: Contoso Connects Remote Sites” (DNSREM_1.doc) on the Windows Server 2003 Deployment Kit
companion CD (or see “Example: Contoso Connects Remote Sites” on the Web at
http://www.microsoft.com/reskit). This job aid shows you how to deploy a PPTP VPN and a dial-up connection
in a lab environment.
For additional test lab deployment examples, including information about deployments that include certificates
and L2TP/VPN connections, see “Routing scenarios” and “Virtual private network implementation examples”
in Help and Support Center for Windows Server 2003.
Deploy a Remote Site Connection

To connect remote sites using a site-to-site link, you must decide which of the design options described earlier
in this chapter you want to deploy. Use the “Choose Optional Tasks You Need” column in Figure 10.10 to mark
which optional tasks you will perform for your deployment.
Figure 10.10 Deployment Tasks for a Site-to-Site Connection Worksheet
For a copy of Figure 10.10 that you can use to record which deployment options you need for your site-to-site
deployment, see “Site-to-Site Connection Deployment Steps” (DNSREM_2.doc) on the Windows Server 2003
Deployment Kit companion CD (or see “Site-to-Site Connection Deployment Steps” at
http://www.microsoft.com/reskit). You can also use this worksheet as a guide for the sequence in which you
must perform the tasks.
Deploy Active Directory

How you manage Active Directory and domain controllers in a branch office varies depending on the size,
complexity, and structure of your overall network. If you do not plan to deploy a domain controller in the branch
office location, Microsoft recommends that you establish a persistent connection between the two sites. If you
do plan to locate a domain controller in the remote site with which you want to establish a site-to-site
connection, you must place it in a subnet separate from the computers at the main site and create a separate
Active Directory site for the branch office subnet.
To deploy a domain controller for a new branch office site
Note
This procedure assumes that both sites belong to the same Active
Directory domain.
1. Install the Windows Server 2003 operating system on a computer at the main office, promote it
to a domain controller, and then confirm that it successfully replicates with the existing domain
controllers.
2. Log on as a member of either the Domain Administrators or Enterprise Administrators security
group of the forest root domain, open Active Directory Sites and Services, right-click Sites,
select New Site, type a name for the new branch office site, and then, under Link Name, select
the appropriate site link (such as DEFAULTIPSITELINK).
3. Right-click the server object of the new branch office domain controller from its current
location (which might be under Default-First-Site-Name), click Move, and then, in the Move
Server dialog box, click the new site that you just created.
4. Right-click Subnets, click New, and then click Subnet to create a new child for the new remote
site, providing the appropriate network ID and subnet mask.
Note
If, until now, your domain has had only one site, you must create two
child objects under Subnets — one for the main office site and one for
the branch office site, each with its own network ID and subnet mask.
5. If necessary to optimize network performance, make the domain controller a global catalog.
6. Ship the new domain controller to the remote site.
7. Install a LAN adapter connected to the branch office intranet, and then, on the LAN adapter’s
Internet Protocol (TCP/IP) Properties page, configure an IP address, subnet mask, and
gateway appropriate for the branch office subnet.
The domain controllers in the main and branch offices cannot replicate yet, because the demand-dial connection
does not exist yet. For information about how to configure replication after a connection exists, see “Configure
Replication” later in this chapter.
Deploy a Certificate Infrastructure

If you plan to use EAP-TLS as your authentication protocol for user-level authentication on a dial-up, PPTP
VPN, or L2TP/IPSec VPN connection, or if you plan to use L2TP/IPSec with computer certificates for your
VPN connection, or if you plan to do both, you must have a certificate infrastructure in place in your network.
For information about creating a certificate infrastructure, see “Certificate Services” in Help and Support Center
for Windows Server 2003, and see “Designing a Public Key Infrastructure” in Designing and Deploying
Directory and Security Services of this kit.
Deploy an IAS Server for RADIUS Authentication

For a site-to-site only connection, you use Windows authentication and do not need to deploy an IAS server.
However, if you use the same answering router for both a site-to-site connection and a remote access connection
that supports mobile or home users, you might decide to use RADIUS authentication instead. If you plan to use
RADIUS authentication and Windows Server 2003 IAS, you must have an IAS server available in your
network. Deploying an IAS server is the same for both dial-up and VPN site-to-site connections.
To enable RADIUS authentication
1. Install an IAS server. To ensure that RADIUS authentication and accounting services remain
available, configure both a primary IAS server and one or more backup (secondary) IAS servers
to provide redundancy and fault tolerance.
2. Register the IAS servers in the appropriate Active Directory domain.
3. Configure the primary IAS server with RADIUS clients corresponding to your answering
routers.
4. Configure each answering router with the RADIUS servers of your primary and secondary
RADIUS servers.
5. After you enable the Routing and Remote Access service, configure remote access policies that
reflect your dial-up or VPN connection requirements on the primary IAS server. For more
information, see “Configure the Routing and Remote Access Service and Demand-Dial
Interfaces” and “Configure a Remote Access Policy” later in this chapter.
6. Configure logging methods for user authentication and accounting requests.
7. Copy the IAS configuration (including the remote access policies) from the primary IAS server
to the secondary IAS server.
For more information about installing an IAS server and using it for RADIUS authentication, see “Deploying
IAS” in this book, and see “Checklist: Configuring IAS for dial-up and VPN access” in Help and Support
Configure Active Directory User Accounts and Groups

Note
If you plan to use local accounts, do not perform these steps. Instead,
use the Demand-Dial Interface Wizard to create a user account for the
calling router locally on the answering router.
Each calling router must have a user account, which the answering router uses to authenticate the calling router.
If you have more than one calling router and if you joined your routers to the Active Directory domain, you can
add each router user account to an Active Directory group to simplify administration.
Use the following procedures to accomplish these tasks:
• Create Active Directory user accounts for routers.
• Add router user accounts to an Active Directory group.
Create Active Directory User Accounts for Routers

If you plan to use Active Directory user accounts for demand-dial routers, you manually create an Active
Directory user account for each calling router (you can use the Demand-Dial Interface Wizard to create the user
account only if you use a local user account).
To create an Active Directory user account for a router
1. Open the Active Directory Users and Computers snap-in, and create a user account for the
calling router (for a two-way connection, create a user account for the calling router in both
sites). The name of the account must match the name of a corresponding demand-dial interface
on the remote router.
2. To ensure that connectivity occurs, clear the User must change password at next logon check
box and select the Password never expires check box on the Account tab on the property sheet
for the user account object.
3. On the user account Dial-in tab, select one of the following options:
• Allow access. This option overrides the grant or deny remote access permission setting
specified on the Properties page of any associated remote access policy.
• Control access through Remote Access Policy. This option ensures that the grant or deny
remote access permission setting specified on the Properties page of any associated remote
access policy is used.
Add Router User Accounts to an Active Directory Group

If you use Active Directory user accounts for demand-dial routers, you can add the router user accounts to a
group to simplify administering them and to simplify configuring remote access policies.
To add router user accounts to a group
1. Open the Active Directory Users and Computers snap-in, create an Active Directory group to
contain the user accounts of the calling routers. Use an appropriate name, such as
BranchOfficeRouters.
2. Add the user accounts of the calling routers to the group.
Configure the WAN Adapter

On the demand-dial router at each site, use the following procedures, as appropriate, to configure the WAN
adapter for a dial-up connection, the WAN adapter for a dedicated link to an ISP, or (if needed) to configure the
DNS server IP address.
To configure the WAN adapter for a dial-up connection
1. On the demand-dial router at each site, install the WAN adapter. This WAN adapter is a modem,
an ISDN adapter, or other physical device connected to one of the following:
• For a non-VPN dial-up connection, the line that links the two sites.
• For a VPN with a dial-up connection to the local ISP, the line that links the branch office
router to its local ISP.
2. Provide the phone number and the authorized user name and password. Leave the Domain field
blank. The phone number is one of the following:
• For a non-VPN dial-up connection, the phone number of the answering router.
• For a VPN that uses a modem, ISDN, or PPPoE dial-up connection to its local ISP, the
phone number of the local ISP.
To configure the WAN adapter for a dedicated link from a VPN router to an ISP
1. On the demand-dial router at each site, install the Internet-connected WAN adapter. This WAN
adapter is a DDS, T1, Fractional T1, or Frame Relay adapter.
2. On the WAN adapter’s Internet Protocol (TCP/IP) Properties page, configure the following:
a. The public IP address and subnet mask allocated to you by your ISP (or by the InterNIC).
b. The default gateway of the firewall (if you plan to have the router connect to a perimeter
network) or of the ISP router (if you plan to have the router connect directly to the
Internet).
To configure the DNS server IP address (if needed)

• If you have a VPN connection, configure the DNS server IP address on the Internet-connected
interface of the calling router if either of the following is true:
• If you use the DNS name of the answering router (instead of its IP address), you must
specify the DNS server IP address in the Internet-connected interface of the calling router.
Because the Routing and Remote Access Wizard clears the Register this connection’s
addresses in DNS check box (on the DNS tab) and selects Disable NetBIOS over TCP/IP
(on the WINS tab), you must configure the DNS server IP address on the VPN Internet-
connected interface after you run the wizard.
• If the branch office calling router will provide users access to the Internet (in addition to
supporting site-to-site traffic to the main office), you must specify the DNS server IP
address in the Internet-connected interface of the calling router. For more information
about configuring access to the Internet, see “Configure Internet Access Through the
Calling Router” later in this chapter.
Configure the Intranet Connection

Configure the intranet interface on the demand-dial router at each site.
To configure the connection to the local intranet
1. Install a LAN adapter connected to the intranet.
2. On the LAN adapter’s Internet Protocol (TCP/IP) Properties page, configure the following:
a. The public or private IP address and subnet mask that your network administrator
assigned.
b. The IP addresses of the DNS and WINS name servers for your organization’s intranet.
3. Typically, leave the default gateway value on the LAN adapter blank to avoid default route
conflicts with the default route pointing to the Internet.
Note
If a router is positioned between the demand-dial router that you are
configuring and the intranet, the Routing and Remote Access Wizard
might not be able to add the demand-dial router to the list of valid
remote access servers in the Active Directory. One workaround to this
problem is to temporarily configure the default gateway on the LAN
adapter. To do this, enter a value for the default gateway, run the
Routing and Remote Access and Demand-Dial Interface wizards (as
described later), and then remove the default gateway from the LAN
adapter.
Do not configure the intranet interface of the router to be a DHCP client. However, an answering router can still
use DHCP to obtain IP addresses for calling routers, and vice versa.
Join the Router to the Domain

After you install the Windows Server 2003 operating system on the computers that you want to use as the
calling and answering routers, you can join the routers to the Active Directory domain.
If you have a calling router that is located in the branch office, and you already have a domain controller in the
branch office, join the router computer to the domain there.
If you do not have a domain controller at the branch office yet, you can install the Windows Server 2003
operating system on the computer that you want to use as the calling router while that computer is located in the
main office, join the computer to the domain, and then ship it to the branch office.
Note
Alternatively, you can set up the routers to dial in once, install Active
Directory on the computer in the branch office that you want to use as
the domain controller, replicate, and then join the routers to the domain.
Place the Router in Your Perimeter Network

For optimal security, place both the answering router and the calling router in a perimeter network at their
respective sites. For more information about VPN routers and perimeter networks, see “VPN servers and
firewall configuration” in Help and Support Center for Windows Server 2003.
Install Computer Certificates for L2TP/IPSec

If you use an L2TP/IPSec site-to-site connection, you must install a computer certificate on both the answering
router and on the calling router. You must have a certification authority (CA) in your network to issue these
certificates.
You can install a computer certificate for L2TP/IPSec by using one of three methods:
• Configure the automatic enrollment of computer certificates in a Windows Server 2003 domain
system container by using Group Policy.
• Use the Certificates snap-in to request a computer certificate.
• Use your Web browser to connect to the CA Web enrollments pages to request a certificate.
Note
It is also possible to use a preshared key to provide authentication for
IPSec security associations for an L2TP/IPSec connection. However,
using computer certificates is the recommended method.
For information about how to create a certificate infrastructure and install computer certificates, see “Certificate
Services” in Help and Support Center for Windows Server 2003, and see “Designing a Public Key
Infrastructure” in Designing and Deploying Directory and Security Services of this kit. For more information
about configuring a preshared key, see “Configure a pre-shared key for a demand-dial routing interface” in Help
and Support Center for Windows Server 2003.
Install Computer and User Certificates for EAP-TLS

When you use EAP-TLS as the user authentication method for your site-to-site connection, you must install a
computer certificate on the authentication server of the answering router and a user certificate on the calling
router. These steps are the same for a dial-up router and for a VPN router.
For information about how to deploy certificates required by EAP-TLS see “Deploying certificate-based
authentication for demand-dial routing” in Help and Support Center for Windows Server 2003.
Configure the Routing and Remote Access Service and

Demand-Dial Interfaces
Use the following procedures to enable the Routing and Remote Access service and to establish a site-to-site
connection:
• Enable Routing and Remote Access.
• Configure the demand-dial interface for the remote site connection.
• Configure an additional demand-dial interface for a temporary ISP link.
Enable Routing and Remote Access

When you run the Routing and Remote Access Wizard to enable the Routing and Remote Access service, the
choices you make are the same for dial-up routing and for VPN routing.
To enable the Routing and Remote Access service
Note
You can skip step 1 if either of the following is true:
• If this server uses local authentication or authenticates against a
RADIUS server.
• If you have administrative rights to add the computer account of
the Routing and Remote Access server to the RAS and IAS
Servers security group. The wizard automatically adds the
computer to RAS and IAS Servers.
1. Enable the router as follows:

a. Ask your domain administrator to add the router’s computer account to the RAS and IAS
Servers security group for this domain by using the Active Directory Users and Computers
snap-in or the netsh ras add registeredserver command.
b. If this router must access other domains, ask your domain administrator to add the router’s
computer account to the RAS and IAS Servers security group of the other domains.
c. Restart the router for the change to take effect immediately.
2. Open Routing and Remote Access, select the computer on which you want to enable the
Routing and Remote Access service (probably the computer you are currently working on), and
then, on the Action menu, select Configure and Enable Routing and Remote Access to start
the Routing and Remote Access Wizard. Complete the wizard pages as shown in Table 10.13.
Table 10.13 Enabling the Routing and Remote Access Service

Wizard Page Action
Configuration Select Secure connection between two private networks.
Demand-Dial Select Yes (to use demand-dial routing to access remote
Connections networks).
IP Address Choose one of the following alternative options:
Assignment Select Automatically to use DHCP if you want to assign
addresses automatically without using a specified range of
addresses.
-or-
Select From a specified range of addresses if you want to
specify an address range (recommended):
1. On the Address Range Assignment screen, select New,
and then type values for the following:
• Starting address
• Ending address
You can use public or private address ranges.
Based on what you specify for the starting and ending
addresses, the Number of addresses for the IP address
pool field is prepopulated for you.
Note. For example, for a two-way connection, you might
specify the range 192.168.10.1–192.168.10.2 on the calling
router and the range 192.168.0.220–192.168.0.221 on the
answering router. In this case, if the calling router initiates the
connection, the calling router assigns 192.168.10.1 to itself,
and it assigns 192.168.10.2 to the answering router.
2. If the static IP address pool address range is an off-subnet
address range, ensure that the routes to the address range
exist in the routers of your intranet.
When the Routing and Remote Access Wizard completes, you might see the message
“Windows was unable to add this computer to the list of valid remote access servers in the
Active Directory. Before you can use this computer as a remote access server, the domain
administrator must complete this task.” If you see this message, click OK. Later, after you
complete the Demand-Dial Interface Wizard (described next), you will add the computer
account to the RAS and IAS Servers security group.
Configure the Demand-Dial Interface for the Remote Site Connection

The Demand-Dial Interface Wizard appears automatically after the Routing
and Remote Access Wizard completes.
To configure the demand-dial interface for a remote site connection
• Complete the wizard pages for the Demand-Dial Interface Wizard as shown in Table 10.14.
Table 10.14 Configuring the Demand-Dial Interface for a Remote Site
Connection
Wizard Page Action
Interface Type a name for the remote router that matches the user
Name account name that you created earlier for the remote router.
Connection Choose one of the following alternative options:
Type Connect using a modem, ISDN adapter, or other physical
device. Select this option to establish a device-to-device
dial-up connection.
1. On the Select a device screen, select the modem or adapter
this interface will use from the prepopulated list.
2. On the Phone Number screen, if this is a calling router, type
the phone number of the router this interface will call. (If this
is an answering router that is not also a calling router, you
can leave this blank.)
-or-
Connect using virtual private networking (VPN). Select
this option to establish a VPN connection over the Internet.
1. On the VPN Type screen, select one of the following:
• Automatic (accepts either PPTP or L2TP connections)
• Point to Point Tunneling Protocol (PPTP)
• Layer Two Tunneling Protocol (L2TP)
2. On the Destination Address screen, if this is a calling router,
type the IP address of the remote router this interface will
connect to. (If this is an answering router, you can leave this
field blank.)
Do not select the third option, Connect using PPP over
Ethernet (PPPoE), because PPPoE is used to link to the
local ISP, not to create a device-to-device dial-up link or a
VPN tunnel.
(continued)
Table 10.14 Configuring the Demand-Dial Interface for a Remote Site

Connection (continued)
Wizard Page Action
Protocols 3. Select Route IP packets on this interface (the default).
and Security 4. If this is an answering router that is not joined to an Active
Directory domain, add a local account by selecting Add a
user account so a remote router can dial in. This creates a
local user account on the demand-dial router. (Do not select
this option if you earlier created an Active Directory user
account for the answering router to use to authenticate the
calling router.)
Static Routes To add one or more static routes to define the permanent
for Remote route between this network and the remote network, click
Networks Add, and then, in the Static Route dialog box, do the
following:
1. Destination — Type the network ID of the remote site.
2. Network Mask — Type the subnet mask for the network ID of
the remote site.
3. Metric — Select an appropriate number for the metric.
Dial In Type and confirm a password for the local user account.
Credentials Note. This page appears only if this is an answering router
(for an and if you chose Add a user account so a remote router can
answering dial in on the Protocols and Security page earlier in the
router) wizard (to use a local account rather than an Active Directory
account for router authentication). Notice that the
prepopulated User name provided is the same name as that
used for the demand-dial interface.
Dial Out Specify the dial-out credentials that this interface will use to
Credentials connect to the remote router:
(for a calling 1. User name — Type the name of the user account for the
router) calling router that matches the name of the corresponding
demand-dial interface on the answering router.
2. Domain — Type the domain name; typically, both sites
belong to the same domain.
3. Password and Confirm Password — Type the password.
Note. If this is an answering router that is not also a calling
router, you do not need to provide this information; however,
the wizard requires that you fill in this page, so type any
name, domain, and password.
If the Routing and Remote Access Wizard (which ran before the Demand-Dial Interface Wizard) was unable to
add the computer to the list of valid remote access servers in Active Directory, you saw the error message
“Windows was unable to add this computer to the list of valid remote access servers in the Active Directory.
Before you can use this computer as a remote access server, the domain administrator must complete this task.”
To enable the computer to function as a remote access server, add the computer account for the router to the
RAS and IAS Servers security group. For information about how to add a computer account to a group, see
“Add a computer account to a group” in Help and Support Center for Windows Server 2003. If you did not see
the error message indicating that the computer had not been added to the valid remote access servers in Active
Directory, you do not need to perform this step.
After at least one demand-dial interface exists, you can run the Demand-Dial Interface Wizard at any time to
add additional demand-dial interfaces by right-clicking Network Interfaces in console tree, and then clicking
New Demand-dial Interface. You run the wizard again for the following reasons:
• To add other branch office sites, repeat the steps in this procedure for each additional demand-
dial interface you want to create.
• To establish a temporary link to the local ISP at the branch office in order to create a demand-
dial interface for that link, perform the steps as described in the next section.
Configure an Additional Demand-Dial Interface for a Temporary ISP

Link
If this is a VPN connection, and you connect your branch office to its local ISP through a temporary link, you
must run the Demand-Dial Interface Wizard a second time to create a demand-dial interface for this physical
link to the ISP. This link to the ISP can be a dial-up link or a PPPoE link.
Note
If you are deploying a non-VPN dial-up link, or a VPN connection
between two sites, each of which connects to its local ISP through a
dedicated link, do not perform these steps. Instead, perform the steps
in “Configure the Routing and Remote Access Service and Demand-
Dial Interfaces” earlier in this chapter.
To configure a demand-dial interface for a temporary link to the ISP

• Open Routing and Remote Access, right-click Network Interfaces, click New Demand-dial
Interface, and then complete the wizard pages for the Demand-Dial Interface Wizard as shown
in Table 10.15.
Table 10.15 Configuring an Additional Demand-Dial Interface for a Temporary

Link to the ISP
Wizard Page Action
Interface Type an appropriate name, such as Dial_ISP.
Name
Connection Choose one of the following alternative options:
Type Select Connect using a modem, ISDN adapter, or other
physical device. Select this option to create a dial-up link to
your local ISP.
1. On the Select a device screen, select the modem or adapter
that this interface will use from the prepopulated list.
2. On the Phone Number screen, type the phone number of
your local ISP.
-or-
Select Connect using PPP over Ethernet (PPPoE). Select
this option to create a PPPoE link to your local ISP.
3. On the Service Name screen, type the name of the service
in the text box provided. (If you leave this text box blank,
Windows will automatically detect and configure your service
when you connect.)
Do not select the third option, Connect using virtual private
networking (VPN), because this demand-dial interface is for
the link to the ISP, not for a VPN tunnel.
Protocols Select Route IP packets on this interface (do not select Add
and Security a user account so a remote router can dial in).
Static Routes To add a static host route for the IP address allocated to the
for Remote answering router by the answering router’s ISP (or by
Networks InterNIC):
1. Destination — Type the IP address of the answering router’s
Internet-connected interface.
2. Network Mask — Type 255.255.255.255
3. Metric — Select an appropriate number for the metric.
Dial-In This page does not appear.
Credentials
Dial-Out Specify the dial-out credentials that this interface will use to
Credentials connect to the local ISP:
1. User name — Type the name of the user account that has
permission to access the local ISP (this is not the router user
account).
2. Domain — leave this field blank.
3. Password and Confirm password — Type the password.
Note. Open Active Directory Users and Computers, and then,
on the Dial-in tab of the user object’s Properties page for the
user account that has permission to access the local ISP,
select Allow access.
Configure a Remote Access Policy

You can use a remote access policy to validate a variety of connection settings before a connection is authorized,
and to specify a variety of connection restrictions after the connection is authorized.
Configure the Default Policy or Create a New Policy

Configuring the Routing and Remote Access service on a demand-dial router or installing IAS on a computer
running Windows Server 2003 creates two default remote access policies. You can use the Connections to
Microsoft Routing and Remote Access server default policy for your site-to-site connection. However, if you
want more precise control over connection requirements than the default policy provides, you can create a
common or a custom remote access policy.
To enable the default policy
Note
Do not perform these steps if you plan to create a common or custom
remote access policy, described next.
1. To enable the default policy, do one of the following:

• If you use Windows authentication, on the answering router open Routing and Remote
Access, and, if necessary, double-click Routing and Remote Access and the server name.
(Use Windows authentication for a site-to-site only connection.)
• If you use RADIUS authentication, on the IAS server open Internet Authentication Service,
and, if necessary, double-click Internet Authentication Service. (Use either Windows or
RADIUS authentication if the answering router for the site-to-site connection also supports
remote access users.)
2. In the console tree, click Remote Access Policies. In the details pane, right-click the default
policy Connections to Microsoft Routing and Remote Access server, and then click
Properties.
3. Select Grant remote access permission. (The default selection is Deny remote access
permission.)
To add a common or custom remote access policy
Note
Do not perform these steps if you plan to use the default policy,
described earlier.
1. To add a common or custom remote access policy, do one of the following:

• If you use Windows authentication, open Routing and Remote Access, and, if necessary,
double-click Routing and Remote Access and the server name.
• If you use RADIUS authentication, open Internet Authentication Service, and, if necessary,
double-click Internet Authentication Service.
2. In the console tree, right-click Remote Access Policies, and then click New Remote Access
Policy. Use the New Remote Access Policy wizard to create a common policy, as shown in
Table 10.16, or to create a custom policy, as shown in Table 10.17.
Table 10.16 Creating a Common Remote Access Policy by Using the New
Remote Access Policy Wizard
Wizard Page Action
Policy Select Use the wizard to set up a typical policy for a
Configuration common scenario, and then type an appropriate name for
Method the policy, such as Authenticate BranchOfficeRouters.
Access Method Select VPN or Dial-up, as appropriate.
User or Group Click Group, click Add, and then type the group name you
Access created earlier, such as BranchOfficeRouters.
Authentication Either accept the default method, MS-CHAP v2, or choose
Methods Extensible Authentication Protocol (EAP) and specify its
type (either MD5-Challenge or Smart card or other
certificate).
Policy Select Strongest encryption, and clear any other
Encryption selections.
Level
Table 10.17 Creating a Custom Remote Access Policy by Using the

New Remote Access Policy Wizard
Wizard Page Action
Policy Select Set up a custom policy, and then type an appropriate
Configuration name for the policy, such as Authenticate
Method BranchOfficeRouters.
Policy If this is a dial-up (non-VPN) connection:
Conditions 1. Click Add.
2. Select Windows-Groups, click Add twice, and then specify
the group name you created earlier (such as
BranchOfficeRouters). Click OK twice to return to the
Policy Conditions page.
3. Click Add, and select NAS-Port-Type. Click Add, and
select the appropriate device type, such as Async
(Modem), ISDN Async V.100, ISDN Async V.120, or ISDN
Sync. Then click Add.
4. Click Add, select Authentication Type, click Add, select
either MS-CHAP v2 or EAP, and then click Add.
5. Select and configure any other attributes for which you want
to specify a setting.
-or-
If this is a VPN connection:
1. Click Add.
2. Select Windows-Groups, click Add twice, and then specify
the group name you created earlier (such as
BranchOfficeRouters). Click OK twice to return to the
Policy Conditions page.
3. Click Add, select NAS-Port-Type, click Add, select Virtual
VPN, and then click Add.
4. Click Add, select Tunnel-Type, click Add, select either
Point-to-Point Tunneling Protocol or Layer 2 Tunneling
Protocol (as appropriate), and then click Add.
5. Click Add, select Authentication-Type, select either
MS-CHAP v2 or EAP, and then click Add.
6. Select and configure any other attributes for which you want
to specify a setting.
Permissions Select Grant remote access permission.
Profile If you want to change the defaults, click Edit Profile, and
then make the desired changes. For example, click Edit
Profile, select the Encryption tab, select Strongest
encryption, and clear any other selections.
Configure a Persistent Connection or a Disconnect Interval

By default, the wizards configure a site-to-site connection to be an on-demand rather than a persistent
connection, and the idle time before disconnecting the on-demand connection is set to Never. You can change
these defaults.
To configure a persistent connection or a disconnect interval
1. On the calling router, open the Routing and Remote Access snap-in.
2. In the console tree, under the desired router, click Network Interfaces. Right-click the
appropriate demand-dial interface in the details pane, and then click Properties.
3. Click the Options tab, and then, under Connection type, do one of the following:
• If you want a connection that disconnects, accept the default Demand dial (on-demand)
option, and then configure the Idle time before hanging up by using the drop-down list to
select, for example, 10 minutes.
• If you want a connection that is always available, select Persistent connection.
4. Specify values for Redial attempts and Average redial interval.
Configure Static Routes

You can configure several types of static routes for a site-to-site connection. You can add static routes manually
or, when requesting routes from the remote router, by using auto-static updates.
Create Static Routes for a Site-to-Site Connection

For a site-to-site connection, you can use Routing and Remote Access to create the following types of static
routes.
• LAN interface. If you do not use routing protocols for the local intranet, you must create one
or more static routes for locations on the local intranet.
• Demand-dial interface for the remote site connection. Although you were
prompted to provide a static route for the network ID of the remote site when you ran the
Demand-Dial Interface Wizard, you might need to recreate this static route in the future.
Alternatively, for a persistent site-to-site connection only, you can enable a routing protocol
instead of using static routes.
• Demand-dial interface for a link to a local ISP. If you created an additional demand-
dial interface for a link to the local ISP, you were prompted to provide a static host route for the
IP address of the answering router’s Internet-connected interface when you ran the Demand-
Dial Interface Wizard. You might need to recreate this static host route in the future.
• Router user account. For a one-way initiated connection in which the answering router is a
standalone router or a member of a native-mode Active Directory domain, you can omit
creating a demand-dial interface on the answering router, but, in this case only, you must create
one or more static routes on the calling router’s user account that identify the network IDs of
the calling router’s site.
• Create static routes on the LAN or demand-dial interfaces.
• Create static routes on the router user account.
Create static routes on the LAN or demand-dial interfaces
For each static route you create, fill out the Static Route dialog box as shown in Table 10.18. For information
about how to add static routes, see “Add a static route” in Help and Support Center for Windows Server 2003.
Table 10.18 Configuring the Static Route Dialog Box for a Site-to-Site Connection
Interface Action
LAN Specify values for the following fields:
interface • Interface. Select Local Area Connection.
(Calling and • Destination. Type the network ID of the local site.
answering
• Network mask. Type the subnet mask of the local site.
routers)
• Gateway. Do not specify a default gateway on the LAN interface.
• Metric. Select a number representing the appropriate metric.
(The check box Use this route to initiate demand-dial
connections is unavailable.)
Demand-dial Specify values for the following fields:
interface for • Interface. Select the demand-dial interface for the connection to
the remote the remote site.
site 1
• Destination. Type the network ID of the remote site.
(Calling (Alternatively, you can use the default route.)
router only)
• Network mask. Type the subnet mask of the remote site.
• Gateway. This field is unavailable.
• Metric. Select a number representing the appropriate metric. To
prevent this static route from causing problems with RIP or OSPF,
give it a higher cost than the cost of the static route configured on
the LAN interface.
Select the following check box:
• Use this route to initiate demand-dial connections.
(continued)
Table 10.18 Configuring the Static Route Dialog Box for a Site-to-Site Connection (continued)
Interface Action
Demand-dial Specify values for the following fields:
interface for • Interface. Select the demand-dial interface for the link to the local
the local ISP ISP.
(if any) 1
• Destination. Type the IP address (static host route) of the
(Calling answering router’s Internet-connected interface.
router only)
• Network mask. 255.255.255.255
• Gateway. This field is unavailable.
• Metric. Select a number representing the appropriate metric. To
prevent this static route from causing problems with RIP or OSPF,
give it a higher cost than the cost of the static route configured on
the LAN interface.
Select the following check box:
• Use this route to initiate demand-dial connections.
1. You might have already created one or more static routes for one or both of these demand-dial
interfaces when you ran the Demand-Dial Interface Wizard.
Create static routes on the router user account

For a one-way connection, you can create a demand-dial interface on the answering router, but this is not
required. If you do not create a demand-dial interface on the answering router, you must create a static route or
routes that identify the network IDs of the calling router’s site on the calling router’s user account.
For information about how to configure static routes on either a local user account or on an Active Directory
user account, see “Configure static routes for a dial-in user” in Help and Support Center for Windows
Server 2003. When performing the steps in that Help topic, you are prompted to provide a value for
Destination. Type a network ID of the calling router’s site.
Configure Auto-static Updates

You can use auto-static updates to request all of the routes of the router on the other side of a site-to-site
connection. Auto-static updates are supported when you use RIP for IP, but not OSPF.
For more information about how to manually configure auto-static updates, see “Perform manual auto-static
updates” in Help and Support Center for Windows Server 2003.
For more information about how to schedule auto-static updates, see “Perform scheduled auto-static updates” in
Help and Support Center for Windows Server 2003.
Configure Routing Protocols

Instead of manually configuring static routes, you can use routing protocols for the following:
• On each LAN interface.
• On each demand-dial interface that is used for a persistent site-to-site connection.
If you use routing protocols, you must configure each new LAN interface or demand-dial interface to use the
protocols, because, typically, each interface is connected to a different subnet.
To configure routing protocols for a persistent site-to-site connection
• For information about how to deploy the IP unicast routing protocols supported by Routing and
Remote Access, see “RIP for IP” and “OSPF” in Help and Support Center for Windows
Server 2003.
Configure Internet Access Through the Calling Router

At a branch office, you can configure the calling router to grant users access to the Internet in addition to
sending traffic to the main site over the site-to-site connection. Choose one of the following scenarios if you
want to configure access to the Internet:
• Access the Internet through the main office — for greater security.
• Access the Internet directly — for faster performance.
For Security, Access the Internet Through the Main Office

To access the Internet through the main office, use the following steps to add a default (0.0.0.0/0.0.0.0) route to
the demand-dial interface used for the dial-up or VPN connection. The default route ensures that all IP packets
that cannot find specific routes on the private branch office network are sent to the Internet-connected interface
of the demand-dial router at the main office. You might use this alternative if you use ISA Server at the main
office.
To use the calling router to access the Internet through the main office
1. On the branch office demand-dial router, open the Routing and Remote Access snap-in.
2. In the console tree, expand the router you want to configure, expand IP Routing, right-click
Static Routes, and then select New Static Route.
3. In the Static Route dialog box, configure the following:
a. In the Interface box, select the demand-dial interface used for the dial-up or VPN
connection to the main office.
b. In the Destination box, type 0.0.0.0
c. In the Network Mask box, type 0.0.0.0
d. In the Metric box, accept the default value (1).
e. Select Use this route to initiate demand-dial connections.
f. Click OK.
For Performance, Access the Internet Directly

To access the Internet directly from the branch office, you have two options, depending on how the branch
office connects to the local ISP:
• The branch office uses a dial-up connection to its local ISP.
• The branch office uses a demand-dial connection to its local ISP.
Option 1: The branch office uses a dial-up connection to its local ISP
This method, which is more common and requires configuring only one static route, assumes that the branch
office uses a dial-up connection to the local ISP in conjunction with the demand-dial connection to the main
office.
To use the calling router to access the Internet directly if the branch office uses a
dial-up connection to its local ISP
b. In the Destination box, type the network ID of the main office network.
c. In the Network Mask box, type the network mask for the main office network ID.
f. Click OK.
Option 2: The branch office uses a demand-dial connection to its local
ISP
This method, which is less common and requires configuring two static routes, assumes that the branch office
uses a demand-dial connection to the local ISP in conjunction with the demand-dial connection to the main
office.
To use the calling router to access the Internet directly if the branch office uses a
demand-dial connection to its local ISP

a. In the Interface box, select the demand-dial interface used for connecting the branch
office to its ISP.
b. In the Destination box, type 0.0.0.0.
c. In the Network Mask box, type 0.0.0.0.
f. Click OK.
4. In the console tree, right-click Static Routes, and then select New Static Route.
b. In the Destination box, type the network ID of the main office network.
c. In the Network Mask box, type the network mask for the main office network ID.
f. Click OK.
Configure IP Multicasting
You can configure your site-to-site connection to support IP multicast applications.
To configure demand-dial routers for IP multicasting
1. For both the calling and the answering router, in the Routing and Remote Access snap-in,
expand IP Routing, right-click General, click New Routing Protocol, and then click IGMP
Router and Proxy.
2. Right-click IGMP, click New Interface, select the interface you want to enable, and then
configure the interface as follows:
a. Select Enable IGMP (the default), and then do the following:
If this is the demand-dial interface, select IGMP proxy.
If this is an intranet interface, select IGMP router.
b. Typically, for IGMP protocol version, you can accept Version 3 (the default).
3. If needed, modify the default IGMP router settings. In most cases, no changes are needed.
For more information about how to modify these settings, if analysis of your network indicates
that you do need to modify them, see “Configure IGMP router settings” in Help and Support
Configure the Authentication Provider

After the Routing and Remote Access and Demand-Dial Interface wizards complete, Windows authentication
and Windows accounting are selected by default. You can change these defaults from Windows authentication
and Windows accounting to RADIUS authentication and RADIUS accounting, or you can choose separate
providers for authentication and accounting. For a deployment that supports only a site-to-site connection, use
Windows authentication and Windows accounting. However, you can change these defaults if the same
answering router will support both the site-to-site connection and remote access users, and you want to use
RADIUS as either the authentication provider or the accounting provider.
• Configure the authentication provider on the answering router.
• Configure the accounting provider on the answering router.
To configure the authentication provider on the answering router
1. Configure either Windows authentication or RADIUS authentication.
For information about how to configure Windows or RADIUS authentication, see “Use
Windows authentication” or “Use RADIUS authentication” in Help and Support Center for
Windows Server 2003.
2. If you select RADIUS authentication, add the answering router as a RADIUS client on the IAS
server.
For information about how to add the answering router as a RADIUS client, see “Configure
RADIUS clients” in Help and Support Center for Windows Server 2003.
To configure the accounting provider on the answering router
1. Select either Windows accounting or RADIUS accounting.
For information about how to select the accounting method you want to use, see “Use Windows
accounting” or “Use RADIUS accounting” in Help and Support Center for Windows
Server 2003.
2. If you select RADIUS accounting, add the answering router as a RADIUS client on the IAS
server.
For information about how to add the answering router as a RADIUS client, see “Configure
RADIUS clients” in Help and Support Center for Windows Server 2003.
Configure Authentication Methods

By default, the answering router is configured to accept EAP-TLS, MS-CHAP v2, and MS-CHAP as the
authentication methods. To increase security, use either EAP-TLS alone or EAP-TLS along with MS-CHAP v2.
Alternatively, you can use MS-CHAP v2 with passwords for user authentication.
To configure the authentication method on the answering router

1. On the answering router, specify which authentication method or methods to accept.
By default, the answering router is configured to accept EAP-TLS, MS-CHAP v2, and
MS-CHAP.
• To increase security, clear the MS-CHAP selection, and, if you plan to use EAP-TLS only,
also clear the MS-CHAP v2 selection.
-or-
• To use MS-CHAP v2 with passwords for user authentication, clear the EAP-TLS selection.
For information about how to add or clear authentication methods, see “Enable authentication
protocols” in Help and Support Center for Windows Server 2003.
2. If you select EAP-TLS authentication, be sure to perform the steps in “Install Computer and
User Certificates for EAP-TLS” earlier in this chapter.
Configure Ports
If needed, you can change the default values for Ports in Routing and Remote Access.
To configure ports
• Fill out the Configure Device dialog box as shown in Table 10.19. For information about how
to configure ports for your site-to-site connection, see “Enable routing on ports” in Help and
Table 10.19 Using the Configure Device Dialog Box to Configure Ports
Option Action
Remote access Select this option if you want to allow connections
connections (inbound from individual remote access users in addition to
only) connections from a remote router.
Demand-dial routing Select this option if you want to enable a site-to-site
connections (inbound demand-dial connection. This is the default.
and outbound)
Demand-dial routing This option is available only for a PPPoE
connections connection to the Internet. Select this option if you
(outbound only) want this router to function only as a calling router.
(continued)
Table 10.19 Using the Configure Device Dialog Box to Configure Ports
(continued)
Option Action
Phone number for this If you configure a value for Called-Station-ID in the
device remote access policy associated with this
connection, you must manually type a value for this
field:
• If this is a dial-up connection, type the phone
number that was entered in the Called-Station-ID
remote access policy attribute.
• If this is a VPN connection, type the IP address of
the VPN server’s Internet-connected interface
(entered in the Called-Station-ID remote access
policy attribute).
Maximum ports For PPTP or L2TP/IPSec VPN routers only, change
the default number of ports. For optimal scalability,
use 10 or fewer ports.
Configure Dial-out or Dial-in Hours

For on-demand connections, you can specify time limits for dial-out or dial-in hours.
To configure dial-out hours on a calling router
• Configure dial-out routers on the calling router to prevent connections at unwanted times.
For information about how to use Routing and Remote Access to configure dial-out hours on
the demand-dial interface of a calling router to block outgoing connections at specific times of
the day or week (such as at night or on weekends), see “Configure dial-out hours” in Help and
To configure dial-in hours on an answering router
• Configure dial-in hours on the answering router to specify when the calling router can access
the answering router.
For information about how to use remote access policies to configure dial-in hours on an
answering router to block incoming connections at specific times of the day or week (such as at
night or on weekends), see “Configure dial-in constraints” in Help and Support Center for
Windows Server 2003.
Configure IP Packet Filters and Demand-Dial Filters

For an on-demand VPN connection, you can specify IP packet filters and demand-dial filters.
• Configure IP packet filters on the Internet interface
• Match IP demand-dial filters to IP packet filters on the demand-dial interface
Configure IP Packet Filters on the Internet Interface

You can configure PPTP or L2TP/IPSec input and output filters on the Internet-connected interface of a VPN
router to allow only PPTP or only L2TP/IPSec traffic to travel between the two sites.
How you configure firewall filters and filters on the VPN router depends on the relative position of the VPN
router and firewall. For information about configuring filters for a VPN site-to-site server, see “Deploying
Dial-up and VPN Remote Access Servers” in this book, and see “VPN servers and firewall configuration,” “Add
PPTP filters,” and “Add L2TP over IPSec filters” in Help and Support Center for Windows Server 2003.
Configure IP Demand-Dial Filters and Match Them to IP Packet Filters

on the Demand-Dial Interface
You can configure demand-dial filters to specify which types of traffic are allowed to create a site-to-site
connection. By matching demand-dial filters to the IP packet filters, you can also prevent a calling router from
establishing a demand-dial connection for traffic that IP packet filters are configured to discard.
For information about how to configure demand-dial filters and to match them to IP packet filters, see
“Configure demand-dial filters” and “Demand-dial routing design considerations” in Help and Support Center
for Windows Server 2003.
Initiate the Connection

First, ensure that both routers are enabled for dial-up access, and then initiate the connection.
To confirm that a router has permission to initiate an on-demand connection
1. Open Active Directory Users and Computers, and then on the Dial-in tab of the user account of
the router’s Properties page, confirm that either Allow access or Control access through Remote
Access Policy is selected.
2. If Control access through Remote Access Policy is selected, open the Routing and Remote
Access snap-in and confirm that the remote access permission setting on the Properties page of
the associated Remote Access Policy is set to Grant remote access permission.
To initiate the on-demand connection on the calling router

• On the calling router, in the Routing and Remote Access snap-in, click Network Interfaces,
right-click the demand-dial interface for which you want to initiate a connection, and then click
Connect.
If the calling router uses a dial-up connection to the local ISP, the local ISP assigns the router a temporary IP
address. You can confirm that this IP address exists by typing ipconfig at a command prompt.
Test Connectivity
Use the following procedures to test the remote site connection:
• Test network connectivity. To test network connectivity, ping a client computer at the main
office from a client computer in the branch office.
• Test application connectivity. To test application connectivity, map a network drive to a client
computer at the main office from a client computer in the branch office. For example, map a
drive to \\ClientComputerName\c$.
• Force replication between domain controllers in both sites. If you have a domain controller
in both sites, use the following procedure to test replication:
1. Open Active Directory Users and Computers, and create a new user account called, for
example, TestReplication.
2. Use the Active Directory Replicate Now option to test that replication takes place over
the site-to-site connection.
For information about how to force replication between the two sites, see “Force
replication over a connection” in Help and Support Center for Windows Server 2003.
3. Confirm that the new user account exists on domain controllers located in both sites.
Configure Replication
If you installed an Active Directory domain controller in the branch office, you must ensure that replication
takes place continually. How you do this depends on whether this is a persistent connection or an on-demand
connection.
• Configure a replication interval for a persistent connection
• Configure reciprocal replication for a one-way initiated on-demand connection
Configure a Replication Interval for a Persistent Connection

If this is a persistent connection, you can schedule replication to occur after a specified interval.
Use the Active Directory Sites and Services snap-in to configure a replication interval. For information about
how to specify a replication interval, see “Configure site link replication frequency” in Help and Support Center
for Windows Server 2003.
Configure Reciprocal Replication for a One-Way Initiated On-Demand

Connection
If this is a one-way initiated on-demand connection, you must configure reciprocal replication using the Active
Directory Service Interfaces (ADSI) Edit tool.
Install ADSI Edit, a Windows Support tool, on a domain controller in the main office or in the branch office. For
information about how to install Windows Support Tools, which include ADSI Edit, in Help and Support Center
for Windows Server 2003, click Tools, and then click Windows Support Tools.
Caution
If you use the ADSI Edit snap-in and incorrectly modify the attributes of
Active Directory objects, you can cause serious problems that might
require you to reinstall Windows Server 2003. Microsoft cannot
guarantee that problems resulting from the incorrect modification of
Active Directory object attributes can be solved. Modify these attributes
at your own risk.
To enable reciprocal replication on a site link for a one-way initiated on-demand

connection
1. On a domain controller, type adsiedit.msc in the Run dialog box to open the ADSI Edit snap-in.
2. Expand the Configuration container, expand the Sites container, expand the Inter-Site
Transports container, and then click CN=IP.
3. In the details pane, right-click the site link object for the sites for which you want to enable
reciprocal replication, and then click Properties.
4. In the Attributes box, double-click Options.
5. In the Integer Attribute Editor dialog box, take one of the following actions:
a. If the Value box displays <not set>, type 2.
b. If a value is displayed, convert the integer value to a binary value and use the binary OR
operation to combine that value with the binary value 0010, and then type the integer value
of the result in the Value box.
For a job aid that includes a table of examples showing how to perform this operation, see
“Example: Contoso Connects Remote Sites” (DNSREM_1.doc) on the Windows
Server 2003 Deployment Kit companion CD (or see “Example: Contoso Connects Remote
Sites” on the Web at http://www.microsoft.com/reskit).
Alternatively, you can enable reciprocal replication on a connection, instead of on a site link.
To confirm reciprocal replication over a one-way initiated on-demand connection

1. On the branch office domain controller, create a user account called TestReplication.
2. On the calling router in the branch office, establish a connection to the answering router in the
main office.
3. Wait 15 to 20 minutes, and then open Active Directory Users and Computers on a domain
controller in the main office. If your connection is working correctly, the TestReplication user
account will be listed.
4. To confirm that replication did in fact take place over the one-way initiated site-to-site
connection, perform the following steps:
a. On both the calling router and the answering router, type ipconfig at a command prompt.
If, when you ran the Routing and Remote Access wizard, you chose the recommended
option to configure IP address assignment from a specified range of addresses, the output
of both ipconfig commands will include IP addresses from the specified address ranges.
b. On the branch office domain controller, type tracert at a command prompt. If, when you
ran the Routing and Remote Access wizard, you configured IP address assignment from a
specified range of addresses, the output of the tracert command will include an IP address
from the specified range that the answering router assigns to the calling router.
Additional Resources
These resources contain additional information related to this chapter.
Related Information
• “Planning for Deployment” in Planning, Testing, and Piloting Deployment Projects of this kit
for more information about creating hardware and software inventories and mapping your
existing network before deploying new features.
• “Deploying DNS” and “Deploying WINS” in this book for more information about name
resolution.
• “Deploying DHCP” in this book for more information about IP address assignment.
• “Deploying Dial-up and VPN Remote Access Servers” and “Deploying Remote Access Clients
Using Connection Manager” in this book for more information about using the Routing and
Remote Access service to connect individual computers (such as computers of users working
from home or mobile users) to a central office.
• “Deploying IAS” in this book for more information about deploying IAS.
• “Designing the Site Topology” in Designing and Deploying Directory and Security Services of
this kit for more information about Active Directory replication between sites.
• “Designing a Public Key Infrastructure” in Designing and Deploying Directory and Security
Services of this kit for more information about creating a certificate infrastructure.
• The Internetworking Guide of the Windows Server 2003 Resource Kit (or see the
Internetworking Guide on the Web at http://www.microsoft.com/reskit) for more information
about Routing and Remote Access, demand-dial routing, virtual private networking, unicast IP
routing, and Network Address Translation (NAT).
• The Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide
on the Web at http://www.microsoft.com/reskit) for more information about Internet
Authentication Service (IAS).
• The Virtual Private Networks link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources for more information about virtual
private networking.
• The Windows Catalog link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources for more information about hardware
compatibility.
• The Active Directory Branch Office Planning Guide link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources for more information about planning
and deploying Active Directory for multiple branch office sites.
Related Help Topics
For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set
search options. Under Help Topics, select the Search in title only checkbox.
• “Setting up demand-dial routing” and “Deploying router-to-router VPNs” in Help and Support
Center for Windows Server 2003 for more information about deploying site-to-site connections.
• “Routing scenarios” and “Virtual private network implementation examples” in Help and
Support Center for Windows Server 2003 for more examples of test lab deployments for site-to-
site connections.
Related Job Aids
• “Example: Contoso Connects Remote Sites” (DNSREM_1.doc) on the Windows Server 2003
Deployment Kit companion CD (or see “Example: Contoso Connects Remote Sites” on the Web
at http://www.microsoft.com/reskit).
• “Site-to-Site Connection Deployment Steps” (DNSREM_2.doc) on the Windows Server 2003
Deployment Kit companion CD (or see “Site-to-Site Connection Deployment Steps” on the
Web at http://www.microsoft.com/reskit).

Connecting Remote Sites

Uploaded by

Copyright:

Available Formats

You might also like

Connecting Remote Sites

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Connecting Remote Sites

Uploaded by

Copyright:

Available Formats

C H A P T E R 1 0

Overview of Remote Site

Remote Site Connectivity Process

Remote Site Connectivity Background

PPTP VPN Solution

L2TP/IPSec VPN Solution

Choosing the Remote Site

Choosing a Dial-up or VPN Connection

Choosing PPTP or L2TP/IPSec

Table 10.1 Comparing a PPTP Solution with an L2TP/IPSec Solution (continued)

Using Both a PPTP Connection and an L2TP/IPSec Connection

Choosing a One-Way or Two-Way

Choosing Security Features

Integrate the VPN Server into a

VPN Router Placement in Relation to Firewall

Match IP Packet Filters to Demand-Dial Filters

Choosing the Authentication Provider

Choosing an Authentication Method

Choosing EAP-TLS or MS-CHAP v2 for User-Level

Advantages of EAP-TLS and MS-CHAP v2

Choosing Computer Certificates or Preshared Keys for

Choosing MPPE or IPSec Encryption

Choosing Router User Accounts and Groups

Configuring Router User Accounts

Configure the Router User Account Name to Match the Demand-Dial

Configure the Authentication Provider for the Router

Choose an Active Directory User Account or a Local User Account

Choose Dial-in Options for the Router User Account

Ensure That the Calling Router Can Establish a Connection

Configuring Router Groups

Choosing a Remote Access Policy Type

Integrating the Remote Site

Designing the Routing Infrastructure

Adding Static Routes

Static Routes for a Site-to-Site Connection

Using On-Subnet or Off-Subnet Address Ranges

On-subnet address range

Using Routing Protocols

Servicing Internet Traffic

For performance, route branch office Internet traffic directly to the

Enabling Multicast Connectivity Between Sites

Planning IP Address Assignment and

Client IP Address Assignment

IP Address Assignment for the Logical Interface

Using IP Addresses to Avoid Name Resolution Issues

Using Name Resolution When Accessing Other Services on a

Planning Active Directory Integration

Putting a Domain Controller at the Branch Office

Using One Domain to Include Geographically Remote Sites

Using Scheduled Replication or Reciprocal Replication

Joining Demand-Dial Routers to the Active Directory Domain

Preparing for Server Configuration

Migrating Routers from Windows NT 4.0 or

Migrating Router Settings

Planning Server Capacity

Planning Server Deployment

Meeting Server Requirements

Disabling Unused Services