Integrating the Remote Site Connection into Your Network

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

Figure 10.7: Integrating the Remote Site Connection into Your Network

Designing the Routing Infrastructure

Integrating a remote site connection into your existing routing infrastructure requires that you decide which choices you want to make about the following tasks:

• Adding static routes

• Using routing protocols

• Servicing Internet traffic

• Enabling multicast connectivity between sites

Adding Static Routes

In some cases, instead of using routing protocols to dynamically update routing tables, you must configure one or more static routes on the intranet interfaces and demand-dial interfaces of the demand-dial routers in your site-to-site deployment. A static route, which creates a specific path to a destination IP address in an IP network, is one of a set of routes in a routing table that are permanent until changed by a network administrator or by an automatically scheduled auto-static update.

The following topics provide the information that you need to manage static routes for a site-to-site connection:

• Static routes for a site-to-site connection

• Auto-static updates

• Using on-subnet or off-subnet address ranges

Static Routes for a Site-to-Site Connection

You might need to create one or more the following types of static routes for your site-to-site connection:

• LAN interface at both sites. On both the calling and the answering router, configure a static route or routes on the LAN interface that connects the router to the local intranet. Include a static route for each subnet on the local area network.

  Alternatively, you can use a routing protocol instead of configuring static routes. For more information about using routing protocols, see "Using Routing Protocols" later in this chapter.

• Demand-dial interface for the remote site. On the calling router, configure a static route or routes on the demand-dial interface that connects the router to the remote site. Include a static route for each subnet in the answering router's network that you want users to be able to access (or you can use the default route).

  Alternatively, for a persistent site-to-site connection only, you can enable a routing protocol on the demand-dial interface instead of configuring static routes. For more information about using routing protocols, see "Using Routing Protocols" later in this chapter.

• Demand-dial interface for the local ISP. On the calling router — for a VPN connection in which the branch office router uses a temporary link to a local ISP only — you must configure a static host route on the demand-dial interface that connects to the local ISP. The destination that you specify for this static host route is the IP address of the answering router's Internet-connected interface; this IP address is assigned to the answering router by its local ISP (or by InterNIC).

• Router user account. For a one-way connection in which the answering router is a standalone router or a member of a native-mode Active Directory domain, you can omit creating a demand-dial interface on the answering router. In this case, you must configure a static route or routes in the calling router's user account that identify the network IDs of the calling router's site.

For information about how to configure these static routes, see "Configure Static Routes" later in this chapter. For general information about the difference between using static routes or routing protocols, see the discussion of developing routing strategies in "Designing a TCP/IP Network" in this book.

Auto-static Updates

You can add the static routes that correspond to the network IDs available across a demand-dial interface either manually or by using auto-static updates. An auto-static update is a one-time, one-way transfer of routing information. In contrast to the periodic announcements issued by routing protocols, an administrator must either issue a command to initiate a manual auto-static update or must schedule auto-static updates by running the update as a scheduled task.

When instructed, a demand-dial interface that is configured for auto-static updates sends a request across an active connection to request all of the routes of the router on the other side of the connection. In response to the request, all of the routes of the requested router are automatically entered as static routes in the routing table of the requesting router.

Using On-Subnet or Off-Subnet Address Ranges

If any of the static address ranges that you configure in the IP properties of the answering router is an off-subnet address range, you must add routes to the routing infrastructure in order for the logical interfaces of calling routers to be reachable. During the PPP negotiation, each router typically assigns an IP address to the logical interface of the other router. When a site-to-site connection is made, each router sends traffic to the other router using the logical interface that corresponds to the dial-up, PPTP, or L2TP port of the connection. For more information about how each router assigns an IP address to the other, see "IP Address Assignment for the Logical Interface" later in this chapter.

The method used to ensure the reachability of the logical interfaces in a site-to-site connection depends on how you configure each router to obtain IP addresses for calling routers (and for remote access clients, if your network also supports them). You use either an on-subnet or an off-subnet address range for these IP addresses.

On-subnet address range

An on-subnet address range is an address range of the subnet to which the answering router is attached. An on-subnet address range provides the IP address for a logical interface whenever the router is configured to use Dynamic Host Configuration Protocol (DHCP) to obtain IP addresses, a DHCP server is available, and the manually configured pool (or pools) of IP addresses are within the range of addresses of the attached subnet. If you use an on-subnet address range, no additional routing configuration is required.

