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 TCarrier 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-tosite 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.

222

Chapter 10

Connecting Remote Sites

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 highsecurity 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

Additional Resources

223

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

224

Chapter 10

Connecting Remote Sites

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

Additional Resources

225

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

226

Chapter 10

Connecting Remote Sites

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.

Additional Resources

227

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.

228

Chapter 10

Connecting Remote Sites

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 version

PPTP is supported by Windows Server 2003, as well as the Microsoft® Windows® 2000 Server operating system, and the Microsoft® Windows NT® version 4.0 operating system with the Routing and Remote Access Service (RRAS). Most third-party VPN routers also support PPTP.

L2TP/IPSec is supported by Windows Server 2003 and Windows 2000 Server (with the Routing and Remote Access service). Most thirdparty VPN routers also support L2TP/IPSec.

User authentication

EAP-TLS or MS-CHAP v2 is recommended.

EAP-TLS or MS-CHAP v2 is recommended.

Certificates

PPTP requires certificates only when using EAP-TLS for user authentication, in which case a user certificate for the calling router and a computer certificate for the authenticating server of the answering router are required.

•

•

Using EAP-TLS user authentication with L2TP/IPSec requires a user certificate for the calling router and a computer certificate for the authenticating server of the 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)

Additional Resources

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 connection, choosing either EAP-TLS or MS-CHAP v2 for user authentication provides MPPE for data encryption. MPPE provides data confidentiality (encryption); that is, captured packets cannot be interpreted without the encryption key.

L2TP/IPSec generates its encryption keys by using IPSec. IPSec provides data confidentiality (encryption), replay protection, data integrity, and data origin authentication.

NATs

In most cases, you can locate PPTP-based calling routers behind a network address translator (NAT), so you can configure a small or home office (SOHO) network to share a single connection to the Internet. Most NATs include a NAT editor that can accurately translate PPTP-tunneled data.

With Windows Server 2003– based calling or answering routers, you can use IPSec NAT traversal (NAT-T) to create L2TP/IPSec connections across NATs. Using NAT-T requires running Windows Server 2003 on both the calling and answering routers. With NAT-T, hosts that are hidden behind a NAT can use IPSec to connect to a remote site.

Ease of deployment

When using MS-CHAP v2 (or • MS-CHAP) for user authentication, PPTP is costeffective and easier to deploy than L2TP/IPSec with computer certificates.

•

When you use computer certificates as the authentication method, L2TP/IPSec requires a certificate infrastructure 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 longterm 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.

229

230

Chapter 10

Connecting Remote Sites

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 Type PPTP

Typical Uses • • •

L2TP/IPSec

• •

• •

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. 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.

Additional Resources

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 connection

Establishes a connection when traffic is forwarded, and it terminates the connection when the link is not used for a specified period of time.

Use an on-demand connection if using the communications link incurs per-minute charges. For an on-demand VPN connection, the initiating router can use either a permanent or a dial-up link to the Internet. The 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 connection

Sustains a connection for 24 hours a day.

Use a persistent connection in 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 timesensitive. 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.

231

232

Chapter 10

Connecting Remote Sites

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.

Additional Resources

233

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 connection

A one-way initiated connection is one in which one site contains only an answering router and the other site contains only a calling router.

Use an on-demand or persistent one-way initiated connection when users at a branch office need to connect to a headquarters office but not vice versa. 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 twoway initiated connection for 10 or more connections, performance is too slow.

Two-way initiated connection

A two-way initiated connection is one in which a router at each site can function as both the answering router and as the calling router.

Use a two-way initiated connection when users at both locations need to access resources or people in the other location and you have 10 or fewer connections (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.

234

Chapter 10

Connecting Remote Sites

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

Additional Resources

235

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.

236

Chapter 10

Connecting Remote Sites

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.

Additional Resources

237

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.

238

Chapter 10

Connecting Remote Sites

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 userlevel 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.

Additional Resources

239

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 (Answering Router or RADIUS Server)

Certificates Installed on Calling Router

•

•

• •

•

•

•

Computer certificates must be installed in the Local Computer certificate store. Computer certificates must have a corresponding private key. The cryptographic service provider for the certificates must support secure channel (Schannel). (If not, the authenticating server cannot use the certificate and the certificate cannot be selected from the properties of the Smart Card or Other Certificate EAP type on the Authentication tab in the properties of a profile for a remote access policy.) Computer certificates must contain 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.

• • •

•

User certificates must have a corresponding private key. User certificates must contain the Client Authentication EKU (the 1.3.6.1.5.5.7.3.2 object identifier). User certificates must be installed in the Current User certificate store. User certificates must contain the universal principal name (UPN) of the user account in the Subject Alternative Name property. The root CA certificates of the CAs that issued the authenticating server computer certificates must be installed in the Trusted Root Certification Authorities 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.

240

Chapter 10

Connecting Remote Sites

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.

Additional Resources

241

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 Connection Type

Recommended User Authentication Protoco l

Encryption Method

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

242

Chapter 10

Connecting Remote Sites

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)

