Components of Windows 2000 Router-to-Router VPNs

  • Article
On This Page

VPN routers
Internet network infrastructure
Authentication protocols
VPN protocols
Site network infrastructure
AAA Infrastructure
Certificate infrastructure

Figure 2 shows the components of Windows 2000 router-to-router virtual private networks.

Bb727141.bug28137-fig2-sm(en-us,TechNet.10).gif

Figure 2: Components of Windows 2000 router-to-router VPNs

The major components are:

  • VPN routers

  • Internet infrastructure

  • Intranet infrastructure

  • Authentication, authorization, and accounting (AAA) infrastructure

  • Certificate infrastructure

VPN routers

VPN routers either initiate or receive VPN-based demand-dial connections and consists of the following components:

  • Routing and Remote Access service. The Routing and Remote Access service on both the calling and answering router is configured as a VPN server using the Routing and Remote Access Server Setup Wizard.

  • Ports. A port is a logical or physical communications channel capable of supporting a single PPP connection. Physical ports are based on equipment installed in the VPN router. Virtual private network (VPN) ports are logical ports.

  • Demand-dial interfaces. A demand-dial interface configured on the calling router represents the PPP connection and contains configuration information such as the type of port to use, the addressing used to create the connection (an IP address or domain name), authentication methods, encryption requirements, and authentication credentials.
    For two-way initiated connections, a demand-dial interface configured on the answering router represents the PPP connection to the calling router. For a one-way initiated connection using static routes on the user account of the calling router, a demand-dial interface on the answering router does not need to be configured.

  • User account. To authenticate the calling router, the credentials of the calling router must be verified by the properties of a corresponding user account. If the answering router is configured for Windows authentication, a user account in the authentication credentials of the calling router must be verifiable using Windows security. If the answering router is configured for RADIUS authentication, then the RADIUS server must have access to the user account in the authentication credentials of the calling router.
    The user account must have the following settings:

    • On the Dial-in tab, remote access permission is set to either Allow access or Control access through Remote Access Policy. When you create user accounts with the Demand-Dial Interface Wizard, the remote access permission is set to Allow access.

    • On the General or Account tab, User must change password at next logon is disabled and Password never expires is enabled. These settings are configured when you create user accounts with the Demand-Dial Interface Wizard.

    For a one-way initiated connection, you can configure static IP routes on the Dial-in tab that are added to the answering router's routing table when the demand-dial connection is made.

  • Routes. To forward traffic across a router-to-router VPN connection, IP routes in the routing tables of the VPN routers is configured to use the correct demand-dial interface.
    For one-way initiated connections, configure the calling router normally. For the answering router, you can configure the user account specified in the authentication credentials of the calling router with static IP routes.

  • Remote access policy. On the answering router or the Internet Authentication Service (IAS) server that is acting as a RADIUS server to the answering router, to specify connection parameters that are specific to demand-dial connections, create a separate remote access policy that uses the Windows-Groups attribute set to the group that has all of the user accounts for calling routers as members. A separate remote access policy for demand-dial connections is not required.

A calling router does the following:

  • Initiates VPN connections based on an administrator action or when a packet being forwarded matches a route using a VPN-based demand-dial interface.

  • Waits for authentication and authorization before forwarding packets.

  • Acts as a router forwarding packets between nodes in its site and the answering router.

  • Acts as an endpoint of the VPN connection.

The answering router does the following:

  • Listens for VPN connection attempts.

  • Authenticates and authorizes VPN connections before allowing data to flow.

  • Acts as a router forwarding packets between nodes in its site and the calling router.

  • Acts as an endpoint of the VPN connection.

VPN routers typically have two installed network adapters one network adapter connected to the Internet and one network adapter connected to the intranet.

When you configure and enable the Routing and Remote Access service, the Routing and Remote Access Server Setup Wizard prompts you to select the role that the computer will fulfill. For VPN routers, you should select the Virtual private network (VPN) server option. With the Virtual private network (VPN) server option, the Routing and Remote Access server operates in the role of a VPN server that supports both remote access and router-to-router VPN connections. For remote access VPN connections, users run VPN client software and initiate a remote access connection to the VPN server. For router-to-router VPN connections, a router initiates a VPN connection to the VPN server. Alternately, the VPN server can initiate a VPN connection to another VPN router.

Note: Microsoft recommends the choice of Virtual private network (VPN) server over Network router in the Routing and Remote Access Server Setup Wizard because the Network router option does not prompt you to select an Internet interface over which to automatically configure packet filters, does not prompt you to configure RADIUS servers, and only creates 5 PPTP and 5 L2TP ports.

When you select the Virtual private network (VPN) server option in the Routing and Remote Access Server Setup Wizard:

  1. You are first prompted to verify the protocols over which VPN traffic is forwarded. By default, all of the protocols that can be used with a remote access or router-to-router VPN connection are listed.

  2. Next, you are prompted to select the interface that is connected to the Internet. The interface that you select will be automatically configured with packet filters that allow only PPTP and L2TP-related traffic. All other traffic is silently discarded. For example, you will no longer be able to ping the Internet interface of the calling router. If you do not want to have VPN packet filters automatically configured, you can select <No Internet connection>. If you want to use the calling router computer as a network address translator (NAT), Web server, or other function, see Appendix B.

  3. Next, if you have multiple network adapters that are connected to the intranet, you are prompted to select an interface over which DHCP, DNS, and WINS configuration is obtained.

  4. Next, you are prompted to determine whether you want to assign IP addresses to either remote access clients or other calling routers by using either DHCP or a specified range of addresses. If you select a specified range of addresses, you are prompted to add one or more address ranges.

  5. Next, you are prompted to specify whether you want to use RADIUS as your authentication and accounting provider. If you select RADIUS, you are prompted to configure primary and alternate RADIUS servers and the shared secret.