Off-subnet address range

An off-subnet address range is an address range that represents a different subnet than the subnet to which the router is attached. Off-subnet addressing uses a separate subnet address space that is unique to the intranet. An off-subnet address range provides the IP address for a logical interface whenever the router is manually configured with a pool of IP addresses for a separate subnet.

If you use an off-subnet address range, you must add the route or routes that summarize the off-subnet address range to the intranet routing infrastructure so that traffic destined to the logical interfaces of connected routers are forwarded from the originating node to the local dial-up or VPN router and then sent by it to the appropriate connected remote router. You can add the routes that summarize the off-subnet address range to the routing infrastructure by using one of the following methods:

• Add static routes for the off-subnet address range that point to the dial-up or VPN router's intranet interface to the neighboring router. Configure the neighboring router to propagate this static route to other routers in the site by using the dynamic routing protocol used in your site.

• If the dial-up or VPN router uses Open Shortest Path First (OSPF) and participates as a dynamic router, you must configure the router as an autonomous system boundary router (ASBR) so that the static routes of the off-subnet address range are propagated to the other OSPF routers in the site.

If your site consists of a single subnet, and you use an off-subnet address range, you must do one of the following:

• Configure each intranet host for a persistent route (or routes) that points to the dial-up or VPN router's intranet interface. The route (or routes) expresses the off-subnet address range.

  In the Routing and Remote Access snap-in, you must configure address ranges with a starting and ending address. To simplify the set of routes needed to express the off-subnet address ranges, express each range as an IP address with a subnet mask. For more information about using an IP address and a mask to express an address range, see "Expressing an IP address range with a mask" in Help and Support Center for Windows Server 2003.

• Configure each intranet host with the IP address of the intranet-connected interface of the dial-up or VPN router as its default gateway.

Therefore, if your site consists of a single subnet, it is more efficient to use an on-subnet address range.

Using Routing Protocols

If you use the Routing Information Protocol version 1 or 2 (RIPv1 or RIPv2) or the OSPF routing protocol in your site, you can add and configure the RIP or OSPF routing protocol components of the Routing and Remote Access service so that a demand-dial router participates in the propagation of routing information as a dynamic router. As an efficient alternative to manually configuring static routes, you can use routing protocols on each LAN interface and on each demand-dial interface that is used for a persistent site-to-site connection. You must configure dynamic routing protocols for each new router so that it can participate in the dynamic routing architecture and share its subnets.

If you use a routing protocol other than RIP or OSPF, such as the Cisco proprietary Interior Gateway Routing Protocol (IGRP) or Enhanced Interior Gateway Routing Protocol (EIGRP), configure the neighboring Cisco router for RIP or OSPF on the interface connected to the subnet that contains the dial-up or VPN router, and then configure IGRP or EIGRP on all other interfaces. You must also configure the neighboring Cisco router to redistribute the IGRP or EIGRP routes into the OSPF or RIP routing tables.

Do not use routing protocols across an on-demand site-to-site connection. The periodic announcements that most routing protocols use to propagate routing information cause one demand-dial router to call another each time an announcement occurs. For example, RIPv1, by default, announces routing information every 30 seconds. If your router incurs a long-distance charge every 30 seconds, the phone bill that results defeats the cost savings that an on-demand link is designed to provide. Instead, add routes for network IDs that are available across the demand-dial interface as static routes to the routing tables of demand-dial routers.

Servicing Internet Traffic

Depending on the immediate task at hand, users in an organization that includes more than one site might want to access people or resources at the remote site, or they might want to access the Internet. You can use a demand-dial router to handle both types of traffic. If you do use the demand-dial router to enable users to access the Internet, you must decide whether you want users at a branch office to access the Internet through the main office or to access the Internet directly from the branch office.

For security, route branch office Internet traffic through the main office

If you deploy Microsoft Internet Security and Acceleration (ISA) Server at the main office, and you want branch office Internet traffic to be protected by this system, configure branch office Internet traffic to go over the dial-up or VPN connection to the ISA server at the main office. ISA Server is an integrated firewall and Internet caching server that can also act as a VPN router to provide Internet access that is both secure and fast. For information about deploying ISA Server, see "Deploying ISA Server" in this book.