Additional Resources

243

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.

244

Chapter 10

Connecting Remote Sites

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 demanddial 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 TwoWay Initiated VPN Connection Router

Demand-Dial Interface

User Account for Calling Router

Router located in Seattle (Functions as both a calling and an answering router)

Interface Name: VPN_NewYork Destination IP Address: 131.107.0.1 Credentials: VPN_Seattle Password: PasswordOne

VPN_NewYork PasswordTwo

Router located in New York (Functions as both a calling and an answering router)

Interface Name: VPN_Seattle Destination IP Address: 157.54.0.1 Credentials: VPN_NewYork Password: PasswordTwo

VPN_Seattle PasswordOne

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.

Additional Resources

245

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 Router

Demand-Dial Interface

Calling Router User Accounts

Answering router in Seattle

No demand-dial interface needed. If you do not configure a demanddial interface on the answering router, you must configure static routes specifying the network IDs of the calling router’s site on the Dial-in tab of the calling router’s user account.

DD_Olympia PasswordOne -andDD_Portland PasswordTwo

Calling router in Olympia

Interface Name: DD_Seattle Modem or adapter: Modem on COM1 Phone number: 555-0111 Credentials: DD_Olympia / PasswordOne

No user accounts needed, because the Seattle router does not call the routers in Olympia or Portland.

Calling router in Portland

Interface Name: DD_Seattle Modem or adapter: Modem on COM2 Phone number: 555-0111 Credentials: DD_Portland / PasswordTwo

No user accounts needed, because the Seattle router does not call the routers in Olympia or Portland.

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-tosite 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 mixedmode Active Directory domains and Windows NT 4.0 domains.

246

Chapter 10

Connecting Remote Sites

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 Support Center for Windows Server 2003.

Additional Resources

247

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.

248

Chapter 10

Connecting Remote Sites

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 lowcost 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.

Additional Resources

249

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.

250

Chapter 10

Connecting Remote Sites

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 Support Center for Windows Server 2003. 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.

Additional Resources

251

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

252

Chapter 10

Connecting Remote Sites

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.

Additional Resources

253

•

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 Internetconnected 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.

254

Chapter 10

Connecting Remote Sites

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 dialup 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.

Additional Resources

255

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.

256

Chapter 10

Connecting Remote Sites

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 siteto-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).

Additional Resources

257

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.

258

Chapter 10

Connecting Remote Sites

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.

Additional Resources

259

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.

260

Chapter 10

Connecting Remote Sites

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.

Additional Resources

261

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.

262

Chapter 10

Connecting Remote Sites

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.

Additional Resources

263

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

264

Chapter 10

Connecting Remote Sites

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 Release Windows 2000 Server

New Features • • • •

Windows Server 2003

• •

•

•

• •

L2TP/IPSec. An L2TP/IPSec VPN tunnel provides stronger 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. Improved wizards and snap-in. The Routing and Remote 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 Internetconnected 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.

Additional Resources

265

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 connections

For two-way connections, one answering router supports 10 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 throughput

The amount of data throughput that a site-to-site connection 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, rightclick 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-tosite connections and for remote access connections.

266

Chapter 10

Connecting Remote Sites

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 adapter

• •

Software

For a dial-up site-to-site connection: An ISDN adapter, analog 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.

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.

Additional Resources

267

The following is a list of services that you might be able to disable on a server that you plan to use as a demanddial 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.

268

Chapter 10

Connecting Remote Sites

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.

Additional Resources

269

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.

270

Chapter 10

Connecting Remote Sites

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.

Additional Resources

271

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.

272

Chapter 10

Connecting Remote Sites

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 Center for Windows Server 2003.

Additional Resources

273

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.

274

Chapter 10

Connecting Remote Sites

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).

Additional Resources

275

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 Internetconnected 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.

276

Chapter 10

Connecting Remote Sites

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.

Additional Resources

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.

277

278

Chapter 10

Connecting Remote Sites

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.

Additional Resources

Table 10.13 Enabling the Routing and Remote Access Service Wizard Page

Action

Configuration Select Secure connection between two private networks. Demand-Dial Connections

Select Yes (to use demand-dial routing to access remote networks).

IP Address Assignment

Choose one of the following alternative options: Select Automatically to use DHCP if you want to assign addresses automatically without using a specified range of addresses. -orSelect 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.

279

280

Chapter 10

Connecting Remote Sites

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 Name

Type a name for the remote router that matches the user account name that you created earlier for the remote router.

Connection Type

Choose one of the following alternative options: 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.) -orConnect 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)

Additional Resources

Table 10.14 Configuring the Demand-Dial Interface for a Remote Site Connection (continued) Wizard Page Protocols and Security

Action

3. Select Route IP packets on this interface (the default). 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 Credentials (for an answering router)

Type and confirm a password for the local user account. Note. This page appears only if this is an answering router and if you chose Add a user account so a remote router can dial in on the Protocols and Security page earlier in the 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 Credentials (for a calling router)