When you complete the Virtual private network (VPN) server option in the Routing and Remote Access Server Setup Wizard, the results are as follows:

  1. The Routing and Remote Access service is enabled as both a remote access server and a LAN and demand-dial router, with Windows as the authentication and accounting provider (unless RADIUS was chosen and configured). If there is only one network adapter connected to the site, that network adapter is automatically selected as the IP interface from which to obtain DHCP, DNS, and WINS configuration. Otherwise, the network adapter specified in the wizard is selected to obtain DHCP, DNS, and WINS configuration. If specified, the static IP address ranges are configured.

  2. Exactly 128 PPTP and 128 L2TP ports are created. All of them are enabled for both inbound remote access connections and inbound and outbound demand-dial connections.

  3. The selected Internet interface is configured with input and output IP packet filters that allow only PPTP and L2TP traffic.

  4. All protocols selected are configured to both allow remote access connections and access the network to which the remote access server is attached.

  5. The DHCP Relay Agent component is added with the Internal interface. If the VPN router is a DHCP client at the time the wizard is run, the DHCP Relay Agent is automatically configured with the IP address of a DHCP server. Otherwise, you must manually configure the properties of the DHCP Relay Agent with an IP address of a DHCP server in your site. The DHCP Relay Agent forwards DHCPInform packets between VPN remote access clients and a site DHCP server.

  6. The IGMP component is added. The Internal interface and all other LAN interfaces are configured for IGMP router mode. This allows VPN remote access clients to send and receive IP multicast traffic.

Installing a certificate on a VPN router

If VPN routers are making L2TP connections or using EAP-TLS authentication, certificates must be installed on the VPN router computers. For L2TP connections, a computer certificate must be installed on both the calling and answering router computer to provide authentication for establishing an IPSec security association (SA). For EAP-TLS authentication, a computer certificate must be installed on the authenticating server (either the answering router or a RADIUS server) and a user certificate must be installed on the calling router.

For more information about installing certificates on calling routers, answering routers, and authentication server computers, see "Certificate infrastructure" in this paper.

Design Points: Configuring the VPN router

Consider the following before running the Routing and Remote Access Server Setup Wizard:

  • Which protocols will be supported over the VPN connection?
    The Routing and Remote Access service can forward IP or IPX packets over a PPTP or L2TP connection.

  • Which connection of the VPN router is connected to the Internet?
    Typical Internet-connected VPN routers have at least two LAN connections: one connected to the Internet (either directly or connected to a perimeter network) and one connected to the site. To make this distinction easier to see for the Routing and Remote Access Server Setup Wizard, rename the connections with their purpose or role using Network and Dial-up Connections. For example, rename the connection connected to the Internet, default name Local Area Connection 2, to Internet.

  • Can the VPN router be a DHCP client?
    The VPN router must have a manual TCP/IP configuration for its Internet interface. While technically possible, it is not recommended that the VPN router be a DHCP client for its site interface(s). Due to the routing requirements of the VPN router, manually configure an IP address, subnet mask, DNS server(s), and WINS server(s), but do not configure a default gateway.

    Note that it is possible for the VPN router to have a manual TCP/IP configuration and still use DHCP to obtain IP addresses for remote access VPN clients and other calling routers.

  • How will IP addresses be allocated to remote access VPN clients and other calling routers?
    The VPN router can be configured to obtain IP addresses from DHCP or from a manually configured set of address ranges. Using DHCP to obtain IP addresses simplifies the configuration, however, you must ensure that the DHCP scope for the subnet to which the site connection of the calling router is attached has enough addresses for all the computers physically connected to the subnet and the maximum number of PPTP and L2TP ports. For example, if the subnet to which the site connection of the VPN router is attached contains 50 DHCP clients, then, for the default configuration of the VPN router, the scope should contain at least 307 addresses (50 computers + 128 PPTP clients + 128 L2TP clients + 1 address for the VPN router). If there are not enough IP addresses in the scope, remote access VPN clients and calling routers that connect after all the addresses in the scope are allocated will be assigned an address in the Automatic Private IP Addressing (APIPA) range of 169.254.0.0/16.

    If you configure a static pool of addresses, ensure that the pool has enough addresses for all your PPTP and L2TP ports, plus an additional address for the VPN router. If there are not enough addresses in your static pool, remote access VPN clients and Windows NT® 4.0 RRAS calling routers will not be able to connect. Windows 2000 calling routers, however, will still be able to connect. Windows 2000 calling and answering routers still request an IP address from each other during the connection establishment process. But if one of the routers does not have an address to assign, both routers continue with the connection establishment process. The logical interface on the point-to-point connection does not have an assigned IP address. This is known as an unnumbered connection. While Windows 2000 VPN routers support unnumbered connections, the routing protocols included with Windows 2000 do not work over an unnumbered connection.

    If you are configuring a static pool of addresses, there might be additional routing considerations. For more information, see "Site network infrastructure" in this paper.

  • What is the authentication and accounting provider?
    The VPN router can use Windows or RADIUS as its authentication or accounting provider.

    When Windows is used as the authentication and accounting provider, the VPN router uses Windows 2000 security to validate the credentials of a calling router and access the calling router's user account dial-in properties. Locally configured remote access policies authorize the VPN connection and locally written accounting log files log VPN connection accounting information.

    When RADIUS is used as the authentication and accounting provider, the VPN router uses a configured RADIUS server to validate the credentials of a calling router, authorize the connection attempt, and store VPN connection accounting information.

  • Are you making L2TP connections?
    If so, you must install a computer certificate on both the calling router and answering router computers.

  • Are you using user-level certificate authentication with EAP-TLS?
    If so, you must install a user certificate on the calling router computer and a computer certificate on the authenticating server (either the answering router computer [if the answering router is configured for the Windows authentication provider] or the RADIUS server [if the answering router is configured for the RADIUS authentication provider]). If the authenticating server is a Windows 2000 VPN router or a Windows 2000 Internet Authentication Service (IAS) server, EAP-TLS is only available if the authenticating server is a member of an Active Directory™ service domain.

  • For on-demand connections, do you want prevent connections from occurring during certain times of the day during the week or for certain types of traffic?
    If so, configure dial-out hours or demand-dial filters on the demand-dial interface of the calling router.

  • Do you want to match your IP packet filters to the demand-dial filters?
    Demand-dial filters are applied before the connection is made. IP packet filters are applied after the connection is made. To prevent the demand-dial connection from being established for traffic that is discarded by the IP packet filters:

    • If you have configured a set of output IP packet filters with the Receive all packets except those that meet the criteria listed below option, then configure the same set of filters as demand-dial filters with Initiate connection set to For all traffic except.

    • If you have configured a set of output IP packet filters with the Drop all packets except those that meet the criteria listed below option, then configure the same set of filters as demand-dial filters with Initiate connection set to Only for the following traffic.