For performance, route branch office Internet traffic directly to the Internet

To give branch office users faster access to the Internet than is possible if the Internet traffic must travel to the main office and back, configure branch office Internet traffic to go directly out to the Internet through the demand-dial router. In addition, if you use an on-demand connection rather than a persistent connection, you must provide direct access to the Internet through the demand-dial router rather than over the link to the main office. Configuring client computers to allow users in the branch office to access the Internet directly through the demand-dial router is known as split tunneling.

For information about handling each alternative, see "Configure Internet Access Through the Calling Router" later in this chapter.

Enabling Multicast Connectivity Between Sites

An increasing number of organizations use multicast communication for such multiple-user applications as video conferencing, collaborative computing, and distance learning. Computers running Windows Server 2003 can both send and receive IP multicast traffic. The Routing and Remote Access service includes the Windows Server 2003 Internet Group Management Protocol (IGMP) routing protocol component, which you can configure with IGMP router mode and IGMP proxy mode to enable the exchange of multicast packets between remote sites. The IGMP Router and Proxy routing protocol is not itself a multicast routing protocol.

When you make your demand-dial routers multicast-capable, they can listen for all multicast traffic over all site-to-site connections, they can listen for IGMP Membership Report messages, and they can update the TCP/IP multicast forwarding table so that routers can determine where to forward incoming multicast traffic.

For a site-to-site connection, use the Routing and Remote Access snap-in to enable IGMP with IGMP proxy mode on the demand-dial interface on both the calling router and the answering router, and to enable IGMP with IGMP router mode on all other interfaces internal to the site.