Specify the dial-out credentials that this interface will use to connect to the remote router: 1. User name — Type the name of the user account for the 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.

281

282

Chapter 10

Connecting Remote Sites

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 demanddial interface you want to create.

•

To establish a temporary link to the local ISP at the branch office in order to create a demanddial 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 DemandDial 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.

Additional Resources

Table 10.15 Configuring an Additional Demand-Dial Interface for a Temporary Link to the ISP Wizard Page

Action

Interface Name

Type an appropriate name, such as Dial_ISP.

Connection Type

Choose one of the following alternative options: 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. -orSelect 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 and Security

Select Route IP packets on this interface (do not select Add a user account so a remote router can dial in).

Static Routes for Remote Networks

To add a static host route for the IP address allocated to the answering router by the answering router’s ISP (or by 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 Credentials

This page does not appear.

Dial-Out Credentials

Specify the dial-out credentials that this interface will use to 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.

283

284

Chapter 10

Connecting Remote Sites

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.)

Additional Resources

285

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 Configuration Method

Select Use the wizard to set up a typical policy for a common scenario, and then type an appropriate name for the policy, such as Authenticate BranchOfficeRouters.

Access Method

Select VPN or Dial-up, as appropriate.

User or Group Access

Click Group, click Add, and then type the group name you created earlier, such as BranchOfficeRouters.

Authentication Methods

Either accept the default method, MS-CHAP v2, or choose Extensible Authentication Protocol (EAP) and specify its type (either MD5-Challenge or Smart card or other certificate).

Policy Encryption Level

Select Strongest encryption, and clear any other selections.

286

Chapter 10

Connecting Remote Sites

Table 10.17 Creating a Custom Remote Access Policy by Using the New Remote Access Policy Wizard Wizard Page

Action

Policy Configuration Method

Select Set up a custom policy, and then type an appropriate name for the policy, such as Authenticate BranchOfficeRouters.

Policy Conditions

If this is a dial-up (non-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, 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. -orIf 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.

Additional Resources

287

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 demanddial 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 DemandDial Interface Wizard. You might need to recreate this static host route in the future.

288

Chapter 10

•

Connecting Remote Sites

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.

Use the following procedures to accomplish these tasks: •

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 interface (Calling and answering routers)

Specify values for the following fields: • Interface. Select Local Area Connection. • Destination. Type the network ID of the local site. • Network mask. Type the subnet mask of the local site. • 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 interface for the remote site 1 (Calling router only)

Specify values for the following fields: • Interface. Select the demand-dial interface for the connection to the remote site. • Destination. Type the network ID of the remote site. (Alternatively, you can use the default route.) • 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)

Additional Resources

289

Table 10.18 Configuring the Static Route Dialog Box for a Site-to-Site Connection (continued) Interface

Action

Demand-dial interface for the local ISP (if any) 1 (Calling router only)

Specify values for the following fields: • Interface. Select the demand-dial interface for the link to the local ISP. • Destination. Type the IP address (static host route) of the answering router’s Internet-connected interface. • 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.

290

Chapter 10

Connecting Remote Sites

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.

Additional Resources

291

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 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 the network ID of the main office network.

c.

In the Network Mask box, type the network mask for the main office network ID.

d.

In the Metric box, accept the default value (1).

e.

Select Use this route to initiate demand-dial connections.

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 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.

292

Chapter 10

Connecting Remote Sites

3. In the Static Route dialog box, configure the following: 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.

d.

In the Metric box, accept the default value (1).

e.

Select Use this route to initiate demand-dial connections.

f.

Click OK.

4. In the console tree, right-click Static Routes, and then select New Static Route. 5. 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 the network ID of the main office network.

c.

In the Network Mask box, type the network mask for the main office network ID.

d.

In the Metric box, accept the default value (1).

e.

Select Use this route to initiate demand-dial connections.

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 Center for Windows Server 2003.

Additional Resources

293

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. Use the following procedures to accomplish these tasks: •

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.

294

Chapter 10

Connecting Remote Sites

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 Support Center for Windows Server 2003. Table 10.19 Using the Configure Device Dialog Box to Configure Ports Option

Action

Remote access connections (inbound only)

Select this option if you want to allow connections from individual remote access users in addition to connections from a remote router.

Demand-dial routing connections (inbound and outbound)

Select this option if you want to enable a site-to-site demand-dial connection. This is the default.

Demand-dial routing connections (outbound only)

This option is available only for a PPPoE connection to the Internet. Select this option if you want this router to function only as a calling router.

(continued)

Additional Resources

295

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 Support Center for Windows Server 2003.

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.

296

Chapter 10

Connecting Remote Sites

Configure IP Packet Filters and Demand-Dial Filters For an on-demand VPN connection, you can specify IP packet filters and demand-dial filters. Use the following procedures to accomplish these tasks: •

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.

Additional Resources

297

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. Use the following procedures to accomplish these tasks: •

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.

298

Chapter 10

Connecting Remote Sites

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.

Additional Resources

299

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.

300

Chapter 10

Connecting Remote Sites

•

“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-tosite 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).