Consider the following when changing the default configuration of the VPN router for router-to-router VPN connections:

  • Do you want to support remote access VPN connections?
    By default, all the PPTP and L2TP ports are configured to allow both remote access connections (inbound only) and demand-dial routing connections (inbound and outbound). To disable remote access connections and create a dedicated router-to-router VPN connection server, clear the Remote access connections (inbound only) check box from the properties of the WAN miniport (PPTP) and WAN miniport (L2TP) devices from the properties of the Ports object in the Routing and Remote Access snap-in.

  • Do you need to install a computer certificate?
    If the VPN router is supporting L2TP connections or is authenticating connections using the EAP-TLS authentication protocol and configured to use the Windows authentication provider, you must install a computer certificate. If the VPN router is a calling router using the EAP-TLS authentication protocol, you must install a user certificate. For more information, see "Certificate infrastructure" in this paper.

  • Do you need custom remote access policies for VPN connections?
    If you configure the VPN router for Windows authentication or for RADIUS authentication and the RADIUS server is an IAS server, the default remote access policy rejects all types of connection attempts unless the remote access permission of the user account's dial-in properties is set to Allow access. If you want to manage authorization and connection parameters by group or by type of connection, you must configure custom remote access policies. For more information, see "Remote Access Policies" in this paper.

  • Do you want separate authentication and accounting providers?
    The Routing and Remote Access Server Setup Wizard configures both authentication and accounting providers to be the same. After the Wizard is complete, however, you can configure the authentication and accounting providers separately (for example, if you want to use Windows authentication and RADIUS accounting). You can configure authentication and accounting providers on the Authentication tab from the properties of the VPN router in the Routing and Remote Access snap-in.

After the VPN router is configured, you can begin creating demand-dial interfaces and configuring routes using the Routing and Remote Access snap-in. For more information, see "Deploying a PPTP-based Router-to-Router VPN Connection" and "Deploying an L2TP-based Router-to-Router VPN Connection" in this paper.

Internet network infrastructure

To create a router-to-router VPN connection to an answering router across the Internet:

  • The answering router's name must be resolvable.

  • The answering router must be reachable.

  • VPN traffic must be allowed to and from the answering router.

Answering router name resolvability

While it is possible to configure demand-dial interfaces with the names of the answering routers to which a connection is made, it is recommended that you use IP addresses rather than names. If you use a name and the name resolves to the public IP address of the answering router, traffic sent to services running on the VPN router will be sent in clear text across the Internet. For more information, see "Routing and multi-use VPN routers" in this paper.

Answering router reachability

To be reachable, the answering router must be assigned a public IP address to which packets are forwarded by the routing infrastructure of the Internet. If you have been assigned a static public IP address from an ISP or an Internet registry, this is typically not an issue. In some configurations, the answering router is actually configured with a private IP address and has a published static IP address by which it is known on the Internet. A device between the Internet and the answering router translates the published and actual IP addresses of the answering router in packets to and from the answering router.

While the routing infrastructure might be in place, the answering router might be unreachable due to the placement of firewalls, packet filtering routers, network address translators, security gateways, or other types of devices that prevent packets from either being sent to or received from the answering router computer.

VPN routers and firewall configuration

There are two approaches to using a firewall with a VPN router:

  1. The VPN router is attached directly to the Internet and the firewall is between the VPN router and the site.
    In this configuration, the VPN router must be configured with packet filters that only allow VPN traffic in and out of its Internet interface. The firewall can be configured to allow specific types of inter-site traffic.

  2. The firewall is attached to the Internet and the VPN router is between the firewall and the site.
    In this configuration, both the firewall and the VPN router are attached to a network segment known as the perimeter network (also known as a demilitarized zone [DMZ] or a screened subnet). Both the firewall and the VPN router must be configured with packet filters that allow only VPN traffic to and from the Internet. Figure 2 shows this configuration.

For the details of configuring packet filters for the VPN router and the firewall for both of these configurations, see Appendix A.

Design Points: Answering router accessibility from the Internet

Consider the following when configuring your Internet infrastructure for router-to-router VPN connections:

  • Wherever possible, configure your demand-dial interfaces with the IP addresses of answering routers. If you are using names, ensure that the DNS names of your answering routers are resolvable by either placing an appropriate DNS record in your Internet DNS server or the DNS server of your ISP. Test the resolvability by using the Ping tool to ping the name of each of your answering routers. Due to packet filtering, the result of the ping command may be "Request timed out", but check to ensure that the name specified was resolved by the Ping tool to the correct IP address.

  • Ensure that the IP addresses of your answering routers are reachable from the Internet by using the Ping tool to ping the name or address of your answering router with a 5 second timeout (using the -w command line option) when directly connected to the Internet. If you see a "Destination unreachable" error message, the answering router is not reachable.

  • Configure packet filtering for PPTP traffic, L2TP traffic, or both types of traffic on the appropriate firewall and answering router interfaces connecting to the Internet and the perimeter network. For more information, see Appendix A.

Authentication protocols

To authenticate the calling router who is attempting a create a PPP connection, Windows 2000 supports a wide variety of PPP authentication protocols including:

  • Password Authentication Protocol (PAP)

  • Shiva Password Authentication Protocol (SPAP)

  • Challenge-Handshake Authentication Protocol (CHAP)

  • Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)

  • MS-CHAP version 2 (MS-CHAP v2)

  • Extensible Authentication Protocol-Message Digest 5 (EAP-MD5)

  • Extensible Authentication Protocol-Transport Level Protocol (EAP-TLS)

