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

  • Before installing a VPN server, see Checklist: Installing and configuring a VPN server.

  • Before installing a PPTP server, see Checklist: Installing and configuring a PPTP server.

  • To find features that have been moved in Windows 2000 Server, see New ways to do familiar tasks.

  • For tips about using VPNs, see Best practices.

  • For general background information, see Concepts.

  • For problem-solving instructions, see Troubleshooting.


Checklists

This section covers:

  • Checklist: Installing and configuring a VPN server

  • Checklist: Installing and configuring a PPTP server


Checklist: Installing and configuring a VPN server

Step | Reference
Review key concepts. | Virtual private networks overview
Install the hardware. | Manufacturer's documentation
Verify the compatibility of all hardware to be installed in the computer running Windows 2000. | Microsoft Windows Hardware Compatibility List at the Microsoft Web site (http://www.microsoft.com/)
Verify that the hardware is successfully installed on Windows 2000. | Device Manager
Install and configure the protocols. | Network communications
Install the Routing and Remote Access service. | To enable the Routing and Remote Access service
Configure the TCP/IP protocol. | TCP/IP and remote access
Configure the number of PPTP and L2TP ports needed. | To add PPTP or L2TP ports
Configure PPTP and L2TP over IPSec filters on the Internet interface. | Manage packet filters
Configure dial-in properties and remote access policies for dial-in permission, authentication, and encryption settings. | Introduction to remote access policies
(Optional) Configure the Windows 2000 remote access router as a RADIUS client. | To use RADIUS authentication
(Optional) Configure the IPX protocol. | IPX and remote access
(Optional) Configure the NetBEUI protocol. | NetBEUI and remote access


Checklist: Installing and configuring a PPTP server

Step | Reference
Review key concepts. | Virtual private networks overview
Install the hardware. | Manufacturer's documentation
Verify the compatibility of all hardware to be installed in the computer running Windows 2000. | Microsoft Windows Hardware Compatibility List at the Microsoft Web site (http://www.microsoft.com/)
Verify that the hardware is successfully installed on Windows 2000. | Device Manager
Install and configure the TCP/IP protocol. | Network communications
Install the Routing and Remote Access service. | To enable the Routing and Remote Access service
Configure the number of PPTP ports needed. | To add PPTP or L2TP ports
Configure PPTP filters on the Internet interface. | Add PPTP filters
Configure dial-in properties and remote access policies for dial-in permission, authentication, and encryption settings. | Introduction to remote access policies

Note

  • 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 Point-to-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:

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

  • Use strong authentication
    • 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.
    • 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.
    • 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.
  • 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.

  • 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:

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


Virtual private networks overview

This section covers:

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

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.

The logical equivalent of a virtual private network 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)

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

    3. 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 and demand-dial routing. There are two types of VPN connections:

  • Remote access VPN connection
  • 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 Point-to-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-to-Point 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:

  • Internet-based VPNs
  • 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.

Remote access over the Internet by using a virtual private network connection

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.

Connecting networks over the Internet by using a virtual private network connection

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

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.

Remote access over an intranet by using a virtual private network connection

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.

Connecting networks over an intranet by using a virtual private network connection


New features of virtual private networks for Windows 2000

Windows 2000 provides the following new features for virtual private networks:

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

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

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

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

  • 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:

  • 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

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

    • A computer that accepts VPN connections from VPN clients.

  • VPN client

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

  • Tunnel

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

  • 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

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

  • Tunneled data

    • Data that is usually sent across a private point-to-point link.

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

Components of a virtual private network

Note

  • 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 (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:

  • Encapsulation
  • Authentication
  • 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

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

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

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

  • Point-to-Point Tunneling Protocol
  • Layer Two Tunneling Protocol


VPN security

This section covers:

  • 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 PPTP-based VPN server running Windows 2000:

  1. The VPN client creates a PPTP tunnel with the VPN server.
  2. The server sends a challenge to the client.
  3. The client sends an encrypted response to the server.
  4. The server checks the response against the user accounts database.
  5. 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

  • 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. 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.
  2. The VPN client creates a L2TP tunnel with the VPN server.
  3. The server sends a challenge to the client.
  4. The client sends an encrypted response to the server.
  5. The server checks the response against the user accounts database.
  6. 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

  • Steps 3 through 5 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.

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

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

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

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


Using virtual private networks

This section covers:

  • Installing the Windows 2000 remote access router
  • Deploying virtual private networks
  • 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:

  • 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:

  • Setting up remote access VPNs
  • Setting up router-to-router VPNs
  • Setting up certificate-based authentication for VPN connections


Setting up remote access VPNs

This section covers:

  • Remote access VPN design considerations
  • Remote access VPN security
  • Deploying remote access VPNs


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.


Remote access VPN security

You can enhance remote access VPN security through:

  • 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:

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


Deploying remote access VPNs

This section covers:

  • PPTP-based remote access VPN
  • L2TP-based remote access VPN


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:

  • Machine certificates for L2TP over IPSec VPN connections
  • Smart cards and remote access VPN connections
  • 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:

  • By configuring the automatic allocation of computer certificates to computers in a Windows 2000 domain.
  • 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. 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.
  2. To auto-enroll machine certificates, configure the Windows 2000 domain. For more information, see To configure automatic certificate allocation from an enterprise CA.

    3. To create a computer certificate for the VPN server 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.


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

  • 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.
  • Enable smart card authentication on the VPN connection on the remote access client computer.

Configuring the remote access router to provide 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:

  • By configuring the automatic allocation of computer certificates to computers in a Windows 2000 domain.
  • 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. 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.
  2. To auto-enroll machine certificates, configure the Windows 2000 domain. For more information, see To configure automatic certificate allocation from an enterprise CA.

    3. 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. To prepare a certification authority to issue smart card certificates
  2. To prepare a smart card certificate enrollment station
  3. 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 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 dial-up or VPN connection. For more information, see To enable smart card or other certificate authentication.


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

  • 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:

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

Note

  • 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:

  • The network configuration
  • The remote access policy configuration
  • The domain configuration
  • The security configuration

The network configuration

The key elements of the network configuration are:

  • 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.
  • The VPN server computer is directly attached to the Internet by using a T3 (also known as a DS-3) dedicated WAN link.
  • 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.
  • 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.
  • 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.

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.

5. Configure static routes to reach intranet and Internet locations

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

  • 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:

  • 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

  • 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:

  • VPN_Users

    Used for remote access VPN connections

  • VPN_Routers

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

  • 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

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

Remote access for Electronic, Inc. employees

Domain configuration

For each employee that is allowed VPN access:

  • The remote access permission on the dial-in properties of the user account is set to Allow access.
  • The user account is added to the VPN_Users Windows 2000 group.

Remote access policy configuration

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

  • Policy name: Remote Access VPN Clients
  • Conditions:
    • NAS-Port-Type is set to Virtual (VPN)
    • Windows-Groups is set to VPN_Users
    • Called-Station-ID is set to 207.46.130.1
  • Permission is set to Grant remote access permission
  • Profile settings:
    • 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.
    • Encryption tab: Strongest is the only option that is selected.

Notes

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

  • 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 auto-enrollment. Then, the Make New Connection wizard is used to create VPN connection with the following setting:

  • Host name or IP address: vpn.electronic.microsoft.com

The VPN connection settings are modified as follows:

  • On the Networking tab, Type of dial-up server I am calling is set to Layer-2 Tunneling Protocol (L2TP).

Note

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

On-demand VPN connections for Electronic, Inc. branch offices

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:

  • Password of nY7W{q8~=z3.
  • 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.
  • 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:

  • Password of P*4s=wq!Gx1.
  • 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.
  • 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:

  • Policy name: VPN Routers
  • Conditions:
    • NAS-Port-Type is set to Virtual (VPN)
    • Windows-Groups is set to VPN_Routers
    • Called-Station-ID is set to 207.46.130.1
  • Permission is set to Grant remote access permission
  • Profile settings:
    • 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.
    • Encryption tab: Strongest is the only option that is selected.

Notes

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

  • The Dallas office: PPTP-based on-demand branch office
  • The Portland office: L2TP-based on-demand branch office

Note

  • 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:

  • Interface name

    ISP

  • Connection type

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

  • Select a device

    The appropriate ISDN device is selected.

  • Phone number or address

    Phone number of the ISP for the Dallas office.

  • Protocols and security

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

  • Dial-out credentials
    • User name: Dallas office ISP account name.
    • Domain: Dallas office ISP account domain name.
    • Password: Dallas office ISP account password.
    • 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:

  • Interface name

    CorpHQ

  • Connection type

    Connect using virtual private networking (VPN) is selected.

  • VPN type

    Point to Point Tunneling Protocol (PPTP) is selected.

  • Destination address

    207.46.130.1

  • Protocols and security

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

  • Dial-out credentials
    • User name: VPN_Dallas
    • Domain: electronic.microsoft.com
    • Password: nY7W{q8~=z3
    • Confirm password: nY7W{q8~=z3

Static route for corporate headquarters

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

  • 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:

  • 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, demand-dial filters are configured on the PPTP demand-dial interface. The following filter settings are configured:

  • Filter action: Only for the following traffic is selected.
  • 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

  • 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 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 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 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:

  • Interface name

    ISP

  • Connection type

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

  • Select a device

    The appropriate ISDN device is selected.

  • Phone number or address

    Phone number of the ISP for the Portland office.

  • Protocols and security

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

  • Dial-out credentials
    • User name: Portland office ISP account name.
    • Domain: Portland office ISP account domain name.
    • Password: Portland office ISP account password.
    • 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:

  • Interface name

    CorpHQ

  • Connection type

    Connect using virtual private networking (VPN) is selected.

  • VPN type

    Layer-2 Tunneling Protocol (L2TP) is selected.

  • Destination address

    207.46.130.1

  • Protocols and security

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

  • Dial-out credentials
    • User name: VPN_Portland
    • Domain: electronic.microsoft.com
    • Password: P*4s=wq!Gx1
    • 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:

  • 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:

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

L2TP over IPSec packet filters on the demand-dial 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, demand-dial filters are configured on the L2TP demand-dial interface. The following filter settings are configured:

  • Filter action: Only for the following traffic is selected.
  • 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

  • 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

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.

Persistent VPN connections for Electronic, Inc. branch offices

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:

  • Password of U9!j5dP(%q1.
  • For the dial-in properties on the VPN_Chicago account, the remote access permission is set to Allow access.
  • 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:

  • Password of z2F%s)bW$4f.
  • For the dial-in properties on the VPN_Phoenix account, the remote access permission is set to Allow access.
  • 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:

  • Password of o3\Dn6@`-J4.
  • For the dial-in properties on the VPN_CorpHQ account, the remote access permission is set to Allow access.
  • 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:

  • Policy name: VPN Routers
  • Conditions:
    • NAS-Port-Type is set to Virtual (VPN)
    • Windows-Groups is set to VPN_Routers
    • Called-Station-ID is set to 131.107.0.1
  • Permission is set to Grant remote access permission
  • Profile settings:
    • 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.
    • Encryption tab: Strongest is the only option that is selected.

Notes

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

  • Policy name: VPN Routers
  • Conditions:
    • NAS-Port-Type is set to Virtual (VPN)
    • Windows-Groups is set to VPN_Routers
    • Called-Station-ID is set to 131.107.128.1
  • Permission is set to Grant remote access permission
  • Profile settings:
    • 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.
    • Encryption tab: Strongest is the only option that is selected.

Notes

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

  • The Chicago office: PPTP-based persistent branch office
  • The Phoenix office: L2TP-based persistent branch office

Note

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

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:

  • Interface name

    VPN_Chicago

  • Connection type

    Connect using virtual private networking (VPN) is selected.

  • VPN type

    Point to Point Tunneling Protocol (PPTP) is selected.

  • Destination address

    131.107.0.1

  • Protocols and security

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

  • Dial-out credentials
    • User name: VPN_CorpHQ
    • Domain: electronic.microsoft.com
    • Password: o3\Dn6@`-J4
    • Confirm password: o3\Dn6@`-J4

Once the demand-dial interface is created, the following change is made:

  • 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:

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

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:

  • Interface name

    VPN_CorpHQ

  • Connection type

    Connect using virtual private networking (VPN) is selected.

  • VPN type

    Point to Point Tunneling Protocol (PPTP) is selected.

  • Destination address

    207.46.130.1

  • Protocols and security

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

  • Dial-out credentials
    • User name: VPN_Chicago
    • Domain: electronic.microsoft.com
    • Password: U9!j5dP(%q1
    • Confirm password: U9!j5dP(%q1

Once the demand-dial interface is created, the following change is made:

  • 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:

  • 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

  • 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:

  • 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

  • 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:

  • Interface name

    VPN_Phoenix

  • Connection type

    Connect using virtual private networking (VPN) is selected.

  • VPN type

    Layer-2 Tunneling Protocol (L2TP) is selected.

  • Destination address

    131.107.128.1

  • Protocols and security

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

  • Dial-out credentials
    • User name: VPN_CorpHQ
    • Domain: electronic.microsoft.com
    • Password: o3\Dn6@`-J4
    • Confirm password: o3\Dn6@`-J4

Once the demand-dial interface is created, the following change is made:

  • 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:

  • 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:

  • Interface name

    VPN_CorpHQ

  • Connection type

    Connect using virtual private networking (VPN) is selected.

  • VPN type

    Layer-2 Tunneling Protocol (L2TP) is selected.

  • Destination address

    207.46.130.1

  • Protocols and security

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

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

Once the demand-dial interface is created, the following change is made:

  • 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:

  • 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

  • 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:

  • 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

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

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.

Extranet connections for Electronic, Inc. 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:

  • Password of Y8#-vR7?]fI.
  • 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.
  • 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:

  • Password of W@8c^4r-;2\.
  • 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.
  • 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, 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:

  • Policy name: VPN Partners
  • Conditions:
    • NAS-Port-Type is set to Virtual (VPN)
    • Windows-Groups is set to VPN_Partners
    • Called-Station-ID is set to 207.46.130.1
  • Permission is set to Grant remote access permission
  • Profile settings:
    • On the IP tab, the following TCP/IP packet filters are configured:

      From client

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

      • To client

      • Filter action: Deny all traffic except those listed below
      • Filter 1: Source network IP address of 172.31.0.10 and subnet mask of 255.255.255.255
      • Filter 2: Source network IP address of 172.31.0.11 and subnet mask of 255.255.255.255
    • 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.
    • Encryption tab: Strongest is the only option that is selected.

Notes

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

  • Tasmanian Traders: PPTP-based extranet for business partners
  • Parnell Aerospace: L2TP-based extranet for business partners

Note

  • 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 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:

  • Interface name

    Electronic

  • Connection type

    Connect using virtual private networking (VPN) is selected.

  • VPN type

    Point to Point Tunneling Protocol (PPTP) is selected.

  • Destination address

    207.46.130.1

  • Protocols and security

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

  • Dial-out credentials
    • User name: PTR_Tasmanian
    • Domain: electronic.microsoft.com
    • Password: Y8#-vR7?]fI
    • 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:

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

Note

  • 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:

  • Interface name

    Electronic

  • Connection type

    Connect using virtual private networking (VPN) is selected.

  • VPN type

    Layer-2 Tunneling Protocol (L2TP) is selected.

  • Destination address

    207.46.130.1

  • Protocols and security

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

  • Dial-out credentials
    • User name: PTR_Parnell
    • Domain: electronic.microsoft.com
    • Password: W@8c^4r-;2\
    • 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:

  • 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

  • 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 modem-based 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.

RADIUS authentication and accounting

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

Remote access policies must be modified in two ways:

  1. The existing remote access policies that are configured on the VPN server running Windows 2000 must be copied to the IAS server.
  2. 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:

  • Policy name: Dial-Up for New York Employees
  • Conditions:
    • NAS-Port-Type is set to all types except Virtual (VPN)
    • Windows-Groups is set to NY_Employees
  • Permission is set to Grant remote access permission
  • Profile settings:
    • 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.
    • Encryption tab: All options are selected.

Note

  • 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:

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

Dial-up remote access client configuration

The Make New Connection wizard is used to create a dial-up connection with the following setting:

  • Phone number: 555-0111

Note

  • 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:

  • References
  • Virtual private networking RFCs
  • Troubleshooting tools


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

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


Troubleshooting

This section covers:

  • Troubleshooting remote access VPNs
  • 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 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:

  • Match all of the conditions of at least one remote access policy.
  • 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).
  • Match all the settings of the profile.
  • 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:

  • Multilink
  • Bandwidth allocation protocol
  • 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.

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:

  • 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.
  • The RAS and IAS Servers security group has Read permission to the RAS and IAS Servers Access Check object.
  • 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.

  • For a native-mode domain, the VPN server has joined the domain.

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

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:

  • Match all of the conditions of at least one remote access policy.
  • 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).
  • Match all the settings of the profile.
  • 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:

  • Multilink
  • Bandwidth allocation protocol
  • Authentication protocols

If the settings of the profile of the matching remote access policy are in conflict with the settings of the 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:

  • 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.
  • The RAS and IAS Servers security group has Read permission to the RAS and IAS Servers Access Check object.
  • 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.

  • For a native-mode domain, the answering router has joined the domain.

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.

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.