Virtual Private Networks 2

  • November 2019
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Virtual Private Networks 2 as PDF for free.

More details

  • Words: 34,705
  • Pages: 87
Virtual private networks

Page 1 of 87

Virtual private networks The Routing and Remote Access service in Windows 2000 Server provides virtual private network (VPN) services for remote access and router-to-router VPN connections by using either the Point-to-Point Tunneling Protocol (PPTP) or the Layer Two Tunneling Protocol (L2TP) with Internet Protocol security (IPSec). z Before installing a VPN server, see Checklist: Installing and configuring a VPN server. z Before installing a PPTP server, see Checklist: Installing and configuring a PPTP server. z To find features that have been moved in Windows 2000 Server, see New ways to do familiar tasks. z For tips about using VPNs, see Best practices. z For general background information, see Concepts. z For problem-solving instructions, see Troubleshooting.

Checklists This section covers: z Checklist: Installing and configuring a VPN server z Checklist: Installing and configuring a PPTP server

Checklist: Installing and configuring a VPN server Step

Reference

c Review key concepts. d e f g

Virtual private networks overview

c Install the hardware. d e f g

Manufacturer's documentation

Verify the compatibility of all hardware to be installed in the

c computer running Windows 2000. d e f g

Verify that the hardware is successfully installed on