For PPTP connections, you must use MS-CHAP, MS-CHAP v2, or EAP-TLS. Only these three authentication protocols provide a mechanism to generate the same encryption key on both the calling router and the answering router. MPPE uses this encryption key to encrypt all PPTP data sent on the VPN connection. MS-CHAP and MS-CHAP v2 are password-based authentication protocols.

In the absence of user certificates, MS-CHAP v2 is highly recommended as it is a stronger authentication protocol than MS-CHAP and provides mutual authentication. With mutual authentication, the calling router is authenticated by the answering router and the answering router is authenticated by the calling router.

Note: If you must use a password-based authentication protocol, enforce the use of strong passwords on your network. Strong passwords are long (greater than 8 characters) and contain a random mixture of upper and lower case letters, numbers, and punctuation. An example of a strong password is f3L*q02~>xR3w#4o. In an Active Directory™ service domain, use Group Policy settings to enforce the use of strong user passwords.

EAP-TLS is designed to be used in conjunction with a certificate infrastructure and user certificates. With EAP-TLS, the calling router sends a user certificate for authentication and the answering router or RADIUS server sends a computer certificate for authentication. This is the strongest authentication method as it does not rely on passwords. If the authenticating server is a Windows 2000 VPN router or an IAS server, EAP-TLS is only available if the authenticating server is a member of an Active Directory domain.

Note: You can use third-party CAs as long as the certificate in the computer store of the answering router or RADIUS server contains the Server Authentication certificate purpose (also known as a certificate usage, certificate issuance policy, or Enhanced Key Usage [EKU]). A certificate purpose is identified using an object identifier (OID). The OID for Server Authentication is "1.3.6.1.5.5.7.3.1". Additionally, the user certificate installed on the Windows 2000 calling router must contain the Client Authentication certificate purpose (OID "1.3.6.1.5.5.7.3.2").

For L2TP/IPSec connections, any PPP authentication protocol can be used because the user authentication occurs after the calling router and answering router have established a secure channel of communication known as an IPSec security association (SA). However, the use of either MS-CHAP v2 and EAP-TLS are recommended to provide mutual user authentication.

Design Point: Which authentication protocol to use?

Consider the following when choosing an authentication protocol for VPN connections:

  • If you are using a certificate infrastructure that issues user certificates, use the EAP-TLS authentication protocol for both PPTP and L2TP connections. EAP-TLS is not supported by Windows NT 4.0 RRAS routers.

  • If you must use a password-based authentication protocol, use MS-CHAP v2 and enforce strong passwords using Group Policy. MS-CHAP v2 is supported by computers running Windows 2000 and Windows NT 4.0 with RRAS and Service Pack 4 and later.

VPN protocols

Windows 2000 includes support for two PPP-based router-to-router VPN protocols:

  1. Point-to-Point Tunneling Protocol

  2. Layer Two Tunneling Protocol with IPSec

Point-to-Point Tunneling Protocol

Introduced in Windows NT 4.0, PPTP leverages Point-to-Point Protocol (PPP) user authentication and Microsoft Point-to-Point Encryption (MPPE) to encapsulate and encrypt IP and IPX traffic. When MS-CHAP v2 is used with strong passwords, PPTP is a secure VPN technology. For nonpassword-based authentication, EAP-TLS can be used in Windows 2000 to support user certificates. PPTP is widely supported, easily deployed, and can be used across most network address translators (NATs).

Layer Two Tunneling Protocol with IPSec

L2TP leverages PPP user authentication and IPSec Encapsulating Security Payload (ESP) transport mode to encapsulate and encrypt IP and IPX traffic. This combination, known as L2TP/IPSec, uses certificate-based computer identity authentication to create the IPSec security association in addition to PPP-based user authentication. L2TP/IPSec provides data integrity and data authentication for each packet. However, L2TP/IPSec requires a certificate infrastructure to allocate computer certificates and is supported by Windows 2000 VPN routers and other third-party VPN routers.

Design Point: PPTP or L2TP?

Consider the following when deciding between PPTP and L2TP for router-to-router VPN connections:

  • PPTP can be used with Windows 2000 and Windows NT version 4.0 with RRAS. PPTP does not require a certificate infrastructure to issue computer certificates.

  • PPTP-based VPN connections provide data confidentiality (captured packets cannot be interpreted without the encryption key). PPTP VPN connections, however, do not provide data integrity (proof that the data was not modified in transit) or data authentication (proof that the data was sent by the authorized computer).

  • PPTP-based calling routers can be located behind a NAT because most NATs include a NAT editor that knows how to properly translate PPTP tunneled data. For example, the Internet connection sharing (ICS) feature of Windows 2000 Network and Dial-up Connections and the NAT routing protocol component of the Windows 2000 Routing and Remote Access service include a NAT editor that translates PPTP traffic from PPTP clients located behind the NAT. Answering routers cannot be behind a NAT unless there are multiple public IP addresses and there is a one-to-one mapping of a public IP address to the private IP address of the answering router or, if there is only one public address, if the NAT is configured to translate and forward the PPTP tunneled data to the VPN router. Most NATs using a single public IP address, including ICS and the NAT routing protocol component, can be configured to allow inbound traffic based on IP addresses and TCP and UDP ports. However, PPTP tunneled data does not use TCP or UDP headers. Therefore, an answering router cannot be located behind a computer using ICS or the NAT routing protocol component when using a single IP address.

  • L2TP-based VPN routers cannot be behind a NAT because Internet Key Exchange (IKE), the protocol to negotiate Windows 2000 IPSec security associations, and IPSec-protected traffic is not NAT-translatable.

  • L2TP can only be used with Windows 2000 and third-party VPN routers and supports computer certificates as the authentication method for IPSec. Computer certificate authentication requires a certificate infrastructure to issue computer certificates to the answering router computer and all calling router computers.

  • By using IPSec, L2TP-based VPN connections provide data confidentiality, data integrity, data authentication, and replay protection.

  • PPTP and L2TP is not an either/or choice. By default, a Windows 2000 VPN router supports both PPTP and L2TP connections simultaneously. You can use PPTP for some router-to-router VPN connections (from calling routers that are running Windows NT 4.0 with RRAS or Windows 2000 and do not have an installed computer certificate) and L2TP for other router-to-router VPN connections (from calling routers running Windows 2000 that have an installed computer certificate).

  • If you are using both PPTP and L2TP, you can create separate remote access policies that define different connection parameters for PPTP and L2TP connections.

