Microsoft Corporation Microsoft Windows Server 2003 Deployment Kit(c) Deploying Network Services 2003

After you make all the necessary design decisions, you can deploy a remote site connection for your organization. The flowchart in Figure 10.9 shows the tasks that can help you to successfully deploy a site-to-site connection.

Figure 10.9: Deploying a Site-to-Site Connection

If you want to try a test deployment to prepare for your production deployment, see "Perform a Test Deployment in Your Lab" later in this chapter. If you are ready to connect two sites in your production environment now, see "Deploy a Remote Site Connection" later in this chapter.

Perform a Test Deployment in Your Lab

By reading the design sections earlier in this chapter, you can develop a good idea about which remote site connectivity features are appropriate for your organization. However, before you deploy any technology in your production network, it is a good practice to perform a test deployment in a lab first. Testing in a lab familiarizes you with how the technology works and gives you the opportunity to experiment with different features when alternatives are available.

When testing how to deploy a remote site connection, evaluate the following key issues in a lab setting before deciding how to deploy the technology in your production environment:

For a tool to assist you in evaluating some of the remote connectivity features presented in this list, see "Example: Contoso Connects Remote Sites" (DNSREM_1.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Example: Contoso Connects Remote Sites" on the Web at http://www.microsoft.com/reskit). This job aid shows you how to deploy a PPTP VPN and a dial-up connection in a lab environment.

For additional test lab deployment examples, including information about deployments that include certificates and L2TP/VPN connections, see "Routing scenarios" and "Virtual private network implementation examples" in Help and Support Center for Windows Server 2003.

Deploy a Remote Site Connection

To connect remote sites using a site-to-site link, you must decide which of the design options described earlier in this chapter you want to deploy. Use the "Choose Optional Tasks You Need" column in Figure 10.10 to mark which optional tasks you will perform for your deployment.

Figure 10.10: Deployment Tasks for a Site-to-Site Connection Worksheet

For a copy of Figure 10.10 that you can use to record which deployment options you need for your site-to-site deployment, see "Site-to-Site Connection Deployment Steps" (DNSREM_2.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Site-to-Site Connection Deployment Steps" at http://www.microsoft.com/reskit). You can also use this worksheet as a guide for the sequence in which you must perform the tasks.

Deploy Active Directory

How you manage Active Directory and domain controllers in a branch office varies depending on the size, complexity, and structure of your overall network. If you do not plan to deploy a domain controller in the branch office location, Microsoft recommends that you establish a persistent connection between the two sites. If you do plan to locate a domain controller in the remote site with which you want to establish a site-to-site connection, you must place it in a subnet separate from the computers at the main site and create a separate Active Directory site for the branch office subnet.

The domain controllers in the main and branch offices cannot replicate yet, because the demand-dial connection does not exist yet. For information about how to configure replication after a connection exists, see "Configure Replication" later in this chapter.

Deploy a Certificate Infrastructure

If you plan to use EAP-TLS as your authentication protocol for user-level authentication on a dial-up, PPTP VPN, or L2TP/IPSec VPN connection, or if you plan to use L2TP/IPSec with computer certificates for your VPN connection, or if you plan to do both, you must have a certificate infrastructure in place in your network.

For information about creating a certificate infrastructure, see "Certificate Services" in Help and Support Center for Windows Server 2003, and see "Designing a Public Key Infrastructure" in Designing and Deploying Directory and Security Services of this kit.

Deploy an IAS Server for RADIUS Authentication

For a site-to-site only connection, you use Windows authentication and do not need to deploy an IAS server. However, if you use the same answering router for both a site-to-site connection and a remote access connection that supports mobile or home users, you might decide to use RADIUS authentication instead. If you plan to use RADIUS authentication and Windows Server 2003 IAS, you must have an IAS server available in your network. Deploying an IAS server is the same for both dial-up and VPN site-to-site connections.

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.

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

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

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.

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.

Configure the Intranet Connection

Configure the intranet interface on the demand-dial router at each site.

Do not configure the intranet interface of the router to be a DHCP client. However, an answering router can still use DHCP to obtain IP addresses for calling routers, and vice versa.

Join the Router to the Domain

After you install the Windows Server 2003 operating system on the computers that you want to use as the calling and answering routers, you can join the routers to the Active Directory domain.

If you have a calling router that is located in the branch office, and you already have a domain controller in the branch office, join the router computer to the domain there.

If you do not have a domain controller at the branch office yet, you can install the Windows Server 2003 operating system on the computer that you want to use as the calling router while that computer is located in the main office, join the computer to the domain, and then ship it to the branch office.

Note

Alternatively, you can set up the routers to dial in once, install Active Directory on the computer in the branch office that you want to use as the domain controller, replicate, and then join the routers to the domain.

Place the Router in Your Perimeter Network

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

Install Computer Certificates for L2TP/IPSec

If you use an L2TP/IPSec site-to-site connection, you must install a computer certificate on both the answering router and on the calling router. You must have a certification authority (CA) in your network to issue these certificates.

You can install a computer certificate for L2TP/IPSec by using one of three methods:

Note

It is also possible to use a preshared key to provide authentication for IPSec security associations for an L2TP/IPSec connection. However, using computer certificates is the recommended method.

For information about how to create a certificate infrastructure and install computer certificates, see "Certificate Services" in Help and Support Center for Windows Server 2003, and see "Designing a Public Key Infrastructure" in Designing and Deploying Directory and Security Services of this kit. For more information about configuring a preshared key, see "Configure a pre-shared key for a demand-dial routing interface" in Help and Support Center for Windows Server 2003.

Install Computer and User Certificates for EAP-TLS

When you use EAP-TLS as the user authentication method for your site-to-site connection, you must install a computer certificate on the authentication server of the answering router and a user certificate on the calling router. These steps are the same for a dial-up router and for a VPN router.

For information about how to deploy certificates required by EAP-TLS see "Deploying certificate-based authentication for demand-dial routing" in Help and Support Center for Windows Server 2003.

Configure the Routing and Remote Access Service and Demand-Dial Interfaces

Use the following procedures to enable the Routing and Remote Access service and to establish a site-to-site connection:

Enable Routing and Remote Access

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.

When the Routing and Remote Access Wizard completes, you might see the message "Windows was unable to add this computer to the list of valid remote access servers in the Active Directory. Before you can use this computer as a remote access server, the domain administrator must complete this task." If you see this message, click OK. Later, after you complete the Demand-Dial Interface Wizard (described next), you will add the computer account to the RAS and IAS Servers security group.

Configure the Demand-Dial Interface for the Remote Site Connection

The Demand-Dial Interface Wizard appears automatically after the Routing and Remote Access Wizard completes.

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:

Configure an Additional Demand-Dial Interface for a Temporary ISP Link

If this is a VPN connection, and you connect your branch office to its local ISP through a temporary link, you must run the Demand-Dial Interface Wizard a second time to create a demand-dial interface for this physical link to the ISP. This link to the ISP can be a dial-up link or a PPPoE link.

Note

If you are deploying a non-VPN dial-up link, or a VPN connection between two sites, each of which connects to its local ISP through a dedicated link, do not perform these steps. Instead, perform the steps in "Configure the Routing and Remote Access Service and Demand-Dial Interfaces" earlier in this chapter.

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.

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.

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.

Use the following procedures to accomplish these tasks:

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.

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.

Configure Routing Protocols

Instead of manually configuring static routes, you can use routing protocols for the following:

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.

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:

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.

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:

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.

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.

Configure IP Multicasting

You can configure your site-to-site connection to support IP multicast applications.

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

Configure Ports

If needed, you can change the default values for Ports in Routing and Remote Access.

Configure Dial-out or Dial-in Hours

For on-demand connections, you can specify time limits for dial-out or dial-in hours.

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

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.

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:

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

If this is a persistent connection, you can schedule replication to occur after a specified interval.

Use the Active Directory Sites and Services snap-in to configure a replication interval. For information about how to specify a replication interval, see "Configure site link replication frequency" in Help and Support Center for Windows Server 2003.

Configure Reciprocal Replication for a One-Way Initiated On-Demand Connection

If this is a one-way initiated on-demand connection, you must configure reciprocal replication using the Active Directory Service Interfaces (ADSI) Edit tool.

Install ADSI Edit, a Windows Support tool, on a domain controller in the main office or in the branch office. For information about how to install Windows Support Tools, which include ADSI Edit, in Help and Support Center for Windows Server 2003, click Tools, and then click Windows Support Tools.

Caution

If you use the ADSI Edit snap-in and incorrectly modify the attributes of Active Directory objects, you can cause serious problems that might require you to reinstall Windows Server 2003. Microsoft cannot guarantee that problems resulting from the incorrect modification of Active Directory object attributes can be solved. Modify these attributes at your own risk.

Категории