For more information about IP multicasting, see "Designing a TCP/IP Network" in this book and the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit). For more information about multiple supported multicast configurations, see the Internetworking Guide of the Windows Server 2003 Resource Kit (or see the Internetworking Guide on the Web at http://www.microsoft.com/reskit).

Planning IP Address Assignment and Name Resolution

The DHCP and name resolution issues that you must consider when planning how to integrate a site-to-site connection into your existing network include:

• Client IP address assignment

• IP address assignment for the logical interface

• Using IP addresses to avoid name resolution issues

• Using name resolution when accessing other services on a VPN router

Client IP Address Assignment

Typically, when you have slower WAN links or when you have dial-up links, you place a DHCP server on each side of a remote site connection. Installing the DHCP service on a calling router or other server at a branch office lets branch office clients obtain IP addresses from that server.

However, a DHCP server located in one subnet can support other subnets. If no DHCP server is located at the branch office, when a client at the branch office requests an address, the calling router can forward the client's request across the dial-up or VPN link to the DHCP server in the main office, which then leases the client an address. For this to work, ensure the following:

• The calling router contains the DHCP Relay Agent (the DHCP Relay Agent component is added with the internal interface by default).

• The calling router is configured with the DHCP server's IP address.

• The site-to-site connection is a persistent connection.

For an on-demand connection, if the DHCP Relay Agent is installed on a branch office router, this can cause the router to dial the main office router (for a non-VPN dial-up connection) or the local ISP (for a VPN connection that uses a dial-up link to the ISP) every time a DHCP packet is sent by a computer in the branch office network. Therefore, if you deploy an on-demand connection, install the DHCP service in the branch office and uninstall the DCHP Relay Agent on the calling router.

For more information about deploying DHCP, see "Deploying DHCP" in this book.

IP Address Assignment for the Logical Interface

When a calling router initiates a connection, the router creates a temporary logical interface (also known as a virtual interface or a virtual network adapter) and requests that the answering router assign an IP address to this logical interface. The answering router then creates a logical interface and requests an IP address for itself from the calling router. The logical interface on the calling router connects to the logical interface on the answering router to form the demand-dial connection. The IP address assignment for each demand-dial interface lasts for the duration of the connection. These IP addresses can be either private or public IP addresses. If both requests are successful, the logical interface on the PPP connection for each router is assigned an IP address from the other router. This is known as a numbered connection. In the absence of a numbered connection, a site-to-site connection can also use an unnumbered connection.

Numbered Connection

A numbered IP address assignment can occur in one of the following ways:

• Dynamic IP addresses allocated by a DHCP server. The answering router obtains the IP address to assign to a calling router from a DHCP server. This is the default method for IP address assignment. If no DHCP server is available, the router uses an address from the Automatic Private IP Addressing (APIPA) range 169.254.0.1-169.254.255.254. You must install a DHCP server on each network that contains an answering router.

• Dynamic IP addresses allocated from a static address pool configured on the answering router. The answering router obtains the IP address from a static pool of addresses. If you configure a static address pool, be sure to use only IP addresses that are not in a range that your DHCP server might assign to another computer and that are not already assigned to specific computers. The pool can be ranges of addresses that are a subset of addresses from the IP network to which the server is attached or from a separate subnet. As described earlier, if the static IP address pool address ranges represent a different subnet, ensure that routes to the address ranges exist on the routers of your intranet so that traffic to the logical interface of a calling router is forwarded to the remote server.

• Static IP address specified in the calling router user account. You configure a static IP address on the router user account Dial-in tab for both the calling and the answering router. In this case, when a calling router initiates a connection, creates a temporary logical interface, and requests that the answering router assign an IP address to this logical interface, the answering router assigns the IP address specified in the calling router's user account. The answering router then creates a logical interface and requests an IP address for itself from the calling router. The calling router assigns the IP address specified in the answering router's user account.

Unnumbered Connection

Site-to-site connections in Windows Server 2003 and Windows 2000 do not require a numbered connection (Windows NT 4.0 RRAS connections do require a numbered connection). If one of the routers rejects the request for an IP address during the connection establishment process between a calling and an answering router (because no addresses are available to assign, probably due to a misconfiguration), a connection is still established. In this case, the logical interface on the PPP connection does not have an assigned IP address. This is known as an unnumbered connection.

The routing protocols provided with Routing and Remote Access cannot operate over unnumbered connections. Therefore, you must use static routing if you use unnumbered connections.

Using IP Addresses to Avoid Name Resolution Issues

When you configure a demand-dial interface for a dial-up calling router, you provide the phone number of the answering router with which this router establishes a connection. In this case, name resolution is not an issue.

For VPN connections, however, the corresponding entry on the demand-dial interface is the destination address of the answering router. In this case, name resolution can be an issue, because you can provide either the Domain Name System (DNS) name or the IP address of the answering router. Microsoft recommends that you provide the IP address rather than the answering router name when you configure a demand-dial interface so that resolution of the name to the IP address by means of a DNS or Windows Internet Name Service (WINS) server is not needed.

If you do use names for demand-dial interfaces, make sure that an appropriate DNS record exists on the DNS server that hosts the public namespace that is visible to Internet users and computers, or on the DNS server of your ISP, so that the DNS names of your answering routers can be resolved.

Using Name Resolution When Accessing Other Services on a VPN Router

In some organizations, you might want users to be able to access other services, such as file shares, on the answering VPN router. For this type of configuration, if you specify the DNS name rather than the IP address in the demand-dial interface, and the name resolves to the public IP address of the answering router, traffic sent to the services running on the router is sent in clear text (unencrypted) across the Internet. It is not encapsulated, encrypted, and sent using the VPN connection, which can compromise security.

A related problem is that if you configure packet filters on the answering router to allow only traffic over a VPN connection, all other traffic is discarded. Attempts to connect to services running on the answering router fail in this situation, because traffic attempting to connect to those services is not sent over the site-to-site VPN connection.

If the site DNS and WINS servers do not contain a record mapping the name of the VPN router to its public IP address, traffic to services running on the VPN router is always sent across the VPN connection. To ensure that the name of the VPN router is always resolved to the private or site IP address of the VPN router, disable DNS dynamic update and NetBIOS over TCP/IP (NetBT) on the Internet-connected interface (or interfaces) of the VPN router from the properties of the Internet connection in Network Connections as follows:

• Prevent DNS name resolution. To prevent a VPN router from dynamically registering the public IP address of its Internet interface on the site DNS servers, on the Internet interface of the router, configure the properties of Internet Protocol (TCP/IP) by clicking the Advanced button, selecting the DNS tab, and then clearing the Register this connection's addresses in DNS check box.

• Prevent WINS name resolution. To prevent a VPN router from dynamically registering the public IP address of its Internet interface on the site WINS servers, on the Internet interface of the router, configure the properties of Internet Protocol (TCP/IP) by clicking the Advanced button, selecting the WINS tab, and then selecting the option Disable NetBIOS over TCP/IP.

  Note

  By default, the Routing and Remote Access Wizard clears Register this connection's addresses in DNS and selects Disable NetBIOS over TCP/IP. Be sure not to change these defaults if you want users to be able to access services such as file shares on the answering VPN router.

For more information about name resolution, see "Deploying DNS" and "Deploying WINS" in this book.

Planning Active Directory Integration

Integrating a remote site connection into an Active Directory-based network requires you to decide which choices you want to make about the following tasks:

• Put a domain controller at the branch office.

• Use one domain to include geographically remote sites.

• Use scheduled replication or reciprocal replication.

• Join demand-dial routers to the Active Directory domain.

Putting a Domain Controller at the Branch Office

If you deploy a persistent site-to-site connection between a branch office and a main office, you might not need a domain controller at the branch office. Branch office users can access a domain controller in the main office when they log on to their computers or use other Active Directory services.

For an on-demand connection, install a domain controller at the remote site.

Using One Domain to Include Geographically Remote Sites

You can include a main office and a branch office in one Active Directory domain. However, geographically remote sites must not share the same address space and must have separate Active Directory sites. You must create a separate Active Directory site for the branch office and create a child object for the branch office, providing the appropriate network ID and subnet mask for the branch office site.

For more information about deploying Active Directory, see "Deploy Active Directory" later in this chapter.

Using Scheduled Replication or Reciprocal Replication

Typically, domain controllers have a constantly available connection so that all domain controllers obtain a steady flow of updated directory information. If you have domain controllers in sites that are connected by a site-to-site connection, you must ensure that replication takes place. Directory updates can be exchanged through a site-to-site connection in one of two ways:

• Scheduled replication. On a persistent site-to-site connection, you can schedule replication to take place at specified intervals.

• Reciprocal replication. For a one-way initiated on-demand connection in which no constantly available connection exists between domain controllers in the two sites, you must enable reciprocal replication. With reciprocal replication, all replication occurs simultaneously between the domain controllers in the two sites, and the connection is closed when replication is complete. Reciprocal replication maximizes the efficiency of directory information exchange while minimizing connection time and eliminating timeout errors that can occur if the main site domain controller requests changes from the branch site domain controller when the connection is not available. You can configure reciprocal replication on a site link or on a connection.

For more information, see "Configure Replication" later in this chapter.

Joining Demand-Dial Routers to the Active Directory Domain

In an Active Directory domain, you can choose either to join a demand-dial router computer to the domain or not to, based on the following factors:

• If your answering router uses Active Directory user accounts to authenticate and authorize a calling router, you must join the answering and calling routers to the domain.

• If you use EAP-TLS user authentication with Windows as the authentication provider, you must join the answering router (which is the authenticating server) to the Active Directory domain. If you use EAP-TLS user authentication with RADIUS as the authentication provider, you must join the IAS server (which is the authenticating server) to the Active Directory domain. With RADIUS authentication, the answering router does not need to be joined to the domain. (Use Windows authentication for a site-to-site only connection. You might use RADIUS authentication for a site-to-site connection if the answering router also supports remote access users.)

• If you use L2TP/IPSec with computer certificates, the demand-dial routers are not required to join the Active Directory domain. However, the Windows Server 2003 PKI uses Active Directory, if it is installed, to store certificates, certificate revocation lists, and delta certificate revocation lists and to publish root CA certificates and cross-certificates. Using Active Directory makes this information easy to locate from anywhere on the network. (If you use L2TP/IPSec with preshared keys, you are not required to join the VPN routers to the Active Directory domain.)

For more information about planning and deploying Active Directory for an organization with multiple branch office sites, see the Active Directory Branch Office Planning Guide link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

For more information about deploying Active Directory domains and sites and Active Directory replication between sites, see "Designing the Site Topology" in Designing and Deploying Directory and Security Services of this kit.