Site network infrastructure

The network infrastructure of the site is an important element of VPN design. Without proper design, calling routers are unable to obtain proper IP addresses, and packets cannot be forwarded between calling routers and site resources.

Name resolution

If the calling router is configured with the IP addresses of Domain Name System (DNS) or Windows Internet Name Service (WINS) servers, DNS and WINS server IP addresses are not requested from the answering router during the PPP connection negotiation. If the calling router is not configured with the IP addresses of DNS and WINS servers, DNS and WINS servers are requested. The answering router never requests DNS and WINS server IP addresses from the calling router.

Unlike Windows 2000 and Windows XP remote access clients, the calling router does not send a DHCPInform message to the answering router to discover additional TCP/IP configuration information.

By default, the calling router does not register itself with the DNS or WINS servers of the answering router. To change this behavior, set the registry value HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman \PPP\ControlProtocols\BuiltIn\RegisterRoutersWithNameServers to 1.

Routing

Each VPN router is an IP router and as such must be properly configured with the set of routes that makes all locations reachable. Specifically, each VPN router needs the following:

  • A default route that points to a firewall or router directly connected to the Internet. This route makes all of the locations on the Internet reachable.

  • One or more routes that summarize the addresses used within the site of the VPN router that points to a neighboring site router.
    These routes make all of the locations within the site of the VPN router reachable from the VPN router. Without these routes, all hosts in the site not connected to the same subnet as the VPN router are unreachable.

To add a default route that points to the Internet, configure the Internet interface with a default gateway and then manually configure the site interface without a default gateway.

To add site routes to the routing table of each VPN router, you can:

  • Add static routes using the Routing and Remote Access snap-in. You do not necessarily have to add a route for each subnet in your site. At a minimum, you just need to add the routes that summarize all the possible addresses in your site. For example, if your site uses portions of the private address space 10.0.0.0/8 to number its subnets and hosts, you do not have to add a route for each subnet. Just add a route for 10.0.0.0 with the subnet mask 255.0.0.0 that points to a neighboring router on the site subnet to which your VPN router is attached.

  • If you are using the Routing Information Protocol (RIP) or the Open Shortest Path First (OSPF) routing protocols in your site, you can add and configure the RIP or OSPF routing protocol components of the Routing and Remote Access service so that the VPN router participates in the propagation of routing information as a dynamic router.

If your site has only a single subnet, no further configuration is required.

When a router-to-router VPN connection is made, each router sends traffic using a logical interface that corresponds to the PPTP or L2TP port of the connection. During the PPP negotiation, IP addresses might be assigned to these logical interfaces. Ensuring the reachability of the logical interfaces of VPN routers depends on how you configure each VPN router to obtain IP addresses for remote access clients and calling routers. The IP addresses assigned to VPN routers as they connect can be from:

  • An on-subnet address range, which is an address range of the site subnet to which the VPN router is attached.
    An on-subnet address range is used whenever the VPN router is configured to use DHCP to obtain IP addresses and when the manually configured pool(s) of IP addresses are within the range of addresses of the attached subnet.

  • An off-subnet address range, which is an address range that represents a different subnet that is logically attached to the VPN router.
    An off-subnet address range is used whenever the VPN router is manually configured with a pool of IP addresses for a separate subnet.

On-subnet address range

If you are using an on-subnet address range, no additional routing configuration is required as the VPN router acts as a proxy for all packets destined to the logical interfaces of the other connected VPN routers. Routers and hosts on the VPN router subnet forward packets destined to the logical interfaces of connected VPN routers to the VPN router and the VPN router relays them the appropriate connected VPN routers.

Off-subnet address range

If you are using an off-subnet address range, you must add the route(s) that summarize the off-subnet address range to the site routing infrastructure so that traffic destined to the logical interfaces of connected VPN routers are forwarded to the VPN router and then sent by the VPN router to the appropriate connected VPN router. You can add the routes that summarize the off-subnet address range to the routing infrastructure of the site through the following:

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

  • If the VPN router is using OSPF and participating as a dynamic router, the VPN router must be configured 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, then you must either configure each site host for persistent route(s) of the off-subnet address range that point to the VPN router's site interface or configure each site host with the VPN router as its default gateway. Because routing for off-subnet address ranges requires additional host configuration, it is recommended that you use an on-subnet address pool for a small office/home office (SOHO) network consisting of a single subnet.

Routing and multi-use VPN routers

If you want to access services running on the VPN router, whether or not the traffic to those services is sent on the Internet in an encrypted or clear text form depends on which address the node is using to access the VPN router service:

  • If the node accesses the service running on the VPN router using its site IP address, all traffic is sent encrypted inside the tunnel of the VPN connection.

  • If the node accesses the service running on the VPN router using its public IP address, all traffic is sent as clear text outside the tunnel of the VPN connection.

Due to the way in which routes are created on calling routers when making a VPN connection, it may be possible to connect to services running on an answering router, however, the traffic might not be sent across the VPN connection. When a calling router creates a VPN connection with an answering router, it creates a host route to the answering router that uses the Internet connection. The host route for the answering router's address is created so that it is reachable using the Internet connection. If the host route is not present, VPN traffic to the answering router cannot be sent.

The result of having the host route for the calling router is that all traffic that is sent by nodes in the calling router's site to the answering router's public IP address are not sent across the VPN connection, and are instead sent in an unencrypted form across the network between the calling router and answering router.