Microsoft Windows Hardware Compatibility List at the Microsoft Web site (http://www.microsoft.com/)

c Windows 2000. d e f g

Device Manager

c Install and configure the protocols. d e f g

Network communications

c Install the Routing and Remote Access service. d e f g

To enable the Routing and Remote Access service

c Configure the TCP/IP protocol. d e f g

TCP/IP and remote access

c Configure the number of PPTP and L2TP ports needed. d e f g

To add PPTP or L2TP ports

Configure PPTP and L2TP over IPSec filters on the Internet

c interface. d e f g

Configure dial-in properties and remote access policies for dial-in

c permission, authentication, and encryption settings. d e f g

(Optional) Configure the Windows 2000 remote access router as a

Manage packet filters Introduction to remote access policies

c RADIUS client. d e f g

To use RADIUS authentication

c (Optional) Configure the IPX protocol. d e f g

IPX and remote access

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 2 of 87

c (Optional) Configure the NetBEUI protocol. d e f g

NetBEUI and remote access

Checklist: Installing and configuring a PPTP server Step

Reference

c Review key concepts. d e f g

Virtual private networks overview

c Install the hardware. d e f g

Manufacturer's documentation

Verify the compatibility of all hardware to be installed in the

c computer running Windows 2000. d e f g

Verify that the hardware is successfully installed on

Microsoft Windows Hardware Compatibility List at the Microsoft Web site (http://www.microsoft.com/)

c Windows 2000. d e f g

Device Manager

c Install and configure the TCP/IP protocol. d e f g

Network communications

c Install the Routing and Remote Access service. d e f g

To enable the Routing and Remote Access service

c Configure the number of PPTP ports needed. d e f g

To add PPTP or L2TP ports

c Configure PPTP filters on the Internet interface. d e f g

Add PPTP filters

Configure dial-in properties and remote access policies for dial-in

c permission, authentication, and encryption settings. d e f g

Introduction to remote access policies

Note z The Point-to-Point Tunneling Protocol is automatically installed.

New ways to do familiar tasks The following table lists common tasks for configuring virtual private networks in Windows 2000. The user interface for performing these tasks is different in Windows 2000 than it was in Windows NT version 4.0 and Windows NT version 4.0 with the Routing and Remote Access Service (RRAS).

If you want to

In Windows NT 4.0 use

In Windows NT 4.0 with RRAS use

In Windows 2000 use

Install the Pointto-Point Tunneling Protocol (PPTP)

Protocols tab of Network in Control Panel

Protocols tab of Network in Control Panel

PPTP is automatically installed

Set the maximum number of PPTP connections

Protocols tab of Network in Control Panel

Protocols tab of Network in Control Panel

Properties of Ports in Routing and Remote Access

Set PPTP packet filtering

The Advanced IP Addressing dialog box from the properties of the TCP/IP protocol (Protocols tab of Network in Control Panel)

Properties of the IP interface in Summary under IP Routing in Routing and RAS Admin

Properties of the IP interface in General under IP Routing in Routing and Remote Access

Best practices The following list provides best practices for implementing and configuring VPNs and is based on recommendations from Microsoft Product Support Services:

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 3 of 87

z Use DHCP to obtain IP addresses

If you installed a DHCP server, configure the VPN server to use DHCP to obtain IP addresses for VPN clients. If you did not install a DHCP server and you have a single subnet, configure the VPN server with a static IP address pool that is a subset of addresses for the subnet to which the VPN server is attached. For more information, see To create a static IP address pool. If you did not install a DHCP server and you have multiple subnets and a routed infrastructure, configure the VPN server with a static IP address pool that consist of ranges of addresses that are a separate subnet from the subnet to which the VPN server is attached. Then, either add the static routes that represent the address ranges to the routing tables of neighboring routers or enable the routing protocol of your routed infrastructure on the VPN server. For more information, see To create a static IP address pool. z Use strong authentication z Use strong passwords more than 8 characters long that contain a mixture of uppercase and lowercase

letters, numbers, and permitted punctuation. Do not use passwords based on names or words. Strong passwords are more resistant to a dictionary attack, where an unauthorized user attempts to crack a password by sending a series of commonly used names and words. z Although EAP-TLS works with registry-based certificates, it is highly recommended that you only use EAP-TLS with smart cards for remote access VPN connections. z If you are using MS-CHAP, use MS-CHAP version 2. You can obtain the latest MS-CHAP updates for Windows NT version 4.0, Windows 98, and Windows 95 VPN clients from Microsoft. For more information, see MS-CHAP version 2. z Use strong encryption Use the strongest level of encryption that your situation allows. For VPN connections within North America, use strong or strongest encryption. For VPN connections outside of North America, use basic encryption. Strongest encryption is only available on North American versions of Windows 2000. z Use automatic allocation for IPX network IDs

Configure the VPN server to automatically allocate the same IPX network ID to all VPN clients.

Concepts This section provides general background information about virtual private networking with the Windows 2000 remote access router: z z z z

Virtual private networks overview Understanding virtual private networks Using virtual private networks Resources

Virtual private networks overview This section covers: z z z z

Virtual private networks VPN connections Types of virtual private networks New features of virtual private networks for Windows 2000

Virtual private networks A virtual private network (VPN) is the extension of a private network that encompasses links across shared or public networks like the Internet. With a VPN, you can send data between two computers across a shared or public network in a manner that emulates a point-to-point private link. Virtual private networking is the act of creating and configuring a virtual private network.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 4 of 87

To emulate a point-to-point link, data is encapsulated, or wrapped, with a header that provides routing information, which allows the data to traverse the shared or public network to reach its endpoint. To emulate a private link, the data is encrypted for confidentiality. Packets that are intercepted on the shared or public network are indecipherable without the encryption keys. The link in which the private data is encapsulated and encrypted is a virtual private network (VPN) connection. The following illustration shows the logical equivalent of a VPN connection.

Users working at home or on the road can use VPN connections to establish a remote access connection to an organization server by using the infrastructure provided by a public network such as the Internet. From the user's perspective, the VPN is a point-to-point connection between the computer (the VPN client) and an organization server (the VPN server). The exact infrastructure of the shared or public network is irrelevant because it appears logically as if the data is sent over a dedicated private link. Organizations can also use VPN connections to establish routed connections with geographically separate offices or with other organizations over a public network such as the Internet while maintaining secure communications. A routed VPN connection across the Internet logically operates as a dedicated WAN link. With both remote access and routed connections, an organization can use VPN connections to trade long-distance dial-up or leased lines for local dial-up or leased lines to an Internet service provider (ISP). There are two types of VPN technology in Windows 2000: 1.

Point-to-Point Tunneling Protocol (PPTP) PPTP uses user-level Point-to-Point Protocol (PPP) authentication methods and Microsoft Point-to-Point Encryption (MPPE) for data encryption.

2.

Layer Two Tunneling Protocol (L2TP) with Internet Protocol security (IPSec) L2TP uses user-level PPP authentication methods and machine-level certificates with IPSec for data encryption.

VPN connections Creating a VPN connection is very similar to establishing a point-to-point connection by using dial-up connections

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 5 of 87

and demand-dial routing. There are two types of VPN connections: z Remote access VPN connection z Router-to-router VPN connection

Remote access VPN connection A remote access client (a single user computer) makes a remote access VPN connection that connects to a private network. The VPN server provides access to the resources of the VPN server or to the entire network to which the VPN server is attached. The packets sent from the remote client across the VPN connection originate at the remote access client computer. The remote access client (the VPN client) authenticates itself to the remote access server (the VPN server) and, for mutual authentication, the server authenticates itself to the client. Computers running Windows 2000, Windows NT version 4.0, Windows 95, and Windows 98 can create remote access VPN connections to a VPN server running Windows 2000. VPN clients may also be any non-Microsoft Pointto-Point Tunneling Protocol (PPTP) client or Layer Two Tunneling Protocol (L2TP) client with IPSec.

Router-to-router VPN connection A router makes a router-to-router VPN connection that connects two portions of a private network. The VPN server provides a routed connection to the network to which the VPN server is attached. On a router-to-router VPN connection, the packets sent from either router across the VPN connection typically do not originate at the routers. The calling router (the VPN client) authenticates itself to the answering router (the VPN server) and, for mutual authentication, the answering router authenticates itself to the calling router. Computers running Windows 2000 Server and Windows NT Server 4.0 with the Routing and Remote Access Service (RRAS) can create router-to-router VPN connections. VPN clients may also be any non-Microsoft Point-toPoint Tunneling Protocol (PPTP) client or Layer Two Tunneling Protocol (L2TP) client with IPSec. For information about creating router connections by using IPSec Encapsulating Security Payload (ESP) tunnel mode, see the Windows 2000 Resource Kit.

Types of virtual private networks You can use VPN connections whenever you need a secure point-to-point connection to connect users or networks. Typical VPN connections are either Internet-based or intranet-based. This section covers: z Internet-based VPNs z Intranet-based VPNs

Internet-based VPNs By using an Internet-based VPN connection, you can avoid long-distance and 1-800 telephone charges while taking advantage of the global availability of the Internet.

Remote access over the Internet Rather than making a long distance or 1-800 call to a corporate or outsourced network access server (NAS), a remote access client can call a local ISP. By using the established physical connection to the local ISP, the remote access client initiates a VPN connection across the Internet to the organization's VPN server. Once the VPN connection is created, the remote access client can access the resources of the private intranet. The following illustration shows remote access over the Internet.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 6 of 87

Connecting networks over the Internet When networks are connected over the Internet, a router forwards packets to another router across a VPN connection. To the routers, the VPN operates as a data-link layer link. The following illustration shows connecting networks over the Internet.

Using dedicated WAN links Rather than using an expensive long-distance dedicated WAN link between branch offices, the branch office routers are connected to the Internet by using local dedicated WAN links to a local ISP. A router-to-router VPN connection is then initiated by either router across the Internet. Once connected, routers can forward directed or routing protocol traffic to each other by using the VPN connection.

Using dial-up WAN links Rather than making a long distance or 1-800 call to a corporate or outsourced NAS, a branch office router can call a local ISP. By using the established connection to the local ISP, a router-to-router VPN connection is initiated by the branch office router to the corporate office router across the Internet. The corporate office router acts as a VPN server and must be connected to a local ISP by using a dedicated WAN link. It is possible to have both the corporate office and the branch office connected to the Internet by using a dial-up WAN link. However, this is only feasible if the ISP supports demand-dialing routing to customers—the ISP calls the customer router when an IP datagram is to be delivered to the customer. Demand-dial routing to customers is not widely supported by ISPs.

Intranet-based VPNs

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 7 of 87

The intranet-based VPN connection takes advantage of IP connectivity in an organization intranet.

Remote access over an intranet In some organization intranets, the data of a department, such as a human resources department, is so sensitive that the department's network is physically disconnected from the rest of the organization's intranet. While this protects the department's data, it creates information accessibility problems for those users who are not physically connected to the separate network. With a VPN connection, the department's network is physically connected to the organization intranet but separated by a VPN server. The VPN server does not provide a direct routed connection between the organization intranet and the department's network. Users on the organization intranet with the appropriate permissions can establish a remote access VPN connection with the VPN server and access the protected resources of the sensitive department's network. Additionally, all communication across the VPN connection is encrypted for data confidentiality. For those users who do not have permissions to establish a VPN connection, the department's network is hidden from view. The following illustration shows remote access over an intranet.

Connecting networks over an intranet You can also connect two networks over an intranet by using a router-to-router VPN connection. Organizations with departments in separate locations, whose data is highly sensitive, may use a router-to-router VPN connection to communicate with each other. For example, the finance department might need to communicate with the human resources department to exchange payroll information. The finance department and the human resources department are connected to the common intranet with computers that can act as VPN clients or VPN servers. Once the VPN connection is established, users on computers on either network can exchange sensitive data across the corporate intranet. The following illustration shows connecting networks over an intranet.

New features of virtual private networks for Windows 2000

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 8 of 87

Windows 2000 provides the following new features for virtual private networks: z Layer Two Tunneling Protocol

In addition to the Point-to-Point Tunneling Protocol (PPTP), Windows 2000 includes the industry standard Layer Two Tunneling Protocol (L2TP), which is used in conjunction with Windows 2000 Internet Protocol security (IPSec) to create secure virtual private network connections. z Remote access policies

Remote access policies are a set of conditions and connection settings that allow network administrators more flexibility in setting remote access permissions and connection attributes. With remote access policies, you can force the use of strong authentication and encryption for VPN users and a different set of authentication and encryption constraints for dial-up users. For more information, see Remote access policies. z MS-CHAP version 2

The Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 2 significantly strengthens the security for the passing of security credentials and the generation of encryption keys during the negotiation of a remote access connection. MS-CHAP version 2 was specifically designed for authenticating virtual private network connections. For more information, see MS-CHAP version 2. z Extensible Authentication Protocol

The Extensible Authentication Protocol (EAP) allows new authentication methods to be used with remote access, a feature that is especially important for the deployment of security based on smart cards. EAP is the interface that allows other authentication modules to plug into the Windows 2000 remote access PPP implementation. Windows 2000 supports EAP-MD5 CHAP, EAP-TLS (used for smart card and certificate-based authentication), and the passing of EAP messages to a RADIUS server. For more information, see EAP. z Account lockout

Account lockout is a security feature that denies access after a configured number of failed authentication attempts. Account lockout is designed to help prevent dictionary attacks. A dictionary attack is when an unauthorized user attempts to log on by using a known user name and a list of common words as the password. Account lockout is disabled by default. For more information, see Account lockout.

Understanding virtual private networks This section covers: z z z z z

Components of virtual private networks Properties of VPN connections VPN tunneling protocols VPN security An on-demand router-to-router VPN

Components of virtual private networks

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 9 of 87

A Windows 2000 VPN connection includes the following components: z VPN server

A computer that accepts VPN connections from VPN clients. z VPN client

A computer that initiates a VPN connection to a VPN server. A VPN client can be an individual computer or a router. z Tunnel

The portion of the connection in which your data is encapsulated. z VPN connection

The portion of the connection in which your data is encrypted. For typical secure VPN connections, the data is encrypted and encapsulated along the same portion of the connection. Note z It is possible to create a tunnel and send the data through the tunnel without encryption. This is not a VPN

connection because the private data is sent across a shared or public network in an unencrypted and easily readable form. z Tunneling protocols Protocols that are used to manage tunnels and encapsulate private data. Data that is tunneled must also be encrypted to be a VPN connection. Windows 2000 includes the PPTP and L2TP tunneling protocols. For more information, see Point-to-Point Tunneling Protocol and Layer Two Tunneling Protocol. z Tunneled data

Data that is usually sent across a private point-to-point link. z Transit internetwork

The shared or public network crossed by the encapsulated data. For Windows 2000, the transit internetwork is always an IP internetwork. The transit internetwork can be the Internet or a private IP-based intranet. The following illustration shows the components of a virtual private network.

Note z Typically, the tunnel and the VPN connection are along the same portion of the connection. However, there are

implementations known as compulsory tunneling where the tunnel (the encapsulation) and the VPN connection

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 10 of 87

(the encryption) are not defined along the same portion of the connection.

Properties of VPN connections VPN connections that use PPTP and L2TP over IPSec have the following properties: z Encapsulation z Authentication z Data encryption

Encapsulation With VPN technology, private data is encapsulated with a header that provides routing information, which allows the data to traverse the transit internetwork. For examples of encapsulation, see VPN tunneling protocols.

Authentication Authentication for VPN connections takes three different forms: 1.

User-level authentication by using PPP authentication To establish the VPN connection, the VPN server authenticates the VPN client that is attempting the connection by using a Point-to-Point Protocol (PPP) user-level authentication method and verifies that the VPN client has the appropriate permissions. If mutual authentication is used, the VPN client also authenticates the VPN server, which provides protection against masquerading VPN servers.

2.

Machine-level authentication by using ISAKMP To establish an IPSec security association, the VPN client and the VPN server use machine certificates and the Internet Security Association and Key Management Protocol (ISAKMP) and the Oakley key generation protocol. For more information, see IPSec security negotiation.

3.

Data authentication and integrity To verify that the data sent on the VPN connection originated at the other end of the connection and was not modified in transit, the data contains a cryptographic checksum based on an encryption key known only to the sender and the receiver. Data authentication and integrity are only available for L2TP over IPSec connections.

Data encryption To ensure confidentiality of the data as it traverses the shared or public transit internetwork, the data is encrypted by the sender and decrypted by the receiver. The encryption and decryption processes depend on both the sender and the receiver using a common encryption key. Intercepted packets sent along the VPN connection in the transit internetwork are unintelligible to anyone who does not have the common encryption key. The length of the encryption key is an important security parameter. You can use computational techniques to determine the encryption key. However, such techniques require more computing power and computational time as the encryption keys get larger. Therefore, it is important to use the largest possible key size to ensure data confidentiality.

VPN tunneling protocols This section covers:

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 11 of 87

z Point-to-Point Tunneling Protocol z Layer Two Tunneling Protocol

Point-to-Point Tunneling Protocol The Point-to-Point Tunneling Protocol (PPTP) is a de facto industry standard tunneling protocol first supported in Windows NT 4.0. PPTP is an extension of the Point-to-Point Protocol (PPP) and leverages the authentication, compression, and encryption mechanisms of PPP. PPTP is installed with the Routing and Remote Access service. By default, PPTP is configured for five PPTP ports. You can enable PPTP ports for inbound remote access and demand-dial routing connections by using the Routing and Remote Access wizard. To enable PPTP ports for routing after the wizard is run, see To enable routing on ports. PPTP and Microsoft Point-to-Point Encryption (MPPE) provide the primary VPN services of encapsulation and encryption of private data.

Encapsulation A PPP frame (an IP datagram, an IPX datagram, or a NetBEUI frame) is wrapped with a Generic Routing Encapsulation (GRE) header and an IP header. In the IP header is the source and destination IP address that correspond to the VPN client and VPN server. The following illustration shows PPTP encapsulation for a PPP frame.

Encryption The PPP frame is encrypted with Microsoft Point-to-Point Encryption (MPPE) by using encryption keys generated from the MS-CHAP or EAP-TLS authentication process. Virtual private networking clients must use either the MS-CHAP or EAP-TLS authentication protocol in order for the payloads of PPP frames to be encrypted. PPTP is taking advantage of the underlying PPP encryption and encapsulating a previously encrypted PPP frame. Note z It is possible to have a nonencrypted PPTP connection where the PPP frame is sent in plaintext. However, a

nonencrypted PPTP connection is not recommended for virtual private network connections over the Internet because communications of this type are not secure.

Layer Two Tunneling Protocol The Layer Two Tunneling Protocol (L2TP) is an RFC-based tunneling protocol destined to become the industry standard. Unlike PPTP, L2TP in Windows 2000 does not utilize Microsoft Point-to-Point Encryption (MPPE) to encrypt PPP datagrams. L2TP relies on Internet Protocol security (IPSec) for encryption services. The combination

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 12 of 87

of L2TP and IPSec is known as L2TP over IPSec. The result is that L2TP-based virtual private networking connections are a combination of L2TP and IPSec. Both L2TP and IPSec must be supported by both the VPN client and the VPN server. For more information about IPSec, see IP Security overview. L2TP is installed with the Routing and Remote Access service. By default, L2TP is configured for five L2TP ports. You can enable L2TP ports for inbound remote access and demand-dial routing connections by using the Routing and Remote Access wizard. To enable PPTP ports for routing after the wizard is run, see To enable routing on ports. L2TP over IPSec provides the primary VPN services of encapsulation and encryption of private data.

Encapsulation Encapsulation for L2TP over IPSec packets consists of two layers: 1.

L2TP encapsulation A PPP frame (an IP datagram, an IPX datagram, or a NetBEUI frame) is wrapped with a L2TP header and a UDP header.

2.

IPSec encapsulation The resulting L2TP message is then wrapped with an IPSec Encapsulating Security Payload (ESP) header and trailer, an IPSec Authentication trailer that provides message integrity and authentication, and a final IP header. In the IP header is the source and destination IP address that corresponds to the VPN client and VPN server.

The following illustration shows L2TP and IPSec encapsulation for a PPP datagram.

Encryption The L2TP message is encrypted with IPSec encryption mechanisms by using encryption keys generated from the

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 13 of 87

IPSec authentication process. Note z It is possible to have a non-IPSec-based (nonencrypted) L2TP connection where the PPP frame is sent in

plaintext. However, a nonencrypted L2TP connection is not recommended for virtual private network connections over the Internet because communications of this type are not secure.

VPN security This section covers: z z z z

Authorization Authentication Data encryption Packet filtering

Authorization VPN connections are only created for those users and routers that have been authorized. For Windows 2000, authorization of VPN connections is determined by the dial-in properties on the user account and remote access policies. For more information, see Remote access policies. You do not need to create user accounts just for VPN connections. VPN servers use the user accounts specified in the available user accounts databases according to Windows 2000 security.

How security works at connection The following steps describe what happens during a connection attempt from a PPTP-based VPN client to a PPTPbased VPN server running Windows 2000: 1. 2. 3. 4. 5.

The VPN client creates a PPTP tunnel with the VPN server. The server sends a challenge to the client. The client sends an encrypted response to the server. The server checks the response against the user accounts database. If the account is valid and has remote access permission, the server accepts the connection subject to the remote access policies and user account properties for the VPN client.

Note z Steps 2 through 4 assume that the VPN client and the VPN server use the MS-CHAP v1 or CHAP authentication

protocols. The sending of client credentials may vary for other authentication protocols. The following steps describe what happens during a connection attempt from a L2TP over IPSec-based VPN client to a L2TP over IPSec-based VPN server running Windows 2000: 1. 2. 3. 4. 5. 6.

The IPSec security association is created by using machine certificates and the Internet Security Association and Key Management Protocol (ISAKMP) and the Oakley key generation protocol. The VPN client creates a L2TP tunnel with the VPN server. The server sends a challenge to the client. The client sends an encrypted response to the server. The server checks the response against the user accounts database. If the account is valid and has remote access permission, the server accepts the connection subject to the remote access policies and user account properties for the VPN client.

Note z Steps 3 through 5 assume that the VPN client and the VPN server use the MS-CHAP v1 or CHAP authentication

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 14 of 87

protocols. The sending of client credentials may vary for other authentication protocols.

Security after the connection is made After passing authorization and authentication and connecting to the LAN, VPN clients for remote access VPN connections can only access network resources for which they have permission. Remote access VPN clients are subject to Windows 2000 security, just as they are at the office. In other words, remote access VPN clients cannot do anything for which they lack sufficient rights, nor can they access resources for which they do not have permission. The remote access server must authenticate the remote access VPN clients before they can access or generate traffic on the network. This authentication is a separate step from logging on to Windows 2000. You can restrict access by remote access VPN clients to only the shared resources of the VPN server and not the network to which the VPN server is attached. Therefore, an administrator can tightly control what information is available to remote access VPN clients and limit clients' exposure in the event of a security breach. Additionally, you can restrict access to intranet resources for IP traffic through the use of packet filters based on a remote access policy profile. With profile packet filters, you can configure the IP traffic that is allowed out of the connection (output filters) or into the connection (input filters) on an exception basis: either all traffic except traffic specified by the filters or no traffic except traffic specified by the filters. Remote access policy profile filtering applies to all connections that match the remote access policy. For more information, see Elements of a remote access policy.

Authentication The authentication of VPN clients by the VPN server is a vital security concern. Authentication takes place at two levels: 1.

Machine-level authentication When Internet Protocol security (IPSec) is used for a L2TP over IPSec VPN connection, machine-level authentication is performed through the exchange of machine certificates during the establishment of the IPSec security association. For more information, see IPSec security negotiation.

2.

User-level authentication Before data can be sent over the PPTP or L2TP tunnel, the user or demand-dial router that requests the VPN connection must be authenticated. User-level authentication occurs through the use of a Point-to-Point Protocol (PPP) authentication method. For more information, see Authentication methods.

Data encryption You must use data encryption to protect the data that is sent between the VPN client and the VPN server or the shared or public network, where there is always a risk of unauthorized interception. You can configure the VPN server to force encrypted communications. Users who connect to that server must encrypt their data or a connection is not allowed. For VPN connections, Windows 2000 uses Microsoft Point-to-Point Encryption (MPPE) with the Point-to-Point Tunneling Protocol (PPTP) and Internet Protocol security (IPSec) encryption with the Layer Two Tunneling Protocol (L2TP). Because data encryption is performed between the VPN client and VPN server, data encryption is not necessary on the communication link between a dial-up client and its Internet service provider (ISP). For example, a mobile user uses a dial-up connection to dial in to a local ISP. Once the Internet connection is made, the user creates a VPN connection with the corporate VPN server. If the VPN connection is encrypted, encryption is not needed on the dial-up connection between the user and the ISP. Notes

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 15 of 87

z Data encryption for PPP or PPTP connections is available only if you use MS-CHAP (version 1 or version 2) or

EAP-TLS as the user-level authentication method. Data encryption for L2TP connections relies on IPSec machine-level authentication, which does not require any specific user-level authentication method. z VPN data encryption does not provide end-to-end data encryption. End-to-end encryption is data encryption between the client application and the server hosting the resource or service that is accessed by the client application. To get end-to-end data encryption, you can use IPSec to create a secure connection after the VPN connection is made.

Packet filtering To secure the VPN server from sending or receiving any traffic on its Internet interface except VPN traffic, you need to configure PPTP or L2TP over IPSec input and output filters on the interface that corresponds to the connection to the Internet. For router-to-router VPN connections, you must also configure the calling router (the VPN client) with PPTP or L2TP over IPSec packet filters. Because, by default, IP routing is enabled on intranet interfaces and the interface that corresponds to the connection to the Internet, the computer running Windows 2000 forwards IP packets between the Internet and your intranet. This provides a direct, routed connection between your intranet and possible malicious users on the Internet. To protect your intranet so that the only traffic that is forwarded to the intranet is the traffic that is sent and received over secure VPN connections, you must configure PPTP or L2TP over IPSec filters on the Internet interface. For more information about PPTP filters, see Add PPTP filters. For more information about L2TP over IPSec filters, see Add L2TP over IPSec filters.

An on-demand router-to-router VPN A router-to-router VPN connection is typically used to connect remote offices together when both routers are connected to the Internet through permanent WAN links, such as T1 or Frame Relay. In this configuration, the VPN connection is persistent (available 24 hours a day). However, when a permanent WAN link is not possible or practical, you can configure an on-demand router-to-router VPN connection. The following illustration shows an on-demand router-to-router VPN connection.

An on-demand router-to-router VPN connection consists of two demand-dial interfaces and two static routes that are configured on the VPN client (the calling router): 1. 2. 3. 4.

A A A A

demand-dial interface to dial in to a local Internet service provider (ISP). demand-dial interface for the router-to-router VPN connection. static host route to dynamically connect to the Internet. static route to reach the locations of the corporate office.

An on-demand router-to-router VPN connection is automatically established when you route traffic to a specific location. For example, in a branch office configuration, when a packet is received to be routed to the corporate

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 16 of 87

office, the branch office router uses a dial-up link to connect to a local Internet service provider (ISP) and then creates a router-to-router VPN connection with the corporate office router located on the Internet. Note z This discussion assumes that the corporate office router (the answering router) is connected to the Internet by

using a permanent WAN link. It is possible to have both routers connected to the Internet by using a dial-up WAN link. However, this is only feasible if the ISP supports demand-dialing routing to customers; the ISP calls the customer router when an IP datagram is to be delivered to the customer. Demand-dial routing to customers is not widely supported by ISPs. To configure an on-demand router-to-router VPN connection at the branch office router, do the following: 1. 2.

3. 4.

Create a demand-dial interface for the Internet connection that is configured for the appropriate equipment (a modem or ISDN device), the phone number of the local ISP, and the user name and password to gain Internet access. Create a demand-dial interface for the VPN connection with the corporate office router that is configured for a VPN port (a PPTP or L2TP port), the IP address of the interface on the Internet for the corporate office router, and a user name and password that can be verified by the VPN server. The user name must match the name of a demand-dial interface on the corporate office router. Create a static host route to the corporate office router that uses the ISP demand-dial interface. Create a static route (or routes) for the IP network IDs of the corporate intranet that uses the VPN demand-dial interface.

To configure the corporate office router, do the following: 1. 2.

Create a demand-dial interface for the VPN connection with the branch office that is configured for a VPN device (a PPTP or L2TP port). The demand-dial interface must have the same name as the user name in the authentication credential that is used by the branch office router to create the VPN connection. Create a static route (or routes) for the IP network IDs of the branch office that uses the VPN demand-dial interface.

The router-to-router VPN connection is automatically initiated by the branch office router through the following process: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

Packets sent to a corporate hub network location from a computer in the branch office are forwarded to the branch office router. The branch office router checks its routing table and finds a route to the corporate intranet network ID, which uses the VPN demand-dial interface. The branch office router checks the state of the VPN demand-dial interface and finds it is in a disconnected state. The branch office router retrieves the configuration of the VPN demand-dial interface. Based on the VPN demand-dial interface configuration, the branch office router attempts to initialize a router-to-router VPN connection at the IP address of the corporate office router on the Internet. To establish a VPN, either a TCP (by using PPTP) or UDP (by using L2TP over IPSec) packet must be sent to corporate office router that acts as the VPN server. The VPN establishment packet is created. To forward the VPN establishment packet to the corporate office router, the branch office router checks its routing table and finds the host route is using the ISP demand-dial interface. The branch office router checks the state of the ISP demand-dial interface and finds it is in a disconnected state. The branch office router retrieves the configuration of the ISP demand-dial interface. Based on the ISP demand-dial interface configuration, the branch office router uses its modem to dial and establish a connection with its local ISP. Once the ISP connection is made, the VPN establishment packet is sent to the corporate office router. A router-to-router VPN connection is negotiated between the branch office router and the corporate office router. As part of the negotiation, the branch office router sends authentication credentials that are verified by the corporate office router. The corporate office router checks its demand-dial interfaces and finds one that matches the user name sent during authentication and changes the interface to a connected state. The branch office router forwards the routed packet across the VPN and the corporate office router forwards the packet to the appropriate intranet location. When the intranet location responds to the packet sent to it by the user in the branch office, the packet is forwarded to the corporate office router.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

16. 17. 18. 19.

Page 17 of 87

The corporate office router checks its routing table and finds a route to the branch office network that uses the VPN demand-dial interface. The corporate office router checks the state of the VPN demand-dial interface and finds it is in a connected state. The response packet is forwarded across the Internet by using the VPN connection. The response packet is received by the branch office router and is forwarded to the original user.

Using virtual private networks This section covers: z Installing the Windows 2000 remote access router z Deploying virtual private networks z Virtual private network scenarios

Installing the Windows 2000 remote access router A computer running Windows 2000 Server configured as a VPN server is a remote access router, providing both remote access and routing services to VPN clients. To install and configure the Windows 2000 remote access router, you must be logged on as a member of the Administrators group.

Hardware requirements Before you install the Windows 2000 remote access router, all hardware needs to be installed and working. Depending on your network and requirements, you might need the following hardware: z z z z z

A LAN or WAN adapter with a certified Network Driver Interface Specification (NDIS) driver One or more compatible modems and an available COM port A multiport adapter for acceptable performance with multiple remote connections An X.25 smart card (if you are using an X.25 network) An ISDN adapter (if you are using an ISDN line)

To verify the compatibility of all hardware in a computer running Windows 2000 Server, see the Microsoft Windows Hardware Compatibility List on the Microsoft Web site (http://www.microsoft.com/)

Installation The Windows 2000 Routing and Remote Access service is automatically installed when you install Windows 2000 Server. However, the Routing and Remote Access service is installed in a disabled state. For more information, see To enable the Routing and Remote Access service

Deploying virtual private networks This section covers: z Setting up remote access VPNs z Setting up router-to-router VPNs z Setting up certificate-based authentication for VPN connections

Setting up remote access VPNs This section covers: z Remote access VPN design considerations z Remote access VPN security z Deploying remote access VPNs

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 18 of 87

Remote access VPN design considerations To prevent problems, you should consider the following design issues before you implement remote access VPN connections.

Installing certificates In order to create L2TP over IPSec remote access VPN connections, you must install machine certificates on the VPN client and the VPN server. For more information, see Machine certificates for L2TP over IPSec VPN connections.

Increasing the number of PPTP or L2TP ports The default number of PPTP and L2TP ports is five. For multiple remote access VPN clients, five ports may not be enough. To increase the number of PPTP and L2TP ports, see To add PPTP or L2TP ports.

Creating a remote access policy for remote access VPN connections By using remote access policies, you can create a policy that requires remote access VPN connections to use a specific authentication method and encryption strength. For example, you can create a Windows 2000 group called VPN Users whose members are the user accounts of the users creating remote access VPN connections across the Internet. 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 VPN Users. Finally, you configure the profile for the policy to select a specific authentication method and encryption strength. For more information, see Introduction to remote access policies.

Using an IAS server If you have multiple VPN servers running Windows 2000, you need to configure remote access policies and logging for each VPN server. If you want to take advantage of centralized remote access policies and logging, you can configure the VPN servers as Remote Authentication Dial-In User Service (RADIUS) clients to a single computer (a RADIUS server) running Windows 2000 and the Internet Authentication Service (IAS). You should also use an IAS server if you have VPN servers running Windows NT 4.0 with the Routing and Remote Access Service (RRAS) and you want to take advantage Windows 2000 remote access policies. You cannot configure VPN servers running Windows NT 4.0 as RADIUS clients. You must upgrade a VPN server running Windows NT 4.0 to a VPN server running Windows NT 4.0 and RRAS. For more information, see Using RADIUS for multiple remote access servers.

Using Connection Manager For a large remote access VPN deployment, you can use Connection Manager and the Connection Manager Administration Kit to provide a custom dialer with preconfigured VPN connections to all remote access clients across your organization. For more information about Connection Manager, see Connection Manager Administration Kit. For information about implementing VPN support with the Connection Manager Administration Kit, see Implementing VPN support.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 19 of 87

Remote access VPN security You can enhance remote access VPN security through: z z z z

Strong authentication Data encryption PPTP or L2TP over IPSec packet filtering Remote access policy profile packet filtering

Strong authentication For authentication, use the strongest authentication scheme that is possible for your remote access VPN configuration. The strongest authentication scheme is the use of EAP-TLS with certificates. For more information, see Setting up certificate-based authentication for VPN connections. Otherwise, use MS-CHAP version 2 authentication and enforce the use of strong passwords on your network. For more information, see MS-CHAP version 2.

Data encryption For encryption, you can use either link encryption or end-to-end encryption: z Link encryption encrypts the data only on the link between the VPN client and the VPN server. You can use

strong encryption if your locations are within North America. For PPTP connections, you must use Microsoft Point-to-Point Encryption (MPPE) in conjunction with either MS-CHAP or EAP-TLS authentication. For L2TP over Internet Protocol security (IPSec) connections, IPSec provides encryption on the link between the VPN client and the VPN server. z End-to-end encryption encrypts the data between the source host and its final destination. You can use IPSec after the VPN connection is made to encrypt data from the source host to the destination host. To require encryption, clear the No encryption option and select the appropriate encryption strengths on the Encryption tab of the remote access policy profile that is used by your remote access VPN clients. For more information, see To configure encryption.

PPTP or L2TP over IPSec filtering To secure the VPN server from sending or receiving any traffic on its Internet interface except VPN traffic, you need to configure PPTP or L2TP over IPSec input and output filters on the interface that corresponds to the connection to the Internet. For more information about PPTP filters, see Add PPTP Filters. For more information about L2TP over IPSec filters, see Add L2TP over IPSec Filters. Because IP routing is enabled on the Internet interface, if PPTP or L2TP over IPSec filters are not configured on the Internet interface, then any traffic received on the Internet interface is routed, which may forward unwanted Internet traffic to your intranet.

Remote access policy profile packet filtering To define the specific types of IP traffic that are allowed into and out of the VPN connection, you need to configure IP packet filters on the profile for the remote access policy that is used for your remote access VPN connections. With profile packet filters, you can configure the IP traffic that is allowed out of the connection (output filters) or into the connection (input filters) on an exception basis: either all traffic except traffic specified by filters or no traffic except traffic specified by filters. Remote access policy profile filtering applies to all connections that match the remote access policy. For more information, see To configure IP options.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 20 of 87

Deploying remote access VPNs This section covers: z PPTP-based remote access VPN z L2TP-based remote access VPN

PPTP-based remote access VPN You can use Windows 2000 remote access to provide access to a corporate intranet for remote access clients who are making PPTP connections across the Internet. If you want your remote access server to support multiple PPTP connections, complete the following steps: z z z z z z z z

Configure Configure Configure Configure Configure Configure Configure Configure

the connection to the Internet. the connection to the intranet. the remote access server as a corporate intranet router. the remote access server for PPTP clients. the PPTP ports. multicast support. PPTP filters. remote access policies.

The following illustration shows the elements of a Windows 2000 remote access server that provides PPTP-based remote access to a corporate intranet.

Configuring the connection to the Internet The connection to the Internet from a computer running Windows 2000 Server is a dedicated connection—a WAN adapter installed in the computer. The WAN adapter is typically a DDS, T1, Fractional T1, or Frame Relay adapter. You must contract with a local telephone company to run the appropriate physical wiring to your premises. You need to verify that the WAN adapter is on the Microsoft Windows Hardware Compatibility List at the Microsoft Web site(http://www.microsoft.com/). The WAN adapter includes drivers that are installed in the Windows 2000 operating system so that the WAN adapter appears as a network adapter. You need to configure the following TCP/IP settings on the WAN adapter: z IP address and subnet mask assigned from the InterNIC or an Internet service provider (ISP). z Default gateway of the ISP router.

Configuring the connection to the intranet

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 21 of 87

The connection to the intranet from a computer running Windows 2000 Server is a LAN adapter that is installed in the computer. You need to verify that the LAN adapter is on the Microsoft Windows Hardware Compatibility List at the Microsoft Web site(http://www.microsoft.com/). You need to configure the following TCP/IP settings on the LAN adapter: z IP address and subnet mask assigned from the network administrator. z DNS and WINS name servers of corporate intranet name servers.

Configuring the remote access server as a corporate intranet router In order for the remote access server to properly forward traffic on the corporate intranet, you must configure it as a router with either static routes or routing protocols so that all of the locations of the intranet are reachable from the remote access server. For information about routing concepts, see Routing overview. For information about setting up the remote access server as a router, see Deploying routing.

Configuring the remote access server for PPTP clients First, you need to enable the remote access server by enabling the Routing and Remote Access service. For more information, see To enable the Routing and Remote Access service. You can then configure the properties of the remote access server in Routing and Remote Access. For more information, see To view properties of the remote access server. To allow multiple PPTP clients access to the corporate intranet, you need to configure the following settings: z General

Verify that the Remote access server check box is selected. z Security z Authentication Methods

Select the authentication methods that are supported by the remote access server to authenticate the credentials of dial-up clients. Microsoft dial-up networking clients typically use MS-CHAP authentication. For smart card support, you need to enable EAP authentication. Non-Microsoft dial-up networking clients use CHAP, SPAP, and PAP authentication. For encrypted PPTP connections, you must use MS-CHAP or EAP-TLS as the authentication method. z Authentication Provider

You can verify the credentials of dial-up clients by using Windows 2000 security or a RADIUS server. If RADIUS is selected, you need to configure RADIUS server settings for your RADIUS server or RADIUS proxy. z Accounting Provider

You can record dial-up client activity for analysis or accounting purposes by selecting and configuring an accounting provider. z IP

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 22 of 87

Verify that the Enable IP routing and Allow IP-based remote access and demand-dial connections check boxes are selected. If a DHCP server allocating intranet IP addresses is available, click Dynamic Host Allocation Protocol (DHCP). If not, click Static address pool and type the range of IP addresses that are dynamically allocated to PPTP-based VPN clients in the form of an IP address and mask. If the static IP address pool represents a separate subnet, then you must add a static IP route that consists of the remote access address pool {IP Address, Mask} to the routers of the intranet. If the route is not added, then PPTP-based VPN clients cannot receive traffic from resources on the intranet. For more information about configuring IP address pools, see To create a static IP address pool.

Configuring the PPTP ports All the PPTP ports are listed as separate ports under Ports in Routing and Remote Access. You should configure all the PPTP ports for remote access. For more information about configuring ports for remote access, see To configure ports for remote access. By default, five PPTP ports are enabled. If you need to add additional PPTP ports, see To add PPTP or L2TP ports.

Configuring multicast support Depending on the options selected during the Routing and Remote Access wizard, multicast support may already be enabled. To configure multicast support, you need to complete the following steps: 1. 2. 3.

Add the IGMP version 2, Router and Proxy routing protocol. For more information, see To add the IGMP routing protocol. Add the Internal interface to the IGMP routing protocol and configure it in IGMP router mode. For more information, see To enable IGMP router and IGMP proxy mode. Add the interface that represents the permanent connection to the intranet to the IGMP routing protocol and configure the interface in IGMP proxy mode. For more information, see To enable IGMP router and IGMP proxy mode.

Configuring PPTP filters To secure the remote access server from sending or receiving any traffic on its Internet interface except PPTP from remote access clients, you need to configure PPTP input and output filters on the interface on the remote access server that corresponds to the Internet connection. For more information, see Add PPTP filters. Because IP routing is enabled on the Internet interface, if PPTP filters are not configured on the Internet interface of the remote access server, then any traffic received on the Internet interface is routed, possibly forwarding unwanted Internet traffic to your intranet. Depending on the options selected during the Routing and Remote Access wizard, PPTP filters may already be configured.

Configuring remote access policies For an access-by-user administrative model, you need to set the remote access permission to Allow access on the user accounts for those users who will be making VPN connections. For an access-by-policy model, make the appropriate changes to the remote access permission of the user accounts. For more information, see Remote access policy administrative models.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 23 of 87

To configure a remote access policy to control the authentication and encryption options for VPN connections, you can create a remote access policy with the following settings: z Set Policy name to VPN Access (example). z For conditions, set the NAS-Port-Type condition to Virtual (VPN) and the Tunnel-Type condition to Point-

to-Point Tunneling Protocol. z Select the Grant remote access permission option. z For profile settings, select the appropriate authentication and encryption options.

Then, either delete the default remote access policy named Allow access if dial-in permission is enabled or move it after the new policy. This remote access policy allows all users with remote access permission to create a VPN connection. If you want to distinguish dial-up remote access users from VPN remote access users, do the following: 1. 2. 3.

4.

Create a Windows 2000 group whose members can create virtual private networking connections with the VPN server. For example, VPN_Users. Add the appropriate user accounts to the new Windows 2000 group. Create a new remote access policy with the following properties: z Set Policy name to VPN Access if member of VPN_Users (example). z For conditions, set the Windows-Groups condition to VPN_Users (example), set the NAS-Port-Type condition to Virtual (VPN), and set the Tunnel-Type condition to Point-to-Point Tunneling Protocol. z Select the Grant remote access permission option. Move the default remote access policy named Allow access if dial-in permission is enabled after the new policy.

The default encryption settings allow no encryption and all levels of encryption strength. To require encryption, clear the No Encryption option and select the appropriate encryption strengths on the Encryption tab of the remote access policy profile. The encryption strengths are: z Basic

You should use this option when communicating with older Microsoft dial-up networking clients who are connecting from outside North America. This option uses Microsoft Point-to-Point Encryption (MPPE) and a 40bit encryption key. z Strong

You should use this option when communicating with Windows 2000 and Windows 98 dial-up networking clients who are connecting from outside North America. This option uses MPPE and a 56-bit encryption key. z Strongest

You should use this option when communicating with dial-up networking clients who are connecting from inside North America. This option uses MPPE and a 128-bit encryption key and is only available on North American versions of Windows 2000. For more information, see To configure encryption.

L2TP-based remote access VPN You can use Windows 2000 remote access to provide access to a corporate intranet for remote access clients who are making L2TP over IPSec connections across the Internet. If you want your remote access server to support multiple L2TP over IPSec connections, complete the following steps: z Configure the connection to the Internet. z Configure the connection to the intranet. z Configure the remote access server as a corporate intranet router.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

z z z z z

Configure Configure Configure Configure Configure

Page 24 of 87

the remote access server for L2TP clients. the L2TP ports. multicast support. L2TP over IPSec filters. remote access policies.

The following illustration shows the elements of a Windows 2000 remote access server that provides L2TP-based remote access to a corporate intranet.

Note z The following configuration assumes that computer certificates, also known as machine certificates, are already

installed on the VPN server and remote access client computers. Computer certificates are required for L2TP over IPSec connections. For more information, see Machine certificates for L2TP over IPSec VPN connections.

Configuring the connection to the Internet The connection to the Internet from a computer running Windows 2000 Server is a dedicated connection—a WAN adapter installed in the computer. The WAN adapter is typically a DDS, T1, Fractional T1, or Frame Relay adapter. You must contract with a local telephone company to run the appropriate physical wiring to your premises. You need to verify that the WAN adapter is on the Microsoft Windows Hardware Compatibility List at the Microsoft Web site(http://www.microsoft.com/). The WAN adapter includes drivers that are installed in the Windows 2000 operating system so that the WAN adapter appears as a network adapter. You need to configure the following TCP/IP settings on the WAN adapter: z IP address and subnet mask assigned from the InterNIC or an Internet service provider (ISP). z Default gateway of the ISP router.

Configuring the connection to the intranet The connection to the intranet from a computer running Windows 2000 Server is a LAN adapter that is installed in the computer. You need to verify that the LAN adapter is on the Microsoft Windows Hardware Compatibility List at the Microsoft Web site(http://www.microsoft.com/). You need to configure the following TCP/IP settings on the LAN adapter: z IP address and subnet mask assigned from the network administrator. z DNS and WINS name servers of corporate intranet name servers.

Configuring the remote access server as a

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 25 of 87

corporate intranet router In order for the remote access server to properly forward traffic on the corporate intranet, you must configure it as a router with either static routes or routing protocols so that all of the locations of the intranet are reachable from the remote access server. For information about routing concepts, see Routing overview. For information about setting up the remote access server as a router, see Deploying routing.

Configuring the remote access server for L2TP clients First, you need to enable the remote access server by installing the Routing and Remote Access service. For more information, see To enable the Routing and Remote Access service. You can then configure the properties of the remote access server by using Routing and Remote Access. For more information, see To view properties of the remote access server. To allow multiple L2TP clients access to the corporate intranet, you need to configure the following settings: z General

Verify that the Remote access server check box is selected. z Security z Authentication Methods

Select the authentication methods that are supported by the remote access server to authenticate the credentials of remote access clients. Microsoft remote access clients typically use MS-CHAP authentication. For smart card support, you need to enable EAP authentication. z Authentication Provider

You can verify the credentials of remote access clients by using Windows 2000 security or a RADIUS server. If RADIUS is selected, you need to configure RADIUS server settings for your RADIUS server or RADIUS proxy. z Accounting Provider

You can record remote access client activity for analysis or accounting purposes by selecting and configuring an accounting provider. z IP

Verify that the Enable IP routing and Allow IP-based remote access and demand-dial connections check boxes are selected. If a DHCP server allocating intranet IP addresses is available, click Dynamic Host Allocation Protocol (DHCP). If not, click Static address pool and configure the ranges of IP addresses that are dynamically allocated to L2TP-based VPN clients. If the static IP address pool consists of ranges of IP addresses that are for a separate subnet, then you need to either enable an IP routing protocol on the remote access server computer or add static IP routes consisting of the {IP Address, Mask} of each range to the routers of the intranet. If the routes are not added, then L2TPbased VPN clients cannot receive traffic from resources on the intranet.

Configuring the L2TP ports file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 26 of 87

All the L2TP ports are listed as separate ports under Ports in Routing and Remote Access. You should configure all the L2TP ports for remote access. For more information about configuring ports for remote access, see To configure ports for remote access. By default, five L2TP ports are enabled. If you need to add additional L2TP ports, see To add PPTP or L2TP ports.

Configuring multicast support Depending on the options selected during the Routing and Remote Access wizard, multicast support may already be enabled. To configure multicast support, you need to complete the following steps: 1. 2. 3.

Add the IGMP version 2, Router and Proxy routing protocol. For more information, see To add the IGMP routing protocol. Add the Internal interface to the IGMP routing protocol and configure it in IGMP router mode. For more information, see To enable IGMP router and IGMP proxy mode. Add the interface that represents the permanent connection to the intranet to the IGMP routing protocol and configure the interface in IGMP proxy mode. For more information, see To enable IGMP router and IGMP proxy mode.

Configuring L2TP over IPSec filters To secure the remote access server from sending or receiving any traffic on its Internet interface except L2TP over IPSec traffic from remote access clients, you need to configure L2TP over IPSec input and output filters on the interface on the remote access server that corresponds to the Internet connection. For more information, see Add L2TP over IPSec filters. Because IP routing is enabled on the Internet interface, if L2TP over IPSec filters are not configured on the Internet interface of the remote access server, then any traffic received on the Internet interface is routed, possibly forwarding unwanted Internet traffic to your intranet. Depending on the options selected during the Routing and Remote Access wizard, L2TP filters may already be configured.

Configuring remote access policies For an access-by-user administrative model, you need to set the remote access permission to Allow access on the user accounts for those users who will be making VPN connections. For an access-by-policy model, make the appropriate changes to the remote access permission of the user accounts. For more information, see Remote access policy administrative models. To configure a remote access policy to control the authentication and encryption options for VPN connections, create a remote access policy with the following settings: z Set Policy name to VPN Access (example). z For conditions, set the NAS-Port-Type condition to Virtual (VPN) and the Tunnel-Type condition to Layer

Two Tunneling Protocol. z Select the Grant remote access permission option. z For profile settings, select the appropriate authentication and encryption options.

Then, either delete the default remote access policy named Allow access if dial-in permission is enabled or move it after the new policy. This remote access policy allows all users with remote access permission to create a VPN connection. If you want to distinguish dial-up remote access users from VPN remote access users, do the following:

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

1. 2. 3.

4.

Page 27 of 87

Create a Windows 2000 group whose members can create virtual private networking connections with the VPN server. For example, VPN_Users. Add the appropriate user accounts to the new Windows 2000 group. Create a new remote access policy with the following properties: z Set Policy name to VPN Access if member of VPN_Users (example). z For conditions, set the Windows-Groups condition to VPN_Users (example), set the NAS-Port-Type condition to Virtual (VPN), and set the Tunnel-Type condition to Layer Two Tunneling Protocol. z Select the Grant remote access permission option. Move the default remote access policy named Allow access if dial-in permission is enabled after the new policy.

The default encryption settings allow no encryption and all levels of encryption strength. To require encryption, clear the No Encryption option and select the appropriate encryption strengths on the Encryption tab of the remote access policy profile. The encryption strengths are: z Basic

You should use this option when communicating with L2TP over IPSec-based VPN clients who are connecting from outside North America. This option uses 56-bit DES encryption. z Strong

You should use this option when communicating with L2TP over IPSec-based VPN clients who are connecting from outside North America. This option uses 56-bit DES encryption. z Strongest

You should use this option when communicating with L2TP over IPSec-based VPN clients who are connecting from inside North America. This option uses triple DES (3DES) encryption and is only available on North American versions of Windows 2000. For more information, see To configure encryption.

Setting up router-to-router VPNs This section covers: z Router-to-router VPN design considerations z Router-to-router VPN security z Deploying router-to-router VPNs

Router-to-router VPN design considerations To prevent problems, you should consider the following design issues before you implement router-to-router VPN connections.

On-demand or persistent connections You must decide whether your router-to-router VPN connections will be on-demand or persistent: z On-demand demand-dial connections require that the answering router is permanently connected to the

Internet. The calling router connects to the Internet by using a dial-up link such as an analog phone line or ISDN. You need to configure a single demand-dial interface at the answering router. You need to configure two demand-dial interfaces at the calling router: one to connect to a local Internet service provider (ISP) and one for the router-to-router VPN connection. Demand-dial router-to-router VPN connections also require an additional host route in the IP routing table of the calling router. For more information, see An on-demand router-to-router VPN.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 28 of 87

z Persistent connections require that both routers are connected to the Internet by using permanent WAN

connections. You only need to configure a single demand-dial interface at each router. Permanent connections can be initiated and left in a connected state 24 hours a day.

Restricting the initiation of an on-demand connection To prevent the calling router from making unnecessary connections, you can restrict the calling router from making on-demand router-to-router VPN connections in two ways: z Demand-dial filtering

You can use demand-dial filtering to configure either the types of IP traffic that do not cause a demand-dial connection to be made or the types of IP traffic that cause a connection to be made. For more information, see To configure demand-dial filters. z Dial-out hours

You can use dial-out hours to configure the hours that a calling router is either permitted or denied to make a router-to-router VPN connection. For more information, see To configure dial-out hours.

One-way or two-way initiated connections You must decide whether your router-to-router VPN connections will be initiated by one router or by both routers: z With one-way initiated connections, one router is the VPN server and one router is the VPN client. The VPN

server accepts the connection and the VPN client initiates the connection. One-way initiated connections are well suited to a permanent connection spoke-and-hub topology where the branch office router is the only router that initiates the connection. One-way initiated connections require that: z The VPN server (the answering router) is configured as a LAN and WAN router. z A user account is added for the authentication credentials of the calling router that is accessed and validated by the answering router. z A demand-dial interface is configured at the answering router with the same name as the user account that is used by the calling router. This demand-dial interface is not used to dial out, therefore it does is not configured with the host name or IP address of the calling router or with valid user credentials. For more information, see One-way initiated demand-dial connections. z With two-way initiated connections, either router can be the VPN server or the VPN client depending on who is

initiating the connection. Both routers must be configured to initiate and accept a VPN connection. You can use two-way initiated connections when the router-to-router VPN connection is not up 24 hours a day and traffic from either router is used to create the on-demand connection. Two-way initiated router-to-router VPN connections require that: z Both routers are connected to the Internet by using a permanent WAN link. z Both routers are configured as LAN and WAN routers. z User accounts are added for both routers so that the authentication credentials for the calling router are accessed and validated by the answering router. z Demand-dial interfaces, with the same name as the user account that is used by the calling router, must be fully configured at both routers, including settings for the host name or IP address of the answering router and user account credentials to authenticate the calling router.

Number of PPTP or L2TP ports needed The default number of PPTP and L2TP ports is five. For a corporate router in a spoke-and-hub configuration, five ports may not be enough. To increase the number of PPTP and L2TP ports, see To add PPTP or L2TP ports.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 29 of 87

Routing Both routers on a router-to-router VPN connection must have the appropriate routes in their routing tables to forward traffic across the connection. Routes can be static or dynamic. You can add static routes to the routing table either manually or through an auto-static update. You can add dynamic routes to the routing table by adding the VPN connection demand-dial interface to a routing protocol. However, enabling a routing protocol on the VPN connection demand-dial interface is only recommended when the demand-dial interface is permanently connected. Note z Unlike demand-dial routing by using direct links, you cannot use a default IP route for the VPN demand-dial

interface to summarize all the routes of the corporate office. Because the branch office router is connected to the Internet, the default route must be used to summarize all the routes of the Internet and configured to use the interface that connects the router to the Internet.

Single hop across VPN connection For the purposes of designing a routed infrastructure, you can consider the router-to-router VPN connection as a single hop regardless of how many routers are crossed when the encapsulated data is sent across the Internet.

Creating a remote access policy for router-torouter VPN connections By using remote access policies, you can create a policy that requires router-to-router VPN connections to use a specific authentication method and encryption strength. For example, you can create a Windows 2000 group called VPN Routers whose members are the user accounts that are used by calling routers when a router-to-router VPN connection is created. Then, you create a policy with two conditions on the policy: the NAS-Port-Type is set to Virtual (VPN) and the Windows-Group is set to VPN Routers. Finally, you configure the profile for the policy to select a specific authentication method and encryption strength. You can also use the Tunnel-Type condition to create separate remote access policies for PPTP and L2TP connections. For example, to require a specific authentication method and encryption strength for PPTP connections, set the Tunnel-Type condition to Point-to-Point Tunneling Protocol.

L2TP over IPSec connections To create L2TP over IPSec router-to-router VPN connections, you must install machine certificates on the VPN client and the VPN server. For more information, see Machine certificates for L2TP over IPSec VPN connections. For information about creating a preshared key L2TP over IPSec router-to-router VPN connection, see the Windows 2000 Resource Kit.

Router-to-router VPN security In addition to the security steps listed in Static routing security, you can enhance router-to-router VPN security through: z Strong authentication z Data encryption z PPTP or L2TP over IPSec packet filtering

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 30 of 87

Strong authentication For authentication, use the strongest authentication scheme that is possible for your router-to-router VPN configuration. The strongest authentication scheme is the use of EAP-TLS with certificates. For more information, see Deploying certificate-based authentication for demand-dial routing. Otherwise, use MS-CHAP version 2 authentication and enforce the use of strong passwords on your network. For more information, see MS-CHAP version 2.

Data encryption For encryption, you can use either link encryption or end-to-end encryption: z Link encryption encrypts the data only on the link between the two routers. You can use 128-bit Microsoft

Point-to-Point Encryption (MPPE) if your locations are within North America. Otherwise, you can use either 56bit or 40-bit MPPE. 40-bit MPPE is used with older versions of Microsoft operating systems. You must use MPPE in conjunction with either MS-CHAP or EAP-TLS authentication. z End-to-end encryption encrypts the data between the source host and its final destination. You can use IPSec to encrypt data from the source host to the destination host across the demand-dial link. To require encryption, clear the No Encryption option and select the appropriate encryption strengths on the Encryption tab of the remote access policy profile that is used by your calling routers. For more information, see To configure encryption.

PPTP or L2TP over IPSec filtering To secure the calling or answering corporate router from sending or receiving any traffic on its Internet interface except router-to-router VPN traffic, you need to configure PPTP or L2TP over IPSec input and output filters on the router interface that corresponds to the connection to the Internet. For more information about PPTP filters, see Add PPTP filters. For more information about L2TP over IPSec filters, see Add L2TP over IPSec filters. Because IP routing is enabled on the Internet interface, if PPTP or L2TP over IPSec filters are not configured on the Internet interface, then any traffic received on the Internet interface is routed, which may forward unwanted Internet traffic to your intranet.

Deploying router-to-router VPNs This section covers: z PPTP-based router-to-router VPN z L2TP-based router-to-router VPN

PPTP-based router-to-router VPN To create a PPTP-based router-to-router VPN connection to send private data across the Internet, you must perform the following: 1. 2. 3.

Configure the Windows 2000 router at the corporate office to receive PPTP connections from a branch office router. Configure the Windows 2000 router at the branch office to initiate a PPTP connection with the corporate office router. Initiate the PPTP connection from the branch office router.

Note

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 31 of 87

z These steps assume that the PPTP-based router-to-router VPN connection is between a corporate office and a

branch office. However, you can also apply these steps to the VPN connection between two corporate offices.

Configuring the corporate office router If you want your Windows 2000 router in the corporate to support multiple branch office PPTP connections, complete the following steps: z z z z z z z z

Configure Configure Configure Configure Configure Configure Configure Configure

the connection to the Internet. the connection to the intranet. the corporate router. the PPTP ports. demand-dial interfaces. static routes. PPTP filters. remote access policies.

The following illustration shows the elements of a Windows 2000 PPTP-based router-to-router VPN connection.

Note z To simplify configuration, the branch office router always initiates the PPTP connection.

Configuring the connection to the Internet The connection to the Internet is a dedicated connection—a WAN adapter that is installed in the computer. The WAN adapter is typically a DDS, T1, Fractional T1, or Frame Relay adapter. You must contract with a local telephone company to run the appropriate physical wiring to your premises. You need to verify that the WAN adapter is on the Microsoft Windows Hardware Compatibility List at the Microsoft Web site (http://www.microsoft.com/). The WAN adapter includes drivers that are installed in the Windows 2000 operating system so that the adapter appears as a network adapter. You need to configure the following TCP/IP settings on the WAN adapter: z IP address and subnet mask assigned from the InterNIC or an Internet service provider (ISP). z Default gateway of the ISP router.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 32 of 87

Configuring the connection to the intranet The connection to the intranet is a LAN adapter that is installed in the computer. You need to verify that the LAN adapter is on the Microsoft Windows Hardware Compatibility List at the Microsoft Web site (http://www.microsoft.com/). You need to configure the following TCP/IP settings on the LAN adapter: z IP address and subnet mask assigned from the network administrator. z DNS and WINS name servers of corporate intranet name servers.

Because the corporate router will route traffic between the corporate office and the branch office, you must configure the corporate router with either static routes or with routing protocols so that all of the destinations on the corporate network are reachable from the corporate router.

Configuring the corporate router You need to enable the corporate router by installing the Routing and Remote Access service. For more information, see To enable the Routing and Remote Access service. You can configure the corporate router through the properties on the remote access router in Routing and Remote Access. For more information, see To view properties of the remote access server. To allow multiple branch office routers access to the corporate intranet, you need to configure the following settings: z General

Verify that the Router check box and LAN and demand-dial routing are selected. z Security z Authentication Methods

Select the authentication methods that are supported by the corporate router to authenticate the credentials of demand-dial routers. You can select either MS-CHAP or EAP-TLS (if smart cards or computer certificates are available) authentication. z Authentication Provider

You can verify the credentials of dial-up clients by using Windows 2000 security or a RADIUS server. If RADIUS is selected, you need to configure RADIUS server settings for your RADIUS server or RADIUS proxy. z Accounting Provider

You can record dial-up client activity for analysis or accounting purposes by selecting and configuring an accounting provider. z IP

Verify that the Enable IP routing and Allow IP-based remote access and demand-dial connections check boxes are selected. Click Static address pool and configure the ranges of IP addresses that are dynamically allocated to PPTPbased VPN clients. z PPP

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 33 of 87

Select the Link control protocol (LCP) extensions check box. Select the Software compression check box.

Configuring the PPTP ports All the PPTP ports appear as a single device under Ports in Routing and Remote Access. By default, all ports on a Windows 2000 router are configured for Demand-dial routing connections (inbound and outbound), so additional configuration is not necessary. For more information about configuring ports for demand-dial routing connections, see To configure ports for remote access. By default, five PPTP ports are enabled. If you need to add additional PPTP ports, see To add PPTP or L2TP ports.

Configuring demand-dial interfaces For each branch office router, you can create a demand-dial interface by using the Demand-Dial Interface wizard. In the wizard, configure the following: z Interface Name

The name of the interface that represents the connection to the branch office. For example, for a router in the New York branch office, type NewYorkRouter. z Connection Type

Click Connect using virtual private networking (VPN). z VPN Type

Click Point-to-Point Tunneling Protocol (PPTP). z Destination Address

Because the corporate router will not initiate the VPN connection, no phone number or address is required. z Protocols and Security

Select the Add a user account so a remote router can dial in check box. z Dial-out Credentials

Because the corporate router will not initiate the VPN connection, type in any name, domain, and password. z Dial-in Credentials

Type the domain and password for the account that will be used to authenticate the branch office router. The Demand-Dial Interface wizard automatically creates the account and sets its remote access permission to Allow access. The name of the account is the same as the name of the demand-dial interface. For example, for the New York branch office router, the name of the account is NewYorkRouter.

Configuring static routes

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 34 of 87

You need to add static routes so that traffic to the branch office is forwarded by using the appropriate demand-dial interface. For each route of each branch office, configure the interface, destination, network mask, and metric. For the interface, you need to select the demand-dial interface that corresponds to the branch office. For example, the route that corresponds to the New York branch office is 192.168.25.0 with a subnet mask of 255.255.255.0. This route becomes the static route with the following configuration: z z z z

Interface: NewYorkRouter Destination: 192.168.25.0 Network mask: 255.255.255.0 Metric: 1 Note

z Because the PPTP connection is a point-to-point connection, the Gateway IP address is not configurable.

For more information, see To add a static route.

Configuring PPTP filters To secure the corporate router from sending or receiving any traffic on its Internet interface except PPTP traffic from branch office routers, you need to configure PPTP input and output filters on the interface on the corporate router that corresponds to the Internet connection. For more information, see Add PPTP filters. Because IP routing is enabled on the Internet interface, if you do not configure PPTP filters on the Internet interface of the corporate router, then any traffic received on the Internet interface is routed, which may forward unwanted Internet traffic to your intranet.

Configuring remote access policies By using the Demand-Dial Interface wizard, the dial-in properties of user accounts that are used by branch office routers are already configured to allow remote access. If you want to grant remote access to the PPTP-based branch office routers based on group membership, do the following: 1. 2. 3. 4. 5.

6.

For a stand-alone router that is not a member of a domain, use Local Users and Groups and set dial-in properties to Allow access for all users. For a directory services-based router, use Active Directory Users and Computers and set dial-in properties to Control access through Remote Access Policy for all users. Create a Windows 2000 group whose members can create virtual private networking connections with the VPN server. For example, BranchOfficeRouters. Add the appropriate user accounts that corresponds to the accounts that are used by the branch office routers to the Windows 2000 group. Create a new remote access policy with the following properties: z Set Policy name to VPN Access if member of BranchOfficeRouters (example). z Set the Windows-Groups condition to BranchOfficeRouters (example). z Set the NAS-Port-Type condition to Virtual (VPN). z Set the Tunnel-Type condition to Point-to-Point Tunneling Protocol. z Select the Grant remote access permission option. If this computer is only used to provide router-to-router VPN connections, you need to delete the default remote access policy named Allow access if dial-in permission is enabled. Otherwise, move the default remote access policy so that it is evaluated last.

For encryption, the default setting allows no encryption and all levels of encryption strength. To require encryption, clear the No Encryption option and select the appropriate encryption strengths on the Encryption tab of the remote access policy profile that is used by your calling routers.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 35 of 87

For more information, see To configure encryption.

Configuring the branch office router If you want your Windows 2000 router in the branch office to initiate a PPTP connection with the corporate office router, complete the following steps: z z z z z

Configure Configure Configure Configure Configure

the connection to the Internet. the connection to the branch office network. a demand-dial interface. static routes. PPTP filters.

Note z To simplify this configuration, the branch office router always initiates the PPTP connection.

Configuring the connection to the Internet The connection to the Internet is a dedicated connection—a WAN adapter that is installed in the computer. The WAN adapter is typically a DDS, T1, Fractional T1, or Frame Relay adapter. You must contract with a local telephone company to run the appropriate physical wiring to your premises. You need to verify that the WAN adapter is on the Microsoft Windows Hardware Compatibility List at the Microsoft Web site (http://www.microsoft.com/). The WAN adapter includes drivers that are installed in the Windows 2000 operating system so that the adapter appears as a network adapter. You need to configure the following TCP/IP settings on the WAN adapter: z IP address and subnet mask assigned from the InterNIC or an Internet service provider (ISP). z Default gateway of the ISP router.

Configuring the connection to the branch office network The connection to the branch office network is a LAN adapter that is installed in the computer. You need to verify that the LAN adapter is on the Microsoft Windows Hardware Compatibility List at the Microsoft Web site (http://www.microsoft.com/). You need to configure the following TCP/IP settings on the LAN adapter: z IP address and subnet mask assigned from the network administrator. z DNS and WINS name servers of branch office name servers.

Configuring a demand-dial interface You can create a demand-dial interface by using the Demand-Dial Interface wizard. In the wizard, configure the following: z Interface Name

The name of the interface that represents the connection to the corporate office. For example, type CorpOffice. z Connection Type

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 36 of 87

Click Connect using virtual private networking (VPN). z VPN Type

Click Point-to-Point Tunneling Protocol (PPTP). z Destination Address

Type the IP address or host name that is assigned to the Internet interface of the router at the corporate office. If you enter a host name, verify that the host name resolves to the proper IP address. z Dial-out Credentials

Type the name, domain name, and password of the user account that corresponds to this branch office router. The credentials are the same as those entered in the Dial-Out Credentials page of the Demand-Dial Interface wizard when the demand-dial interface for this branch office was created on the corporate router.

Configuring static routes You need to add static routes so that traffic to the corporate office is forwarded by using the appropriate demanddial interface. For each route of the corporate office, configure the interface, destination, network mask, and metric. For the interface, select the demand-dial interface that corresponds to the corporate office previously created. For example, the route that corresponds to the corporate office is 10.0.00 with a subnet mask of 255.0.0.0. This route becomes a static route with the following configuration: z z z z

Interface: CorpOffice Destination: 10.0.0.0 Network mask: 255.0.0.0 Metric: 1 Note

z Because the PPTP connection is a point-to-point connection, the Gateway IP address is not configurable.

For more information, see To add a static route.

Configuring PPTP filters To secure the branch office router from sending or receiving any traffic on its Internet interface except PPTP traffic from the corporate router, you need to configure PPTP input and output filters on the interface on the branch office router that corresponds to the Internet connection. For more information, see Add PPTP filters. Because IP routing is enabled on the Internet interface, if you do not configure PPTP filters on the Internet interface of the branch office router, then any traffic received on the Internet interface is routed, which may forward unwanted Internet traffic to your intranet.

Initiating the PPTP router-to-router VPN connection To connect the branch office router to the corporate router, in Routing and Remote Access, right-click the demanddial interface that connects to the corporate office, and then click Connect.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 37 of 87

For information about troubleshooting a router-to-router VPN, see Troubleshooting router-to-router VPNs.

L2TP-based router-to-router VPN To create a L2TP-based router-to-router VPN connection to send private data across the Internet, you must perform the following: 1. 2. 3.

Configure the Windows 2000 router at the corporate office to receive L2TP connections from a branch office router. Configure the Windows 2000 router at the branch office to initiate a L2TP connection with the corporate office router. Initiate the L2TP connection from the branch office router.

Note z These steps assume that the L2TP-based router-to-router VPN connection is between a corporate office and a

branch office. However, you can also apply these steps to a VPN connection between two corporate offices.

Configuring the corporate office router If you want your Windows 2000 router in the corporate to support multiple branch office L2TP connections, complete the following steps: z z z z z z z z z

Configure the connection to the Internet. Configure the connection to the intranet. Install a computer certificate. Configure the corporate router. Configure the L2TP ports. Configure demand-dial interfaces. Configure static routes. Configure L2TP over IPSec filters. Configure remote access policies.

The following illustration shows the elements of a Windows 2000 L2TP-based router-to-router VPN connection.

Note z To simplify this configuration, the branch office router always initiates the L2TP connection.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 38 of 87

Configuring the connection to the Internet The connection to the Internet is a dedicated connection—a WAN adapter that is installed in the computer. The WAN adapter is typically a DDS, T1, Fractional T1, or Frame Relay adapter. You must contract with a local telephone company to run the appropriate physical wiring to your premises. You need to verify that the WAN adapter is on the Microsoft Windows Hardware Compatibility List at the Microsoft Web site (http://www.microsoft.com/). The WAN adapter includes drivers that are installed in the Windows 2000 operating system so that the adapter appears as a network adapter. You need to configure the following TCP/IP settings on the WAN adapter: z IP address and subnet mask assigned from the InterNIC or an Internet service provider (ISP). z Default gateway of the ISP router.

Configuring the connection to the intranet The connection to the intranet is a LAN adapter that is installed in the computer. You need to verify that the LAN adapter is on the Microsoft Windows Hardware Compatibility List at the Microsoft Web site (http://www.microsoft.com/). You need to configure the following TCP/IP settings on the LAN adapter: z IP address and subnet mask assigned from the network administrator. z DNS and WINS name servers of corporate intranet name servers.

Because the corporate router will route traffic between the corporate office and the branch office, you must configure the corporate router with either static routes or with routing protocols so that all of the destinations on the corporate network are reachable from the corporate router.

Installing a computer certificate You must install a computer certificate on the corporate router in order for an L2TP over IPSec connection to be successfully established. For more information about installing a computer certificate on the corporate router, see Machine certificates for L2TP over IPSec VPN connections.

Configuring the corporate router You need to enable the corporate router by installing the Routing and Remote Access service. For more information, see To enable the Routing and Remote Access service. You can configure the corporate router through the properties on the remote access router in Routing and Remote Access. For more information, see To view properties of the remote access server. To allow multiple branch office routers access to the corporate intranet, you need to configure the following settings: z General

Verify that the Router check box and LAN and demand-dial routing are selected. z Security

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 39 of 87

z Authentication Methods

Select the authentication methods that are supported by the corporate router to authenticate the credentials of dial-up clients. For Windows 2000 demand-dial routers, you can select either MS-CHAP or EAP-TLS (if smart cards or computer certificates are available) authentication. z Authentication Provider

You can verify the credentials of dial-up clients by using Windows 2000 security or a RADIUS server. If RADIUS is selected, you need to configure RADIUS server settings for your RADIUS server or RADIUS proxy. z Accounting Provider

You can record dial-up client activity for analysis or accounting purposes by selecting and configuring an accounting provider. z IP

Verify that the Enable IP routing and Allow IP-based remote access and demand-dial connections check boxes are selected. Click Static address pool and configure the ranges of IP addresses that are dynamically allocated to L2TPbased VPN clients. z PPP

Select the Link control protocol (LCP) extensions check box. Select the Software compression check box.

Configuring the L2TP ports All the L2TP ports appear as a single device under Ports in Routing and Remote Access. By default, all ports on a Windows 2000 router are configured for Demand-dial routing connections (inbound and outbound), so additional configuration is not necessary. For more information about configuring ports for demand-dial routing connections, see To configure ports for remote access. By default, five L2TP ports are enabled. If you need to add additional L2TP ports, see To add PPTP or L2TP ports.

Configuring demand-dial interfaces For each branch office router, you can create a demand-dial interface by using the Demand-Dial Interface wizard. In the wizard, configure the following: z Interface Name

The name of the interface that represents the connection to the branch office. For example, for a router in the New York branch office, type NewYorkRouter. z Connection Type

Click Connect using virtual private networking (VPN). z VPN Type

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 40 of 87

Click Layer 2 Tunneling Protocol (L2TP). z Destination Address

Because the corporate router will not initiate the VPN connection, no address is required. z Protocols and Security

Select the protocols you want to route, and then select the Add a user account so a remote router can dial in check box. z Dial-out Credentials

Because the corporate router will not initiate the VPN connection, type in any name, domain, and password. z Dial-in Credentials

Type the domain and password for the account that will be used to authenticate the branch office router. The Demand-Dial Interface wizard automatically creates the account and sets its remote access permission to Allow access. The name of the account is the same as the name of the demand-dial interface. For example, for the New York branch office router, the name of the account is NewYorkRouter.

Configuring static routes You need to add static routes so that traffic to the branch office is forwarded by using the appropriate demand-dial interface. For each route of each branch office, configure the interface, destination, network mask, and metric. For interface, you need to select the demand-dial interface that corresponds to the branch office. For example, the route that corresponds to the New York branch office is 192.168.25.0 with a subnet mask of 255.255.255.0. This route becomes the static route with the following configuration: z z z z

Interface: NewYorkRouter Destination: 192.168.25.0 Network mask: 255.255.255.0 Metric: 1 Note

z Because the L2TP connection is a point-to-point connection, the Gateway IP address is not configurable.

For more information, see To add a static route.

Configuring L2TP over IPSec filters To secure the corporate router from sending or receiving any traffic on its Internet interface except L2TP over IPSec traffic from branch office routers, you need to configure L2TP over IPSec input and output filters on the interface on the corporate router that corresponds to the Internet connection. For more information, see Add L2TP over IPSec filters. Because IP routing is enabled on the Internet interface, if you do not configure L2TP over IPSec filters on the Internet interface of the corporate router, then any traffic received on the Internet interface is routed, which may forward unwanted Internet traffic to your intranet.

Configuring remote access policies

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 41 of 87

By using the Demand-Dial Interface wizard, the dial-in properties of user accounts that are used by branch office routers are already configured to allow remote access. If you want to grant remote access to the L2TP-based branch office routers based on group membership, do the following: 1. 2. 3. 4. 5.

6.

For a stand-alone router that is not a member of a domain, use Local Users and Groups and set dial-in properties to Allow access for all users. For a directory services-based router, use Active Directory Users and Computers and set dial-in properties to Control access through Remote Access Policy for all users. Create a Windows 2000 group whose members can create virtual private networking connections with the VPN server. For example, BranchOfficeRouters. Add the appropriate user accounts that corresponds to the accounts that are used by the branch office routers to the Windows 2000 group. Create a new remote access policy with the following properties: z Set Policy name to VPN Access if member of BranchOfficeRouters (example). z Set the Windows-Groups condition to BranchOfficeRouters (example). z Set the NAS-Port-Type condition to Virtual (VPN). z Set the Tunnel-Type condition to Layer Two Tunneling Protocol. z Select the Grant remote access permission option. If this computer is only used to provide router-to-router VPN connections, you need to delete the default remote access policy named Allow access if dial-in permission is enabled. Otherwise, move the default remote access policy so that it is evaluated last.

For encryption, the default setting allows no encryption and all levels of encryption strength. To require encryption, clear the No Encryption option and select the appropriate encryption strengths on the Encryption tab of the remote access policy profile that is used by your calling routers. For more information, see To configure encryption.

Configuring the branch office router If you want your Windows 2000 router in the branch office to initiate a L2TP connection with the corporate office router, complete the following steps: z z z z z z

Configure the connection to the Internet. Configure the connection to the branch office network. Install a computer certificate. Configure a demand-dial interface. Configure static routes. Configure L2TP over IPSec filters. Note

z To simplify configuration, the branch office router always initiates the L2TP connection.

Configuring the connection to the Internet The connection to the Internet is a dedicated connection—a WAN adapter that is installed in the computer. The WAN adapter is typically a DDS, T1, Fractional T1, or Frame Relay adapter. You must contract with a local telephone company to run the appropriate physical wiring to your premises. You need to verify that the WAN adapter is on the Microsoft Windows Hardware Compatibility List at the Microsoft Web site (http://www.microsoft.com/). The WAN adapter includes drivers that are installed in the Windows 2000 operating system so that the adapter appears as a network adapter. You need to configure the following TCP/IP settings on the WAN adapter:

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 42 of 87

z IP address and subnet mask assigned from the InterNIC or an Internet service provider (ISP). z Default gateway of the ISP router.

Configuring the connection to the branch office network The connection to the branch office network is a LAN adapter that is installed in the computer. You need to verify that the LAN adapter is on the Microsoft Windows Hardware Compatibility List at the Microsoft Web site (http://www.microsoft.com/). You need to configure the following TCP/IP settings on the LAN adapter: z IP address and subnet mask assigned from the network administrator. z DNS and WINS name servers of branch office name servers.

Because the branch office router will act as a router between the corporate office and the branch office, you must configure the branch office router with either static routes or with routing protocols so that all of the destinations on the branch office network are reachable from the branch office router.

Installing a computer certificate You must install a computer certificate on the branch office router in order for an L2TP over IPSec connection to be successfully established. For more information about installing a computer certificate on the branch office router, see Machine certificates for L2TP over IPSec VPN connections.

Configuring a demand-dial interface You can create a demand-dial interface by using the Demand-Dial Interface wizard. In the wizard, configure the following: z Interface Name

The name of the interface that represents the connection to the corporate office. For example, type CorpOffice. z Connection Type

Click Connect using virtual private networking (VPN). z VPN Type

Click Layer 2 Tunneling Protocol (L2TP). z Destination Address

Type the IP address or host name that is assigned to the Internet interface of the router at the corporate office. If you enter a host name, verify that the host name resolves to the proper IP address. z Protocols and Security

Select the protocols you want to route. z Dial-out Credentials

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 43 of 87

Type the name, domain name, and password of the user account that corresponds to this branch office router. The credentials are the same as those entered in the Dial-Out Credentials page of the Demand-Dial Interface wizard when the demand-dial interface for this branch office was created on the corporate router.

Configuring static routes You need to add static routes so that traffic to the corporate office is forwarded by using the appropriate demanddial interface. For each route of the corporate office, configure the interface, destination, network mask, and metric. For the interface, select the demand-dial interface that corresponds to the corporate office previously created. For example, the route that corresponds to the corporate office is 10.0.00 with a subnet mask of 255.0.0.0. This route becomes a static route with the following configuration: z z z z

Interface: CorpOffice Destination: 10.0.0.0 Network mask: 255.0.0.0 Metric: 1 Note

z Because the L2TP connection is a point-to-point connection, the Gateway IP address is not configurable.

For more information, see To add a static route.

Configuring L2TP over IPSec filters To secure the branch office router from sending or receiving any traffic on its Internet interface except L2TP over IPSec traffic from the corporate router, you need to configure L2TP over IPSec input and output filters on the interface on the branch office router that corresponds to the Internet connection. For more information, see Add L2TP over IPSec filters. Because IP routing is enabled on the Internet interface, if you do not configure L2TP over IPSec filters on the Internet interface of the branch office router, then any traffic received on the Internet interface is routed, which may forward unwanted Internet traffic to your intranet.

Initiating the L2TP router-to-router VPN connection To connect the branch office router to the corporate router, in Routing and Remote Access, right-click the demanddial interface that connects to the corporate office, and then click Connect. For information about troubleshooting a router-to-router VPN, see Troubleshooting router-to-router VPNs.

Setting up certificate-based authentication for VPN connections The use of certificates for authentication of VPN connections is the strongest form of authentication in Windows 2000. You must use certificate-based authentication for L2TP over IPSec VPN connections and with smart cards. With smart cards, you must use the Extensible Authentication Protocol (EAP) with the Smartcard or other certificate (TLS) EAP type, also known as EAP-Transport Level Security (EAP-TLS). This section covers: z Machine certificates for L2TP over IPSec VPN connections

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 44 of 87

z Smart cards and remote access VPN connections z Deploying certificate-based authentication for demand-dial routing

Machine certificates for L2TP over IPSec VPN connections The use of machine certificates for machine-level authentication of VPN clients and VPN server is required for L2TP over IPSec-based VPN connections. In order to create an L2TP over IPSec connection, you must install a machine certificate, also known as a computer certificate, on the VPN client and VPN server computer. To install a computer certificate, a certificate authority must be present to issue certificates. Once the certificate authority is configured, you can install a certificate in two different ways: z By configuring the automatic allocation of computer certificates to computers in a Windows 2000 domain. z By using Certificate Manager to obtain a computer certificate.

Based on the certificate policies in your organization, you only need to perform one of these two allocations. To configure a certificate authority and install the computer certificate, perform the following steps: 1.

2.

Install the Windows 2000 Certificate Services component as an enterprise root certificate authority (CA). This step is only necessary if you do not already have an enterprise root CA. 1. If necessary, promote the computer that will be a CA to a domain controller (DC). For more information, see To install a domain controller. 2. Install the Windows 2000 Certificate Services component as an enterprise root CA. For more information, see To install an enterprise root certification authority. To auto-enroll machine certificates, configure the Windows 2000 domain. For more information, see To configure automatic certificate allocation from an enterprise CA. To create a computer certificate for the VPN server that is a member of the domain for which autoenrollment is configured (as well as other computers that are members of the domain), restart the computer or type secedit /refreshpolicy machine_policy from a Windows 2000 command prompt.

3.

To manually enroll machine certificates, use Certificate Manager to install the CA root certificate. For more information, see To manage certificates for a computer and To request a certificate.

Smart cards and remote access VPN connections The use of smart cards for user authentication is the strongest form of authentication in Windows 2000. For remote access VPN connections, you must use the Extensible Authentication Protocol (EAP) with the Smart card or other certificate (TLS) EAP type, also known as EAP-Transport Level Security (EAP-TLS). Note z A computer running Windows 2000 Server and the Routing and Remote Access service is referred to as the

Windows 2000 remote access router. To use smart cards for remote access VPN authentication, you must do the following: Configure remote access on the remote access router. Install a computer certificate on the remote access router. Enable a smart card logon process for the domain. Enable the Extensible Authentication Protocol (EAP) and configure the Smartcard or other certificate (TLS) EAP type on the remote access router computer. z Enable smart card authentication on the VPN connection on the remote access client computer. z z z z

Configuring the remote access router to provide

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 45 of 87

remote access VPN services Configure the Windows 2000 remote access router as described in Deploying remote access VPNs.

Installing a computer certificate on the remote access router In order to configure EAP-TLS on the remote access router computer, you must install a computer certificate, also known as a machine certificate. To install a computer certificate on the remote access router computer, a certificate authority must be present to issue certificates. Once the certificate authority is configured, you can install a certificate on the remote access router computer in two different ways: z By configuring the automatic allocation of computer certificates to computers in a Windows 2000 domain. z By using Certificate Manager to obtain a computer certificate.

Based on the certificate policies in your organization, you only need to perform one of these two allocations. To configure a certificate authority and install the computer certificate, perform the following steps: 1.

2.

Install the Windows 2000 Certificate Services component as an enterprise root certificate authority (CA). This step is only necessary if you do not already have an enterprise root CA. 1. If necessary, promote the computer that will be a CA to a domain controller (DC). For more information, see To install a domain controller. 2. Install the Windows 2000 Certificate Services component as an enterprise root CA. For more information, see To install an enterprise root certification authority. To auto-enroll machine certificates, configure the Windows 2000 domain. For more information, see To configure automatic certificate allocation from an enterprise CA. To create a computer certificate for the remote access router that is a member of the domain for which auto-enrollment is configured (as well as other computers that are members of the domain), restart the computer or type secedit /refreshpolicy machine_policy from a Windows 2000 command prompt.

3.

To manually enroll machine certificates, use Certificate Manager to install the CA root certificate. For more information, see To manage certificates for a computer and To request a certificate.

Enabling a smart card logon process for the domain To enable a smart card logon process for the domain, complete the following procedures: 1. 2. 3.

To prepare a certification authority to issue smart card certificates To prepare a smart card certificate enrollment station To set up a smart card for user logon

Configuring the remote access router for smart card remote access To configure the Windows 2000 remote access router for smart card remote access, see To configure smart card remote access.

Configuring the remote access client for smart

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 46 of 87

card remote access You need to install a smart card reader on the remote access client computer. For more information, see To install a smart card reader on a computer. Once a smart card reader is installed on the computer running Windows 2000, then you are prompted whether you want to use the smart card for authentication when you create dial-up or VPN connections. For existing dial-up or VPN connections, you can enable smart card authentication from the properties of the dialup or VPN connection. For more information, see To enable smart card or other certificate authentication.

Deploying certificate-based authentication for demand-dial routing The use of certificates for authentication of calling routers is the strongest form of authentication in Windows 2000. For certificate-based authentication of demand-dial connections, you must use the Extensible Authentication Protocol (EAP) with the Smart card or other certificate (TLS) EAP type, also known as EAPTransport Level Security (EAP-TLS). EAP-TLS requires the use of user certificates for the calling router and machine certificates (also known as computer certificates) for the answering router. The deployment of certificate-based authentication for demand-dial routing typically occurs in the following situations: z Business partner demand-dial connection z Branch office demand-dial connection

Business partner demand-dial connection To use certificates for a two-way initiated, mutually authenticated, demand-dial configuration between two business partners (in this example, Company A and Company B), you must perform the following: Configure the calling and answering routers for demand-dial routing. Install computer certificates on the calling router and answering router computers. Configure the domain for Web-based certificate enrollment. At Company A, create a user account for the Company B router and export a certificate At Company B, create a user account for the Company A router and export a certificate At Company A, import the certificate from Company B. Configure the Company A router to support certificate-based authentication as a calling answering router. z At Company B, import the certificate from Company A. z Configure the Company B router to support certificate-based authentication as a calling answering router. z z z z z z z

for the user account. for the user account. router and as an router and as an

Configuring the calling and answering routers for demand-dial routing Configure the Windows 2000 calling and answering routers as described in Deploying demand-dial routing for dialin demand-dial routing or Deploying router-to-router VPNs for VPN demand-dial routing.

Installing computer certificates on the calling router and answering router computers In order to configure EAP-TLS on the answering router computer, you must install a computer certificate (also known as a machine certificate). In order to install a computer certificate, a certificate authority must be present to issue certificates. Once the certificate authority is configured, you can install a certificate two different ways:

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 47 of 87

z By configuring the automatic allocation of computer certificates to computers in a Windows 2000 domain. z By using Certificate Manager to obtain a computer certificate.

Based on the certificate policies in your organization, you only need to perform one of these two allocations. To configure a certificate authority and install the computer certificate, perform the following steps: 1.

2. 3.

Install the Windows 2000 Certificate Services component as an enterprise root certificate authority (CA). This step is only necessary if you do not already have an enterprise root CA. 1. If necessary, promote the computer that will be a CA to a domain controller (DC). For more information, see To install a domain controller. 2. Install the Windows 2000 Certificate Services component as an enterprise root CA. For more information, see To install an enterprise root certification authority. Configure the CA to issue router (offline request) certificates. For more information, see To establish the certificate types that an enterprise certification authority can issue. To auto-enroll machine certificates, configure the Windows 2000 domain. For more information, see To configure automatic certificate allocation from an enterprise CA. To create a computer certificate for the calling or answering router that is a member of the domain for which auto-enrollment is configured (as well as other computers that are members of the domain), restart the computer or type secedit /refreshpolicy machine_policy from a Windows 2000 command prompt.

4.

To manually enroll machine certificates, use Certificate Manager to install the CA root certificate. For more information, see To manage certificates for a computer and To request a certificate.

Configuring the domain for Web-based certificate enrollment In order for the CA to issue certificates for the calling router, you must configure the Windows 2000 domain for Web-based enrollment. For more information, see To set up certification authority Web enrollment support.

Creating a user account and exporting its certificate for the Company B router To create a dial-in user account for the Company B router and export the user certificate of the user account, do the following: 1. 2. 3. 4. 5. 6.

7.

Log on as a domain administrator. Create a user account that the Company B router will use when it dials the Company A router. For more information, see To add a user account. Obtain a router (offline request) certificate from the certificate authority through Web-based enrollment. For more information, see To install a router (offline request) certificate. Export the router (offline request) certificate to a .cer file. For more information, see To export a certificate. Within the Certificate Manager Export wizard, do not export the private key. Map the newly created router (offline request) certificate (the .cer file) to the user account that was created for the Company B router. For more information, see To map a certificate to a user account. Export the router (offline request) certificate to a .pfx file. For more information, see To export a certificate. Within the Certificate Manager Export wizard, export the private key, select the Delete the private key if the import is successful check box, and click Include all certificates in the certification path if possible. Save this file to a floppy disk to send to the network administrator at Company B. Send the floppy disk that contains the Company B dial-in account user certificate file to the network administrator at Company B.

Creating a user account and exporting its

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 48 of 87

certificate for the Company A router To create a dial-in user account for the Company A router and export the user certificate of the user account, do the following: 1. 2. 3. 4. 5. 6.

7.

Log on as a domain administrator. Create a user account that the Company A router will use when it dials the Company B router. For more information, see To add a user account. Obtain a router (offline request) certificate from the certificate authority through Web-based enrollment. For more information, see To install a router (offline request) certificate. Export the router (offline request) certificate to a .cer file. For more information, see To export a certificate. Within the Certificate Manager Export wizard, do not export the private key. Map the newly created router (offline request) certificate (the .cer file) to the user account created for the Company A router. For more information, see To map a certificate to a user account. Export the router (offline request) certificate to a .pfx file. For more information, see To export a certificate. Within the Certificate Manager Export wizard, export the private key, select the Delete the private key if the import is successful check box, and click Include all certificates in the certification path if possible. Save this file to a floppy disk to send to the network administrator at Company A. Send the floppy disk that contains the Company A dial-in account user certificate file to the network administrator at Company A.

Importing the certificates from Company B Upon receipt at Company A of the floppy disk that contains the certificate file from Company B, on the Company A router, import the user certificate. For more information, see To import a certificate.

Configuring the Company A router to support certificate-based authentication To configure the Company A router for certificate-based authentication as an answering router, see To configure the answering router for certificate-based EAP. To configure the Company A router for certificate-based authentication as a calling router, see To configure the calling router for certificate-based EAP.

Importing the certificates from Company A Upon receipt at Company B of the floppy disk that contains the certificate files from Company A, on the Company B router, import the user certificate. For more information, see To import a certificate.

Configuring the Company B router to support certificate-based authentication To configure the Company B router for certificate-based authentication as an answering router, see To configure the answering router for certificate-based EAP. To configure the Company B router for certificate-based authentication as a calling router, see To configure the calling router for certificate-based EAP.

Branch office demand-dial connection To use certificates for a two-way initiated, mutually authenticated, demand-dial configuration between two routers

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 49 of 87

in the same organization (in this example, a branch office router and a corporate office router), you must perform the following: Configure the calling and answering routers for demand-dial routing. Install a computer certificate on the corporate office router. Configure the domain for Web-based certificate enrollment. Create user accounts and export certificates. Import the dial-out user certificate on the corporate office router. Configure the corporate office router to support certificate-based authentication as a calling router and as an answering router. z Import the dial-in certificate on the branch office router. z Configure the branch office router to support certificate-based authentication as a calling router. z Connect to the corporate office and join the organization domain. z z z z z z

Configuring the calling and answering routers for demand-dial routing Configure the Windows 2000 calling and answering routers as described in Deploying demand-dial routing for dialup demand-dial routing or Deploying router-to-router VPNs for VPN demand-dial routing.

Installing a computer certificate on the corporate office router In order to configure EAP-TLS on the corporate office router, you must install a computer certificate (also known as a machine certificate). In order to install a computer certificate, a certificate authority must be present to issue certificates. Once the certificate authority is configured, you can install a certificate two different ways: z By configuring the automatic allocation of computer certificates to computers in a Windows 2000 domain. z By using Certificate Manager to obtain a computer certificate.

Based on the certificate policies in your organization, you only need to perform one of these two allocations. To configure a certificate authority and install the computer certificate, perform the following steps: 1.

2. 3.

Install the Windows 2000 Certificate Services component as an enterprise root certificate authority. This step is only necessary if you do not already have an enterprise root certificate authority (CA). 1. If necessary, promote the computer that will be a CA to a domain controller (DC). For more information, see To install a domain controller. 2. Install the Windows 2000 Certificate Services component as an enterprise root CA. For more information, see To install an enterprise root certification authority. Configure the CA to issue router (offline request) certificates. For more information, see To establish the certificate types that an enterprise certification authority can issue. To auto-enroll machine certificates, configure the Windows 2000 domain. For more information, see To configure automatic certificate allocation from an enterprise CA. To create a computer certificate for the calling or answering router that is a member of the domain for which auto-enrollment has been configured (as well as other computers that are members of the domain), restart the computer or type secedit /refreshpolicy machine_policy from a Windows 2000 command prompt.

4.

To manually enroll machine certificates, use Certificate Manager to install the CA root certificate. For more information, see To manage certificates for a computer and To request a certificate.

Configuring the domain for Web-based certificate enrollment file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 50 of 87

In order for the CA to issue certificates for the calling router, you must configure the Windows 2000 domain for Web-based enrollment. For more information, see To set up certification authority Web enrollment support.

Creating user accounts and exporting certificates To create dial-in and dial-out user accounts and export certificates, do the following: 1. 2. 3. 4. 5. 6.

7. 8. 9. 10. 11.

12.

Log on as a domain administrator. Create a user account that the corporate office router will use when it dials the branch office router (the dial-out account). For more information, see To add a user account. Obtain a router (offline request) certificate for the dial-out account from the certificate authority through Web-based enrollment. For more information, see To install a router (offline request) certificate. Export the router (offline request) certificate for the dial-out account to a .cer file. For more information, see To export a certificate. Within the Certificate Manager Export wizard, do not export the private key. Map the newly created router (offline request) certificate (the .cer file) to the dial-out user account. For more information, see To map a certificate to a user account. Export the router (offline request) certificate of the dial-out account to a .pfx file. For more information, see To export a certificate. Within the Certificate Manager Export wizard, export the private key and click Delete the private key if the import is successful and select the option to Include all certificates in the certification path if possible. Create a user account that the branch office router will use when it dials the corporate office router (the dial-in account). For more information, see To add a user account. Obtain a router (offline request) certificate for the dial-in account from the certificate authority through Web-based enrollment. For more information, see To install a router (offline request) certificate. Export the router (offline request) certificate for the dial-in account to a .cer file. For more information, see To export a certificate. Within the Certificate Manager Export wizard, do not export the private key. Map the newly created router (offline request) certificate (the .cer file) to the dial-in user account. For more information, see To map a certificate to a user account. Export the router (offline request) certificate of the dial-in account to a .pfx file. For more information, see To export a certificate. Within the Certificate Manager Export wizard, export the private key and click Delete the private key if the import is successful. Save this file to a floppy disk to send to the network administrator at the branch office. Send the floppy disk that contains the dial-in account user certificate file to the network administrator at the branch office.

Importing the dial-out certificate on the corporate office router On the corporate office router, import the user certificate for the dial-out account. For more information, see To import a certificate.

Configuring the corporate office router to support certificate-based authentication To configure the corporate office router for certificate-based authentication as an answering router, see To configure the answering router for certificate-based EAP. To configure the corporate office router for certificate-based authentication as a calling router, see To configure the calling router for certificate-based EAP.

Importing the certificate on the branch office

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 51 of 87

router Upon receipt at the branch office of the floppy disk that contains the certificate file from the corporate office, import the user certificate for the dial-in account. For more information, see To import a certificate.

Configuring the branch office router to support certificate-based authentication To configure the branch office router for certificate-based authentication as a calling router, see To configure the calling router for certificate-based EAP.

Connecting to the corporate office and joining the organization domain To connect to the corporate office and join the organization domain, do the following: 1. 2. 3. 4. 5.

6.

From the branch office, connect to the corporate office by right-clicking the demand-dial interface, and then clicking Connect. Once connected, the branch office router joins the domain through the Network Identification tab (in the properties of My Computer). After joining the domain, restart the branch office router. After restarting the branch office router, connect to the corporate office router again. Once connected, the branch office router receives domain policy and a machine certificate (if autoenrollment of machine certificates is configured). If auto-enrollment of machine certificates is not configured, obtain a machine certificate through Certificate Manager. For more information, see To manage certificates for a computer and To request a certificate. Once a machine certificate is obtained, configure the branch office router for certificate-based authentication as an answering router. For more information, see To configure the answering router for certificate-based EAP.

At this point, you can install a domain controller in the branch office by using the demand-dial connection to the corporate office. For more information on installing a Windows 2000 domain controller, see Checklist: Installing a domain controller. Notes z The ability of the branch office router to join the domain and the installation of a domain controller depends on

DNS name resolution. Ensure that both the router and the domain controller computer are configured with the proper DNS server IP addresses. z By default, an answering router checks the certificate revocation list when authenticating the calling router. Because the root CA computer is always reachable by the corporate office router, the certificate revocation list can always be checked. However, the root CA computer is not reachable by the branch office router until after the connection is made. If the root CA computer cannot be reached, then Active Directory is checked. In this case, the branch office router accesses its local domain controller for the revocation list. If the certificate revocation list is not published in Active Directory, then the branch office router acting as the answering router rejects the connection attempt. To prevent this problem, do one of the following: z Publish the certificate revocation list in Active Directory. For more information, see Schedule the publication of the certificate revocation list or To manually publish the certificate revocation list. z On the branch office router, set the following registry value to 1: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan \PPP\EAP\13\IgnoreRevocationOffline Caution z Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 52 of 87

should back up any valued data on the computer.

Virtual private network scenarios This section describes how common virtual private network scenarios are configured for a fictional company by using Windows 2000. While your network configuration may be different than those described here, you can apply the basic concepts. Note z A computer running Windows 2000 Server and the Routing and Remote Access service is referred to as the

Windows 2000 remote access router. Electronic, Inc. is an electronics design and manufacturing company with a main corporate campus in New York and branch offices and distribution business partners throughout the United States. Electronic, Inc. has implemented a VPN solution by using Windows 2000 that connects remote access users, branch offices, and business partners. The VPN server at the corporate office provides both remote access and router-to-router PPTP and L2TP VPN connections and the routing of packets to intranet and Internet locations. For more information, see Common configuration for the VPN server. Based on the common configuration of the VPN server, the following virtual private network scenarios are described: z z z z z

Remote access for employees On-demand branch office Persistent branch office Extranet for business partners Dial-up and VPNs with RADIUS Note

z The example companies, organizations, products, people and events depicted herein are fictitious. No

association with any real company, organization, product, person or event is intended or should be inferred.

Common configuration for the VPN server To deploy a VPN solution for Electronic, Inc., the network administrator performs an analysis and makes design decisions regarding: z z z z

The The The The

network configuration remote access policy configuration domain configuration security configuration

The network configuration The key elements of the network configuration are: z The Electronic, Inc. corporate intranet uses the private networks of 172.16.0.0 with a subnet mask of

255.240.0.0 and 192.168.0.0 with a subnet mask of 255.255.0.0. The corporate campus network segments use subnets of 172.16.0.0 and the branch offices use subnets of 192.168.0.0. z The VPN server computer is directly attached to the Internet by using a T3 (also known as a DS-3) dedicated WAN link. z The IP address of the WAN adapter on the Internet is 207.46.130.1 as allocated by the Internet service provider (ISP) for Electronic, Inc. The IP address of the WAN adapter is referred to on the Internet by the domain name vpn.electronic.microsoft.com.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 53 of 87

z The VPN server computer is directly attached to an intranet network segment that contains a RADIUS server, a

file and Web server for business partner access, and a router that connects to the rest of the Electronic, Inc. corporate campus intranet. The intranet network segment has the IP network ID of 172.31.0.0 with the subnet mask of 255.255.0.0. z The VPN server computer is configured with a static pool of IP addresses to allocate to remote access clients and calling routers. The following illustration shows the network configuration of the Electronic, Inc. VPN server.

Based on the network configuration of the Electronic, Inc. corporate campus intranet, the VPN server computer is configured as follows.

1. Install hardware in the VPN server The network adapter that is used to connect to the intranet segment and the WAN adapter that is used to connect to the Internet are installed according to the adapter manufacturer's instructions. Once drivers are installed and functioning, both adapters appeared as local area connections in the Network and Dial-up Connections folder.

2. Configure TCP/IP on the LAN and WAN adapter For the LAN adapter, an IP address of 172.31.0.1 with a subnet mask 255.255.0.0 is configured. For the WAN adapter, an IP address of 207.46.130.1 with a subnet mask 255.255.255.255 is configured. A default gateway is not configured for either adapter. DNS and WINS server addresses are also configured.

3. Install the Routing and Remote Access service The Routing and Remote Access Installation wizard is run. Within the wizard, both remote access and LAN and WAN routing are enabled, all ports are enabled for both routing and remote access, and IPSec encryption is required for L2TP connections. For more information, see To enable the Routing and Remote Access service. Within the wizard, a static IP address pool with a starting IP address of 172.31.255.1 and an ending IP address of 172.31.255.254 is configured. This creates a static address pool for up to 253 VPN clients. For more information, see To create a static IP address pool.

4. Enable the EAP authentication method To enable the use of smart card-based remote access VPN clients and certificate-based calling routers, the network administrator enables the Extensible Authentication Protocol on the VPN server. For more information, see To enable EAP.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 54 of 87

5. Configure static routes to reach intranet and Internet locations To reach intranet locations, a static route is configured with the following settings: z z z z z

Interface: The LAN adapter attached to the intranet Destination: 172.16.0.0 Network mask: 255.240.0.0 Gateway: 172.31.0.2 Metric: 1

To reach Internet locations, a static route is configured with the following settings: z z z z z

Interface: The WAN adapter attached to the Internet Destination: 0.0.0.0 Network mask: 0.0.0.0 Gateway: 0.0.0.0 Metric: 1 Note

z Because the WAN adapter creates a point-to-point connection to the ISP, any address can be entered for the

gateway. The gateway address of 0.0.0.0 is an example. 0.0.0.0 is the unspecified IP address.

6. Increase the number of PPTP and L2TP ports By default, only five L2TP ports and five PPTP ports are enabled for VPN connections. The number of L2TP and PPTP ports is increased to 253. For more information, see To add PPTP or L2TP ports.

7. Configure PPTP and L2TP over IPSec packet filters Both PPTP and L2TP over IPSec packet filters are configured on the WAN adapter that connects to the Internet. For more information, see Add PPTP filters and Add L2TP over IPSec filters.

The remote access policy configuration To ease the transition from a Windows NT 4.0 environment, the network administrator for Electronic, Inc. decides on an access-by-user administrative model. Remote access is controlled by setting the dial-in permission of individual user accounts to either Allow access or Deny access. Remote access policies are used to apply different VPN connection settings based on group membership, and the default remote access policy named Allow access if dial-in permission is enabled is deleted. For more information, see Remote access policy administrative models.

The domain configuration To take advantage of the ability to apply different connection settings to different types of VPN connections, the following Windows 2000 groups are created: z VPN_Users

Used for remote access VPN connections

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 55 of 87

z VPN_Routers

Used for router-to-router VPN connections from Electronic, Inc. branch offices z VPN_Partners

Used for router-to-router VPN connections from Electronic, Inc. business partners Electronic, Inc. has a mixed-mode domain. For more information, see Upgrading to Active Directory.

The security configuration To enable L2TP over IPSec connections, the use of smart cards by remote access clients, and the use of EAP-TLS by routers, the Electronic, Inc. domain is configured to auto-enroll machine certificates to all domain members. For more information, see Setting up certificate-based authentication for VPN connections. Note z The example companies, organizations, products, people and events depicted herein are fictitious. No

association with any real company, organization, product, person or event is intended or should be inferred.

Remote access for employees Remote access for Electronic, Inc. employees is deployed by using remote access VPN connections across the Internet based on the settings configured in Common configuration for the VPN server and the following additional settings. The following illustration shows the Electronic, Inc. VPN server that provides remote access VPN connections.

Domain configuration For each employee that is allowed VPN access: z The remote access permission on the dial-in properties of the user account is set to Allow access. z The user account is added to the VPN_Users Windows 2000 group.

Remote access policy configuration file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 56 of 87

To define the authentication and encryption settings for remote access VPN clients, the following remote access policy is created: z Policy name: Remote Access VPN Clients z Conditions: z NAS-Port-Type is set to Virtual (VPN) z Windows-Groups is set to VPN_Users z Called-Station-ID is set to 207.46.130.1 z Permission is set to Grant remote access permission z Profile settings: z Authentication tab: Extensible Authentication Protocol is enabled and Smartcard or other

certificate (TLS) is configured to use the installed machine certificate. Microsoft Encrypted Authentication version 2 (MS-CHAP v2) and Microsoft Encrypted Authentication (MS-CHAP) are also enabled. z Encryption tab: Strongest is the only option that is selected. Notes z The Called-Station-ID condition is set to the IP address of the Internet interface for the VPN server. Only

tunnels initiated from the Internet are allowed. Tunnels initiated from the Electronic, Inc. intranet are not permitted. Electronic, Inc. users that require Internet access from the Electronic, Inc. intranet must go through the Electronic, Inc. proxy server (not shown), where Internet access is controlled and monitored. z In the access-by-user administrative model, the remote access permission on the remote access policy has no effect on granting remote access permission. However, the network administrator for Electronic, Inc. set the remote access permission on the policy to Grant remote access permission so that an eventual transition to an access-by-policy in a native mode domain administrative model does not require changing all the remote access permission settings on all of the configured remote access policies.

PPTP-based remote access client configuration The Make New Connection wizard is used to create a VPN connection with the following setting: z Host name or IP address: vpn.electronic.microsoft.com

L2TP-based remote access client configuration The remote access computer logs on to the Electronic, Inc. domain and receives a certificate through autoenrollment. Then, the Make New Connection wizard is used to create VPN connection with the following setting: z Host name or IP address: vpn.electronic.microsoft.com

The VPN connection settings are modified as follows: z On the Networking tab, Type of dial-up server I am calling is set to Layer-2 Tunneling Protocol

(L2TP). Note z The example companies, organizations, products, people and events depicted herein are fictitious. No

association with any real company, organization, product, person or event is intended or should be inferred.

On-demand branch office The Portland and Dallas branch offices of Electronic, Inc. are connected to the corporate office by using on-demand router-to-router VPN connections. Both the Portland and Dallas offices contain a small number of employees who only need occasional connectivity with the corporate office. The Windows 2000 routers in the Portland and Dallas

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 57 of 87

offices are equipped with an ISDN adapter that dials a local Internet service provider to gain access to the Internet, and then a router-to-router VPN connection is made across the Internet. When the VPN connection is not used for five minutes, the routers at the branch offices terminate the VPN connection. The Dallas branch office uses the IP network ID of 192.168.28.0 with a subnet mask of 255.255.255.0. The Portland branch office uses the IP network ID of 192.168.4.0 with a subnet mask of 255.255.255.0. To simplify the configuration, the VPN connection is a one-way initiated connection that is always initiated by the branch office router. For more information, see One-way initiated demand-dial connections. The following illustration shows the Electronic, Inc. VPN server that provides on-demand branch office connections.

To deploy on-demand router-to-router VPN connections to connect the Portland and Dallas branch offices to the corporate office based on the settings configured in Common configuration for the VPN server, the following additional settings are configured.

Domain configuration For the VPN connection to the Dallas office, the user account VPN_Dallas is created with the following settings: z Password of nY7W{q8~=z3. z For the dial-in properties on the VPN_Dallas account, the remote access permission is set to Allow access and

the static route 192.168.28.0 with a subnet mask of 255.255.255.0 is added. z The VPN_Dallas account is added to the VPN_Routers group.

For the VPN connection to the Portland office, the user account VPN_Portland is created with the following settings: z Password of P*4s=wq!Gx1. z For the dial-in properties on the VPN_Portland account, the remote access permission is set to Allow access

and the static route 192.168.4.0 with a subnet mask of 255.255.255.0 is added. z The VPN_Portland account is added to the VPN_Routers group.

Remote access policy configuration To define the authentication and encryption settings for the VPN routers, the following remote access policy is created:

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 58 of 87

z Policy name: VPN Routers z Conditions: z NAS-Port-Type is set to Virtual (VPN) z Windows-Groups is set to VPN_Routers z Called-Station-ID is set to 207.46.130.1 z Permission is set to Grant remote access permission z Profile settings: z Authentication tab: Extensible Authentication Protocol is enabled and Smartcard or other

certificate (TLS) is configured to use the installed machine certificate. Microsoft Encrypted Authentication version 2 (MS-CHAP v2) is also enabled. z Encryption tab: Strongest is the only option that is selected. Notes z The Called-Station-ID is set to the IP address of the Internet interface for the VPN server. Only tunnels

initiated from the Internet are allowed. Tunnels initiated from the Electronic, Inc. intranet are not permitted. Electronic, Inc. users that require Internet access from the Electronic, Inc. intranet must go through the Electronic, Inc. proxy server (not shown), where Internet access is controlled and monitored. z In the access-by-user administrative model, the remote access permission on the remote access policy has no effect on granting remote access permission. However, the network administrator for Electronic, Inc. set the remote access permission on the policy to Grant remote access permission so that an eventual transition to an access-by-policy in a native mode domain administrative model does not require changing all the remote access permission settings on all of the configured remote access policies. For more information about the branch office router configuration, see: z The Dallas office: PPTP-based on-demand branch office z The Portland office: L2TP-based on-demand branch office

Note z The example companies, organizations, products, people and events depicted herein are fictitious. No

association with any real company, organization, product, person or event is intended or should be inferred.

PPTP-based on-demand branch office The Dallas branch office is a PPTP-based branch office that uses a Windows 2000 router to create an on-demand, router-to-router VPN connection with the corporate office router in New York as needed. When the connection is made and is idle for five minutes, the connection is terminated. To deploy a PPTP, one-way initiated, on-demand, router-to-router VPN connection to the corporate office based on the settings configured in Common configuration for the VPN server and On-demand branch office, the following settings are configured on the Dallas router.

Demand-dial interface for the connection to the ISP To connect the Dallas office router to the Internet by using a local ISP, a demand-dial interface is created by using the Demand-Dial Interface wizard with the following settings: z Interface name

ISP z Connection type

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 59 of 87

Connect using a modem, ISDN adapter, or other physical device is selected. z Select a device

The appropriate ISDN device is selected. z Phone number or address

Phone number of the ISP for the Dallas office. z Protocols and security

The Route IP packets on this interface check box is selected. z Dial-out credentials z User name: Dallas office ISP account name. z Domain: Dallas office ISP account domain name. z Password: Dallas office ISP account password. z Confirm password: Dallas office ISP account password.

Demand-dial interface for router-to-router VPN connection To connect the Dallas office router to the corporate router by using a router-to-router VPN connection over the Internet, a demand-dial interface is created by using the Demand-Dial Interface wizard with the following settings: z Interface name

CorpHQ z Connection type

Connect using virtual private networking (VPN) is selected. z VPN type

Point to Point Tunneling Protocol (PPTP) is selected. z Destination address

207.46.130.1 z Protocols and security

The Route IP packets on this interface check box is selected. z Dial-out credentials z User name: VPN_Dallas z Domain: electronic.microsoft.com z Password: nY7W{q8~=z3 z Confirm password: nY7W{q8~=z3

Static route for corporate headquarters

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 60 of 87

To make all locations on the corporate intranet reachable, the following static route is configured: z z z z

Interface: CorpHQ Destination: 172.16.0.0 Network mask: 255.240.0.0 Metric: 1

Static route for Electronic, Inc. VPN server To create the connection to the Dallas ISP when the router-to-router VPN connection needs to be made, the following static route is configured: z z z z

Interface: ISP Destination: 207.46.130.1 Network mask: 255.255.255.255 Metric: 1

PPTP packet filters on the demand-dial interface that connects to the ISP To ensure that only PPTP-based traffic is allowed on the connection to the Internet, PPTP packet filters are configured on the ISP demand-dial interface. For more information, see Add PPTP filters.

Demand-dial filters on the PPTP demand-dial interface To ensure that only traffic destined for the Electronic, Inc. corporate office creates the VPN connection, demanddial filters are configured on the PPTP demand-dial interface. The following filter settings are configured: z Filter action: Only for the following traffic is selected. z Filter 1: Destination network IP address of 172.16.0.0 and subnet mask of 255.240.0.0

For more information, see To configure demand-dial filters. Note z The example companies, organizations, products, people and events depicted herein are fictitious. No

association with any real company, organization, product, person or event is intended or should be inferred.

L2TP-based on-demand branch office The Portland branch office is an L2TP-based branch office that uses a Windows 2000 router to create an ondemand, router-to-router VPN connection with the corporate office router in New York as needed. When the connection is made and is idle for five minutes, the connection is terminated. To deploy an L2TP, one-way initiated, on-demand, router-to-router VPN connection to the corporate office based on the settings configured in Common configuration for the VPN server and On-demand branch office, the following settings are configured on the Portland router.

Demand-dial interface for the connection to the

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 61 of 87

ISP To connect the Portland office router to the Internet by using a local ISP, a demand-dial interface is created by using the Demand-Dial Interface wizard with the following settings: z Interface name

ISP z Connection type

Connect using a modem, ISDN adapter, or other physical device is selected. z Select a device

The appropriate ISDN device is selected. z Phone number or address

Phone number of the ISP for the Portland office. z Protocols and security

The Route IP packets on this interface check box is selected. z Dial-out credentials z User name: Portland office ISP account name. z Domain: Portland office ISP account domain name. z Password: Portland office ISP account password. z Confirm password: Portland office ISP account password.

Demand-dial interface for router-to-router VPN connection To connect the Portland office router to the corporate router by using a router-to-router VPN connection over the Internet, a demand-dial interface is created by using the Demand-Dial Interface wizard with the following settings: z Interface name

CorpHQ z Connection type

Connect using virtual private networking (VPN) is selected. z VPN type

Layer-2 Tunneling Protocol (L2TP) is selected. z Destination address

207.46.130.1 z Protocols and security

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 62 of 87

The Route IP packets on this interface check box is selected. z Dial-out credentials z User name: VPN_Portland z Domain: electronic.microsoft.com z Password: P*4s=wq!Gx1 z Confirm password: P*4s=wq!Gx1

Static route for corporate headquarters To make all locations on the corporate intranet reachable, the following static route is configured: z z z z

Interface: CorpHQ Destination: 172.16.0.0 Network mask: 255.240.0.0 Metric: 1

Static route for Electronic, Inc. VPN server To create the connection to the Portland ISP when the router-to-router VPN connection needs to be made, the following static route is configured: z z z z

Interface: ISP Destination: 207.46.130.1 Network mask: 255.255.255.255 Metric: 1

L2TP over IPSec packet filters on the demanddial interface that connects to the ISP To ensure that only L2TP over IPSec-based traffic is allowed on the connection to the Internet, L2TP over IPSec packet filters are configured on the ISP demand-dial interface. For more information, see Add L2TP over IPSec filters.

Demand-dial filters on the L2TP demand-dial interface To ensure that only traffic destined for the Electronic, Inc. corporate office creates the VPN connection, demanddial filters are configured on the L2TP demand-dial interface. The following filter settings are configured: z Filter action: Only for the following traffic is selected. z Filter 1: Destination network IP address of 172.16.0.0 and subnet mask of 255.240.0.0

For more information, see To configure demand-dial filters. Note z The example companies, organizations, products, people and events depicted herein are fictitious. No

association with any real company, organization, product, person or event is intended or should be inferred.

Persistent branch office

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 63 of 87

The Chicago and Phoenix branch offices of Electronic, Inc. are connected to the corporate office by using persistent router-to-router VPN connections that stay connected 24 hours a day. The Windows 2000 routers in the Chicago and Phoenix offices are equipped with T1 WAN adapters that have a permanent connection to a local Internet service provider to gain access to the Internet. The Chicago branch office uses the IP network ID of 192.168.9.0 with a subnet mask of 255.255.255.0. The Chicago branch office router uses the public IP address of 131.107.0.1 for its Internet interface. The Phoenix branch office uses the IP network ID of 192.168.14.0 with a subnet mask of 255.255.255.0. The Phoenix branch office router uses the public IP address of 131.107.128.1 for its Internet interface. The VPN connection is a two-way initiated connection. The connection is initiated from either the branch office router or the corporate office router. Two-way initiated connections require the creation of demand-dial interfaces, remote access policies, IP address pools, and packet filters on the routers on both sides of the connection. The following illustration shows the Electronic, Inc. VPN server that provides persistent branch office connections.

To deploy persistent router-to-router VPN connections to connect the Chicago and Phoenix branch offices to the corporate office based on the settings configured in Common configuration for the VPN server, the following additional settings are configured.

Domain configuration For the Chicago office VPN connection that is initiated by the Chicago router, the user account VPN_Chicago is created with the following settings: z Password of U9!j5dP(%q1. z For the dial-in properties on the VPN_Chicago account, the remote access permission is set to Allow access. z The VPN_Chicago account is added to the VPN_Routers group.

For the Phoenix office VPN connection that is initiated by the Phoenix router, the user account VPN_Phoenix is created with the following settings: z Password of z2F%s)bW$4f. z For the dial-in properties on the VPN_Phoenix account, the remote access permission is set to Allow access. z The VPN_Phoenix account is added to the VPN_Routers group.

For the Chicago office VPN connection and the Phoenix office VPN connection that are initiated by the corporate headquarters router, the user account VPN_CorpHQ is created with the following settings:

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 64 of 87

z Password of o3\Dn6@`-J4. z For the dial-in properties on the VPN_CorpHQ account, the remote access permission is set to Allow access. z The VPN_CorpHQ account is added to the VPN_Routers group.

Remote access policy configuration Remote access policies must be configured at the corporate router, the Chicago router, and the Phoenix router.

Remote access policy configuration at the corporate router The remote access policy configuration for the corporate router is the same as described in On-demand branch office.

Remote access policy configuration at the Chicago router To define the authentication and encryption settings for the VPN connections, the default policy named Allow access if dial-in permission is enabled is deleted and the following remote access policy is created: z Policy name: VPN Routers z Conditions: z NAS-Port-Type is set to Virtual (VPN) z Windows-Groups is set to VPN_Routers z Called-Station-ID is set to 131.107.0.1 z Permission is set to Grant remote access permission z Profile settings: z Authentication tab: Extensible Authentication Protocol is enabled and Smartcard or other

certificate (TLS) is configured to use the installed machine certificate. Microsoft Encrypted Authentication version 2 (MS-CHAP v2) is also enabled. z Encryption tab: Strongest is the only option that is selected. Notes z The Called-Station-ID is set to the IP address of the Internet interface for the branch office router. Only

tunnels initiated from the Internet are allowed. Tunnels initiated from the Electronic, Inc. branch office network are not permitted. z In the access-by-user administrative model, the remote access permission on the remote access policy has no effect on granting remote access permission. However, the network administrator for Electronic, Inc. set the remote access permission on the policy to Grant remote access permission so that an eventual transition to an access-by-policy in a native mode domain administrative model does not require changing all the remote access permission settings on all of the configured remote access policies.

Remote access policy configuration at the Phoenix router To define the authentication and encryption settings for the VPN connections, the default policy named Allow access if dial-in permission is enabled is deleted and the following remote access policy is created: z Policy name: VPN Routers z Conditions: z NAS-Port-Type is set to Virtual (VPN) z Windows-Groups is set to VPN_Routers z Called-Station-ID is set to 131.107.128.1 z Permission is set to Grant remote access permission z Profile settings: z Authentication tab: Extensible Authentication Protocol is enabled and Smartcard or other

certificate (TLS) is configured to use the installed machine certificate. Microsoft Encrypted Authentication version 2 (MS-CHAP v2) is also enabled. z Encryption tab: Strongest is the only option that is selected.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 65 of 87

Notes z The Called-Station-ID is set to the IP address of the Internet interface for the branch office router. Only

tunnels initiated from the Internet are allowed. Tunnels initiated from the Electronic, Inc. branch office network are not permitted. z In the access-by-user administrative model, the remote access permission on the remote access policy has no effect on granting remote access permission. However, the network administrator for Electronic, Inc. set the remote access permission on the policy to Grant remote access permission so that an eventual transition to an access-by-policy in a native mode domain administrative model does not require changing all the remote access permission settings on all of the configured remote access policies.

IP address pool configuration IP address pools must be configured at the corporate router, the Chicago router, and the Phoenix router.

IP address pool configuration at the corporate router The IP address pool configuration for the corporate router is the same as described in Common configuration for the VPN server.

IP address pool configuration at the Chicago router A static IP address pool with an IP address of 192.168.9.248 and a mask of 192.168.9.253 is configured. This creates a static address pool for up to five VPN clients. For more information, see To create a static IP address pool.

IP address pool configuration at the Phoenix router A static IP address pool with a starting IP address of 192.168.14.248 and an ending IP address of 192.168.14.253 is configured. This creates a static address pool for up to five VPN clients. For more information, see To create a static IP address pool. For more information about the corporate router and branch office router configuration, see: z The Chicago office: PPTP-based persistent branch office z The Phoenix office: L2TP-based persistent branch office

Note z The example companies, organizations, products, people and events depicted herein are fictitious. No

association with any real company, organization, product, person or event is intended or should be inferred.

PPTP-based persistent branch office The Chicago branch office is a PPTP-based branch office that uses a Windows 2000 router to create a persistent, router-to-router VPN connection with the corporate office router in New York. The connection is never terminated even when idle. To deploy a PPTP, two-way initiated, persistent, router-to-router VPN connection to the corporate office based on the settings configured in Common configuration for the VPN server and Persistent branch office, the following settings are configured on the corporate router and Chicago router.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 66 of 87

Corporate router configuration The corporate router is configured with a demand-dial interface and a static route.

Demand-dial interface for router-to-router VPN connection To connect the corporate office router to the Chicago router by using a router-to-router VPN connection over the Internet, a demand-dial interface is created by using the Demand-Dial Interface wizard with the following settings: z Interface name

VPN_Chicago z Connection type

Connect using virtual private networking (VPN) is selected. z VPN type

Point to Point Tunneling Protocol (PPTP) is selected. z Destination address

131.107.0.1 z Protocols and security

The Route IP packets on this interface check box is selected. z Dial-out credentials z User name: VPN_CorpHQ z Domain: electronic.microsoft.com z Password: o3\Dn6@`-J4 z Confirm password: o3\Dn6@`-J4

Once the demand-dial interface is created, the following change is made: z For the properties of the demand-dial interface, on the Options tab, under Connection type, the Persistent

connection option is selected.

Static route for Chicago office network To make all locations on the Chicago network reachable, the following static route is configured: z z z z

Interface: VPN_Chicago Destination: 192.168.9.0 Network mask: 255.255.255.0 Metric: 1

Chicago router configuration The Chicago router is configured with a demand-dial interface and a static route.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 67 of 87

Demand-dial interface for router-to-router VPN connection To connect the Chicago office router to the corporate office router by using a router-to-router VPN connection over the Internet, a demand-dial interface is created by using the Demand-Dial Interface wizard with the following settings: z Interface name

VPN_CorpHQ z Connection type

Connect using virtual private networking (VPN) is selected. z VPN type

Point to Point Tunneling Protocol (PPTP) is selected. z Destination address

207.46.130.1 z Protocols and security

The Route IP packets on this interface check box is selected. z Dial-out credentials z User name: VPN_Chicago z Domain: electronic.microsoft.com z Password: U9!j5dP(%q1 z Confirm password: U9!j5dP(%q1

Once the demand-dial interface is created, the following change is made: z For the properties of the demand-dial interface, on the Options tab, under Connection type, the Persistent

connection option is selected.

Static route for the Internet To make all locations on the Internet reachable, the following static route is configured: z z z z z

Interface: The WAN adapter attached to the Internet Destination: 0.0.0.0 Network mask: 0.0.0.0 Gateway: 0.0.0.0 Metric: 1 Note

z Because the WAN adapter creates a point-to-point connection to the ISP, any address can be entered for the

gateway. The gateway address of 0.0.0.0 is an example. 0.0.0.0 is the unspecified IP address.

Static route for corporate intranet

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 68 of 87

To make all locations on the corporate intranet reachable, the following static route is configured: z z z z

Interface: VPN_CorpHQ Destination: 172.16.0.0 Network mask: 255.240.0.0 Metric: 1

PPTP packet filters on the Internet interface To ensure that only PPTP-based traffic is allowed on the connection to the Internet, PPTP packet filters are configured on the Internet interface. For more information, see Add PPTP filters. Note z The example companies, organizations, products, people and events depicted herein are fictitious. No

association with any real company, organization, product, person or event is intended or should be inferred.

L2TP-based persistent branch office The Phoenix branch office is an L2TP-based branch office that uses a Windows 2000 router to create a persistent, router-to-router VPN connection with the corporate office router in New York. The connection is never terminated even when idle. To deploy an L2TP, two-way initiated, persistent, router-to-router VPN connection to the corporate office based on the settings configured in Common configuration for the VPN server and Persistent branch office, the following settings are configured on the corporate router and Phoenix router.

Corporate router configuration The corporate router is configured with a demand-dial interface and a static route.

Demand-dial interface for router-to-router VPN connection To connect the corporate office router to the Phoenix router by using a router-to-router VPN connection over the Internet, a demand-dial interface is created by using the Demand-Dial Interface wizard with the following settings: z Interface name

VPN_Phoenix z Connection type

Connect using virtual private networking (VPN) is selected. z VPN type

Layer-2 Tunneling Protocol (L2TP) is selected. z Destination address

131.107.128.1 z Protocols and security

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 69 of 87

The Route IP packets on this interface check box is selected. z Dial-out credentials z User name: VPN_CorpHQ z Domain: electronic.microsoft.com z Password: o3\Dn6@`-J4 z Confirm password: o3\Dn6@`-J4

Once the demand-dial interface is created, the following change is made: z For the properties of the demand-dial interface, on the Options tab, under Connection type, the Persistent

connection option is selected.

Static route for Phoenix office network To make all locations on the Phoenix network reachable, the following static route is configured: z z z z

Interface: VPN_Phoenix Destination: 192.168.14.0 Network mask: 255.255.255.0 Metric: 1

Phoenix router configuration The Phoenix router is configured with a demand-dial interface and a static route.

Demand-dial interface for router-to-router VPN connection To connect the Phoenix office router to the corporate office router by using a router-to-router VPN connection over the Internet, a demand-dial interface is created by using the Demand-Dial Interface wizard with the following settings: z Interface name

VPN_CorpHQ z Connection type

Connect using virtual private networking (VPN) is selected. z VPN type

Layer-2 Tunneling Protocol (L2TP) is selected. z Destination address

207.46.130.1 z Protocols and security

The Route IP packets on this interface check box is selected.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 70 of 87

z Dial-out credentials z User name: VPN_Phoenix z Domain: electronic.microsoft.com z Password: z2F%s)bW$4f z Confirm password: z2F%s)bW$4f

Once the demand-dial interface is created, the following change is made: z For the properties of the demand-dial interface, on the Options tab, under Connection type, the Persistent

connection option is selected.

Static route for the Internet To make all locations on the Internet reachable, the following static route is configured: z z z z z

Interface: The WAN adapter attached to the Internet Destination: 0.0.0.0 Network mask: 0.0.0.0 Gateway: 0.0.0.0 Metric: 1 Note

z Because the WAN adapter creates a point-to-point connection to the ISP, any address can be entered for the

gateway. The gateway address of 0.0.0.0 is an example. 0.0.0.0 is the unspecified IP address.

Static route for corporate intranet To make all locations on the corporate intranet reachable, the following static route is configured: z z z z

Interface: VPN_CorpHQ Destination: 172.16.0.0 Network mask: 255.240.0.0 Metric: 1

L2TP over IPSec packet filters on the Internet interface To ensure that only L2TP over IPSec-based traffic is allowed on the connection to the Internet, L2TP over IPSec packet filters are configured on the Internet interface. For more information, see Add L2TP over IPSec filters. Note z The example companies, organizations, products, people and events depicted herein are fictitious. No

association with any real company, organization, product, person or event is intended or should be inferred.

Extranet for business partners The network administrator for Electronic, Inc. has created an extranet, a portion of the Electronic, Inc. private network that is available to business partners through secured VPN connections. The Electronic, Inc. extranet is the network attached to the Electronic, Inc. VPN server and contains a file server and a Web server. Parts distributors Tasmanian Traders and Parnell Aerospace are Electronic, Inc. business partners and connect to the Electronic, Inc. extranet by using on-demand, router-to-router VPN connections. An additional remote access policy is used to ensure that the business partners can only access the extranet file server and Web server.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 71 of 87

The file server on the Electronic, Inc. extranet is configured with an IP address of 172.31.0.10 and the Web server is configured with an IP address of 172.31.0.11. Tasmanian Traders uses the public network ID of 131.107.254.0 with a subnet mask of 255.255.255.0. Parnell Aerospace uses the public network ID of 131.107.250.0 with a subnet mask of 255.255.255.0. To ensure that the extranet Web server and file server can reach the business partners, static routes are configured on the file server and Web server for each of the business partner networks that use the gateway address of 172.31.0.1 To simplify configuration, the VPN connection is a one-way initiated connection. The connection is always initiated by the business partner router. For more information, see One-way initiated demand-dial connections. The following illustration shows the Electronic, Inc. VPN server that provides extranet connections for business partners.

To deploy business partner, on-demand, one-way initiated, router-to-router VPN connections to connect Tasmanian Traders and Parnell Aerospace to the Electronic, Inc. extranet based on the settings configured in Common configuration for the VPN server, the following additional settings are configured.

Domain configuration For the VPN connection to Tasmanian Traders, the user account PTR_Tasmanian is created with the following settings: z Password of Y8#-vR7?]fI. z For the dial-in properties on the PTR_Tasmanian account, the remote access permission is set to Allow access

and the static route 131.107.254.0 with a subnet mask 255.255.255.0 is added. z The PTR_Tasmanian account is added to the VPN_Partners group.

For the VPN connection to Parnell Aerospace, the user account PTR_Parnell is created with the following settings: z Password of W@8c^4r-;2\. z For the dial-in properties on the PTR_Parnell account, the remote access permission is set to Allow access and

the static route 131.107.250.0 with a subnet mask 255.255.255.0 is added. z The PTR_Parnell account is added to the VPN_Partners group.

Certificate configuration For the business partner routers to perform certificate-based authentication to the corporate office router,

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 72 of 87

certificates must be exchanged between Electronic, Inc. and the business partner. For more information, see Business partner demand-dial connection.

Remote access policy configuration To define the authentication and encryption settings for business partner VPN connections, the following remote access policy is created: z Policy name: VPN Partners z Conditions: z NAS-Port-Type is set to Virtual (VPN) z Windows-Groups is set to VPN_Partners z Called-Station-ID is set to 207.46.130.1 z Permission is set to Grant remote access permission z Profile settings: z On the IP tab, the following TCP/IP packet filters are configured:

From client z Filter action: Deny all traffic except those listed below z Filter 1: Destination network IP address of 172.31.0.10 and subnet mask of 255.255.255.255 z Filter 2: Destination network IP address of 172.31.0.11 and subnet mask of 255.255.255.255

To client z Filter action: Deny all traffic except those listed below z Filter 1: Source network IP address of 172.31.0.10 and subnet mask of 255.255.255.255 z Filter 2: Source network IP address of 172.31.0.11 and subnet mask of 255.255.255.255 z Authentication tab: Extensible Authentication Protocol is enabled and Smartcard or other

certificate (TLS) is configured to use the installed machine certificate. Microsoft Encrypted Authentication version 2 (MS-CHAP v2) is also enabled. z Encryption tab: Strongest is the only option that is selected. Notes z The Called-Station-ID is set to the IP address of the Internet interface for the VPN server. Only tunnels

initiated from the Internet are allowed. Tunnels initiated from the Electronic, Inc. intranet are not permitted. Electronic, Inc. users that require Internet access from the Electronic, Inc. intranet must go through the Electronic, Inc. proxy server (not shown), where Internet access is controlled and monitored. z In the access-by-user administrative model, the remote access permission on the remote access policy has no effect on granting remote access permission. However, the network administrator for Electronic, Inc. set the remote access permission on the policy to Grant remote access permission so that an eventual transition to an access-by-policy in a native mode domain administrative model does not require changing all the remote access permission settings on all of the configured remote access policies. For more information about the business partner router configuration, see: z Tasmanian Traders: PPTP-based extranet for business partners z Parnell Aerospace: L2TP-based extranet for business partners

Note z The example companies, organizations, products, people and events depicted herein are fictitious. No

association with any real company, organization, product, person or event is intended or should be inferred.

PPTP-based extranet for business partners Tasmanian Traders is a business partner that uses a Windows 2000 router to create an on-demand, PPTP-based, router-to-router VPN connection with the Electronic, Inc. corporate office router in New York as needed. When the

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 73 of 87

connection is created and is idle for five minutes, the connection is terminated. The Tasmanian Traders router is connected to the Internet by using a permanent WAN connection. To deploy a PPTP, one-way initiated, on-demand, router-to-router VPN connection to the corporate office based on the settings configured in Common configuration for the VPN server and Extranet for business partners, the following settings are configured on the Tasmanian Traders router:

Demand-dial interface for router-to-router VPN connection To connect the Tasmanian Traders router to the corporate router by using a router-to-router VPN connection over the Internet, a demand-dial interface is created by using the Demand-Dial Interface wizard with the following settings: z Interface name

Electronic z Connection type

Connect using virtual private networking (VPN) is selected. z VPN type

Point to Point Tunneling Protocol (PPTP) is selected. z Destination address

207.46.130.1 z Protocols and security

The Route IP packets on this interface check box is selected. z Dial-out credentials z User name: PTR_Tasmanian z Domain: electronic.microsoft.com z Password: Y8#-vR7?]fI z Confirm password: Y8#-vR7?]fI

Static route for Electronic, Inc. extranet To make all locations on the Electronic, Inc. extranet reachable, the following static route is configured: z z z z

Interface: Electronic Destination: 172.31.0.0 Network mask: 255.255.0.0 Metric: 1

PPTP packet filters on the Internet interface To ensure that only PPTP-based traffic is allowed on the connection to the Internet, PPTP packet filters are configured on the Internet interface. For more information, see Add PPTP filters.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 74 of 87

Note z The example companies, organizations, products, people and events depicted herein are fictitious. No

association with any real company, organization, product, person or event is intended or should be inferred.

L2TP-based extranet for business partners Parnell Aerospace is a business partner that uses a Windows 2000 router to create an on-demand, L2TP-based, router-to-router VPN connection with the Electronic, Inc. corporate office router in New York as needed. When the connection is created and is idle for five minutes, the connection is terminated. The Parnell Aerospace router is connected to the Internet by using a permanent WAN connection. To deploy an L2TP, one-way initiated, on-demand, router-to-router VPN connection to the corporate office based on the settings configured in Common configuration for the VPN server and Extranet for business partners, the following settings are configured on the Parnell Aerospace router.

Demand-dial interface for router-to-router VPN connection To connect the Parnell Aerospace router to the corporate router by using a router-to-router VPN connection over the Internet, a demand-dial interface is created by using the Demand-Dial Interface wizard with the following settings: z Interface name

Electronic z Connection type

Connect using virtual private networking (VPN) is selected. z VPN type

Layer-2 Tunneling Protocol (L2TP) is selected. z Destination address

207.46.130.1 z Protocols and security

The Route IP packets on this interface check box is selected. z Dial-out credentials z User name: PTR_Parnell z Domain: electronic.microsoft.com z Password: W@8c^4r-;2\ z Confirm password: W@8c^4r-;2\

Static route for Electronic, Inc. extranet To make all locations on the Electronic, Inc. extranet reachable, the following static route is configured:

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

z z z z

Page 75 of 87

Interface: electronic Destination: 172.31.0.0 Network mask: 255.255.0.0 Metric: 1

L2TP over IPSec packet filters on the Internet interface To ensure that only L2TP over IPSec-based traffic is allowed on the connection to the Internet, L2TP over IPSec packet filters are configured on the Internet interface. For more information, see Add L2TP over IPSec filters. Note z The example companies, organizations, products, people and events depicted herein are fictitious. No

association with any real company, organization, product, person or event is intended or should be inferred.

Dial-up and VPNs with RADIUS In addition to VPN-based remote access, the network administrator for Electronic, Inc. wants to provide modembased dial-up remote access for employees of the New York office. All employees of the New York office belong to a Windows 2000 group called NY_Employees. A separate remote access server running Windows 2000 provides dial-up remote access at the phone number 555-0111. Rather than administer the remote access policies of both the VPN server and the remote access server separately, the network administrator is using a computer running Windows 2000 with the Internet Authentication Service (IAS) as a RADIUS server. The IAS server has an IP address of 172.31.0.9 on the Electronic, Inc. extranet and provides centralized remote access authentication, authorization, and accounting for both the remote access server and the VPN server. The following illustration shows the Electronic, Inc. RADIUS server that provides authentication and accounting for the VPN server and the remote access server.

Domain configuration For each New York office employee that is allowed dial-up access, the remote access permission for the dial-in properties of the user account is set to Allow access.

Remote access policy configuration

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 76 of 87

Remote access policies must be modified in two ways: 1. 2.

The existing remote access policies that are configured on the VPN server running Windows 2000 must be copied to the IAS server. A new remote access policy is added for dial-up remote access clients on the IAS server.

Copying the remote access policies Once the VPN server running Windows 2000 is configured to use RADIUS authentication, the remote access policies stored on the VPN server are no longer used. Instead, the remote access policies stored on the IAS server running Windows 2000 are used. Therefore, the current set of remote access policies is copied to the IAS server. For more information, see To copy the IAS configuration to another server.

Creating a new remote access policy for dial-up remote access clients To define the authentication and encryption settings for dial-up connections by employees of the New York office, the following remote access policy is created on the RADIUS server computer: z Policy name: Dial-Up for New York Employees z Conditions: z NAS-Port-Type is set to all types except Virtual (VPN) z Windows-Groups is set to NY_Employees z Permission is set to Grant remote access permission z Profile settings: z Authentication tab: Extensible Authentication Protocol is enabled and Smartcard or other

certificate (TLS) is configured to use the installed machine certificate. Microsoft Encrypted Authentication version 2 (MS-CHAP v2) and Microsoft Encrypted Authentication (MS-CHAP) are also enabled. z Encryption tab: All options are selected. Note z In the access-by-user administrative model, the remote access permission on the remote access policy has no

effect on granting remote access permission. However, the network administrator for Electronic, Inc. set the remote access permission on the policy to Grant remote access permission so that an eventual transition to an access-by-policy in a native mode domain administrative model does not require changing all the remote access permission settings on all of the configured remote access policies.

RADIUS configuration To configure RADIUS authentication and accounting, the network administrator for Electronic, Inc. configures the following: z The RADIUS server is a computer running Windows 2000 with the Internet Authentication Service networking

component installed. The Internet Authentication Service is configured for two RADIUS clients; the remote access server and the VPN server. For more information, see Internet Authentication Service and To register RADIUS clients. z The remote access server running Windows 2000 is configured to use RADIUS authentication and accounting at the IP address of 172.31.0.9 and a shared secret. For more information, see To use RADIUS authentication and To use RADIUS accounting. z The VPN server running Windows 2000 is configured to use RADIUS authentication and accounting at the IP address of 172.31.0.9 and a shared secret. For more information, see To use RADIUS authentication and To use RADIUS accounting.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 77 of 87

Dial-up remote access client configuration The Make New Connection wizard is used to create a dial-up connection with the following setting: z Phone number: 555-0111

Note z The example companies, organizations, products, people and events depicted herein are fictitious. No

association with any real company, organization, product, person or event is intended or should be inferred.

Resources This section covers: z References z Virtual private networking RFCs z Troubleshooting tools

References The Windows 2000 router is intended for use by system administrators who are already familiar with routing protocols and router services. For more information about the TCP/IP and IPX protocols, and routing and dynamic routing protocols, you can consult the following references: z Chappell, Laura A., and Hakes, Dan E. Novell's Guide to NetWare LAN Analysis. San Jose, California: Novell

Press, 1994. z Comer, Douglas. Internetworking with TCP/IP, Volume 1. Englewood Cliffs, New Jersey: Prentice Hall, 1991. z Huitema, Christian. Routing in the Internet. Englewood Cliffs, New Jersey: Prentice Hall, 1995. z Perlman, Radia. Interconnections: Bridges and Routers. Reading, Massachusetts: Addison-Wesley, 1992. z Stevens, W. Richard. TCP/IP Illustrated, Volume 1, The Protocols. Reading, Massachusetts: Addison-Wesley,

1994.

Virtual private networking RFCs Requests for Comments (RFCs) are an evolving series of technical reports, proposals for protocols, and protocol standards used by the Internet community. Standards are defined in RFCs published by the Internet Engineering Task Force (IETF) and other working groups. Virtual private networking RFCs RFC number

Title

2637

Point-to-Point Tunneling Protocol (PPTP)

2661

Layer Two Tunneling Protocol "L2TP"

Virtual private networking Internet drafts Draft name

Title

draft-ietf-pppext-l2tp-security-x.txt Securing L2TP using IPSEC

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 78 of 87

Obtaining RFCs You can obtain RFCs from the Request for Comments Web site. (http://www.rfc-editor.org/) This site is currently maintained by members of the Information Sciences Institute (ISI) who publish a classified listing of all RFCs. RFCs are classified as one of the following: approved Internet standard, proposed Internet standard (circulated in draft form for review), Internet best practices, or For Your Information (FYI) document. You can find Internet drafts on the Internet Drafts Web site. (ftp://ftp.ietf.org/internet-drafts/) Note z Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

Troubleshooting tools To help you gather information to troubleshoot problems with the remote access server, the following troubleshooting tools are available: Authentication and accounting logging. For more information see Logging. Event logging records errors, warnings, and events in the system event log. PPP logging creates a log file of the PPP control messages that are sent and received during a PPP connection. Tracing records the sequence of programming functions called during a process to a file. For more information, see Using tracing. z Network Monitor captures traffic sent between a remote access server and dial-up client during the PPP connection process and during data transfer. z z z z

Event logging You can use Windows 2000 event logging to record remote access server errors, warnings, and other detailed information in the Windows 2000 system event log. You can enable event logging on the Event Logging tab on the properties of a remote access server. For more information, see To view properties of the remote access server.

PPP logging PPP logging records the series of programming functions and PPP control messages during a PPP connection and is a valuable source of troubleshooting information when you are troubleshooting the failure of a PPP connection. To enable PPP logging, select the Enable Point-to-Point Protocol (PPP) logging option on the PPP tab on the properties of a remote access server. For more information, see To view properties of the remote access server. The PPP log in Windows NT 4.0 has been replaced by the tracing function. To duplicate the PPP log, you need to enable file tracing for the PPP key. By default, the PPP log is stored as the ppp.log file in the systemroot\Tracing folder. For more information on tracing options, see Using tracing.

Network Monitor Network Monitor can capture the network traffic between a dial-up networking client and the remote access server. By analyzing remote access traffic, you can find answers to remote access problems and possible solutions or workarounds. Note z The proper interpretation of remote access traffic with Network Monitor requires an in-depth understanding of

PPP and other protocols. For more information, see the Windows 2000 Resource Kit or Remote access RFCs.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 79 of 87

You can save Network Monitor traces as files and send them to Microsoft Product Support Services for analysis.

Troubleshooting This section covers: z Troubleshooting remote access VPNs z Troubleshooting router-to-router VPNs

Troubleshooting remote access VPNs What problem are you having? Unable to establish a remote access VPN connection. Cause: The Routing and Remote Access service is not started on the VPN server. Solution: Verify the state of the Routing and Remote Access service on the VPN server. See also: To monitor the Routing and Remote Access service; To start and stop the Routing and Remote Access service Cause: Remote access is not enabled on the VPN server. Solution: Enable remote access on the VPN server. See also: To enable the remote access server Cause: PPTP or L2TP ports are not enabled for inbound remote access requests. Solution: Enable PPTP or L2TP ports, or both, for inbound remote access requests. See also: To configure ports for remote access Cause: The LAN protocols being used by the VPN clients are not enabled for remote access on the VPN server. Solution: Enable the LAN protocols being used by the VPN clients for remote access on the VPN server. See also: To view properties of the remote access server Cause: All of the PPTP or L2TP ports on the VPN server are already being used by currently connected remote access clients or demand-dial routers. Solution: Verify that all of the PPTP or L2TP ports on the VPN server are not already being used by clicking Ports in Routing and Remote Access. If necessary, change the number of PPTP or L2TP ports to allow more concurrent connections. See also: To add PPTP or L2TP ports Cause: The tunneling protocol of the VPN client is not supported by the VPN server. By default, Windows 2000 remote access VPN clients use the Automatic server type option, which means that they try to establish an L2TP over IPSec–based VPN connection first, and then they try a PPTP-based VPN connection. If VPN clients use either the Point-to-Point Tunneling Protocol (PPTP) or Layer-2 Tunneling Protocol (L2TP) server type option, verify that the selected tunneling protocol is supported by the VPN

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 80 of 87

server. By default, a computer running Windows 2000 Server and the Routing and Remote Access service is a PPTP and L2TP server with five L2TP ports and five PPTP ports. To create a PPTP-only server, set the number of L2TP ports to zero. To create an L2TP-only server, set the number of PPTP ports to zero. Solution: Verify that the appropriate number of PPTP or L2TP ports is configured. See also: To add PPTP or L2TP ports Cause: The VPN client and the VPN server in conjunction with a remote access policy are not configured to use at least one common authentication method. Solution: Configure the VPN client and the VPN server in conjunction with a remote access policy to use at least one common authentication method. See also: To configure authentication Cause: The VPN client and the VPN server in conjunction with a remote access policy are not configured to use at least one common encryption method. Solution: Configure the VPN client and the VPN server in conjunction with a remote access policy to use at least one common encryption method. See also: To configure encryption Cause: The VPN connection does not have the appropriate permissions through dial-in properties of the user account and remote access policies. Solution: Verify that the VPN connection has the appropriate permissions through dial-in properties of the user account and remote access policies. In order for the connection to be established, the settings of the connection attempt must: z Match all of the conditions of at least one remote access policy. z Be granted remote access permission through the user account (set to Allow access) or through the user

account (set to Control access through Remote Access Policy) and the remote access permission of the matching remote access policy (set to Grant remote access permission). z Match all the settings of the profile. z Match all the settings of the dial-in properties of the user account. See also: Introduction to remote access policies; Accepting a connection attempt Cause: The settings of the remote access policy profile are in conflict with properties of the VPN server. The properties of the remote access policy profile and the properties of the VPN server both contain settings for: z Multilink z Bandwidth allocation protocol z Authentication protocols

If the settings of the profile of the matching remote access policy are in conflict with the settings of the VPN server, the connection attempt is rejected. For example, if the matching remote access policy profile specifies that the EAP-TLS authentication protocol must be used and EAP is not enabled on the VPN server, the connection attempt is rejected. Solution: Verify that the settings of the remote access policy profile are not in conflict with properties of the VPN server.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 81 of 87

See also: To enable authentication protocols; To configure authentication Cause: The credentials of the VPN client (user name, password, and domain name) are incorrect and cannot be validated by the VPN server. Solution: Verify that the credentials of the VPN client (user name, password, and domain name) are correct and can be validated by the VPN server. Cause: There are not enough addresses in the static IP address pool. Solution: If the VPN server is configured with a static IP address pool, verify that there are enough addresses in the pool. If all of the addresses in the static pool have been allocated to connected VPN clients, the VPN server is unable to allocate an IP address, and the connection attempt is rejected. Modify the static IP address pool if needed. See also: TCP/IP and remote access; To create a static IP address pool Cause: The VPN client is configured to request its own IPX node number and the VPN server is not configured to allow IPX clients to request their own IPX node number. Solution: Configure the VPN server to allow IPX clients to request their own IPX node number. See also: IPX and remote access Cause: The VPN server is configured with a range of IPX network numbers that are being used elsewhere on your IPX internetwork. Solution: Configure the VPN server with a range of IPX network numbers that is unique to your IPX internetwork. See also: IPX and remote access Cause: The authentication provider of the VPN server is improperly configured. Solution: Verify the configuration of the authentication provider. You can configure the VPN server to use either Windows 2000 or RADIUS to authenticate the credentials of the VPN client. See also: Authentication and accounting providers; To use RADIUS authentication Cause: The VPN server cannot access Active Directory. Solution: For a VPN server that is a member server in a mixed-mode or native-mode Windows 2000 domain that is configured for Windows 2000 authentication, verify that: z The RAS and IAS Servers security group exists. If not, then create the group and set the group type to

Security and the group scope to Domain local. z The RAS and IAS Servers security group has Read permission to the RAS and IAS Servers Access

Check object. z The computer account of the VPN server computer is a member of the RAS and IAS Servers security

group. You can use the netsh ras show registeredserver command to view the current registration. You can use the netsh ras add registeredserver command to register the server in a specified domain. If you add (or remove) the VPN server computer to the RAS and IAS Servers security group, the change does not take effect immediately (due to the way that Windows 2000 caches Active Directory information). For the change to take effect immediately, you need to restart the VPN server computer. z For a native-mode domain, the VPN server has joined the domain.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 82 of 87

See also: To add a group; To verify permissions for the RAS and IAS security group; NetShell commands for remote access Cause: A Windows NT 4.0 VPN server cannot validate connection requests. Solution: If VPN clients are dialing in to a VPN server running Windows NT 4.0 that is a member of a Windows 2000 mixed-mode domain, verify that the Everyone group is added to the Pre-Windows 2000 Compatible Access group with the net localgroup "Pre-Windows 2000 Compatible Access" command. If not, type net localgroup "Pre-Windows 2000 Compatible Access" everyone /add at a command prompt on a domain controller computer and then restart the domain controller computer. See also: Windows NT 4.0 remote access server in a Windows 2000 domain Cause: The VPN server is unable to communicate with the configured RADIUS server. Solution: If your RADIUS server is only reachable through your Internet interface, add an input filter and output filter to the Internet interface for UDP port 1812 (based on RFC 2138, "Remote Authentication Dial-In User Service (RADIUS)") or UDP port 1645 (for older RADIUS servers) for RADIUS authentication and UDP port 1813 (based on RFC 2139, "RADIUS Accounting") or UDP port 1646 (for older RADIUS servers) for RADIUS accounting. See also: To add a packet filter Cause: Cannot ping the VPN server from the Internet. Solution: Due to the PPTP and L2TP over IPSec packet filtering that is configured on the Internet interface of the VPN server, Internet Control Message Protocol (ICMP) packets used by the ping command are filtered out. To enable ping capability on the VPN server, you need to add an input filter and an output filter that allow traffic for IP protocol 1 (ICMP traffic). See also: To add a packet filter VPN clients are unable to access resources beyond the VPN server. Cause: The LAN protocols used by remote access VPN clients are not enabled to allow access to the network to which the VPN server is attached. Solution: Configure the LAN protocols used by the remote access VPN clients to allow access to the network to which the VPN server is attached. See also: To view properties of the remote access server Cause: A static IP address pool is configured but there are no routes back to the remote access VPN clients. Solution: If the VPN server is configured to use a static IP address pool, verify that the routes to the ranges of addresses defined by the static IP address pool are reachable by the hosts and routers of the intranet. If not, then IP routes consisting of the address ranges of the static IP address pool, as defined by the IP address and mask of each range, must be added to the routers of the intranet, or the routing protocol of your routed infrastructure on the VPN server must be enabled. If the routes to the remote access VPN client subnets are not present, remote access VPN clients cannot receive traffic from locations on the intranet. A route for the network is implemented either through static routing entries or through a routing protocol, such as Open Shortest Path First (OSPF) or Routing Information Protocol (RIP). If the VPN server is configured to use DHCP for IP address allocation and no DHCP server is available, the VPN server allocates addresses from the Automatic Private IP Addressing (APIPA) address range from 169.254.0.1 through 169.254.255.254. Allocating APIPA addresses for remote access clients works only if the network to which the VPN server is attached is also using APIPA addresses. If the VPN server is using APIPA addresses when a DHCP server is available, verify that the proper adapter is

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 83 of 87

selected from which to obtain DHCP-allocated IP addresses. By default, the VPN server randomly chooses the adapter to use to obtain IP addresses through DHCP. If there is more than one LAN adapter, then the Routing and Remote Access service may choose a LAN adapter for which there is no DHCP server available. If the static IP address pool consists of ranges of IP addresses that are a subset of the range of IP addresses for the network to which the VPN server is attached, verify that the ranges of IP addresses of the static IP address pool are not assigned to other TCP/IP nodes, either through static configuration or through DHCP. See also: TCP/IP and remote access; To create a static IP address pool Cause: Packet filters on the remote access policy profile are preventing the flow of IP traffic. Solution: Verify that there are no configured TCP/IP packet filters on the profile properties of the remote access policies on the VPN server (or the RADIUS server if Internet Authentication Service is used) that are preventing the sending or receiving of TCP/IP traffic. You can use remote access policies to configure TCP/IP input and output packet filters that control the exact nature of TCP/IP traffic allowed on the VPN connection. Verify that the profile TCP/IP packet filters are are not preventing the flow of needed traffic. See also: To configure IP options

Troubleshooting router-to-router VPNs Unable to establish a router-to-router VPN connection. Cause: The Routing and Remote Access service is not started on the VPN client (the calling router) and the VPN server (the answering router). Solution: Verify the state of the Routing and Remote Access service on the VPN client and the VPN server. See also: To monitor the Routing and Remote Access service; To start and stop the Routing and Remote Access service Cause: LAN and WAN routing is not enabled on the calling router and the answering router. Solution: Enable Local and remote routing (LAN and WAN router) on the calling router and the answering router. See also: To enable LAN and WAN routing Cause: PPTP or L2TP ports are not enabled for inbound and outbound demand-dial routing connections. Solution: Enable PPTP or L2TP ports, or both, for inbound and outbound demand-dial routing connections. See also: To enable routing on ports Cause: All of the PPTP or L2TP ports on the calling or answering router are already being used by currently connected remote access clients or demand-dial routers. Solution: Verify that all of the PPTP or L2TP ports on the VPN server are not already being used by clicking Ports in Routing and Remote Access. If necessary, change the number of PPTP or L2TP ports to allow more concurrent connections. See also: To add PPTP or L2TP ports Cause: The tunneling protocol of the calling router is not supported by the answering router.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 84 of 87

By default, Windows 2000 demand-dial interfaces use the Automatic server type option, which means that they try to establish an L2TP over IPSec–based VPN connection first, and then they try a PPTP-based VPN connection. If calling routers use either the Point-to-Point Tunneling Protocol (PPTP) or Layer-2 Tunneling Protocol (L2TP) server type option, verify that the selected tunneling protocol is supported by the answering router. By default, a computer running Windows 2000 Server and the Routing and Remote Access service is a PPTP and L2TP-capable demand dial router with five L2TP ports and five PPTP ports. To create a PPTP-only router, set the number of L2TP ports to zero. To create an L2TP-only router, set the number of PPTP ports to zero. Solution: Verify that the appropriate number of PPTP or L2TP ports is configured on the calling router and answering router. See also: To add PPTP or L2TP ports Cause: The calling router and the answering router in conjunction with a remote access policy are not configured to use at least one common authentication method. Solution: Configure the calling router and the answering router in conjunction with a remote access policy to use at least one common authentication method. See also: To configure authentication Cause: The calling router and the answering router in conjunction with a remote access policy are not configured to use at least one common encryption method. Solution: Configure the calling router and the answering router in conjunction with a remote access policy to use at least one common encryption method. See also: To configure encryption Cause: The VPN connection does not have the appropriate permissions through dial-in properties of the user account and remote access policies. Solution: Verify that the VPN connection has the appropriate permissions through dial-in properties of the user account and remote access policies. In order for the connection to be established, the settings of the connection attempt must: z Match all of the conditions of at least one remote access policy. z Be granted remote access permission through the user account (set to Allow access) or through the user

account (set to Control access through Remote Access Policy) and the remote access permission of the matching remote access policy (set to Grant remote access permission). z Match all the settings of the profile. z Match all the settings of the dial-in properties of the user account. See also: Introduction to remote access policies; Accepting a connection attempt Cause: The settings of the remote access policy profile are in conflict with properties of the answering router. The properties of the remote access policy profile and the properties of the answering router both contain settings for: z Multilink z Bandwidth allocation protocol z Authentication protocols

If the settings of the profile of the matching remote access policy are in conflict with the settings of the

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 85 of 87

answering router, the connection attempt is rejected. For example, if the matching remote access policy profile specifies that the EAP-TLS authentication protocol must be used and EAP is not enabled on the answering router, the connection attempt is rejected. Solution: Verify that the settings of the remote access policy profile are not in conflict with properties of the remote access router. See also: To enable authentication protocols; To configure authentication Cause: The credentials of the calling router (user name, password, and domain name) are incorrect and cannot be validated by the answering router. Solution: Verify that the credentials of the calling router (user name, password, and domain name) are correct and can be validated by the answering router. Cause: There are not enough addresses in the static IP address pool. Solution: If the answering router is configured with a static IP address pool, verify that there are enough addresses in the pool. If all of the addresses in the static pool have been allocated to connected remote access clients or demand-dial routers, the answering router is unable to allocate an IP address, and the connection attempt is rejected. Modify the static IP address pool if needed. See also: TCP/IP and remote access; To create a static IP address pool Cause: The answering router is configured with a range of IPX network numbers that are being used elsewhere on your IPX internetwork. Solution: Configure the answering router with a range of IPX network numbers that is unique to your IPX internetwork. See also: IPX and remote access Cause: The authentication provider of the answering router is improperly configured. Solution: Verify the configuration of the authentication provider. You can configure the answering router to use either Windows 2000 or RADIUS to authenticate the credentials of the VPN client. See also: Authentication and accounting providers; To use RADIUS authentication Cause: The answering router cannot access Active Directory. Solution: For an answering router that is a member server in mixed-mode or native-mode Windows 2000 domain that is configured for Windows 2000 authentication, verify that: z The RAS and IAS Servers security group exists. If not, then create the group and set the group type to

Security and the group scope to Domain local. z The RAS and IAS Servers security group has Read permission to the RAS and IAS Servers Access

Check object. z The computer account of the answering router computer is a member of the RAS and IAS Servers

security group. You can use the netsh ras show registeredserver command to view the current registration. You can use the netsh ras add registeredserver command to register the server in a specified domain. If you add (or remove) the answering router computer to the RAS and IAS Servers security group, the change does not take effect immediately (due to the way that Windows 2000 caches Active Directory information). For the change to take effect immediately, you need to restart the answering router computer. z For a native-mode domain, the answering router has joined the domain.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 86 of 87

See also: To add a group; To verify permissions for the RAS and IAS security group; NetShell commands for remote access Cause: An answering router running Windows NT 4.0 with the Routing and Remote Access Service (RRAS) cannot validate connection requests. Solution: If calling routers are dialing in to a answering router running Windows NT 4.0 with RRAS that is a member of a Windows 2000 mixed-mode domain, verify that the Everyone group is added to the Pre-Windows 2000 Compatible Access group with the net localgroup "Pre-Windows 2000 Compatible Access" command. If not, type net localgroup "Pre-Windows 2000 Compatible Access" everyone /add at a command prompt on a domain controller computer and then restart the domain controller computer. See also: Windows NT 4.0 remote access server in a Windows 2000 domain Cause: The answering router is unable to communicate with the configured RADIUS server. Solution: If your RADIUS server is only reachable through your Internet interface, add an input filter and output filter to the Internet interface for UDP port 1812 (based on RFC 2138, "Remote Authentication Dial-In User Service (RADIUS)") or UDP port 1645 (for older RADIUS servers) for RADIUS authentication and UDP port 1813 (based on RFC 2139, "RADIUS Accounting") or UDP port 1646 (for older RADIUS servers) for RADIUS accounting. See also: To add a packet filter Cause: Cannot ping the answering router from the Internet. Solution: Due to the PPTP and L2TP over IPSec packet filtering that is configured on the Internet interface of the answering router, Internet Control Message Protocol (ICMP) packets used by the ping command are filtered out. To enable ping capability on the answering router, you need to add an input filter and an output filter that allow traffic for IP protocol 1 (ICMP traffic). See also: To add a packet filter Unable to send and receive data. Cause: The appropriate demand-dial interface has not been added to the protocol being routed. Solution: Add the appropriate demand-dial interface to the protocol being routed. See also: To add a routing interface Cause: There are no routes on both sides of the router-to-router VPN connection that support the two-way exchange of traffic. Solution: Unlike a remote access VPN connection, a router-to-router VPN connection does not automatically create a default route. You need to create routes on both sides of the router-to-router VPN connection so that traffic can be routed to and from the other side of the router-to-router VPN connection. You can manually add static routes to the routing table, or you can add static routes through routing protocols. For persistent VPN connections, you can enable Open Shortest Path First (OSPF) or Routing Information Protocol (RIP) across the VPN connection. For on-demand VPN connections, you can automatically update routes through an auto-static RIP update. See also: To add an IP routing protocol; To add a static route; Perform auto-static updates Cause: A two-way initiated, router-to-router VPN connection is being interpreted by the answering router as a remote access connection.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Virtual private networks

Page 87 of 87

Solution: If the user name in the credentials of the calling router appears under Dial-In Clients in Routing and Remote Access, the answering router interpreted the calling router as a remote access client. Verify that the user name in the credentials of the calling router matches the name of a demand-dial interface on the answering router. If the incoming caller is a router, the port on which the call was received shows a status of Active and the corresponding demand-dial interface is in a Connected state. See also: To check the status of the port on the answering router; To check the status of the demand-dial interface Cause: Packet filters on the demand-dial interfaces of the calling router and answering router are preventing the flow of traffic. Solution: Verify that there are no packet filters on the demand-dial interfaces of the calling router and answering router that prevent the sending or receiving of traffic. You can configure each demand-dial interface with IP and IPX input and output filters to control the exact nature of TCP/IP and IPX traffic that is allowed into and out of the demand-dial interface. See also: Manage packet filters Cause: Packet filters on the remote access policy profile are preventing the flow of IP traffic. Solution: Verify that there are no configured TCP/IP packet filters on the profile properties of the remote access policies on the VPN server (or the RADIUS server if Internet Authentication Service is used) that are preventing the sending or receiving of TCP/IP traffic. You can use remote access policies to configure TCP/IP input and output packet filters that control the exact nature of TCP/IP traffic allowed on the VPN connection. Verify that the profile TCP/IP packet filters are not preventing the flow of needed traffic. See also: To configure IP options For more information, see Troubleshooting demand-dial routing.

file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh1071.htm

11/24/2003

Related Documents