For example, when a calling router creates a VPN connection with an answering router and then a node in the calling router's site accesses a file share on the VPN router computer using the VPN router's public IP address, the file sharing traffic is not sent using the router-to-router VPN connection, but is sent in clear text over the network between the calling router and answering router.

Additionally, if packet filters are configured on the answering router that only allow VPN connection traffic, all other traffic sent to the answering router is discarded. In this typical configuration, all attempts to connect to services running on the answering router will fail because traffic attempting to connect to those services are not sent over the VPN connection.

The key to which address is used by the VPN client to access services running on each VPN router lies in the way that the name of the VPN router is resolved. Typical users and applications refer to network resources using names, rather than IP addresses. The name must be resolved to an IP address using either DNS or WINS. If the site DNS and WINS infrastructures never contain a record mapping the VPN router's name to the VPN router's public IP address, traffic to services running on the VPN router is always sent across the VPN connection.

To prevent a VPN router from dynamically registering the public IP address of its Internet interface in the site DNS, obtain properties of the Internet Protocol (TCP/IP) component of the Internet connection in Dial-up and Network Connections. Click Advanced. In the Advanced TCP/IP Settings dialog box, click the DNS tab, and then clear the Register this connection's addresses in DNS check box.

To prevent a VPN router from registering the public IP address of its Internet interface with site WINS servers, obtain properties of the Internet Protocol (TCP/IP) component of the Internet connection in the Dial-up and Network Connections folder. Click Advanced. In the Advanced TCP/IP Settings dialog box, click the WINS tab, and then click Disable NetBIOS over TCP/IP.

Design Points: Routing infrastructure

Consider the following when configuring the routing infrastructure for router-to-router VPN connections:

  • Configure the Internet interface of the VPN router with a default gateway. Do not configure the site interface of the VPN router with a default gateway.

  • Add static IP routes to the VPN router that summarize the addresses used in the site in which the VPN router is located. Alternately, if you use either RIP or OSPF as your dynamic routing protocol, configure and enable RIP or OSPF on the VPN router. If you use a routing protocol other than RIP or OSPF, such as Interior Gateway Routing Protocol (IGRP), configure the neighboring router for RIP or OSPF on the interface connected to the subnet containing the VPN router, and then configure IGRP on all other interfaces.

  • If the VPN router is hosting other services, ensure that the name of the VPN router is always resolved to the private or site IP address of the VPN router. To do this, disable DNS dynamic update and NetBIOS over TCP/IP on the Internet interface(s) of the VPN router.

  • Configure the VPN router with an on-subnet address range by obtaining IP addresses through DHCP or by manually configuring on-subnet address pools.

AAA Infrastructure

The authentication, authorization, and accounting (AAA) infrastructure exists to:

  • Authenticate the credentials of calling routers.

  • Authorize the VPN connection.

  • Record the VPN connection creation and termination for accounting purposes.

The AAA infrastructure consists of:

  • The answering router computer

  • RADIUS server computers

  • Domain controllers

As previously discussed, a Windows 2000 answering router can be configured with either Windows or RADIUS as its authentication or accounting provider. RADIUS provides a centralized AAA service when you have multiple answering routers and remote access VPN servers or a mix of heterogeneous dial-up and VPN equipment.

When you configure Windows as the authentication provider, the answering router performs the authentication of the VPN connection by communicating with a domain controller using a secure remote procedure call (RPC) channel and authorization of the connection attempt through the dial-in properties of the user account and locally configured remote access policies.

When you configure RADIUS as the authentication provider, the answering router relies on a RADIUS server to perform both the authentication and authorization. When a VPN connection is attempted, the calling router credentials and other connection parameters are sent by the answering router to the configured RADIUS server in a RADIUS Access-Request message. If the connection attempt is both authenticated and authorized, the RADIUS server sends back a RADIUS Access-Accept message. If the connection attempt is either not authenticated or not authorized, the RADIUS server sends back a RADIUS Access-Reject message.

When you configure Windows as the accounting provider, the answering router logs VPN connection information in a local log file (SystemRoot\System32\Logfiles\Logfile.log by default) based on settings on the Settings tab of the properties of the Local File object in the Remote Access Logging folder in the Routing and Remote Access snap-in. By default, all types of logging are disabled.

When you configure RADIUS as the authentication provider, the answering router sends RADIUS accounting messages for VPN connections on a RADIUS server, which records the accounting information.

If you are using RADIUS and a Windows domain as the user account database for which to verify user credentials and obtain dial-in properties, Microsoft recommends using the Windows 2000 Internet Authentication Service (IAS). IAS is a full-featured RADIUS server that is tightly integrated with Windows 2000, Active Directory, and the Routing and Remote Access service.

When IAS is used as the RADIUS server:

  • IAS performs the authentication of the VPN connection by communicating with a domain controller using a secure RPC channel. IAS performs authorization of the connection attempt through the dial-in properties of the user account and remote access policies configured on the IAS server.

  • IAS logs all RADIUS accounting information in a local log file (SystemRoot\System32\Logfiles\Logfile.log by default) based on settings configured on the properties of the Local File object in the Remote Access Logging folder in the Internet Authentication Service snap-in.

Remote access policies

Remote access policies are an ordered set of rules that define how connections are either accepted or rejected. For connections that are accepted, remote access policies can also define connection restrictions. For each rule, there are one or more conditions, a set of profile settings, and a remote access permission setting. Connection attempts are evaluated against the remote access policies in order, trying to determine whether the connection attempt matches all of the conditions of each policy. If the connection attempt does not match all of the conditions of any policy, the connection attempt is rejected.

If a connection matches all the conditions of a remote access policy and is granted remote access permission, the remote access policy profile specifies a set of connection restrictions. The dial-in properties of the user account also provide a set of restrictions. Where applicable, user account connection restrictions override the remote access policy profile connection restrictions.

Remote access policies consist of the following elements:

  • Conditions

  • Permission

  • Profile settings

Conditions
A remote access policy profile is a set of properties that are applied to a connection when it is authorized. For VPN connections, you can use the following profile settings:

  • NAS-Port-Type. By setting the NAS-Port-Type condition to Virtual (VPN), you can specify all VPN connections.

  • Tunnel-Type. By setting the Tunnel-Type to Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP), you can specify different policies for PPTP and L2TP connections.

  • Windows-Groups. By setting the Windows-Groups to the appropriate groups, you can specify connection parameters based on group membership.

Permission
You can use the permission setting to either grant to deny remote access for the connection attempt if the remote access permission of the user account is set to Control access through Remote Access Policy. Otherwise, the remote access permission setting on the user account determines the remote access permission.

Profile settings
Remote access policy conditions are one or more attributes that are compared to the settings of the connection attempt. If there are multiple conditions, then all of the conditions must match the settings of the connection attempt in order for it to match the policy. For VPN connections, you commonly use the following conditions:

  • Dial-in constraints can be used to define how long the connection can exist or be idle before being terminated by the answering router, among others.

  • Authentication settings can define which authentication protocols the calling router can use when sending its credentials and the configuration of EAP types, such as EAP-TLS.

  • Encryption settings can define whether encryption is required and the encryption strength. For encryption strengths, Windows 2000 supports Basic (40-bit MPPE for PPTP and 56-bit Data Encryption Standard [DES] for L2TP), Strong (56-bit MPPE for PPTP and 56-bit DES for L2TP), or Strongest (128-bit MPPE for PPTP and 3DES for L2TP). Strongest can be used only if the Windows 2000 High Encryption Pack or Service Pack 2 and later is installed.

For example, you can create a Windows 2000 group called VPNRouters whose members are the user accounts of all calling routers. Then, you create a policy with two conditions on the policy: NAS-Port-Type is set to Virtual (VPN) and Windows-Group is set to VPNRouters. Finally, you configure the profile for the policy to select a specific authentication method and encryption strength.

Note: IP packet filters on the IP tab of the profile settings of a remote access policy only apply to remote access VPN connections. They have no effect on demand-dial connections.

Windows domain user accounts and groups

Windows NT version 4.0 domains, Windows 2000 mixed-mode Active Directory domains, and Windows 2000 native-mode domains contain the user accounts and groups used by the Routing and Remote Access service and IAS to authenticate and authorize VPN connection attempts.

User accounts contain the user name and a form of the user's password that can be used for validation of the calling router's user credentials. Additional account properties determine whether the user account is enabled or disabled, locked out, or permitted to logon only during specific hours. If a user account is disabled, locked out, or not permitted to logon during the time of the VPN connection, the router-to-router VPN connection attempt is rejected. Additionally, if the user account of the calling router is configured to change the password at the next login, the router-to-router VPN connection attempt will fail because changing the password while attempting to make the connection is an interactive process. Demand-dial routers need to be able to make connections as needed without requiring human intervention. Therefore, all user accounts for calling routers must be configured with the User must change password at next logon checkbox cleared and the Password never expires checkbox selected for the account options on the Account tab on the properties of the user account. When you create dial-in accounts with the Demand-Dial Interface Wizard, these account settings are automatically configured.

You should use a separate user account for each site that contains a calling router. Each user account should have a name that matches a demand-dial interface configured on the answering router. When you create dial-in accounts with the Demand-Dial Interface Wizard, this one-to-one relationship between user accounts used by calling routers in separate sites and demand-dial interfaces is automatically maintained.

User accounts also contain dial-in settings. The dial-in setting most relevant for VPN connections is the remote access permission setting, which has the following values:

  • Allow access

  • Deny access

  • Control access through Remote Access Policy

The Allow access and Deny access settings explicitly allow or deny remote access and are equivalent to the remote access permission setting of Windows NT 4.0 domain accounts. When you use the Control access through Remote Access Policy setting, the remote access permission is determined by the remote access permission setting of the matching remote access policy. If the user account is in a mixed-mode domain, the Control access through Remote Access Policy setting is not available and you must manage remote access permission on a per-user basis. If the user account is in a native-mode domain, the Control access through Remote Access Policy setting is available and you can manage remote access permission on a per-user basis or using groups. When a dial-in account is created with the Demand-Dial Interface Wizard, the remote access permission is set to Allow access.

When using groups to manage access, you can use your existing groups and create remote access policies that either allow or reject access or restrict access based on the group name. For example, the Employees group has no VPN remote access restrictions, however, the Contractors group can only create VPN connections during business hours. Alternately, you can create groups based on the type of connection being made. For example, you can create a VPNRouters group and add as members all the user accounts allowed to create VPN connections.

Both the Routing and Remote Access service and IAS can use Active Directory universal principal names (UPNs) and universal groups. In a large domain with thousands of users, create a universal group for all of the users for whom you want to allow access, and then create a remote access policy that grants access for this universal group. Do not put all of your user accounts directly into the universal group, especially if you have a large number of them on your network. Instead, create separate global groups that are members of the universal group, and add users to those global groups.

One-way initiated connections and static routes on the user account
With one-way initiated connections, one router is always the answering router and one router is always the calling router. The answering router accepts the connection and the calling router initiates the connection. One-way initiated connections are well suited to a spoke-and-hub topology where the branch office router is the only router that initiates the connection.

To simplify configuration for one-way initiated connections, user accounts on stand-alone Windows 2000 servers or in a native-mode Active Directory domain support the configuration of static routes. The static routes are automatically added to the routing table of the VPN router when a VPN connection using the user account is made. If the VPN router is participating in dynamic routing for the site, the routes are propagated to the other routers in the site using routing protocols such as RIP and OSPF. Static routes on user accounts are configured by selecting the Apply static routes check box on the Dial-in tab on the properties of a user account, and then adding static routes.

To use static routes on the user account, configure the calling router normally. On the answering router, all you have to do is create a user account that is used by the calling router and configure static routes that correspond to the calling router's site. Because there is no demand-dial interface on the answering router with the same name as the user account of the calling router, the incoming VPN connection is determined to be a remote access connection. The static routes of the calling router's user account are added to the VPN router's routing table and all traffic to the locations implied by the static routes is sent across the logical remote access connection to the calling router.

Note: Static routes on the user account are only applied to the answering router when the incoming connection is a remote access VPN connection (the user account in the credentials of the calling router does not match the name of a demand-dial interface on the answering router). Static routes on the user account are not applied when the incoming connection is a demand-dial connection.

Design Points: AAA infrastructure

Consider the following when configuring the AAA infrastructure for router-to-router VPN connections:

  • If you have multiple VPN routers and you want to centralize AAA service or a heterogeneous mixture of dial-up and VPN equipment, use RADIUS servers and configure the VPN router for the RADIUS authentication and accounting providers.

  • If your user account database is a Windows domain, use IAS as your RADIUS server. If you use IAS, install IAS on a domain controller for best performance. Install at least two IAS servers for fail-over and fault tolerance of AAA services.

  • Whether configured locally or on an IAS server, use remote access policies to authorize VPN connections and specify connection constraints. For example, use the remote access policy profile settings to grant access based on group membership, to enforce the use of encryption and a specific encryption strength, or specify the use of EAP-TLS.

  • For a large Active Directory domain, nest global groups within universal groups to manage access based on group membership.

  • For one-way initiated connections, you can configure the calling router normally and configure the answering router with a user account that contains the static routes of the calling router's site.

  • Sensitive fields of RADIUS messages, such as the user password and encryption keys, are encrypted with the RADIUS shared secret configured on the VPN router and the RADIUS server. Make the shared secret a long (16 characters or longer), random sequence of letters, numbers, and punctuation and change it often to protect your RADIUS traffic. An example of a strong shared secret is 8d#>9fq4bV)H7%a3. To further protect RADIUS traffic, use Windows 2000 IPSec policies to provide data confidentiality for all traffic using the RADIUS UDP ports (1812 and 1645 for RADIUS authentication traffic and 1813 and 1646 for RADIUS accounting traffic).

Certificate infrastructure

To perform certificate-based authentication for L2TP connections and user certificate-based authentication for router-to-router VPN connections using EAP-TLS, a certificate infrastructure must be in place to issue the proper certificates to submit during the authentication process and to validate the certificate being submitted.

Computer certificates for L2TP/IPSec

If you manually configure the certificate authentication method for a rule of an IPSec policy in Windows 2000, you can specify the list of root certification authorities (CAs) from which a certificate is accepted for authentication. For L2TP connections, the IPSec rule for L2TP traffic is automatically configured and the list of root CAs is not configurable. Instead, each computer in the L2TP connection sends a list of root CAs to its IPSec peer from which it accepts a certificate for authentication. The root CAs in this list correspond to the root CAs that issued certificates that are stored in the computer certificate store. For example, if Computer A was issued computer certificates by root CAs CertAuth1 and CertAuth2, it notifies its IPSec peer during main mode negotiation that it will accept certificates for authentication from only CertAuth1 and CertAuth2. If the IPSec peer, Computer B, does not have a valid certificate in its computer certificate store issued from either CertAuth1 or CertAuth2, IPSec security negotiation fails.

Ensure one of the following before attempting an L2TP connection:

  1. Both the calling router and answering router were issued computer certificates from the same CA.

  2. Both the calling router and answering router were issued computer certificates from CAs that follow a valid certificate chain up to the same root CA.

In general, the calling router must have a valid computer certificate installed that was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the answering router trusts. Additionally, the answering router must have a valid computer certificate installed that was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the calling router trusts.

A single CA commonly issues computer certificates to all computers in an organization. Because of this, all computers within the organization both have computer certificates from a single CA and request certificates for authentication from the same single CA.

For information about installing computer certificates on VPN routers for L2TP connections, see "Deploying an L2TP-based Router-to-Router VPN Connection."

User and computer certificates for EAP-TLS authentication

To perform EAP-TLS authentication for a router-to-router VPN connection in Windows 2000:

  • The calling router must be configured to submit a user certificate during the EAP-TLS authentication process.

  • The authenticating server must be configured to submit a computer certificate during the EAP-TLS authentication process. The authenticating server is either the answering router (if the answering router is configured to use the Windows authentication provider) or a RADIUS server (if the answering router is configured to use the RADIUS authentication provider).

EAP-TLS authentication is successful when the following conditions are met:

  • The calling router submits a valid user certificate that was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the answering router trusts.

  • The authenticating server submits a valid computer certificate that was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the calling router trusts.

  • The user certificate of the calling router contains the Client Authentication certificate purpose (OID "1.3.6.1.5.5.7.3.2").

  • The computer certificate of the answering router contains the Server Authentication certificate purpose (OID "1.3.6.1.5.5.7.3.1").

For a Windows 2000 CA, a Router (Offline Request) certificate, a special type of user certificate for demand-dial connections, is created and mapped to an Active Directory user account. When the calling router attempts a VPN connection, the Router (Offline Request) certificate is sent during the connection negotiation process. If the Router (Offline Request) certificate is valid, it is used to determine the appropriate user account from which dial-in properties are obtained.

For information about configuring user and computer certificates for EAP-TLS authentication, see "Deploying a PPTP-based Router-to-Router VPN Connection" and "Deploying an L2TP-based Router-to-Router VPN Connection."

Design Points: Certificate infrastructure

Consider the following when configuring the certificate infrastructure for router-to-router VPN connections:

  • In order to create L2TP/IPSec router-to-router VPN connections using computer certificate authentication for IPSec, you must install a certificate in the computer certificate store of the calling router and the answering router.

  • In order to authenticate VPN connections using EAP-TLS, the calling router must have a user certificate installed and the authenticating server (either the answering router or the RADIUS server) must have a computer certificate installed.

  • To install a computer or user certificate on a computer across the Internet, make a PPTP connection using a password-based authentication protocol such as MS-CHAP v2. After connecting, use the Certificate Manager snap-in or Internet Explorer to request the appropriate certificates. Once the certificates are installed, disconnect and then reconnect with the appropriate VPN protocol and authentication method. An example of this situation is a computer at a remote branch office without the certificates needed to make L2TP/IPSec or EAP-TLS-authenticated connections.