Virtual private networks

The Microsoft® Windows® Server 2003 Routing and Remote Access service provides virtual private network (VPN) services for remote access and router-to-router VPN connections by using either Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP) with Internet Protocol security (IPSec).

  • Before installing a VPN server, see Checklists.
  • To find features that have been moved in the Windows Server 2003 family, 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.

Note

  • XOX


Checklists

This section covers:

  • Checklist: Installing and configuring a VPN server
  • Checklist: Installing and configuring a PPTP server
  • Checklist: Installing and configuring an L2TP server

Note

  • XOX


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 a Windows Server 2003 operating system. | The Compatible Hardware and Software section at Support resources
Verify that the hardware is successfully installed. | Device Manager
Install the Routing and Remote Access service, and configure the server using the Routing and Remote Access Server Setup Wizard. | To enable the Routing and Remote Access service
Configure dial-in properties and remote access policies for dial-in permission, authentication, and encryption settings. | Introduction to remote access policies
Configure packet filters on your firewall. | VPN servers and firewall configuration
(Optional) Configure the virtual private network (VPN) server as a RADIUS client. | To use RADIUS authentication

Note

  • XOX


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 a Windows Server 2003 operating system. | The Compatible Hardware and Software section at Support resources
Verify that the hardware is successfully installed. | Device Manager
Install the Routing and Remote Access service, and configure the server using the Routing and Remote Access Server Setup Wizard. | To enable the Routing and Remote Access service
Configure packet filters on your firewall. | VPN servers and firewall configuration
Configure dial-in properties and remote access policies for dial-in permission, authentication, and encryption settings. | Introduction to remote access policies

Notes

  • Point-to-Point Tunneling Protocol (PPTP) is automatically installed.
  • XOX


Checklist: Installing and configuring an L2TP 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 a Windows Server 2003 operating system. | The Compatible Hardware and Software section at Support resources
Verify that the hardware is successfully installed. | Device Manager
Install the Routing and Remote Access service, and configure the server using the Routing and Remote Access Server Setup Wizard. | To enable the Routing and Remote Access service
Configure packet filters on your firewall. | VPN servers and firewall configuration
Install computer certificates on the Layer Two Tunneling Protocol (L2TP) server computer and L2TP client computers. | Computer certificates for L2TP/IPSec VPN connections; Network access authentication and certificates
Configure dial-in properties and remote access policies for dial-in permission, authentication, and encryption settings. | Introduction to remote access policies

Notes

  • L2TP is automatically installed.
  • XOX


New ways to do familiar tasks

The following table lists common tasks for configuring virtual private networks (VPNs). The user interface for performing these tasks is different in this version of Windows from the way it was in Windows NT 4.0 or Windows NT 4.0 with the Routing and Remote Access Service (RRAS).

Notes

  • XOX
  • XOX

Please choose your upgrade path:

Windows NT 4.0 to a product in the Windows Server 2003 family

If you want to | In Windows NT 4.0 use | In this version of Windows
Install the Point-to-Point Tunneling Protocol (PPTP) | 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 | Use 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) | PPTP packet filtering is set by default when you run the Routing and Remote Access Setup Wizard or set manually when you use Properties of the IP interface in General under IP Routing in Routing and Remote Access.

Windows NT 4.0 with RRAS to a product in the Windows Server 2003 family

If you want to | Windows NT 4.0 with RRAS use | In this version of Windows
Install the Point-to-Point Tunneling Protocol (PPTP) | 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 | Use Properties of Ports in Routing and Remote Access.
Set PPTP packet filtering | Properties of the IP interface in Summary under IP Routing in Routing and RAS Admin | PPTP packet filtering is set by default when you run the Routing and Remote Access Setup Wizard or set manually when you use Properties of IP interface in General under IP Routing in Routing and Remote Access.


Best practices

  • Use the virtual private network (VPN) server to allocate IP address leases to remote access clients.

    • If your VPN server handles more than 20 concurrent remote access connections, then use the VPN server to allocate IP address leases to remote access clients. When you create the IP address pool on the VPN server, be certain not to allocate addresses already in use by DHCP servers on your network.

    If you did not install a DHCP server, and you have a single subnet with computers configured with static IP addresses, configure the VPN server with an 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.

  • Use strong authentication.
    • Use strong passwords that are more than 8 characters long and 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 determine a password by sending a series of commonly used names and words.
    • Although EAP-TLS works with registry-based user certificates, it is highly recommended that you use only EAP-TLS with smart cards for remote access VPN connections. Because smart cards are distributed to trusted users and require a personal identification number (PIN), they are more secure than registry-based user certificates.
    • If you are using password-based user authentication, then use MS-CHAP version 2. You can obtain the latest MS-CHAP updates for VPN clients running Windows NT 4.0, Windows 95, or Windows 98 from Microsoft. For more information, see MS-CHAP version 2.
  • Use strong encryption.

    • Use the strongest level of encryption that your situation allows. The levels of encryption that are available when configuring the profile properties of a remote access policy are: Basic, Strong, and Strongest. For more information, see To configure encryption and Elements of a remote access policy.


Concepts

This section provides general background information about the virtual private network (VPN) services included with the Windows Server 2003 family:

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

Note

  • XOX


Virtual private networks overview

This section covers:

  • Security information for VPN
  • Virtual private networks
  • New features for virtual private networks
  • VPN connections
  • Types of virtual private networks


Security information for VPN

It is important to follow best practices for security when using VPN servers on your network. For more information, see Best practices for security.

If your VPN servers are configured as Remote Authentication Dial-In User Service (RADIUS) clients, see Security information for IAS.

The following are known security issues for VPN connections:

  • Many authentication methods are too weak to provide adequate security for most organizations.

    Many organizations use authentication methods that expose their network to a variety of security attacks. The most secure method of authentication is Extensible Authentication Protocol-Transport Level Security (EAP-TLS) when used in conjunction with smart cards. However, EAP-TLS and smart cards require a public key infrastructure (PKI), which can be complicated to deploy.

    Recommendations:

    • When you use password-based authentication, enforce strong password policies on your network to make dictionary attacks more difficult. For more information, see Creating strong passwords.
    • Make sure that Password Authentication Protocol (PAP), Shiva Password Authentication Protocol (SPAP), and Challenge Handshake Authentication Protocol (CHAP) are disabled. PAP, SPAP, and CHAP are disabled by default on the profile of a remote access policy.
    • Disable Microsoft Challenge Handshake Authentication Protocol (MS-CHAP). MS-CHAP is enabled by default on the profile of a remote access policy. Before you disable MS-CHAP, ensure that all of the clients of your access server are capable of using MS-CHAP version 2 (MS-CHAP v2). If your server is not running Microsoft® Windows® Server 2003, you will need the latest service packs and dial-up networking updates in order to support MS-CHAP v2.
    • If you do not disable MS-CHAP, disable LAN Manager authentication for MS-CHAP. LAN Manager authentication for MS-CHAP is enabled by default on clients running earlier versions of Windows.

      To disable LAN Manager authentication, set the registry value Allow LM Authentication to 0 at the following registry key:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy

      Caution

      • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

      Note

      • You can change an entry in the registry using Registry Editor. For more information, see Registry Editor and To change a value.
    • Make sure that MS-CHAP v2 is enabled. MS-CHAP v2 is enabled by default on the profile of a remote access policy.
    • For wireless clients running XOX, enable Protected Extensible Authentication Protocol (PEAP) with Extensible Authentication Protocol (EAP)-MS-CHAP v2. PEAP with EAP-MS-CHAP v2 provides mutual authentication: the IAS server is authenticated with a certificate, while user authentication is accomplished with password-based credentials. For more information, see New features for IAS. For an example of a remote access policy that uses PEAP, see Wireless access with PEAP-MS-CHAP v2.
    • Enable EAP-TLS. EAP-TLS is disabled by default on the profile of a remote access policy. When you use the EAP-TLS authentication protocol, you must install a computer certificate on the IAS server. For client and user authentication, you can install a certificate on the client computer, or you can use smart cards. Before you deploy certificates, you must design the certificate with the correct requirements. For more information, see Network access authentication and certificates and Computer certificates for certificate-based authentication.
  • Remote access account lockout can deny network access to authorized users.

    When remote access account lockout is enabled, if a malicious user attempts a dictionary attack with the logon name of an authorized user, both the malicious user and the authorized user are locked out of the account until the account lockout threshold is reached.

    Recommendations:

    • Be cautious when defining account lockout policy. For more information, see password Best practices.
    • When the lockout count for a user account is reset to 0, due to either a successful authentication or an automatic reset, the registry subkey for the user account is deleted. To manually unlock a user account (before the account lockout threshold is automatically reset), delete the following registry subkey that corresponds to the account name of the user:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\DomainName:UserName

      • Caution

      • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

    Notes

    • You can change an entry in the registry using Registry Editor. For more information, see Registry Editor and To change a value.
    • Remote access account lockout is not related to the Account locked out setting on the Account tab on the properties of a user account.
    • Remote access account lockout does not distinguish between malicious users who attempt to access your intranet and authentic users who attempt remote access but have forgotten their current passwords. Users who have forgotten their current password typically try the passwords that they remember and, depending on the number of attempts and the MaxDenials setting, might be locked out of their accounts.
  • The default domain functional level setting (Windows 2000 mixed) can create security holes.

    You should use only servers that are running Windows 2000 or Windows Server 2003, if possible. Using servers running Routing and Remote Access in conjunction with servers that are running Windows NT® 4.0 and either Remote Access Service (RAS) or Routing and Remote Access Service (RRAS) decreases your network security. For more information, see Domain and forest functionality and Member server in a mixed functionality or native functionality domain.

Additional recommendations:

  • Allow the VPN server or a DHCP server to assign IP address leases to VPN clients.

    Do not allow VPN clients to specify their own IP address. The method by which the VPN server assigns addresses to remote access clients (either using addresses that the VPN server obtains from a DHCP server or using addresses from a specified range of addresses that you configure) is set when you run the Routing and Remote Access Server Setup Wizard. For more information, see L2TP/IPSec remote access VPN deployment and DHCP.

  • Always use Layer Two Tunneling Protocol/Internet Protocol security (L2TP/IPSec) connections for the strongest encryption.

    Use smart cards for the most secure authentication and certificates when smart cards are not practical.

  • Use certificates for Internet Key Exchange (IKE) negotiations.

    Do not use preshared keys, as they are susceptible to dictionary attacks.

For more information about security considerations and best practices, see:

  • Network access authentication and certificates
  • VPN servers and firewall configuration
  • Best practices
  • VPN security
  • Remote access VPN security considerations
  • Router-to-router VPN security considerations
  • Deploying certificate-based authentication for VPN connections
  • Event Viewer
  • Security information for IAS
  • Security considerations for remote access
  • Security considerations for routing


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

Note

  • XOX

There are two types of Point-to-Point Protocol (PPP)-based VPN technology in the Microsoft Windows Server 2003 family:

  1. Point-to-Point Tunneling Protocol (PPTP)

    2. PPTP uses user-level 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 computer-level certificates with IPSec for data encryption, or IPsec in tunnel mode, in which IPsec itself provides encapsulation (for IP traffic only).

For more information on the types of VPN connections, see VPN connections. For information on how to design and deploy VPN connections, see Deploying virtual private networks.


New features for virtual private networks

The Microsoft® Windows® Server 2003 family provides the following new features for virtual private networks (VPNs):

  • Network address translation (NAT) transparency

    • VPN servers running Windows Server 2003 support Layer Two Tunneling Protocol over Internet Protocol security (L2TP/IPSec) traffic that originates from VPN clients behind NATs. For this feature to function properly, the client computer must support the following IPSec Protocol Working Group Internet drafts:

    • Negotiation of NAT-Traversal in the IKE (draft-ietf-ipsec-nat-t-ike-02.txt).
    • UDP Encapsulation of IPsec Packets (draft-ietf-ipsec-udp-encaps-02.txt).
  • VPN deployment with Network Load Balancing

    • VPN servers running Windows Server 2003 support VPN deployment in conjunction with Network Load Balancing to create high-availability VPN solutions. Support is included for Point-to-Point Tunneling Protocol (PPTP) and L2TP/IPSec VPN solutions with Network Load Balancing.

  • NetBIOS over TCP/IP (NetBT) name resolution proxy

    • When a remote access VPN client connects to a VPN server, it relies on DNS or WINS servers on the target network for name resolution.

    DNS and WINS servers are common in organizations that use DNS for host name resolution or WINS for NetBIOS name resolution. However, in a small office or home office environment, these servers might not be present. In this case, the names of the computers to which communications are attempted need to be resolved by another means for successful communication to occur.

    NetBIOS names can be resolved, without the use of a WINS or DNS server, by a VPN server running Windows Server 2003 because Windows Server 2003 operating systems include the NetBT proxy. With NetBT proxy, connected VPN clients and the nodes on network segments to which the VPN server is attached can resolve each other's NetBIOS names, as follows:

    1. When a VPN client needs to resolve a name to an IP address without a configured DNS or WINS server, it sends a NetBIOS Name Query packet to the VPN server. When a node on a network segment that is attached to the VPN server needs to resolve a name to an IP address without a configured DNS or WINS server, it sends a NetBIOS Name Query packet as a broadcast on the network segment.
    2. The VPN server receives the NetBIOS Name Query packet, checks its local cache of resolved NetBIOS names and, if the name is not found, forwards the NetBIOS Name Query as a NetBIOS broadcast on all attached interfaces, except the logical interface that is connected to all VPN clients.
    3. The node that has registered the NetBIOS name sends a positive NetBIOS Name Query Response to the VPN server.
    4. The VPN server receives the positive NetBIOS Name Query Response and then forwards it on the interface from which the NetBIOS Name Query packet originated to the sending node.

    The result is that network nodes on network segments that are attached to the VPN server (and all connected VPN clients) can automatically resolve each other's names without a DNS or WINS server.

  • Preshared key configuration for L2TP connections

    • The Windows Server 2003 family supports both computer certificates and a preshared key as authentication methods to establish an IPSec security association for L2TP connections. A preshared key is a string of text that is configured on both the VPN client and VPN server. Preshared key is a relatively weak authentication method, therefore it is recommended that you use preshared key authentication only while your public key infrastructure (PKI) is being deployed to obtain computer certificates or when a preshared key is required by VPN clients. You can enable the use of a preshared key for L2TP connections and specify the preshared key from the Security tab on the properties of a server running Routing and Remote Access. For more information, see To view properties of the remote access server.

    Preshared key authentication is also supported by remote access VPN clients running XOX. You can enable preshared key authentication and configure a preshared key from IPSec settings on the Security tab on the properties of a VPN connection in Network Connections. For more information, see To configure a pre-shared key on a remote access client.

    Preshared key authentication is also supported for router-to-router VPN connections between computers running a Windows Server 2003 operating system. You can enable preshared key authentication and configure a preshared key for demand-dial interfaces from IPSec settings on the Security tab on the properties of a demand-dial interface in Routing and Remote Access. For more information, see To configure a pre-shared key for a demand-dial routing interface and To configure a pre-shared key on a remote access server.

The following features for virtual private networks were new in Windows 2000:

  • L2TP

    • In addition to PPTP, the Windows Server 2003 family includes the industry standard L2TP, which is used in conjunction with IPSec to create secure virtual private network connections. The use of L2TP and IPSec is referred to as L2TP/IPSec.

  • 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 restraints. With remote access policies, you can force the use of strong authentication and encryption for VPN users and use a different set of authentication and encryption constraints for dial-up users.

    For more information, see Remote access policies.

  • MS-CHAP version 2

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

    For more information, see MS-CHAP version 2.

  • Extensible Authentication Protocol

    • Extensible Authentication Protocol (EAP) allows new authentication methods to be used, a feature that is especially important for the deployment of security based on smart cards. EAP is an architecture that allows other authentication modules to plug into PPP in Windows 2000, XOX, and products in the Windows Server 2003 family. Both EAP-MD5 CHAP and EAP-TLS (used for smart card and certificate-based authentication) are supported. You can configure your VPN server to handle authentication, or the VPN server can be configured to forward authentication requests to RADIUS servers.

    For more information, see EAP and Internet Authentication Service.

  • Remote access account lockout

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

    For more information, see Account lockout.


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

Note

  • XOX


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

Note

  • XOX

Computers running Microsoft Windows 95, Windows 98, Windows NT® 4.0, Windows 2000, Windows Millennium Edition, XOX, or a Windows Server 2003 operating system can create remote access VPN connections to a VPN server running Windows Server 2003. VPN clients may also be any non-Microsoft Point-to-Point Tunneling Protocol (PPTP) client or Layer Two Tunneling Protocol (L2TP) client with Internet Protocol security (IPSec).

For more information on PPTP and L2TP, see VPN tunneling protocols. For more information on deploying remote access VPN connections, see Deploying remote access VPNs. For an example implementation of a remote access VPN connection, see Virtual private network implementation examples.


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 Microsoft® Windows NT® 4.0 with the Routing and Remote Access Service (RRAS), Windows® 2000 Server, or a Windows Server 2003 operating system can create router-to-router VPN connections. VPN clients may also be any non-Microsoft Point-to-Point Tunneling Protocol (PPTP)-capable router or Layer Two Tunneling Protocol (L2TP)-capable router with Internet Protocol security (IPSec).

For more information on PPTP and L2TP, see VPN tunneling protocols. For more information on deploying router-to-router VPN connections, see Deploying router-to-router VPNs. For an example implementation of router-to-router VPN connections, see Virtual private network implementation examples. For information about creating router-to-router connections by using IPSec Encapsulating Security Payload (ESP) tunnel mode, see Tunnel mode.


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

For more information on deploying remote access VPN connections across the Internet, see Deploying remote access VPNs. For an example implementation of a remote access VPN connection across the Internet, see Virtual private network implementation examples.

Connecting networks over the Internet

When networks are connected over the Internet, a router forwards packets to another router across a VPN connection. This is known as a router-to-router 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.

For more information on deploying router-to-router VPN connections across the Internet, see Deploying router-to-router VPNs. For an example implementation of router-to-router VPN connections across the Internet, see Virtual private network implementation examples.

Note

  • XOX


Intranet-based VPNs

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

Remote access over an intranet

On 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 user rights 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 the user rights 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

For more information on deploying remote access VPN connections across an intranet, see Deploying remote access VPNs.

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

For more information on deploying router-to-router VPN connections across an intranet, see Deploying router-to-router VPNs.

Note

  • XOX


Understanding virtual private networks

This section covers:

  • Components of virtual private networks
  • Properties of VPN connections
  • A dial-up router-to-router VPN connection
  • VPN servers and firewall configuration
  • VPN servers and Microsoft ISA Server
  • Network access authentication and certificates
  • VPN tunneling protocols
  • VPN security


Components of virtual private networks

A 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. The Windows Server 2003 family 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 the Windows Server 2003 family, 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

Notes

  • Typically, the tunnel and the VPN connection are along the same portion of the connection. However, in a compulsory tunneling configuration, the tunnel (the encapsulation) and the VPN connection (the encryption) are not defined along the same portion of the connection.
  • XOX


Properties of VPN connections

VPN connections that use PPTP and L2TP/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 authorization. If mutual authentication is used, the VPN client also authenticates the VPN server, which provides protection against computers that are masquerading as VPN servers.

  2. Computer-level authentication by using IKE

    3. To establish an IPSec security association, the VPN client and the VPN server use the Internet Key Exchange (IKE) protocol to exchange either computer certificates or a preshared key. In either case, the VPN client and server authenticate each other at the computer level. Computer certificate authentication is highly recommended as it is a much stronger authentication method. For more information, see Internet Key Exchange. Computer-level authentication is only done for L2TP/IPSec connections.

  3. Data origin authentication and data 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 origin authentication and data integrity are only available for L2TP/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.

Note

  • XOX


A dial-up router-to-router VPN connection

A router-to-router VPN connection is typically used to connect remote offices together when both routers are connected to the Internet through permanent WAN links, such as T1 or Frame Relay. In this configuration, the VPN connection is always available. However, when a permanent WAN link is not possible or practical, you can configure a dial-up router-to-router VPN connection.

The following illustration shows a dial-up router-to-router VPN connection.

A dial-up router-to-router VPN connection

A dial-up router-to-router VPN connection consists of two demand-dial interfaces and two static routes that are configured on the VPN client (the calling router):

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

A dial-up router-to-router VPN connection is automatically established when you route traffic to a specific location. For example, in a branch office configuration, when a packet is received to be routed to the corporate office, the branch office router uses a dial-up link to connect to a local Internet service provider (ISP) and then creates a router-to-router VPN connection with the corporate office router located on the Internet.

Note

  • This discussion assumes that the corporate office router (the answering router) is connected to the Internet by using a permanent WAN link. It is possible to have both routers connected to the Internet by using a dial-up WAN link. However, this is only feasible if the ISP supports demand-dialing routing to customers; the ISP calls the customer router when an IP datagram is to be delivered to the customer. Demand-dial routing to customers is not widely supported by ISPs.

To configure a dial-up router-to-router VPN connection at the branch office router, do the following:

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

To configure the corporate office router, do the following:

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

The router-to-router VPN connection is automatically initiated by the branch office router through the following process:

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


VPN servers and firewall configuration

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

  • The VPN server is attached to the Internet, and the firewall is between the VPN server and the intranet.
  • The firewall is attached to the Internet, and the VPN server is between the firewall and the intranet.

VPN server in front of the firewall

When the VPN server is in front of the firewall and attached to the Internet, you need to add packet filters to the Internet interface that allow only VPN traffic to and from the IP address of the VPN server's Internet interface.

For inbound traffic, when the tunneled data is decrypted by the VPN server, it is forwarded to the firewall. Through the use of its filters, the firewall allows the traffic to be forwarded to intranet resources. Because the only traffic that crosses the VPN server is generated by authenticated VPN clients, in this scenario, firewall filtering can be used to prevent VPN users from accessing specific intranet resources. Because the only Internet traffic allowed on the intranet must pass through the VPN server, this approach also prevents the sharing of File Transfer Protocol (FTP) or Web intranet resources with non-VPN Internet users.

The following illustration shows the VPN server in front of the firewall.

The VPN server in front of the firewall

For the Internet interface on the VPN server, configure the following input and output filters using Routing and Remote Access:

Packet filters for Point-to-Point Tunneling Protocol (PPTP)

Configure the following input filters with the filter action set to Drop all packets except those that meet the criteria below:

  • Destination IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and TCP destination port of 1723.

    • This filter allows PPTP tunnel maintenance traffic from the PPTP client to the PPTP server.

  • Destination IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and IP Protocol ID of 47.

    • This filter allows PPTP tunneled data from the PPTP client to the PPTP server.

  • Destination IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and TCP [established] source port of 1723.

    • This filter is required only when the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. TCP [established] traffic is accepted only when the VPN server initiated the TCP connection.

Configure the following output filters with the filter action set to Drop all packets except those that meet the criteria below:

  • Source IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and TCP source port of 1723.

    • This filter allows PPTP tunnel maintenance traffic from the VPN server to the VPN client.

  • Source IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and IP Protocol ID of 47.

    • This filter allows PPTP tunneled data from the VPN server to the VPN client.

  • Source IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and TCP destination port of 1723.

    • This filter is required only when the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. TCP [established] traffic is sent only when the VPN server initiated the TCP connection.

For more information, see Add PPTP filters.

Packet filters for Layer Two Tunneling Protocol over Internet Protocol security (L2TP/IPSec)

Configure the following input filters with the filter action set to Drop all packets except those that meet the criteria below:

  • Destination IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and UDP destination port of 500.

    • This filter allows Internet Key Exchange (IKE) traffic to the VPN server.

  • Destination IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and UDP destination port of 1701.

    • This filter allows L2TP traffic from the VPN client to the VPN server.

  • Destination IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and UDP destination port of 4500.

    • This filter allows IPSec network address translator traversal (NAT-T) traffic.

Configure the following output filters with the filter action set to Drop all packets except those that meet the criteria below:

  • Source IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and UDP source port of 500.

    • This filter allows IKE traffic from the VPN server.

  • Source IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and UDP source port of 1701.

    • This filter allows L2TP traffic from the VPN server to the VPN client.

  • Source IP address of the VPN server's Internet interface, subnet mask of 255.255.255.255, and UDP source port of 4500.

    • This filter allows IPSec NAT-T traffic.

For more information, see Add L2TP/IPSec filters.

There are no filters required for Encapsulating Security Payload (ESP) traffic at the IP protocol of 50. The ESP header is removed by the IPSec components before the L2TP packet is passed to Routing and Remote Access.

VPN server behind the firewall

In a more common configuration, the firewall is attached to the Internet, and the VPN server is an intranet resource that is attached to the perimeter network. The VPN server has an interface on both the perimeter network and the intranet. In this scenario, the firewall must be configured with input and output filters on its Internet interface that allow tunnel maintenance traffic and tunneled data to pass to the VPN server. Additional filters can allow traffic to pass to Web, FTP, and other types of servers on the perimeter network. For an additional layer of security, the VPN server can also be configured with PPTP or L2TP/IPSec packet filters on its perimeter network interface.

Because the firewall does not have the encryption keys for each VPN connection, it can filter only on the plaintext headers of the tunneled data. In other words, all tunneled data passes through the firewall. This is not a security concern, however, because the VPN connection requires an authentication process that prevents unauthorized access beyond the VPN server.

The following illustration shows the VPN server behind the firewall on the perimeter network.

The VPN server behind the firewall on the perimeter network

For both the Internet and perimeter network interfaces on the firewall, configure the following input and output filters using the firewall's configuration software:

Packet filters for PPTP

Separate input and output packet filters can be configured on the Internet interface and the perimeter network interface.

Filters on the Internet interface

Configure the following input packet filters on the Internet interface of the firewall to allow the following types of traffic:

  • Destination IP address of the VPN server's perimeter network interface and TCP destination port of 1723 (0x6BB).

    • This filter allows PPTP tunnel maintenance traffic from the PPTP client to the PPTP server.

  • Destination IP address of the VPN server's perimeter network interface and IP Protocol ID of 47 (0x2F).

    • This filter allows PPTP tunneled data from the PPTP client to the PPTP server.

  • Destination IP address of the VPN server's perimeter network interface and TCP source port of 1723 (0x6BB).

    • This filter is required only when the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. This filter should be used only in conjunction with the PPTP packet filters described in VPN server in front of the firewall and configured on the VPN server's perimeter network interface. By allowing all traffic to the VPN server from TCP port 1723, there exists the possibility of network attacks from sources on the Internet that use this port.

Configure the following output filters on the Internet interface of the firewall to allow the following types of traffic:

  • Source IP address of the VPN server's perimeter network interface and TCP source port of 1723 (0x6BB).

    • This filter allows PPTP tunnel maintenance traffic from the VPN server to the VPN client.

  • Source IP address of the VPN server's perimeter network interface and IP Protocol ID of 47 (0x2F).

    • This filter allows PPTP tunneled data from the VPN server to the VPN client.

  • Source IP address of the VPN server's perimeter network interface and TCP destination port of 1723 (0x6BB).

    • This filter is required only when the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. This filter should be used only in conjunction with the PPTP packet filters described in VPN server in front of the firewall and configured on the VPN server's perimeter network interface. By allowing all traffic from the VPN server to TCP port 1723, there exists the possibility of network attacks from sources on the Internet using this port.

Filters on the perimeter network interface

Configure the following input filters on the perimeter network interface of the firewall to allow the following types of traffic:

  • Source IP address of the VPN server's perimeter network interface and TCP source port of 1723 (0x6BB).

    • This filter allows PPTP tunnel maintenance traffic from the VPN server to the VPN client.

  • Source IP address of the VPN server's perimeter network interface and IP Protocol ID of 47 (0x2F).

    • This filter allows PPTP tunneled data from the VPN server to the VPN client.

  • Source IP address of the VPN server's perimeter network interface and TCP destination port of 1723 (0x6BB).

    • This filter is required only when the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. This filter should be used only in conjunction with the PPTP packet filters described in VPN server in front of the firewall and configured on the VPN server's perimeter network interface. By allowing all traffic from the VPN server to TCP port 1723, there exists the possibility of network attacks from sources on the Internet using this port.

Configure the following output packet filters on the perimeter network interface of the firewall to allow the following types of traffic:

  • Destination IP address of the VPN server's perimeter network interface and TCP destination port of 1723 (0x6BB).

    • This filter allows PPTP tunnel maintenance traffic from the PPTP client to the PPTP server.

  • Destination IP address of the VPN server's perimeter network interface and IP Protocol ID of 47 (0x2F).

    • This filter allows PPTP tunneled data from the PPTP client to the PPTP server.

  • Destination IP address of the VPN server's perimeter network interface and TCP source port of 1723 (0x6BB).

    • This filter is required only when the VPN server is acting as a VPN client (a calling router) in a router-to-router VPN connection. This filter should be used only in conjunction with the PPTP packet filters described in VPN server in front of the firewall and configured on the VPN server's perimeter network interface. By allowing all traffic to the VPN server from TCP port 1723, there exists the possibility of network attacks from sources on the Internet using this port.

Packet filters for L2TP/IPSec

Separate input and output packet filters can be configured on the Internet interface and the perimeter network interface.

Filters on the Internet interface

Configure the following input packet filters on the Internet interface of the firewall to allow the following types of traffic:

  • Destination IP address of the VPN server's perimeter network interface and UDP destination port of 500 (0x1F4).

    • This filter allows IKE traffic to the VPN server.

  • Destination IP address of the VPN server's perimeter network interface and UDP destination port of 4500 (0x1194).

    • This filter allows IPSec NAT-T traffic to the VPN server.

  • Destination IP address of the VPN server's perimeter network interface and IP Protocol ID of 50 (0x32).

    • This filter allows IPSec ESP traffic from the VPN client to the VPN server.

Configure the following output packet filters on the Internet interface of the firewall to allow the following types of traffic:

  • Source IP address of the VPN server's perimeter network interface and UDP source port of 500 (0x1F4).

    • This filter allows IKE traffic from the VPN server.

  • Source IP address of the VPN server's perimeter network interface and UDP source port of 4500.

    • This filter allows IPSec NAT-T traffic from the VPN server.

  • Source IP address of the VPN server's perimeter network interface and IP Protocol ID of 50 (0x32).

    • This filter allows IPSec ESP traffic from the VPN server to the VPN client.

There are no filters required for L2TP traffic at the UDP port of 1701. All L2TP traffic at the firewall, including tunnel maintenance and tunneled data, is encrypted as an IPSec ESP payload.

Filters on the perimeter network interface

Configure the following input packet filters on the perimeter network interface of the firewall to allow the following types of traffic:

  • Source IP address of the VPN server's perimeter network interface and UDP source port of 500 (0x1F4).

    • This filter allows IKE traffic from the VPN server.

  • Source IP address of the VPN server's perimeter network interface and UDP source port of 4500.

    • This filter allows IPSec NAT-T traffic from the VPN server.

  • Source IP address of the VPN server's perimeter network interface and IP Protocol ID of 50 (0x32).

    • This filter allows IPSec ESP traffic from the VPN server to the VPN client.

Configure the following output packet filters on the perimeter network interface of the firewall to allow the following types of traffic:

  • Destination IP address of the VPN server's perimeter network interface and UDP destination port of 500 (0x1F4).

    • This filter allows IKE traffic to the VPN server.

  • Destination IP address of the VPN server's perimeter network interface and UDP destination port of 4500 (0x1194).

    • This filter allows IPSec NAT-T traffic to the VPN server.

  • Destination IP address of the VPN server's perimeter network interface and IP Protocol ID of 50 (0x32).

    • This filter allows IPSec ESP traffic from the VPN client to the VPN server.

There are no filters required for L2TP traffic at the UDP port of 1701. All L2TP traffic at the firewall, including tunnel maintenance and tunneled data, is encrypted as an IPSec ESP payload.


VPN servers and Microsoft ISA Server

Microsoft Internet Security and Acceleration (ISA) Server can be installed on a virtual private network (VPN) server running XOX; XOX; or XOX, and provides the capabilities of both the Windows Server 2003 Routing and Remote Access service and the ISA Server.

When ISA Server is installed, all of the packet filters that are configured on the VPN server are ignored by ISA. ISA creates its own packet filters when it is configured to allow VPN connections. After ISA is installed, use ISA Administrator, instead of Routing and Remote Access, to configure additional filters.

ISA Server includes two wizards that you can use to connect two ISA server computers with a router-to-router VPN connection:

  • Local ISA VPN Wizard

    • This wizard is used to create a .vpc (VPN configuration) file.

  • Remote ISA VPN Wizard

    • This wizard is used to read the .vpc file. After the servers have been configured, both ISA servers can initiate and accept VPN connections.

For more information about ISA Server packet filtering capabilities and support for VPNs, see Microsoft Internet Security and Acceleration (ISA) Server online Help.


Network access authentication and certificates

This topic contains the following sections:

  • Overview
  • Certificate requirements for EAP
  • Computer authentication by IPSec
  • Certificate-based authentication and wireless clients
  • Certificate enrollment methods and domain membership
  • Choosing a certificate enrollment method
  • CA Web enrollment services

Overview

Certificates are used for network access authentication because they provide strong security for authenticating users and computers and eliminate the need for less secure password-based authentication methods. This topic describes how Internet Authentication Service (IAS) and virtual private network (VPN) servers use Extensible Authentication Protocol-Transport Level Security (EAP-TLS), Protected Extensible Authentication Protocol (PEAP), or Internet Protocol security (IPSec) to perform certificate-based authentication for many types of network access, including VPN and wireless connections. Additionally, this topic describes certificate enrollment methods to help you determine the best certificate enrollment method for your use.

When discussing authentication, a server is defined as a VPN or IAS server that is a TLS end point. You can configure VPN servers to perform network access authentication without IAS, or you can use IAS for authentication when you have multiple Remote Access Dial-In User Service (RADIUS) clients (such as VPN servers and wireless access points) on your network.

Two authentication methods use certificates: Extensible Authentication Protocol-Transport Level Security (EAP-TLS) and Protected Extensible Authentication Protocol (PEAP). Both methods always use certificates for server authentication. Depending on the authentication type configured with the authentication method, certificates might be used for user authentication and client authentication. For more information, see EAP and PEAP.

The use of certificates for authentication of VPN connections is the strongest form of authentication available with the Windows Server 2003 family. You must use certificate-based authentication for VPN connections based on Layer Two Tunneling Protocol over Internet Protocol security (L2TP/IPSec). Point-To-Point Tunneling Protocol (PPTP) connections do not require certificates, although you can configure PPTP connections to use certificates for computer authentication when you use EAP-TLS as the authentication method. For wireless clients (computing devices with wireless network adapters, such as your portable computer or personal digital assistant), PEAP with EAP-TLS and smart cards or certificates is the recommended authentication method. For more information, see Layer Two Tunneling Protocol, Point-to-Point Tunneling Protocol, and Wireless networking.

Notes

  • During authentication attempts for PPTP connections, computer authentication does not occur. When EAP-TLS is used as the authentication method with PPTP connections, user authentication is performed with a certificate from the certificate store on the local computer or from a smart card.
  • XOX
  • XOX

In order to deploy certificates to users and computers, you must first do the following:

  • Design a public key infrastructure (PKI).
  • Deploy a certification authority (CA) using Certificate Services.
  • Design and publish one or more certificates using Certificate Templates, which is installed with Certificate Services.
  • Select one or more distribution methods (also known as certificate enrollment methods) to install the certificates on computers and distribute them to users.

Notes

  • This topic assumes that you have designed and deployed a PKI according to the guidelines provided in Certificate Services Best Practices. For more information, see Public key infrastructure.
  • PEAP is not supported for VPN or dial-up connections.

For more information on L2TP, see Layer Two Tunneling Protocol.

For more information on PPTP, see Point-to-Point Tunneling Protocol.

Example certificate deployments

  • Remote access VPN connections

    • L2TP/IPSec or PPTP connections between VPN server and VPN client with EAP-TLS used as the authentication method. IPSec uses computer certificates between the client and the server for authentication, and EAP-TLS uses a certificate (from a smart card or the user's local certificate store) for user authentication. The IAS or VPN server certificate must contain the Server Authentication purpose, and the client computer or user certificate must contain the Client Authentication purpose in the Enhanced Key Usage (EKU) extensions of the certificate.

    For more information, see L2TP-based remote access VPN deployment and PPTP-based remote access VPN deployment.

  • Router-to-router VPN connections

    • L2TP/IPSec connections for dedicated or dial-on-demand connections between servers with EAP-TLS as the authentication method. Both servers must have certificates that contain the Server Authentication and Client Authentication purposes in EKU extensions.

    For more information, see Deploying router-to-router VPNs.

  • IEEE 802.1X wireless or switch clients

    • PEAP-EAP-MS-CHAPv2 is configured as the authentication method, and the Validate server certificate option is enabled on the client computers. The IAS server certificate EKU extensions contain the Server Authentication purpose, and the certificate is used to identify the server to the client. User authentication is accomplished with user name and password.

    For more information, see To enable smart card or other certificate authentication, Configuring wireless network settings, and To define 802.1X authentication on a client computer.

  • IEEE 802.1X wireless or switch clients

    • L2TP/IPSec is used, and EAP-TLS with certificates is configured as the authentication method. The IAS server certificate contains the Server Authentication purpose in EKU extensions to identify itself to the client, and the client uses a certificate (from a smart card or the user's local certificate store) to identify itself to the IAS server. (The wireless access points are configured as RADIUS clients on the IAS server, which is the EAP authenticator.)

    For more information, see To define 802.1X authentication in Group Policy.

Note

  • User authentication and network access authorization are performed by either the VPN server or a RADIUS server, such as Internet Authentication Service (IAS), as configured on the VPN gateway. For more information, see To use RADIUS authentication.

Certificate requirements for EAP

When you use EAP with a strong EAP type (such as TLS with smart cards or certificates), both the client and the server use certificates to verify their identities to each other. Certificates must meet specific requirements in order to allow the server and the client to use them for successful authentication.

One such requirement is that the certificate is configured with one or more purposes in EKU extensions that correlate to the certificate use. For example, a certificate used for the authentication of a client to a server must be configured with the Client Authentication purpose. Similarly, a certificate used for the authentication of a server must be configured with the Server Authentication purpose. When certificates are used for authentication, the authenticator examines the client certificate, seeking the correct purpose object identifier in EKU extensions. For example, the object identifier for the Client Authentication purpose is 1.3.6.1.5.5.7.3.2.

Certificate Templates allow customization of the certificates issued by Certificate Services, including both how certificates are issued and what they contain, including their purposes. In Certificate Templates, you can use a default template, such as the Computer template, to define the template that the CA uses to assign certificates to computers. You can also create a certificate template and assign purposes in EKU extensions to the certificate. By default, the Computer template includes the Client Authentication purpose and the Server Authentication purpose in EKU extensions.

The certificate template that you create can include any purpose for which the certificate will be used. For example, if you use smart cards for authentication, you can include the Smart Card Logon purpose in addition to the Client Authentication purpose.

When using IAS, you can configure IAS to check certificate purposes before granting network authorization. IAS can check additional EKUs and Issuance Policy purposes (also known as Certificate Policies).

Some non-Microsoft CA software might contain a purpose named All, which represents all possible purposes. This is indicated by a blank (or null) EKU extension. Although All means all possible purposes, the All purpose cannot be substituted for the Client Authentication purpose, the Server authentication purpose, or any other purpose related to network access authentication.

For more information, see Certificate Templates and Manage certificate templates for an enterprise certification authority.

You can view certificates and their purposes by using the Certificates console to open the certificate store. Certificate stores can be viewed in Logical Store mode or in Purpose mode. For information about how to view certificate purposes, see To display certificate stores in Purpose mode.

Minimum certificate requirements

All certificates that are used for network access authentication must meet the requirements for X.509 certificates and work for connections that use Secure Sockets Layer-Transport Level Security (SSL/TLS). After this minimum requirement is met, both client and server certificates have additional requirements.

Client certificate requirements

With EAP-TLS or PEAP-EAP-TLS, the server accepts the client authentication attempt when the certificate meets the following requirements:

  • The client certificate is issued by an enterprise CA or mapped to a user or computer account in Active Directory.
  • The user or computer certificate on the client chains to a trusted root CA, includes the Client Authentication purpose in EKU extensions (the object identifier for Client Authentication is 1.3.6.1.5.5.7.3.2), and fails neither the checks that are performed by CryptoAPI and specified in the remote access policy nor the Certificate object identifier checks that are specified in IAS remote access policy.
  • The 802.1X client does not use registry-based certificates that are either smart card-logon or password-protected certificates.
  • For user certificates, the Subject Alternative Name (SubjectAltName) extension in the certificate contains the user principal name (UPN). To configure the UPN name in a certificate template:
    1. Open Certificate Templates.
    2. In the details pane, right-click the certificate template that you want to change, and then click Properties.
    3. Click the Subject Name tab, and then click Build from this Active Directory information.
    4. In Include this information in alternate subject name, select User principal name (UPN).
  • For computer certificates, the Subject Alternative Name (SubjectAltName) extension in the certificate must contain the client's fully qualified domain name (FQDN), which is also called the DNS name. To configure this name in the certificate template:
    1. Open Certificate Templates.
    2. In the details pane, right-click the certificate template that you want to change, and then click Properties.
    3. Click the Subject Name tab, and then click Build from this Active Directory information.
    4. In Include this information in alternate subject name, select DNS name.

With PEAP-EAP-TLS and EAP-TLS, clients display a list of all installed certificates in the Certificates snap-in, with the following exceptions:

  • Wireless clients do not display registry-based and smart card-logon certificates.
  • Wireless clients and VPN clients do not display password-protected certificates.
  • Certificates that do not contain the Client Authentication purpose in EKU extensions are not displayed.

Server certificate requirements

Clients can be configured to validate server certificates by using the Validate server certificate option. With PEAP-EAP-MS-CHAPv2, PEAP-EAP-TLS, or EAP-TLS as the authentication method, the client accepts the server's authentication attempt when the certificate meets the following requirements:

  • The Subject name contains a value. If you issue a certificate to your IAS server that has a blank Subject, the certificate is not available to authenticate your IAS server. To configure the certificate template with a Subject name:
    1. Open Certificate Templates.
    2. In the details pane, right-click the certificate template that you want to change, and then click Properties.
    3. Click the Subject Name tab, and then click Build from this Active Directory information.
    4. In Subject name format, select a value other than None.
  • The computer certificate on the server chains to a trusted root CA and does not fail any of the checks that are performed by CryptoAPI and specified in the remote access policy.
  • The IAS or VPN server computer certificate is configured with the Server Authentication purpose in EKU extensions (the object identifier for Server Authentication is 1.3.6.1.5.5.7.3.1).
  • The server certificate is configured with a required cryptographic service provider (CSP) value of Microsoft RSA SChannel Cryptographic Provider. To configure the required CSP:
    1. Open Certificate Templates.
    2. In the details pane, right-click the certificate template that you want to change, and then click Properties.
    3. Click the Request Handling tab, and then click CSPs.
    4. In CSP Selection, select Requests must use one of the following CSPs.
    5. In CSPs, select the Microsoft RSA SChannel Cryptographic Provider checkbox. Clear all other checkboxes in CSPs.
  • The Subject Alternative Name (SubjectAltName) extension, if used, must contain the DNS name of the server. To configure the certificate template with the DNS name of the enrolling server:
    1. Open Certificate Templates.
    2. In the details pane, right-click the certificate template that you want to change, and then click Properties.
    3. Click the Subject Name tab, and then click Build from this Active Directory information.
    4. In Include this information in alternate subject name, select DNS name.

With PEAP and EAP-TLS, servers display a list of all installed certificates in the computer's certificate store, with the following exceptions:

  • Certificates that do not contain the Server Authentication purpose in EKU extensions are not displayed.
  • Certificates that do not contain a Subject name are not displayed.
  • Servers do not display registry-based and smart card-logon certificates.

Note

  • You can designate which certificate is used by the IAS or VPN server in the remote access policy profile. When you configure EAP and PEAP authentication methods that require a certificate for server authentication and you do not select a specific certificate in the Smart Card or other Certificate Properties dialog box, the IAS or VPN server automatically selects a certificate from the computer certificate store. If the server obtains a newer certificate, it uses the new certificate. This might cause the IAS or VPN server to use a certificate that is not correctly configured for authentication, causing authentication to fail as the result. To prevent this, always select a server certificate when configuring PEAP and EAP authentication methods that require one. For more information, see To configure PEAP and EAP methods.

Computer authentication by IPSec

Computer authentication is first performed during L2TP/IPSec connection attempts between remote access client and server. When a secure channel is established between the client and the server, the user authentication and authorization attempt proceeds.

Computer authentication by IPSec is performed using preshared keys or computer certificates. The recommended method of authentication is the use of a PKI and certificates. If certificates are used, a computer certificate is required to establish IPSec trust during the Internet Key Exchange (IKE) negotiation in L2TP/IPSec-based VPN connections.

In order for a VPN server running Windows Server 2003 and a VPN client running Windows 2000 or XOX to establish trust for an L2TP/IPSec VPN connection, both computers must have a computer certificate that was issued by the same trusted enterprise root CA. When both computers have and exchange certificates that were issued by the trusted root CA during IPSec negotiation, they extend trust to each other, and the security association is made.

How VPN servers use certificates

When an L2TP/IPSec VPN connection is attempted between VPN client and server, computer authentication fails if the VPN client certificate (from a smart card or the certificate store on the local computer) is not configured with the Client Authentication purpose in EKU extensions, and the VPN server certificate is not configured with the Server Authentication purpose in EKU extensions. IPSec checks the EKU extensions for the client certificate to determine whether the Client Authentication purpose object identifier is present. When the EKU extension includes the Client Authentication purpose object identifier, IPSec can use the certificate for authentication. Similarly, the client checks the VPN server certificate for the Server Authentication purpose object identifier in EKU extensions.

Although VPN servers that end connections for remote users need a certificate configured with the Server Authentication purpose in EKU extensions only, a VPN servers that is used as an end point for a VPN connection with another VPN server originates (as a client) and ends (as a server) VPN connections. For this reason, the certificate on these servers must contain both the Server Authentication purpose and the Client Authentication purpose in EKU extensions. In addition, due to the way in which automatic certificate selection functions, both purposes (Server Authentication and Client Authentication) must be contained in the same certificate.

Automatic certificate selection can provide IPSec with any certificate in the certificate store that chains to the trusted enterprise root CA, regardless of the purposes contained in the certificate. If two certificates are installed on the server—one that contains the Client Authentication purpose and one that contains the Server Authentication purpose—it is possible that automatic certificate selection could use the wrong certificate for authentication. For example, the certificate with the Client Authentication purpose might be required, but the certificate provided through automatic certificate selection contains the Server Authentication purpose. In this and similar instances, computer authentication fails.

Certificate-based authentication and wireless clients

IEEE 802.1X authentication provides authenticated access to 802.11 wireless networks and to wired Ethernet networks. 802.1X provides support for secure EAP types, such as TLS with smart cards or certificates. You can configure 802.1X with EAP-TLS in a variety of ways. If the Validate server certificate option is configured on the XOX client, the client authenticates the server by using its certificate. Client computer and user authentication can be accomplished using certificates from the client certificate store or a smart card, providing mutual authentication.

With wireless clients, PEAP-EAP-MS-CHAPv2 can be used as the authentication method. PEAP-EAP-MS-CHAPv2 is a password-based user authentication method that uses TLS with server certificates. During PEAP-EAP-MS-CHAPv2 authentication, the IAS or RADIUS server supplies a certificate to validate its identity to the client (if the Validate server certificate option is configured on the XOX client). Client computer and user authentication is accomplished with passwords, which eliminates some of the difficulty of deploying certificates to wireless client computers.

802.1X wireless and switch clients can also use PEAP-EAP-TLS, which provides strong security. PEAP-EAP-TLS uses a public key infrastructure (PKI) with certificates used for server authentication and either smart cards or certificates for client computer and user authentication. For more information, see PEAP.

For more information about 802.1X authentication, see Understanding 802.1X authentication.

Certificate enrollment methods and domain membership

The domain membership of computers for which you want to enroll certificates affects the certificate enrollment method that you can choose. Certificates for domain member computers can be enrolled automatically (also known as auto-enrollment), while an administrator must enroll certificates for non-domain member computers using the Web or a floppy disk. The certificate enrollment method for non-domain member computers is known as a trust bootstrap process, through which certificates are created and then manually requested or distributed securely by administrators, to build common trust.

Domain member certificate enrollment

If your VPN server, IAS server, or client running Windows 2000 or XOX is a member of a domain running Windows Server 2003 and Active Directory, you can configure the auto-enrollment of computer and user certificates. After auto-enrollment is configured and enabled, all domain member computers receive computer certificates when Group Policy is refreshed next, whether the refresh is triggered manually with the gpupdate command, or by logging on to the domain.

If your computer is a member of a domain where Active Directory is not installed, you can install computer certificates manually by requesting them through Certificates.

For more information, see Computer certificates for L2TP/IPSec VPN connections.

Note

  • Computers running Windows 2000 can auto-enroll computer certificates only.

Non-domain member certificate enrollment

Certificate enrollment for computers that are not domain members cannot be done with auto-enrollment. When a computer is joined to a domain, a trust is established that allows auto-enrollment to occur without administrator intervention. When a computer is not joined to a domain, trust is not established and a certificate is not issued. Trust must be established using one of the following methods:

  • An administrator (who is, by definition, trusted) must request a computer or user certificate using the CA Web enrollment tool.
  • An administrator must save a computer or user certificate to a floppy disk and install it on the non-domain member computer. Or, when the computer is not accessible to the administrator (for example, a home computer connecting to an organization network with an L2TP/IPSec VPN connection), a domain user whom the administrator trusts can install the certificate.
  • An administrator can distribute a user certificate on a smart card (computer certificates are not distributed on smart cards).

Many network infrastructures contain VPN and IAS servers that are not domain members. For example, a VPN server in a perimeter network might not be a domain member for security purposes. In this case, a computer certificate with the Server Authentication purpose contained in the EKU extensions must be installed on the non-domain member VPN server before it can successfully negotiate L2TP/IPSec-based VPN connections with clients. Note that if the non-domain member VPN server is used as an end point for a VPN connection with another VPN server, EKU extensions must contain both the Server Authentication and Client Authentication purposes.

Choosing a certificate enrollment method

If you are running an enterprise certification authority (CA) on a computer running XOX, you can use the following table to determine the best certificate enrollment method for your requirements:

Object and domain membership | Certificate template | Certificate purposes | Preferred certificate enrollment method | Alternate certificate enrollment method
VPN or IAS server, domain member | Computer | Server Authentication | Auto-enrollment | Request a certificate with the Certificates snap-in
VPN server with site-to-site connection, domain member | Computer | Server Authentication and Client Authentication | Auto-enrollment | Request a certificate with the Certificates snap-in
XOX client, domain member | Computer | Client Authentication | Auto-enrollment | Request a certificate with the Certificates snap-in
VPN or IAS server, non-domain member | Computer | Server Authentication | CA Web enrollment tool | Install from a floppy disk
VPN server with site-to-site connection, non-domain member | Computer | Server Authentication and Client Authentication | CA Web enrollment tool | Install from a floppy disk
XOX client, non-domain member | Computer | Client Authentication | CA Web enrollment tool | Install from a floppy disk
User, domain user | User | Client Authentication | Auto-enrollment | Use a smart card or the CA Web enrollment tool

If you are running an enterprise certification authority (CA) on a computer running XOX, XOX, the 64-bit version of XOX, or the 64-bit version of XOX, you can use the following certificate templates:

Object and domain membership | Certificate template | Certificate purpose | Preferred certificate enrollment method | Alternate certificate enrollment method
VPN or IAS server, domain member | RAS and IAS Server | Server Authentication | Auto-enrollment | Request a certificate with the Certificates snap-in
XOX client, domain member | Workstation Authentication | Client Authentication | Auto-enrollment | Request a certificate with the Certificates snap-in
VPN or IAS server, non-domain member | RAS and IAS Server | Server Authentication | CA Web enrollment tool | Install from a floppy disk
XOX client, non-domain member | Workstation Authentication | Client Authentication | CA Web enrollment tool | Install from a floppy disk

Important

If your server running IAS is not a domain controller but is a member of a domain with a Windows 2000 mixed functional level, you must add the server to the access control list (ACL) of the RAS and IAS Server certificate template. You must also configure the correct permissions for autoenrollment. There are different procedures for adding single servers and groups of servers to the ACL.

To add an individual server to the ACL for the RAS and IAS Server certificate template:

In Certificate Templates, select the template RAS and IAS Server, and then add the IAS server to the template Security properties. For more information, see To allow subjects to request a certificate that is based on the template. After you have added your IAS server to the ACL, grant Read, Enroll, and Autoenroll permissions.

To manage a group of servers, add the servers to a new global or universal group, and then add the group to the ACL of the certificate template:

  1. In Active Directory Users and Computers, create a new global or universal group for IAS servers. For more information, see To create a new group. Next, add to the group all computers that are IAS servers, are not domain controllers, and are members of a domain with a Windows 2000 mixed functional level. For more information, see To add a member to a group.
  2. In Certificate Templates, select the RAS and IAS Server template, and then add the group you created to the template Security properties by completing the steps in To allow subjects to request a certificate that is based on the template. After you have added your new group, grant Read, Enroll, and Autoenroll permissions.

For more information, see Domain and forest functionality.

CA Web enrollment services

A set of CA Web pages is provided with Certificate Services in the Windows Server 2003 family. These Web enrollment pages allow you to connect to the CA through a Web browser and perform common tasks, such as requesting certificates from a CA.

For more information, see Certification authority Web enrollment services, Using Certificate Services Web pages, and To set up certification authority Web enrollment support.

After your PKI has been designed and deployed and you are assigned the required permissions on the certificate templates, you can request certificates for computers by using the CA Web enrollment pages. You can request a certificate for a non-domain member computer using the CA Web enrollment tool by completing the following steps. You must be an administrator on the local computer to complete these steps.

Install a computer certificate on the local computer

  1. Use your Web browser to log onto the Web enrollment tool at http://ServerName/certsrv, where ServerName is the name of the server hosting the CA, the CA Web pages, or both. Click Request a certificate.
  2. In Request a certificate, click Advanced Certificate Request.
  3. In Advanced Certificate Request, click Create and submit a request to this CA. A Web form that contains the sections Certificate Template, Key Options, and Additional Options becomes available. Select the following:
    • Certificate template: Administrator
    • Key options: Create new key set
    • CSP: Microsoft Enhanced Cryptographic Provider v1.0
    • Key usage: Exchange
    • Key size: 1024
    • Automatic key container name: Selected
    • Mark keys as exportable: Selected
    • Use local machine store: Selected
    • Request format: PKCS 10
    • Hash: SHA-1
    • Friendly name: VPN server name
  4. Click Submit.
  5. Click Install this certificate.

    6. The certificate you requested is installed on your local computer.

Save a computer certificate to floppy disk

  1. Use your Web browser to log onto the Web enrollment tool at http://ServerName/certsrv, where ServerName is the name of the server hosting the CA, the CA Web pages, or both. Click Request a certificate.
  2. In Request a certificate, click Advanced Certificate Request.
  3. In Advanced Certificate Request, click Create and submit a request to this CA. A Web form that contains the sections Certificate Template, Key Options, and Additional Options becomes available. Select the following:
    • Certificate template: Administrator
    • Key options: Create new key set
    • CSP: Microsoft Enhanced Cryptographic Provider v1.0
    • Key usage: Exchange
    • Key size: 1024
    • Automatic key container name: Selected
    • Mark keys as exportable: Selected
    • Export keys to file: Selected
    • Full path name: The path location where you want to save the file and the file name (for example, \\ServerName\ShareName\FileName.pvk.).
    • Request format: PKCS 10
    • Hash: SHA-1
    • Friendly name: VPN server name
  4. Click Submit.
  5. Create and confirm your private key password.
  6. In Certificate Issued, select DER encoded and Download certificate chain.
  7. Insert a floppy disk in your disk drive.
  8. When prompted by your browser, select Save this file to disk, and then click OK.
  9. Browse to your floppy drive, and then click OK.

    10. The certificate you requested is downloaded and saved to floppy disk.

For more information, see To submit an advanced certificate request via the Web.

For information about installing a certificate from floppy to the certificate store of a local computer, see To import a certificate.

Note

  • If you have issued a certificate to your IAS server that has a blank Subject, the certificate is not available to authenticate your IAS server. To change this, you can use Certificate Templates to create a new certificate for enrollment on your IAS server. In the certificate properties, on the Subject Name tab, in Subject name format, select a value other than None.


VPN tunneling protocols

This section covers:

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


Point-to-Point Tunneling Protocol

Point-to-Point Tunneling Protocol (PPTP) is a tunneling protocol first supported in Windows NT 4.0 and Windows 98. PPTP is an extension of Point-to-Point Protocol (PPP) and leverages the authentication, compression, and encryption mechanisms of PPP. Client support for PPTP is built-in to the XOX remote access client.

VPN server support for PPTP is built in to members of the Windows Server 2003 family. PPTP is installed with the TCP/IP protocol. Depending on your choices when running the Routing and Remote Access Server Setup Wizard, PPTP is configured for five or 128 PPTP ports. For more information, see Checklist: Installing and configuring a PPTP server.

PPTP and Microsoft Point-to-Point Encryption (MPPE) provide the primary VPN services of encapsulation and encryption of private data.

Encapsulation

A PPP frame (an IP, IPX, or Appletalk datagram) is wrapped with a Generic Routing Encapsulation (GRE) header and an IP header. In the IP header is the source and destination IP address that correspond to the VPN client and VPN server.

The following illustration shows PPTP encapsulation for a PPP frame.

PPTP encapsulation

Encryption

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

For more information on deploying PPTP-based VPN connections, see Deploying virtual private networks. For a PPTP-based VPN server checklist, see Checklist: Installing and configuring a PPTP server. For an example implementation of PPTP-based VPN connections, see Virtual private network implementation examples. For information on configuring PPTP-based VPN connections in a test lab, see Virtual private network test lab.

Notes

  • It is possible to have a nonencrypted PPTP connection where the PPP frame is sent in plaintext. However, a nonencrypted PPTP connection is not recommended for VPN connections over the Internet because communications of this type are not secure.
  • XOX
  • XOX


Layer Two Tunneling Protocol

Layer Two Tunneling Protocol (L2TP) is an RFC-based tunneling protocol that is an industry standard and was first supported in the Windows 2000 client and server operating systems. Unlike PPTP, L2TP in servers running Windows Server 2003 does not utilize Microsoft Point-to-Point Encryption (MPPE) to encrypt Point-to-Point Protocol (PPP) datagrams. L2TP relies on Internet Protocol security (IPSec) for encryption services. The combination of L2TP and IPSec is known as L2TP/IPSec. L2TP/IPSec provides the primary virtual private network (VPN) services of encapsulation and encryption of private data.

Both L2TP and IPSec must be supported by both the VPN client and the VPN server. Client support for L2TP is built-in to the XOX remote access client, and VPN server support for L2TP is built in to members of the Windows Server 2003 family.

L2TP is installed with the TCP/IP protocol. Depending on your choices when running the Routing and Remote Access Server Setup Wizard, L2TP is configured for five or 128 L2TP ports. For more information, see Checklist: Installing and configuring an L2TP server.

For more information about IPSec, see IP Security overview.

Encapsulation

Encapsulation for L2TP/IPSec packets consists of two layers:

  1. L2TP encapsulation

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

  2. IPSec encapsulation

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

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

L2TP and IPSec encapsulation

Encryption

The L2TP message is encrypted with either Data Encryption Standard (DES) or Triple DES (3DES) by using encryption keys generated from the Internet Key Exchange (IKE) negotiation process.

For more information on deploying L2TP/IPSec VPN connections, see Deploying virtual private networks. For configuration checklists, see Checklists. For an example implementation of L2TP/IPSec VPN connections, see Virtual private network implementation examples. For information on configuring L2TP/IPSec VPN connections in a test lab, see Virtual private network test lab.

Notes

  • It is possible to have a nonencrypted L2TP connection where the PPP frame is sent in plaintext. However, a nonencrypted L2TP connection is not recommended for virtual private network connections over the Internet because communications of this type do not provide data confidentiality.
  • XOX
  • XOX


VPN security

This section covers:

  • Authorization
  • Authentication
  • Data encryption
  • Packet filtering


Authorization

Virtual private network (VPN) connections are only accepted for those users and routers that have been authorized. In the Windows Server 2003 family, 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 additional user accounts just for VPN connections. VPN servers use the user accounts specified in the available user accounts databases according to security in Windows Server 2003 operating systems.

How security works at connection

The following steps describe what happens during a connection attempt from a Point-to-Point Tunneling Protocol (PPTP)-based VPN client to a PPTP-based VPN server running Windows Server 2003:

  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 the connection is authorized, 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 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 Layer Two Tunneling Protocol over Internet Protocol security (L2TP/IPSec)-based VPN client to an L2TP/IPSec-based VPN server running Windows Server 2003:

  1. The IPSec security association is created by using computer certificates and the Internet Key Exchange (IKE) negotiation process.
  2. The VPN client creates an 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 the connection is authorized, 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 security in Windows Server 2003 operating systems—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 VPN 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 a Windows Server 2003 domain.

You use packet filters based on a remote access policy profile to restrict access for remote access VPN connections for IP traffic. 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 remote access traffic except traffic specified by the filters or no traffic except traffic specified by the filters. Remote access policy profile filtering applies to all remote access connections that match the remote access policy.

For more information, see Elements of a remote access policy.

Credential caching

When remote access servers are configured to accept a user's domain credentials (user name and password) as the means for authenticating access requests, the credentials used for remote access are the same as those needed for access to network resources (such as file servers, application servers, and e–mail servers). Each time the remote access client tries to access a server on the network, the server challenges the client for its credentials to ensure that only authorized users can utilize server resources.

If the client computer is a member of the server's domain, then the client responds automatically with the user's logon credentials and gains access to resources for which the user has security permissions. If the client computer is not a member of the server's domain (for example, when the client is a non-domain member home computer), then the client does not have the appropriate logon credentials to meet the server's challenge; for each network resource the user attempts to access, the user is either prompted to enter credentials or is denied access.

When the client is running XOX or a Windows Server 2003 operating system, the credentials that are used for authentication to the remote access server are cached, or saved, by the client. If the non-domain member client attempts to access a domain server for which it has not previously established its credentials, the client responds to the server's challenge with the cached remote access credentials and gains access to resources for which the user has security permissions. Because the credentials are cached and sent automatically upon server challenge, users on non-domain member computers are not prompted for credentials every time they attempt to access network resources.


Authentication

The authentication of virtual private network (VPN) clients by the VPN server is a vital security concern. Authentication takes place at two levels:

  1. Computer-level authentication

    2. When Internet Protocol security (IPSec) is used for a Layer Two Tunneling Protocol (L2TP) over IPSec (L2TP/IPSec) VPN connection, computer-level authentication is performed through the exchange of computer certificates or a preshared key during the establishment of the IPSec security association. For more information, see Internet Key Exchange.

  2. User-level authentication

    3. Before data can be sent over the Point-to-Point Tunneling Protocol (PPTP) or L2TP tunnel, the remote access client 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.

For more information, see Network access authentication and certificates.


Data encryption

You must use data encryption to provide data confidentiality for the data that is sent between the VPN client and the VPN server across a 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, the Windows Server 2003 family 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 Point-to-Point Protocol (PPP) or PPTP connections is available only if you use MS-CHAP, MS-CHAP v2, or EAP-TLS as the user-level authentication method. Data encryption for L2TP connections relies on IPSec computer-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 use PPTP or L2TP/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/IPSec packet filters, a step that is done automatically when you configure your remote access server using the Routing and Remote Access Setup Wizard.

Because, by default, IP routing is enabled on intranet interfaces and the interface that corresponds to the connection to the Internet, the computer running a Windows Server 2003 operating system forwards IP packets between the Internet and your intranet. This provides a direct, routed connection between your intranet and possible attackers 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 use PPTP or L2TP/IPSec filters on the Internet interface.

If you have a firewall, you must configure packet filters on the firewall to allow traffic between the VPN router and the routers on the Internet. For more information, see VPN servers and firewall configuration.

For more information about PPTP filters, see Add PPTP filters. For more information about L2TP/IPSec filters, see Add L2TP/IPSec filters.


Deploying virtual private networks

This section covers:

  • Deploying remote access VPNs
  • Deploying router-to-router VPNs
  • Deploying certificate-based authentication for VPN connections
  • Virtual private network implementation examples
  • Virtual private network test lab


Deploying remote access VPNs

This section covers:

  • Planning for remote access VPNs
  • Remote access VPN deployment


Planning for remote access VPNs

This section covers:

  • Remote access VPN design considerations
  • Remote access VPN security considerations


Remote access VPN design considerations

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

  • Choosing between PPTP-based connections or L2TP/IPSec connections
  • Installing certificates
  • Configuring firewall packet filters
  • Creating a remote access policy for remote access VPN connections
  • Using an IAS server
  • Using Connection Manager

For more information, see Remote access VPN connection.

Note

  • XOX

Choosing between PPTP-based connections or L2TP/IPSec connections

A VPN server running Windows Server 2003 provides support for both Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP). When choosing between PPTP-based and L2TP/IPSec remote access VPN solutions, consider the following:

  • PPTP can be used with a variety of Microsoft clients including Windows 95 (with the Dial-up Networking Upgrade 1.3 and later), Windows 98, Windows Millennium Edition, Windows NT 4.0, Windows 2000, and XOX. PPTP does not require a public key infrastructure (PKI) to issue computer certificates. By using encryption, PPTP-based VPN connections provide data confidentiality (captured packets cannot be interpreted without the encryption key). PPTP-based VPN connections, however, do not provide data integrity (proof that the data was not modified in transit) or data origin authentication (proof that the data was sent by the authorized user).
  • L2TP can only be used with client computers running Windows 2000 or XOX. L2TP supports either computer certificates or a preshared key as the authentication method for Internet Protocol security (IPSec). Computer certificate authentication, the recommended authentication method, requires a PKI to issue computer certificates to the VPN server computer and all VPN client computers. By using IPSec, L2TP/IPSec VPN connections provide data confidentiality, data integrity, and data authentication.

Installing certificates

In order to create L2TP/IPSec remote access VPN connections using computer certificate authentication for IPSec, you must install computer certificates, also known as machine certificates, on the VPN client and the VPN server. For more information, see Network access authentication and certificates and Computer certificates for L2TP/IPSec VPN connections.

Configuring firewall packet filters

If you have a firewall, you must configure packet filters on the firewall to allow traffic between VPN clients on the Internet and the VPN server. For more information, see VPN servers and firewall configuration.

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 an Active Directory 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 Server 2003, 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 XOX; XOX; or XOX; and 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 of remote access policies available in products in the Windows Server 2003 family. 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 considerations

You can enhance remote access VPN security through:

  • L2TP connections
  • Strong authentication
  • Data encryption
  • PPTP or L2TP/IPSec packet filtering
  • Firewall packet filtering
  • Multi-use VPN servers
  • Preventing traffic routed from remote access clients
  • Remote access policy profile packet filtering

For more information, see Remote access VPN connection.

Note

  • XOX

L2TP connections

A VPN server running Windows Server 2003 provides support for both Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP). By using encryption, PPTP-based VPN connections provide data confidentiality (captured packets cannot be interpreted without the encryption key). PPTP-based VPN connections, however, do not provide data integrity (proof that the data was not modified in transit) or data origin authentication (proof that the data was sent by the authorized user). By using Internet Protocol Security (IPSec), L2TP/IPSec VPN connections provide data confidentiality, data integrity, and data origin authentication. However, L2TP can only be used with Windows 2000 and XOX clients.

L2TP/IPSec connections can use the following methods to authenticate the IPSec security association:

  • A computer certificate

    • Computer certificates are the recommended method of authentication as they provide strong authentication and are very difficult to impersonate or compromise. Computer certificate authentication requires a public key infrastructure (PKI) to issue computer certificates to the VPN server computer and all VPN client computers.

  • A preshared key

    • A preshared key is a string of text that is configured on both the VPN client and VPN server. Preshared key is a relatively weak authentication method, therefore it is only recommended that you use preshared key authentication while your PKI is being deployed or when preshared key is required by the VPN server to which your VPN clients are connecting.

Strong user authentication

For user 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 Deploying certificate-based authentication for VPN connections and Network access authentication and certificates.

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 with link encryption:

  • Link encryption encrypts the data only on the link between the VPN client and the VPN server. For PPTP connections, you must use Microsoft Point-to-Point Encryption (MPPE) in conjunction with either MS-CHAP, MS-CHAP v2, or EAP-TLS authentication. For L2TP/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, 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.

Encryption on client computers is configured in the properties of the network connection.

PPTP or L2TP/IPSec filtering

To secure the VPN server from sending or receiving any traffic on its Internet interface except VPN traffic, you need to ensure that PPTP or L2TP/IPSec input and output filters are configured 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/IPSec filters, see Add L2TP/IPSec filters.

Because IP routing is enabled on the Internet interface, if PPTP or L2TP/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.

Firewall packet filtering

It is a common practice to provide protection to intranet hosts, such as a VPN server, from Internet hosts using a firewall. If you have a firewall, you must configure packet filters on the firewall to allow traffic to and from VPN clients on the Internet and the VPN server. For more information, see VPN servers and firewall configuration.

Multi-use VPN servers

Due to the way in which routes are created on VPN remote access clients, it is possible for the VPN client to send some unencrypted traffic to the VPN server rather than through the encrypted tunnel of the VPN connection. For example, the VPN client might connect to other services running on the VPN server without routing traffic across the VPN connection. Only traffic that is destined to the public IP address of the VPN server is sent in the clear. If traffic from the client uses the internal or private interface IP address of the VPN server, however, it will be encrypted.

When a remote access VPN client creates a VPN connection with a VPN server, it creates a series of routes in the IP routing table on the VPN client:

  • Default route that uses the VPN connection

    • The new default route for the VPN connection effectively replaces the existing default route for the duration of the connection. After the connection is made, all traffic that does not match an address on the directly connected network or the address of the VPN server is sent in an encrypted form over the VPN connection.

  • Host route to the VPN server that uses the local network connection

    • The host route for the address of the VPN server is created so that the VPN server is reachable using the locally attached network. If the host route is not present, VPN traffic to the VPN server cannot be sent.

The result of having the host route for the VPN server is that all traffic that is sent to applications running on the VPN server is not sent across the VPN connection, but is instead sent in an unencrypted form across the network between the VPN client and VPN server.

For example, when a remote access VPN client creates a VPN connection with a VPN server and then accesses a shared file on the VPN server computer, that traffic is not sent using the VPN connection. The file sharing traffic is sent in plaintext over the network between the VPN client and VPN server.

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

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

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

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

Before the VPN connection is made, the VPN client uses the Internet DNS infrastructure to resolve the name of the VPN server computer to its public IP addresses. After the VPN connection is made, assuming that intranet DNS and WINS servers are configured either during the PPP connection process or through the relaying of the DHCPInform message, the VPN client uses the intranet DNS and WINS infrastructures to resolve the name of the VPN server computer to its intranet IP addresses.

Preventing traffic routed through remote access clients

Once a remote access client successfully establishes a PPTP or L2TP connection, by default any packet sent over the connection is received by the VPN server and forwarded. Packets sent over the connection can include:

  • Packets originated from the remote access client computer.
  • Packets sent to the remote access client computer by other computers.

When the remote access client computer makes the VPN connection, by default it creates a default route so that all traffic that matches the default route is sent over the VPN connection. If other computers are forwarding traffic to the remote access VPN client, treating the remote access client computer as a router, then that traffic may also be forwarded across the VPN connection. This is a security problem because the computer that is sending traffic to the remote access VPN client has not been authenticated by the VPN server. The computer sending traffic to the remote access VPN client computer has physical network access to the same resources as the authenticated remote access VPN client computer.

To prevent the VPN server from sending traffic across the VPN connection for computers other than authenticated remote access VPN client computers, configure the following remote access policy packet filters on the remote access policy that is used for your VPN connections:

  • From client filter:

    • Filter action set to Deny all traffic except those listed below.

    IP Packet Filter Field | Setting
Source Address | User's address
Source Network Mask | User's mask
Destination Address | Any
Destination Network Mask | Any
Protocol | Any
  • To client filter:

    • Filter action set to Deny all traffic except those listed below.

    IP Packet Filter Field | Setting
Source Address | Any
Source Network Mask | Any
Destination Address | User's address
Destination Network Mask | User's mask
Protocol | Any

This set of IP packet filters will cause the VPN server to discard all traffic sent across the VPN connection except those that either originated from or is sent to authenticated remote access VPN clients.

Remote access policy profile packet filtering

To define the specific types of IP traffic that are allowed for remote access VPN connections, 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 from remote access clients (From client filters) or to remote access clients (To client 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 remote access connections that match the remote access policy. For more information, see Elements of a remote access policy and To configure IP options.


Remote access VPN deployment

This section covers:

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


PPTP-based remote access VPN deployment

You can use remote access with products in the Windows Server 2003 family to provide access to a corporate intranet for remote access clients who are making PPTP connections across the Internet. If you want your remote access server to support multiple PPTP connections, complete the following steps:

  • Configure the connection to the Internet.
  • Configure the connection to the intranet.
  • Configure the remote access server as a corporate intranet router.
  • Configure the VPN server.
  • Configure firewall packet filters.
  • Configure remote access policies.

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

A remote access server providing PPTP-based remote access

For more information, see Remote access VPN connection and Point-to-Point Tunneling Protocol.

Note

  • XOX

Configuring the connection to the Internet

The connection to the Internet from a computer running a Windows Server 2003 operating system is a dedicated connection—a WAN adapter installed in the computer. The WAN adapter is typically a DDS, T1, Fractional T1, or Frame Relay adapter. You must contract with a local telephone company to run the appropriate physical wiring to your premises. You need to verify that the WAN adapter is compatible with products in the Windows Server 2003 family. To verify compatibility, see the Compatible Hardware and Software section at Support resources.

The WAN adapter includes drivers that are installed in memobers of the Windows Server 2003 family so that the WAN adapter appears as a network adapter.

You need to configure the following TCP/IP settings on the WAN adapter:

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

So that VPN clients can connect to your VPN server by name (rather than IP address), you can request DNS registration of your VPN server by your ISP.

Configuring the connection to the intranet

The connection to the intranet from a computer running a Windows Server 2003 operating system is a LAN adapter that is installed in the computer. You need to verify that the LAN adapter is compatible with products in the Windows Server 2003 family. To verify compatibility, see the Compatible Hardware and Software section at Support resources.

You need to configure the following TCP/IP settings on the LAN adapter:

  • IP address and subnet mask assigned from the network administrator.
  • DNS and WINS name servers of corporate intranet name servers.

Configuring the remote access server as a corporate intranet router

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

Configuring the VPN server

You can configure your VPN server by running the Routing and Remote Access Server Setup Wizard. You can configure the following settings using the wizard:

  • A basic firewall on the public interface.
  • The method by which the VPN server assigns addresses to remote access clients (either using addresses that the VPN server obtains from a DHCP server or using addresses from a specified range of addresses that you have configured on the VPN server).
  • Forwarding of authorization and authentication messages to a Remote Access Dial-In User Service (RADIUS) server (configuration of the VPN server as a RADIUS client).

Once the wizard is run, these Routing and Remote Access settings are automatically configured:

  • Network interfaces
  • PPTP and L2TP ports (5 or 128 of each, depending on your choices when running the wizard)
  • Multicast support using Internet Group Messaging Protocol (IGMP)
  • IP routing
  • Installation of the DHCP Relay Agent component.

For more information on enabling Routing and Remote Access and running the wizard, see To enable the Routing and Remote Access service.

Configuring firewall packet filters

If you are using a firewall, you need to configure PPTP packet filters on your firewall to allow PPTP traffic between Internet-based VPN clients and the VPN server computer. For more information, see VPN servers and firewall configuration.

Configuring remote access policies

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

To configure a remote access policy to control the authentication and encryption options for VPN connections, you can create a remote access policy with the following settings:

  • Set Policy name to VPN Access (example).
  • For conditions, set the NAS-Port-Type condition to Virtual (VPN) and the Tunnel-Type condition to Point-to-Point Tunneling Protocol.
  • Select the Grant remote access permission option.
  • For profile settings, select the appropriate authentication and encryption options.

Then, either delete the default remote access policies or position them after the new policy. This remote access policy allows all users with remote access permission to create a VPN connection.

If you want to distinguish dial-up remote access users from VPN remote access users, do the following:

  1. Create an Active Directory group whose members can create virtual private networking connections with the VPN server. For example, VPN_Users.
  2. Add the appropriate user accounts to the new Active Directory group.
  3. Create a new remote access policy with the following properties:
    • Set Policy name to VPN Access if member of VPN_Users (example).
    • For conditions, set the Windows-Groups condition to VPN_Users (example), set the NAS-Port-Type condition to Virtual (VPN), and set the Tunnel-Type condition to Point-to-Point Tunneling Protocol.
    • Select the Grant remote access permission option.
  4. Move the default remote access policies after the new policy.

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

  • Basic

    You can use this option when communicating with older Microsoft dial-up networking clients. This option uses Microsoft Point-to-Point Encryption (MPPE) and a 40-bit encryption key.

  • Strong

    You can use this option when communicating with dial-up networking clients running Windows 98, Windows 2000, or XOX. This option uses MPPE and a 56-bit encryption key.

  • Strongest

    You can use this option when communicating with dial-up networking clients running Windows 98, Windows 2000, or XOX. This option uses MPPE and a 128-bit encryption key.

For more information, see To configure encryption.


L2TP-based remote access VPN deployment

You can use remote access with products in the Windows Server 2003 family to provide access to a corporate intranet for remote access clients who are making Layer Two Tunneling Protocol over Internet Protocol security (L2TP/IPSec) connections across the Internet. If you want your remote access server to support multiple L2TP/IPSec connections, complete the following steps:

  • Configure the connection to the Internet.
  • Configure the connection to the intranet.
  • Configure the remote access server as a corporate intranet router.
  • Configure the VPN server.
  • Install certificates.
  • Configure firewall packet filters.
  • Configure remote access policies.

The following illustration shows the elements of a remote access server running Windows Server 2003 that provides L2TP/IPSec remote access to a corporate intranet.

A remote access server providing L2TP/IPSec remote access

For more information, see Remote access VPN connection and Layer Two Tunneling Protocol.

Notes

  • The following configuration assumes that computer certificates, also known as machine certificates, are already installed on the VPN server and remote access client computers. For more information, see Computer certificates for L2TP/IPSec VPN connections and Network access authentication and certificates.
  • XOX

Configuring the connection to the Internet

The connection to the Internet from a computer running a Windows Server 2003 family operating system is a dedicated connection—a WAN adapter installed in the computer. The WAN adapter is typically a DDS, T1, Fractional T1, or Frame Relay adapter. You must contract with a local telephone company to run the appropriate physical wiring to your premises. You need to verify that the WAN adapter is compatible with products in the Windows Server 2003 family. To verify compatibility, see the Compatible Hardware and Software section at Support resources.

The WAN adapter includes drivers that are installed in members of the Windows Server 2003 family so that the WAN adapter appears as a network adapter.

You need to configure the following TCP/IP settings on the WAN adapter:

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

To enable VPN clients to connect to your VPN server by name rather than by IP address, request that your ISP register your VPN server in DNS.

Configuring the connection to the intranet

The connection to the intranet from a computer running a Windows Server 2003 operating system is a LAN adapter that is installed in the computer. You need to verify that the LAN adapter is compatible with products in the Windows Server 2003 family. To verify compatibility, see the Compatible Hardware and Software section at Support resources.

You need to configure the following TCP/IP settings on the LAN adapter:

  • IP address and subnet mask assigned from the network administrator.
  • DNS and WINS name servers of corporate intranet name servers.

Configuring the remote access server as a corporate intranet router

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

Configuring the VPN server

You can configure your VPN server by running the Routing and Remote Access Server Setup Wizard. You can use the wizard to configure the following settings:

  • A basic firewall on the public interface.
  • The method by which the VPN server assigns addresses to remote access clients (either using addresses that the VPN server obtains from a DHCP server or using addresses from a specified range of addresses that you configure).
  • Forwarding of authorization and authentication messages to a Remote Authentication Dial-In User Service (RADIUS) server (configuration of the VPN server as a RADIUS client).

Once the wizard is run, the following Routing and Remote Access settings are automatically configured:

  • Network interfaces
  • PPTP and L2TP ports (five or 128 of each, depending on the choices you made when you ran the wizard)
  • Multicast support using Internet Group Management Protocol (IGMP)
  • IP routing
  • Installation of the DHCP Relay Agent component.

For more information about enabling Routing and Remote Access and running the wizard, see To enable the Routing and Remote Access service.

Installing certificates

In order to create L2TP/IPSec remote access VPN connections using computer certificate authentication for IPSec, you must install computer certificates, also known as machine certificates, on the VPN client and the VPN server. For more information, see Network access authentication and certificates and Computer certificates for L2TP/IPSec VPN connections.

Configuring firewall packet filters

If you are using a firewall, you need to configure L2TP/IPSec packet filters on your firewall to allow L2TP/IPSec traffic between Internet-based VPN clients and the VPN server computer. For more information, see VPN servers and firewall configuration.

Configuring remote access policies

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

To configure a remote access policy to control the authentication and encryption options for VPN connections, create a remote access policy with the following settings:

  • Set Policy name to VPN Access (example).
  • For conditions, set the NAS-Port-Type condition to Virtual (VPN) and the Tunnel-Type condition to Layer Two Tunneling Protocol.
  • Select the Grant remote access permission option.
  • For profile settings, select the appropriate authentication and encryption options.

Then, either delete the default remote access policies or position them after the new policy. This remote access policy allows all users with remote access permission to create a VPN connection.

If you want to distinguish dial-up remote access users from VPN remote access users, do the following:

  1. Create an Active Directory group whose members can create virtual private networking connections with the VPN server. For example, VPN_Users.
  2. Add the appropriate user accounts to the new Active Directory group.
  3. Create a new remote access policy with the following properties:
    • Set Policy name to VPN Access if member of VPN_Users (example).
    • For conditions, set the Windows-Groups condition to VPN_Users (example), set the NAS-Port-Type condition to Virtual (VPN), and set the Tunnel-Type condition to Layer Two Tunneling Protocol.
    • Select the Grant remote access permission option.
  4. Move the default remote access policies after the new policy.

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

  • Basic

    This option uses 56-bit DES encryption.

  • Strong

    This option uses 56-bit DES encryption.

  • Strongest

    This option uses triple DES (3DES) encryption.

For more information, see To configure encryption.


Deploying router-to-router VPNs

This section covers:

  • Planning for router-to-router VPNs
  • Router-to-router VPN deployment


Planning for router-to-router VPNs

This section covers:

  • Router-to-router VPN design considerations
  • Router-to-router VPN security considerations


Router-to-router VPN design considerations

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

  • PPTP-based or L2TP/IPSec connections
  • Installing certificates
  • On-demand or persistent connections
  • Restricting the initiation of an on-demand connection
  • One-way or two-way initiated connections
  • Number of PPTP or L2TP ports needed
  • Configuring firewall packet filters
  • Routing
  • Single hop across VPN connection
  • Creating a remote access policy for router-to-router VPN connections

For more information, see Router-to-router VPN connection.

PPTP-based or L2TP/IPSec connections

A VPN server running Windows Server 2003 provides support for both Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP). When choosing between PPTP and L2TP/IPSec router-to-router VPN solutions, consider the following:

  • PPTP can be used for router-to-router VPN connections for routers running Windows NT Server 4.0 with the Routing and Remote Access Service (RRAS), Windows 2000 Server, or Windows Server 2003 operating systems. PPTP does not require a public key infrastructure (PKI) to issue computer certificates. By using encryption, PPTP-based VPN connections provide data confidentiality—captured packets cannot be interpreted without the encryption key. PPTP-based VPN connections, however, do not provide data integrity (proof that the data was not modified in transit) or data origin authentication (proof that the data was sent by the authorized user).
  • L2TP can be used only with routers running Windows 2000 Server or Windows Server 2003 operating systems. When both types of routers are used, a public key infrastructure (PKI) is required to issue computer certificates to all routers. Routers running Windows Server 2003 operating systems additionally support a single preshared key configured on the answering router and all calling routers. By using Internet Protocol Security (IPSec), L2TP/IPSec VPN connections provide data confidentiality, data integrity, and data origin authentication.

Installing certificates

To use certificate authentication for L2TP/IPSec router-to-router VPN connections, you must install computer certificates, also known as machine certificates, on both routers. For more information, see Computer certificates for L2TP/IPSec VPN connections and Network access authentication and certificates.

On-demand or persistent connections

You must decide whether your router-to-router VPN connections will be on-demand or persistent:

  • On-demand demand-dial connections require that the answering router is permanently connected to the Internet. The calling router connects to the Internet by using a dial-up link such as an analog phone line or ISDN. You need to configure a single demand-dial interface at the answering router. You need to configure two demand-dial interfaces at the calling router: one to connect to a local Internet service provider (ISP) and one for the router-to-router VPN connection. Demand-dial router-to-router VPN connections also require an additional host route in the IP routing table of the calling router. For more information, see A dial-up router-to-router VPN connection.
  • Persistent connections require that both routers are connected to the Internet by using permanent WAN connections. You only need to configure a single demand-dial interface at each router. Permanent connections can be initiated and left in a connected state 24 hours a day.

Restricting the initiation of an on-demand connection

To prevent the calling router from making unnecessary connections, you can restrict the calling router from making on-demand router-to-router VPN connections in two ways:

  • Demand-dial filtering

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

  • Dial-out hours

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

One-way or two-way initiated connections

You must decide whether your router-to-router VPN connections will be initiated by one router or by both routers:

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

    • For more information, see One-way initiated demand-dial connections.

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

Configuring firewall packet filters

If you have a firewall, you must configure packet filters on the firewall to allow traffic between the VPN router and the routers on the Internet. For more information, see VPN servers and firewall configuration.

Routing

Both routers on a router-to-router VPN connection must have the appropriate routes in their routing tables to forward traffic across the connection. Routes can be static or dynamic. You can add static routes to the routing table either manually or through an auto-static update. You can add dynamic routes to the routing table by adding the VPN connection demand-dial interface to a routing protocol. However, enabling a routing protocol on the VPN connection demand-dial interface is only recommended when the demand-dial interface is permanently connected.

Note

  • Unlike demand-dial routing by using direct links, you cannot use a default IP route for the VPN demand-dial interface to summarize all the routes of the corporate office. Because the branch office router is connected to the Internet, the default route must be used to summarize all the routes of the Internet and configured to use the interface that connects the router to the Internet.

Single hop across VPN connection

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

Creating a remote access policy for router-to-router VPN connections

By using remote access policies, you can create a policy that requires router-to-router VPN connections to use a specific authentication method and encryption strength.

For example, you can create an Active Directory group called VPN Routers whose members are the user accounts that are used by calling routers when a router-to-router VPN connection is created. Then, you create a policy with two conditions on the policy: the NAS-Port-Type is set to Virtual (VPN) and the Windows-Group is set to VPN Routers. Finally, you configure the profile for the policy to select a specific authentication method and encryption strength.

You can also use the Tunnel-Type condition to create separate remote access policies for PPTP and L2TP connections. For example, to require a specific authentication method and encryption strength for PPTP connections, set the Tunnel-Type condition to Point-to-Point Tunneling Protocol.


Router-to-router VPN security considerations

In addition to the security steps listed in Static routing security, you can enhance router-to-router VPN security through:

  • Strong authentication
  • Data encryption
  • PPTP or L2TP/IPSec packet filtering
  • Firewall packet filtering

For more information, see Router-to-router VPN connection.

Strong authentication

For authentication, use the strongest authentication scheme that is possible for your router-to-router VPN configuration. The strongest authentication scheme is the use of EAP-TLS with certificates. For more information, see Deploying certificate-based authentication for demand-dial routing.

Otherwise, use MS-CHAP version 2 authentication and enforce the use of strong passwords on your network. For more information, see MS-CHAP version 2.

Data encryption

For encryption, you can use either link encryption or end-to-end encryption:

  • Link encryption encrypts the data only on the link between the two routers. You can use 128-bit Microsoft Point-to-Point Encryption (MPPE) for high security with PPTP connections. Otherwise, you can use either 56-bit or 40-bit MPPE. 40-bit MPPE is used with older versions of Microsoft operating systems. MPPE is only used in conjunction with either MS-CHAP, MS-CHAP v2, or EAP-TLS authentication. L2TP/IPSec connections use DES or 3DES encryption.
  • End-to-end encryption encrypts the data between the source host and its final destination. You can use IPSec to encrypt data from the source host to the destination host across the demand-dial link.

To specify encryption strength, select the appropriate encryption strengths on the Encryption tab of the remote access policy profile that is used by your calling routers. The No Encryption option is cleared by default; do not select this option or your network security is in jeopardy. For more information, see Security information for VPN and To configure encryption.

Packet filtering

To secure the calling or answering corporate router from sending or receiving any traffic on its Internet interface except router-to-router VPN traffic, you need to ensure that PPTP or L2TP/IPSec input and output filters are configured on the router interface that corresponds to the connection to the Internet.

When you configure your VPN server using the Routing and Remote Access Server Setup Wizard, PPTP or L2TP/IPSec input and output filters are configured automatically. For more information about PPTP filters, see Add PPTP filters. For more information about L2TP/IPSec filters, see Add L2TP/IPSec filters.

Because IP routing is enabled on the Internet interface, if PPTP or L2TP/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.

Firewall packet filtering

It is a common practice to provide protection to intranet hosts, such as a VPN server, from Internet hosts using a firewall. If you have a firewall, you must configure packet filters on the firewall to allow traffic between the VPN router and the routers on the Internet. For more information, see VPN servers and firewall configuration.


Router-to-router VPN deployment

This section covers:

  • PPTP-based router-to-router VPN deployment
  • L2TP-based router-to-router VPN deployment


PPTP-based router-to-router VPN deployment

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

  1. Configure the router running a Windows Server 2003 operating system at the corporate office to receive PPTP connections from a branch office router.
  2. Configure the router running a Windows Server 2003 operating system at the branch office to initiate a PPTP connection with the corporate office router.
  3. Initiate the PPTP connection from the branch office router.

Note

  • These steps assume that the PPTP-based router-to-router VPN connection is between a corporate office and a branch office. However, you can also apply these steps to the VPN connection between two corporate offices.

Configuring the corporate office router

If you want your router running a Windows Server 2003 operating system in the corporate to support multiple branch office PPTP connections, complete the following steps:

  • Configure the connection to the Internet.
  • Configure the connection to the intranet.
  • Configure the corporate router.
  • Configure demand-dial interfaces.
  • Configure firewall packet filters.
  • Configure remote access policies.

The following illustration shows the elements of a PPTP-based router-to-router VPN connection on a computer running a Windows Server 2003 operating system.

A PPTP-based router-to-router VPN connection

For more information, see Router-to-router VPN connection and Point-to-Point Tunneling Protocol.

Note

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

Configuring the connection to the Internet

The connection to the Internet is a dedicated connection—a WAN adapter that is installed in the computer. The WAN adapter is typically a DDS, T1, Fractional T1, or Frame Relay adapter. You must contract with a local telephone company to run the appropriate physical wiring to your premises. You need to verify that the WAN adapter is compatible with products in the Windows Server 2003 family. To verify compatibility, see the Compatible Hardware and Software section at Support resources.

The WAN adapter includes drivers that are installed in Windows Server 2003 operating systems so that the adapter appears as a network adapter.

You need to configure the following TCP/IP settings on the WAN adapter:

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

Configuring the connection to the intranet

The connection to the intranet is a LAN adapter that is installed in the computer. You need to verify that the LAN adapter is compatible with products in the Windows Server 2003 family. To verify compatibility, see the Compatible Hardware and Software section at Support resources.

You need to configure the following TCP/IP settings on the LAN adapter:

  • IP address and subnet mask assigned from the network administrator.
  • DNS and WINS name servers of corporate intranet name servers.

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

Configuring the corporate router

You need to enable the corporate router by installing the Routing and Remote Access service. For more information, see To enable the Routing and Remote Access service.

Configuring demand-dial interfaces

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

  • Interface Name

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

  • Connection Type

    Click Connect using virtual private networking (VPN).

  • VPN Type

    Click Point-to-Point Tunneling Protocol (PPTP).

  • Destination Address

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

  • Protocols and Security

    Select the Add a user account so a remote router can dial in check box.

  • Configuring static routes

    You need to add static routes so that traffic to the branch office is forwarded by using the appropriate demand-dial interface. For each route of each branch office, configure the interface, destination, network mask, and metric. For the interface, you need to select the demand-dial interface that corresponds to the branch office.

    For example, the route that corresponds to the New York branch office is 192.168.25.0 with a subnet mask of 255.255.255.0. This route becomes the static route with the following configuration:

    • Interface: NewYorkRouter
    • Destination: 192.168.25.0
    • Network mask: 255.255.255.0
    • Metric: 1
  • Dial-out Credentials

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

  • Dial-in Credentials

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

Note

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

For more information, see To add a static route.

Configuring firewall packet filters

If you are using a firewall in the corporate office, you need to configure PPTP packet filters on your firewall to allow PPTP traffic between the branch office routers and the corporate office router. For more information, see VPN servers and firewall configuration.

Configuring remote access policies

By using the Demand-Dial Interface Wizard, the dial-in properties of user accounts that are used by branch office routers are already configured to allow remote access.

If you want to grant remote access to the PPTP-based branch office routers based on group membership, do the following:

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

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

For more information, see To configure encryption.

Configuring the branch office router

If you want your router running a Windows Server 2003 operating system in the branch office to initiate a PPTP connection with the corporate office router, complete the following steps:

  • Configure the connection to the Internet.
  • Configure the connection to the branch office network.
  • Configure a demand-dial interface.
  • Configure static routes.
  • Configure firewall packet filters.

Note

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

Configuring the connection to the Internet

The connection to the Internet is a dedicated connection—a WAN adapter that is installed in the computer. The WAN adapter is typically a DDS, T1, Fractional T1, or Frame Relay adapter. You must contract with a local telephone company to run the appropriate physical wiring to your premises. You need to verify that the WAN adapter is compatible with the server operating systems. To verify compatibility, see the Compatible Hardware and Software section at Support resources.

The WAN adapter includes drivers that are installed in Windows Server 2003 operating systems so that the adapter appears as a network adapter.

You need to configure the following TCP/IP settings on the WAN adapter:

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

Configuring the connection to the branch office network

The connection to the branch office network is a LAN adapter that is installed in the computer. You need to verify that the WAN adapter is compatible with products in the Windows Server 2003 family. To verify compatibility, see the Compatible Hardware and Software section at Support resources.

You need to configure the following TCP/IP settings on the LAN adapter:

  • IP address and subnet mask assigned from the network administrator.
  • DNS and WINS name servers of branch office name servers.

Configuring a demand-dial interface

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

  • Interface Name

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

  • Connection Type

    Click Connect using virtual private networking (VPN).

  • VPN Type

    Click Point-to-Point Tunneling Protocol (PPTP).

  • Destination Address

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

  • Dial-out Credentials

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

Configuring static routes

You need to add static routes so that traffic to the corporate office is forwarded by using the appropriate demand-dial interface. For each route of the corporate office, configure the interface, destination, network mask, and metric. For the interface, select the demand-dial interface that corresponds to the corporate office previously created.

For example, the route that corresponds to the corporate office is 10.0.00 with a subnet mask of 255.0.0.0. This route becomes a static route with the following configuration:

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

Note

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

For more information, see To add a static route.

Configuring firewall packet filters

If you are using a firewall in the branch office, you need to configure PPTP packet filters on your firewall to allow PPTP traffic between the corporate office router and the branch office router. For more information, see VPN servers and firewall configuration.

Initiating the PPTP router-to-router VPN connection

To test the branch office router to the corporate router, in Routing and Remote Access, right-click the demand-dial interface that connects to the corporate office, and then click Connect.

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


L2TP-based router-to-router VPN deployment

To create an L2TP/IPSec router-to-router VPN connection to send private data across the Internet, you must perform the following:

  1. Configure the router running a Windows Server 2003 operating system at the corporate office to receive L2TP connections from a branch office router.
  2. Configure the router running a Windows Server 2003 operating system at the branch office to initiate an L2TP connection with the corporate office router.
  3. Initiate the L2TP connection from the branch office router.

Note

  • These steps assume that the L2TP/IPSec router-to-router VPN connection is between a corporate office and a branch office. However, you can also apply these steps to a VPN connection between two corporate offices.

Configuring the corporate office router

If you want your router running a Windows Server 2003 operating system in the corporate office to support multiple branch office L2TP connections, complete the following steps:

  • Configure the connection to the Internet.
  • Configure the connection to the intranet.
  • Install a computer certificate.
  • Configure the corporate router.
  • Configure demand-dial interfaces.
  • Configure firewall packet filters.
  • Configure remote access policies.

The following illustration shows the elements of a L2TP/IPSec router-to-router VPN connection on a computer running a Windows Server 2003 operating system.

An L2TP/IPSec router-to-router VPN connection

For more information, see Router-to-router VPN connection and Layer Two Tunneling Protocol.

Note

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

Configuring the connection to the Internet

The connection to the Internet is a dedicated connection—a WAN adapter that is installed in the computer. The WAN adapter is typically a DDS, T1, Fractional T1, or Frame Relay adapter. You must contract with a local telephone company to run the appropriate physical wiring to your premises. You need to verify that the WAN adapter is compatible with the Windows Server 2003 operating systems. To verify compatibility, see the Compatible Hardware and Software section at Support resources.

The WAN adapter includes drivers that are installed in Windows Server 2003 operating systems so that the adapter appears as a network adapter.

You need to configure the following TCP/IP settings on the WAN adapter:

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

Configuring the connection to the intranet

The connection to the intranet is a LAN adapter that is installed in the computer. You need to verify that the LAN adapter is compatible with the Windows Server 2003 operating systems. To verify compatibility, see the Compatible Hardware and Software section at Support resources.

You need to configure the following TCP/IP setting on the LAN adapter:

  • IP address and subnet mask assigned from the network administrator.

If the corporate router is running applications, you need to configure the following TCP/IP setting on the LAN adapter:

  • DNS and WINS name servers of corporate intranet name servers.

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

Installing a computer certificate

Although you can use either computer certificates or a preshared key to provide authentication for IPSec security associations for an L2TP/IPSec connection, computer certificates are the recommended method. Therefore, you must install a computer certificate on the corporate router.

For more information about installing a computer certificate on the corporate router, see Computer certificates for L2TP/IPSec VPN connections and Network access authentication and certificates.

Configuring the corporate router

You need to enable the corporate router by installing the Routing and Remote Access service. For more information, see To enable the Routing and Remote Access service.

Configuring demand-dial interfaces

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

  • Interface Name

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

  • Connection Type

    Click Connect using virtual private networking (VPN).

  • VPN Type

    Click Layer 2 Tunneling Protocol (L2TP).

  • Destination Address

    Because the corporate router will not initiate the VPN connection, no address is required.

  • Protocols and Security

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

  • Configuring static routes

    You need to add static routes so that traffic to the branch office is forwarded by using the appropriate demand-dial interface. For each route of each branch office, configure the interface, destination, network mask, and metric. For the interface, you need to select the demand-dial interface that corresponds to the branch office.

    For example, the route that corresponds to the New York branch office is 192.168.25.0 with a subnet mask of 255.255.255.0. This route becomes the static route with the following configuration:

    • Interface: NewYorkRouter
    • Destination: 192.168.25.0
    • Network mask: 255.255.255.0
    • Metric: 1
  • Dial-out Credentials

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

  • Dial-in Credentials

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

Note

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

For more information, see To add a static route.

Configuring firewall packet filters

If you are using a firewall in the corporate office, you need to configure L2TP/IPSec packet filters on your firewall to allow L2TP/IPSec traffic between branch office routers and the corporate office router. For more information, see VPN servers and firewall configuration.

Configuring remote access policies

By using the Demand-Dial Interface Wizard, the dial-in properties of user accounts that are used by branch office routers are already configured to allow remote access.

If you want to grant remote access to the L2TP/IPSec branch office routers based on group membership, do the following:

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

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

For more information, see To configure encryption.

Configuring the branch office router

If you want your router running a Windows Server 2003 operating system in the branch office to initiate an L2TP connection with the corporate office router, complete the following steps:

  • Configure the connection to the Internet.
  • Configure the connection to the branch office network.
  • Install a computer certificate.
  • Configure a demand-dial interface.
  • Configure static routes.
  • Configure firewall packet filters.

Note

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

Configuring the connection to the Internet

The connection to the Internet is a dedicated connection—a WAN adapter that is installed in the computer. The WAN adapter is typically a DDS, T1, Fractional T1, or Frame Relay adapter. You must contract with a local telephone company to run the appropriate physical wiring to your premises. You need to verify that the WAN adapter is compatible with the Windows Server 2003 operating systems. To verify compatibility, see the Compatible Hardware and Software section at Support resources.

The WAN adapter includes drivers that are installed in Windows Server 2003 operating systems so that the adapter appears as a network adapter.

You need to configure the following TCP/IP settings on the WAN adapter:

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

Configuring the connection to the branch office network

The connection to the branch office network is a LAN adapter that is installed in the computer. You need to verify that the LAN adapter is compatible with the Windows Server 2003 operating systems. To verify compatibility, see the Compatible Hardware and Software section at Support resources.

You need to configure the following TCP/IP settings on the LAN adapter:

  • IP address and subnet mask assigned from the network administrator.
  • DNS and WINS name servers of branch office name servers.

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

Installing a computer certificate

Because the corporate office router is using computer certificates to authenticate the IPSec security association for the L2TP/IPSec connection, you must install a computer certificate on the branch office router in order for an L2TP/IPSec connection to be successfully established.

For more information about installing a computer certificate on the branch office router, see Computer certificates for L2TP/IPSec VPN connections and Network access authentication and certificates.

Configuring a demand-dial interface

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

  • Interface Name

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

  • Connection Type

    Click Connect using virtual private networking (VPN).

  • VPN Type

    Click Layer 2 Tunneling Protocol (L2TP).

  • Destination Address

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

  • Protocols and Security

    Select the protocols you want to route.

  • Dial-out Credentials

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

Configuring static routes

You need to add static routes so that traffic to the corporate office is forwarded by using the appropriate demand-dial interface. For each route of the corporate office, configure the interface, destination, network mask, and metric. For the interface, select the demand-dial interface that corresponds to the corporate office previously created.

For example, the route that corresponds to the corporate office is 10.0.00 with a subnet mask of 255.0.0.0. This route becomes a static route with the following configuration:

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

Note

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

For more information, see To add a static route.

Configuring firewall packet filters

If you are using a firewall in the branch office, you need to configure L2TP/IPSec packet filters on your firewall to allow L2TP/IPSec traffic between the corporate office router and the branch office router. For more information, see VPN servers and firewall configuration.

Initiating the L2TP router-to-router VPN connection

To connect the branch office router to the corporate router, in Routing and Remote Access, right-click the demand-dial interface that connects to the corporate office, and then click Connect.

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


Deploying certificate-based authentication for VPN connections

The use of certificates for authentication of VPN connections is the strongest form of authentication in the Windows Server 2003 family. You must use certificate-based authentication for Layer Two Tunneling Protocol over Internet Protocol security (L2TP/IPSec)-based 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:

  • Computer certificates for L2TP/IPSec VPN connections
  • Smart cards and remote access VPN connections
  • Deploying certificate-based authentication for demand-dial routing


Computer certificates for L2TP/IPSec VPN connections

The Windows Server 2003 family supports two authentication methods for Layer Two Tunneling Protocol over Internet Protocol security (L2TP/IPSec)-based VPN connections: computer certificates, also known as machine certificates, and preshared keys.

In order to create an L2TP/IPSec connection using the computer certificate authentication method, you must install a certificate in the local computer certificate store on the VPN client and VPN server computer. To install a computer certificate, a certification authority must be present to issue certificates. Once the certification authority is configured, you can install a certificate in three different ways:

  • By configuring the automatic enrollment, or auto-enrollment, of computer certificates to computers in a Windows Server 2003 domain.
  • By using the Certificates snap-in to obtain a computer certificate.
  • By using your browser to connect to the CA Web enrollment pages to install a certificate on the local computer or to a floppy disk for installation on another computer, such as a user's home computer.

Based on the certificate policies in your organization, you need to perform only one of these allocations.

Non-domain member computers cannot obtain certificates through auto-enrollment. For more information, see Network access authentication and certificates.

To configure a CA and install the computer certificate, perform the following steps:

  1. If you do not already have an enterprise root CA:
    1. Promote the computer that will be a CA to a domain controller (DC), if necessary.
    2. Install the Certificate Services component as an enterprise root CA on a computer running XOX; XOX; or XOX. For more information, see To install an enterprise root certification authority.
  2. To auto-enroll computer certificates, configure the Windows Server 2003 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 gpupdate /target:computer from a Windows Server 2003 command prompt.

  3. To manually enroll computer certificates, use the Certificates snap-in to install the CA root certificate. For more information, see Use Windows Server 2003 Certificate Services Web pages, To manage certificates for a computer and To request a certificate.

Note

  • XOX


Smart cards and remote access VPN connections

The use of smart cards for user authentication is the strongest form of authentication in the Windows Server 2003 family. For remote access VPN connections, you must use Extensible Authentication Protocol (EAP) with the Smart card or other certificate (TLS) EAP type, also known as EAP-Transport Level Security (EAP-TLS).

To use smart cards for remote access VPN authentication, you must do the following:

  • Configure the VPN server to provide remote access VPN services.
  • Install a computer certificate on the VPN server.
  • Enable a smart card logon process for the domain.
  • Enable EAP and configure the Smartcard or other certificate (TLS) EAP type on the VPN server computer.
  • Enable smart card authentication on the VPN connection on the remote access client computer.

Configuring the VPN server to provide remote access VPN services

Configure the VPN server running Windows Server 2003 as described in Deploying remote access VPNs.

Installing a computer certificate on the VPN server

In order to configure EAP-TLS on the VPN server computer, you must install a computer certificate, also known as a machine certificate. To install a computer certificate on the VPN server computer, a certification authority (CA) must be present to issue certificates. Once the CA is configured, you can install a certificate on the VPN server computer in one of three different ways:

  • By configuring the automatic enrollment, or auto-enrollment, of computer certificates to computers in a Windows Server 2003 domain.
  • By using the Certificates snap-in to request and install a computer certificate.
  • By using your browser to connect to the CA Web enrollment pages to request and install a certificate on the local computer or to a floppy disk for installation on another computer, such as a user's home computer.

Based on the certificate policies in your organization, you need to perform only one of these enrollment methods.

For more information, see Network access authentication and certificates.

To configure a CA and install the computer certificate, perform the following steps:

  1. If you do not already have an enterprise root CA:
    1. Promote the computer that will be a CA to a domain controller (DC), if necessary.
    2. Install the Certificate Services component on a computer running XOX; XOX; or XOX; as an enterprise root CA. For more information, see To install an enterprise root certification authority.
  2. To auto-enroll computer certificates, configure the Windows Server 2003 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 gpupdate /target:computer from a Windows Server 2003 command prompt.

  3. To manually enroll computer certificates, use the Certificates snap-in to install the CA root certificate, or use your browser to connect to the CA Web enrollment pages. For more information, see Use Windows Server 2003 Certificate Services Web pages, To manage certificates for a computer, and To request a certificate.

Note

  • VPN servers that terminate connections for remote users must have a certificate that contains the Server Authentication purpose in the Enhanced Key Usage extensions. VPN servers that are used for site-to-site VPN connections both originate and terminate connections. For this reason the certificate on these servers must contain both the Server Authentication purpose and the Client Authentication purpose in the Enhanced Key Usage extensions. For more information, see Network access authentication and certificates.

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 VPN server for smart card remote access

To configure the VPN server running Windows Server 2003 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 XOX, then you are prompted about 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.

Note

  • XOX


Virtual private network implementation examples

This section describes how common VPN scenarios are configured for a fictional company by using computers running Windows Server 2003 operating systems. While your network configuration may be different than those described here, you can apply the basic concepts.

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 computers running XOX, that connect 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/IPSec 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.209.68.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 static pool of IP addresses is a subset of the intranet network segment (an on-subnet address pool).

The following illustration shows the network configuration of the Electronic, Inc. VPN server.

Network configuration of the Electronic, Inc. VPN server

Note

  • While the illustration shows the RADIUS server and file and Web server, the RADIUS server is not discussed until Dial-up and VPNs with RADIUS, and the file and Web servers are not discussed until Extranet for business partners.

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 appear as local area connections in the Network 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.209.68.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 Server Setup Wizard is run. Within the wizard, the Remote Access (dial-up or VPN) option is selected. For more information, see To enable the Routing and Remote Access service.

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

The default method of authenticating remote access and demand-dial connections is to use Windows authentication, which is appropriate in this configuration containing only one VPN server. For information on the use of RADIUS authentication for Electronic, Inc., see Dial-up and VPNs with RADIUS. For more information on the use of Windows and RADIUS authentication, see Authentication vs. authorization.

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 Extensible Authentication Protocol (EAP) on the VPN server.

For more information, see To enable EAP.

5. Configure static routes on the VPN server 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

This static route simplifies routing by summarizing all destinations on the Electronic, Inc. intranet. This static route is used so that the VPN server does not need to be configured with a routing protocol.

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

This static route summarizes all destinations on the Internet. This route allows the VPN server to respond to a remote access client or demand-dial router VPN connection from anywhere on the Internet.

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.

Setting the phone number for the PPTP and L2TP devices

To aid in the configuration of remote access policies to confine VPN connections from Internet users, the port properties for the WAN Miniport (PPTP) and WAN Miniport (L2TP) devices are modified with the IP address of the VPN server's Internet interface in the Phone number for this device field. For more information, see Setting a phone number on a device.

Configure a static route on the intranet router to reach all branch offices

To reach branch office locations from the intranet router, a static route is configured with the following settings:

  • Interface: The LAN adapter attached to the intranet
  • Destination: 192.168.0.0
  • Network mask: 255.255.0.0
  • Gateway: 172.31.0.1
  • Metric: 1

This static route simplifies routing by summarizing all destinations at branch offices of Electronic, Inc.

The remote access policy configuration

Electronic, Inc. has migrated to a Windows 2000 native domain and the network administrator for Electronic, Inc. decides on an access-by-policy administrative model. The remote access permission on all user accounts is set to Control access through Remote Access Policy. The granting of remote access permission to connection attempts is controlled by the remote access permission setting on the first matching remote access policy. Remote access policies are used to apply different VPN connection settings based on group membership, and the default remote access policies are deleted.

For more information, see Introduction to remote access policies.

The domain configuration

To take advantage of the ability to apply different connection settings to different types of VPN connections, the following Active Directory 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

Note

  • All users and groups in this implementation example are created in the electronic.microsoft.com Active Directory domain.

The security configuration

To enable L2TP/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 computer certificates to all domain members.

For more information, see Deploying certificate-based authentication for VPN connections.

Notes

  • XOX
  • 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 Control access through Remote Access Policy.
  • The user account is added to the VPN_Users Active Directory 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.209.68.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 computer certificate (also known as the machine certificate). Microsoft Encrypted Authentication version 2 (MS-CHAP v2) and Microsoft Encrypted Authentication (MS-CHAP) are also enabled.
    • Encryption tab: Strong and Strongest are the only options that are selected.

Note

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

PPTP-based remote access client configuration

The New Connection Wizard is used on client computers to create a VPN connection with the following setting:

  • Host name or IP address: vpn.electronic.microsoft.com
  • On the Networking tab, Type of dial-up server I am calling is set to Point-to-Point Tunneling Protocol (PPTP). This is done to provide better performance when connecting. When Type of dial-up server I am calling is set to Automatic, an Internet Protocol security (IPSec) security association (SA) for an Layer Two Tunneling Protocol (L2TP) connection is attempted first. By configuring the connection for PPTP, the IPSec SA for an L2TP connection is not attempted.

L2TP/IPSec remote access client configuration

The remote access computer logs on to the Electronic, Inc. domain using a LAN connection to the Electronic, Inc. intranet and receives a certificate through auto-enrollment. Then, the New Connection Wizard is used to create a 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). When Type of dial-up server I am calling is set to Automatic, an IPSec SA for an L2TP connection is attempted first. If the IPSec SA is not successful, then a PPTP connection is attempted. In this case, the network administrator for Electronic, Inc. does not want remote access clients that are capable of establishing an L2TP connection to fall back to the PPTP connection.

Notes

  • XOX
  • 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 routers running XOX, 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 Control access through Remote Access Policy, and the static route is 192.168.28.0 with a subnet mask of 255.255.255.0 is added.
  • For the account properties on the VPN_Dallas account, the Password never expires account option is enabled.
  • 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 Control access through Remote Access Policy, and the static route is 192.168.4.0 with a subnet mask of 255.255.255.0 is added.
  • For the account properties on the VPN_Portland account, the Password never expires account option is enabled.
  • 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.209.68.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 computer certificate (also known as the machine certificate). Microsoft Encrypted Authentication version 2 (MS-CHAP v2) is also enabled.
    • Encryption tab: Strong and Strongest are the only options that are selected.

Note

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

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 router running XOX, 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.

  • Static Routes for Remote Networks

    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.209.68.1
    • Network mask: 255.255.255.255
    • Metric: 1

  • Dial-out credentials
    • User name: Dallas office ISP account name.
    • Password: Dallas office ISP account password.
    • Confirm password: Dallas office ISP account password.

For more information, see To add a demand-dial interface.

Demand-dial interface for router-to-router VPN connection

To connect the Dallas office router to the VPN server 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.209.68.1

  • Protocols and security

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

  • Static Routes for Remote Networks

    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

    To make all locations on Electronic, Inc. branch offices reachable, the following static route is configured:

    • Interface: CorpHQ
    • Destination: 192.168.0.0
    • Network mask: 255.255.0.0
    • Metric: 1

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

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.

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/IPSec branch office that uses a router running XOX, 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.

Certificate configuration

The Portland router was configured by the Electronic, Inc. network administrator while it was physically connected to the Electronic, Inc. intranet and then shipped to the Portland site. While the Portland router was connected to the Electronic, Inc. intranet, a computer certificate was installed through auto-enrollment.

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.

  • Static Routes for Remote Networks

    The following static route for the Electronic, Inc. VPN server is added automatically when the wizard is run to create the connection to the Portland ISP:

    • Interface: ISP
    • Destination: 207.209.68.1
    • Network mask: 255.255.255.255
    • Metric: 1
  • Dial-out credentials
    • User name: Portland office ISP account 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 VPN server 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.209.68.1

  • Protocols and security

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

  • Static Routes for Remote Networks

    Static route for corporate headquarters and branch offices: 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

    To make all locations on Electronic, Inc. branch offices reachable, the following static route is configured:

    • Interface: CorpHQ
    • Destination: 192.168.0.0
    • Network mask: 255.255.0.0
    • Metric: 1
  • Dial-out credentials
    • User name: VPN_Portland
    • Domain: electronic.microsoft.com
    • Password: P*4s=wq!Gx1
    • Confirm password: P*4s=wq!Gx1

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 routers running XOX, 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 Control access through Remote Access Policy.
  • For the account properties on the VPN_Chicago account, the Password never expires account option is enabled.
  • 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 Control access through Remote Access Policy.
  • For the account properties on the VPN_Phoenix account, the Password never expires account option is enabled.
  • 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 Control access through Remote Access Policy.
  • For the account properties on the VPN_CorpHQ account, the Password never expires account option is enabled.
  • The VPN_CorpHQ account is added to the VPN_Routers group.

Remote access policy configuration

Remote access policies must be configured at the VPN server, the Chicago router, and the Phoenix router.

Remote access policy configuration at the VPN server

The remote access policy configuration for the VPN server 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 policies are 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 computer certificate (also known as the machine certificate). Microsoft Encrypted Authentication version 2 (MS-CHAP v2) is also enabled.
    • Encryption tab: Strong and Strongest are the only options that are selected.

Note

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

Remote access policy configuration at the Phoenix router

To define the authentication and encryption settings for the VPN connections, the default policies are 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 computer certificate (also known as the machine certificate). Microsoft Encrypted Authentication version 2 (MS-CHAP v2) is also enabled.
    • Encryption tab: Strong and Strongest are the only options that are selected.

Note

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

IP address pool configuration

IP address pools must be configured at the VPN server, the Chicago router, and the Phoenix router.

IP address pool configuration at the VPN server

The IP address pool configuration for the VPN server 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 a starting IP address of 192.168.9.248 and an ending IP address 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 router running XOX, 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.

VPN server configuration

The VPN server 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.

  • Static Routes for Remote Networks

    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
  • 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. To obtain properties of a demand-dial interface, click Routing Interfaces, right-click the desired demand-dial interface, and then click Properties.

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

  • Protocols and security

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

  • Static Routes for Remote Networks

    Static route for the Electronic, Inc. VPN server: To make the Electronic, Inc. VPN server on the Internet reachable, the following static route is configured:

    • Interface: The WAN adapter attached to the Internet
    • Destination: 207.209.68.1
    • Network mask: 255.255.255.255
    • Gateway: 0.0.0.0
    • Metric: 1
    Static routes for corporate intranet and branch offices: 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

    To make all locations on Electronic, Inc. branch offices reachable, the following static route is configured:

    • Interface: VPN_CorpHQ
    • Destination: 192.168.0.0
    • Network mask: 255.255.0.0
    • Metric: 1
  • 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.

Notes

  • 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.
  • 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/IPSec branch office that uses a router running XOX, 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.

VPN server configuration

The VPN server 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.

  • Static Routes for Remote Networks

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

Phoenix router configuration

The Phoenix router was configured by the Electronic, Inc. network administrator while connected to the Electronic, Inc. intranet and then shipped to the Phoenix site. While the Phoenix router was connected to the Electronic, Inc. intranet, a computer certificate was installed through auto-enrollment. Additionally, the Phoenix router computer was 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.209.68.1

  • Protocols and security

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

  • Static Routes for Remote Networks

    Static route for the Electronic, Inc. VPN server: To make the Electronic, Inc. VPN server on the Internet reachable, the following static route is configured:

    • Interface: The WAN adapter attached to the Internet
    • Destination: 207.209.68.1
    • Network mask: 255.255.255.255
    • 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 and branch offices: 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

    To make all locations on Electronic, Inc. branch offices reachable, the following static route is configured:

    • Interface: VPN_CorpHQ
    • Destination: 192.168.0.0
    • Network mask: 255.255.0.0
    • Metric: 1
  • 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.

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 Control access through Remote Access Policy.
  • For the account properties on the PTR_Tasmanian account, the Password never expires account option is enabled.
  • 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 Control access through Remote Access Policy.
  • For the account properties on the PTR_Parnell account, the Password never expires account option is enabled.
  • The PTR_Parnell account is added to the VPN_Partners group.

Routing configuration

In order for traffic to be sent back to the Tasmanian Traders and Parnell Aerospace business partners, additional routes are added to the routing tables on the file server and Web server computers. On both computers, the following commands were issued at the Windows Server 2003 command prompt.

  • route -p add 131.107.254.0 mask 255.255.255.0 172.31.0.1
  • route -p add 131.107.250.0 mask 255.255.255.0 172.31.0.1

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.209.68.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 computer certificate (also known as the machine certificate). Microsoft Encrypted Authentication version 2 (MS-CHAP v2) is also enabled.
    • Encryption tab: Strong and Strongest are the only options that are selected.

Demand-dial interface configuration

To connect the Tasmanian Traders router to the Electronic, Inc. VPN server 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

    PTR_Tasmanian

  • Connection type

    Connect using virtual private networking (VPN) is selected.

  • VPN type

    Point to Point Tunneling Protocol (PPTP) is selected.

  • Destination address

    Leave blank.

  • Protocols and security

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

  • Dial-out credentials
    • User name: none
    • Domain: none
    • Password: none
    • Confirm password: none

Note

  • The destination address is left blank, and the user name is set to "none" because this demand-dial interface is never used to initiate the connection. The business partner always initiates the connection to the Electronic, Inc. VPN server.

To connect the Parnell Aerospace router to the Electronic, Inc. VPN server 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

    PTR_Parnell

  • Connection type

    Connect using virtual private networking (VPN) is selected.

  • VPN type

    Point to Point Tunneling Protocol (PPTP) is selected.

  • Destination address

    Leave blank.

  • Protocols and security

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

  • Dial-out credentials
    • User name: none
    • Domain: none
    • Password: none
    • Confirm password: none

Note

  • The destination address is left blank and the user name is set to "none" because this demand-dial interface is never used to initiate the connection. The business partner always initiates the connection to the Electronic, Inc. VPN server.

Static route for Tasmanian Traders

To make all locations at Tasmanian Traders reachable, the following static route is configured:

  • Interface: PTR_Tasmanian
  • Destination: 131.107.254.0
  • Network mask: 255.255.255.0
  • Metric: 1

Static route for Parnell Aerospace

To make all locations at Parnell Aerospace reachable, the following static route is configured:

  • Interface: PTR_Parnell
  • Destination: 131.107.250.0
  • Network mask: 255.255.255.0
  • Metric: 1

IP packet filter configuration

To confine the traffic from the Tasmanian Traders business partner to the file server and Web server, the following IP packet filters are configured on the PTR_Tasmanian demand-dial interface:

  • Input filters

    • 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

    • Output filters

    • 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

To confine the traffic from the Parnell Aerospace business partner to the file server and Web server, the following IP packet filters are configured on the PTR_Parnell demand-dial interface:

  • Input filters

    • 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

    • Output filters

    • 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

Note

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

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 router running a Windows Server 2003 operating system 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 Electronic, Inc. VPN server 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.209.68.1

  • Protocols and security

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

  • Static Routes for Remote Networks

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

Notes

  • XOX
  • 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 router running XOX, to create an on-demand, L2TP/IPSec, 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.

Certificate configuration

The Parnell Aerospace router was configured by the Electronic, Inc. network administrator while physically connected to the Electronic, Inc. intranet and then shipped to the network administrator at Parnell Aerospace. While the Parnell Aerospace router was connected to the Electronic, Inc. intranet, a computer certificate was installed through auto-enrollment.

Demand-dial interface for router-to-router VPN connection

To connect the Parnell Aerospace router to the Electronic, Inc. VPN server 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.209.68.1 (the IP address of the Electronic, Inc. VPN server's interface on the Internet)

  • Protocols and security

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

  • Static Routes for Remote Networks

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

Notes

  • XOX
  • 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 Server 2003 operating system group called NY_Employees. A separate remote access server running XOX, 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 XOX; XOX; or XOX; with 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 Control access through Remote Access Policy.

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 Server 2003 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 Server 2003 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 XOX; XOX; or XOX. 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 computer certificate (also known as the 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.

RADIUS configuration

To configure RADIUS authentication and accounting, the network administrator for Electronic, Inc. configures the following:

  • The RADIUS server is a computer running XOX; XOX; or XOX; and with IAS installed. IAS 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 a member of the Windows Server 2003 family 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 Server 2003 is configured to use RADIUS authentication and accounting at the IP address of 172.31.0.9 and to use a shared secret. For more information, see To use RADIUS authentication and To use RADIUS accounting.

Dial-up remote access client configuration

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


Virtual private network test lab

This section provides detailed information about how you can use five computers to create a test lab with which to configure and test the virtual private network (VPN) features in the Windows Server 2003 family. These instructions are designed to take you through a set of tasks that expose you to VPN connections and their functionality. Beyond the set of tasks, you can use these instructions to create a functioning VPN configuration. You can then use this configuration to experiment with VPN features and functionality in the Windows Server 2003 family prior to deployment on your production network.

This section covers:

  • Setting up the infrastructure
  • Virtual private network test lab tasks

Note

  • XOX

For more information about deploying VPN connections, see Deploying virtual private networks. For configuration checklists, see Checklists. For an example implementation of VPN connections, see Virtual private network implementation examples.


Setting up the infrastructure

The infrastructure for the VPN test lab network consists of five computers performing the following services:

  • A computer running XOX, named DC1 that is acting as a domain controller, a Domain Name System (DNS) server, and a certification authority (CA).
  • A computer running XOX, named IAS1 that is acting as a Remote Authentication Dial-in User Service (RADIUS) server.
  • A computer running XOX, named IIS1 that is acting as a Web server and file sharing server.
  • A computer running XOX, named VPN1 that is acting as a VPN server. VPN1 has two network adapters installed.
  • A computer running XOX named CLIENT1 that is acting as a VPN client.

The following illustration shows the configuration of the VPN test lab.

The configuration of the VPN test lab

There is a network segment representing a corporate intranet and a network segment representing the Internet. All computers on the corporate intranet are connected to a common hub or Layer 2 switch. All computers on the Internet are connected to a separate common hub or Layer 2 switch. Private addresses are used throughout the test lab configuration. The private network of 172.16.0.0/24 is used for the intranet. The private network of 10.0.0.0/24 is used for the simulated Internet.

Each computer is manually configured with the appropriate IP address, subnet mask, and DNS server IP address. There are no Dynamic Host Configuration Protocol (DHCP) or Windows Internet Name Service (WINS) servers present.

The following sections describe the configuration for each of the computers in the test lab. To reconstruct this test lab, configure the computers in the order presented.

Note

  • XOX

DC1

DC1 is a computer running XOX, that is providing the following services:

  • A domain controller for the testlab.microsoft.com domain.
  • A DNS server for the testlab.microsoft.com DNS domain.
  • The enterprise root certification authority (CA) for the testlab.microsoft.com domain.

To configure DC1 for these services, perform the following steps.

  1. Install XOX, as a stand-alone server.
  2. Configure the TCP/IP protocol with the IP address of 172.16.0.1 and the subnet mask of 255.255.255.0. For more information, see To configure TCP/IP for static addressing.
  3. Run Active Directory Installation Wizard for a new domain called testlab.microsoft.com in a new forest. Install the DNS service when prompted.
  4. Install the Certificate Services component as an enterprise root CA. For more information, see To install an enterprise root certification authority.
  5. Configure the testlab.microsoft.com domain for automatic enrollment of computer certificates. For more information, see To configure automatic certificate allocation from an enterprise CA.

IAS1

IAS1 is a computer running XOX, that is providing RADIUS authentication, authorization, and accounting for VPN1 (the VPN server computer).

To configure IAS1 as a RADIUS server, perform the following steps:

  1. On DC1, add a computer account for the IAS1 computer. For more information, see To add a computer account.
  2. Install XOX, as a stand-alone server.
  3. Configure the TCP/IP protocol with the IP address of 172.16.0.2, the subnet mask of 255.255.255.0, and the DNS server IP address of 172.16.0.1. For more information, see To configure TCP/IP for static addressing and To configure TCP/IP to use DNS.
  4. Join IAS1 to the testlab.microsoft.com domain. For more information, see To join a domain.
  5. Install Internet Authentication Service (IAS) and register it in the testlab.microsoft.com domain. For more information, see To install IAS and To enable the IAS server to read user objects in Active Directory.

IIS1

IIS1 is a computer running XOX, and Internet Information Services (IIS). It is providing Web server services for intranet clients. To configure IIS1 as a Web server, perform the following steps:

  1. On DC1, add a computer account for the IIS1 computer. For more information, see To add a computer account.
  2. Install XOX, as a stand-alone server, then install IIS.

    For more information, see Installing IIS.

  3. Configure the TCP/IP protocol with the IP address of 172.16.0.3, the subnet mask of 255.255.255.0, and the DNS server IP address of 172.16.0.1. For more information, see To configure TCP/IP for static addressing and To configure TCP/IP to use DNS.
  4. Join IIS1 to the testlab.microsoft.com domain. For more information, see To join a domain.
  5. Install IIS.
  6. To determine whether the Web server is working correctly, run your Web browser on IAS1. When prompted by the Internet Connection Wizard, configure the wizard for a LAN connection. In your Web browser, in Address, type http://IIS1.testlab.microsoft.com/wnetStndS_v_s_rgb.gif. You should see a XOX, graphic.
  7. On IIS1, in Windows Explorer, share the root directory of Local Disk (C:) using the share name ROOT to the group Everyone with full access. For more information, see To create a shared resource.

VPN1

VPN1 is a computer running XOX, that is providing VPN server services for Internet-based VPN clients. To configure VPN1 as a VPN server, perform the following steps:

  1. On DC1, add a computer account for VPN1. For more information, see To add a computer account.
  2. Install XOX, as a stand-alone server.
  3. For the intranet local area connection, configure the TCP/IP protocol with the IP address of 172.16.0.4, the subnet mask of 255.255.255.0, and the DNS server IP address of 172.16.0.1. For more information, see To configure TCP/IP for static addressing and To configure TCP/IP to use DNS.
  4. For the Internet local area connection, configure the TCP/IP protocol with the IP address of 10.0.0.2 and the subnet mask of 255.255.255.0. For more information, see To configure TCP/IP for static addressing.
  5. Join VPN1 to the testlab.microsoft.com domain. For more information, see To join a domain.
  6. Configure and enable the Routing and Remote Access service. For more information, see To enable the Routing and Remote Access service. In the Routing and Remote Access Server Setup Wizard, select Virtual private network (VPN) server from the list of common configurations. When prompted for IP address assignment, select From a specified range of addresses and configure the range 172.16.0.248 to 172.16.0.255. Do not configure RADIUS authentication.

CLIENT1

CLIENT1 is a computer running XOX that is acting as a VPN client and gaining remote access to intranet resources across the simulated Internet. To configure CLIENT1 as a VPN client, perform the following steps:

  1. On DC1, add a computer account for CLIENT1. For more information, see To add a computer account.
  2. Connect CLIENT1 to the intranet network segment.
  3. On CLIENT1, install XOX as a workgroup computer.
  4. Configure the TCP/IP protocol with the IP address of 172.16.0.5, the subnet mask of 255.255.255.0, and the DNS server IP address of 172.16.0.1. For more information, see To configure TCP/IP for static addressing and To configure TCP/IP to use DNS.
  5. Join CLIENT1 to the testlab.microsoft.com domain. For more information, see To join a domain.
  6. Configure the TCP/IP protocol with the IP address of 10.0.0.1, the subnet mask of 255.255.255.0, and no DNS server IP address. For more information, see To configure TCP/IP for static addressing and To configure TCP/IP to use DNS.
  7. Shut down the CLIENT1 computer.
  8. Disconnect the CLIENT1 computer from the intranet network segment, and connect it to the simulated Internet network segment.
  9. Restart the CLIENT computer and log on using the cached credentials of the testlab.microsoft.com administrator account.


Virtual private network test lab tasks

The following tasks are designed to take you through the most common elements of setting up VPN support with the Windows Server 2003 family:

  • PPTP-based remote access
  • L2TP/IPSec remote access
  • RADIUS authentication and accounting
  • Remote access policies for both PPTP and L2TP connections

Note

  • XOX

PPTP-based remote access

To create a PPTP-based remote access VPN connection between CLIENT1 and VPN1 and test whether intranet resources are available, perform the following steps:

1. Create a user account.

  1. On DC1, use Active Directory Users and Computers to create a user account called PPTPUser and set the password. For more information, see To add a computer account.
  2. Set the remote access permission on the Dial-in tab to Allow access. For more information, see To grant remote access permission to a user.

2. Create the PPTP connection.

  1. On CLIENT1, use the New Connection Wizard to create a new PPTP-based connection named PPTPtoCorpnet, using the IP address of 10.0.0.2. For more information, see To make a virtual private network (VPN) connection.
  2. Obtain properties on the newly created PPTPtoCorpnet connection, and click the Networking tab.
  3. Under Type of VPN server I am calling, select PPTP VPN, and click OK.

3. Make the PPTP connection.

  1. On CLIENT1, double-click the PPTPtoCorpnet connection.
  2. When prompted for credentials, type PPTPUser as the user name, testlab.microsoft.com as the domain name, and the password.

4. Access Web server and file share on the intranet.

  1. On CLIENT1, run your Web browser.
  2. When prompted by the Internet Connection Wizard, configure it for a LAN connection. In your Web browser, type http://IIS1.testlab.microsoft.com/wnetStndS_v_s_rgb.gif.

    3. You should see a XOX, graphic.

  3. On CLIENT1, click Start, click Run, type \\IIS1\ROOT, and then click OK.

    4. You should see the contents of the Local Drive (C:) on IIS1.

5. Disconnect the PPTP connection.

  • On CLIENT1, right-click the PPTPtoCorpnet connection, and then click Disconnect.

L2TP/IPSec remote access

To create an L2TP/IPSec remote access VPN connection between CLIENT1 and VPN1 and test whether intranet resources are available, perform the following steps:

1. Create a user account.

  1. On DC1, use Active Directory Users and Computers to create a user account called L2TPUser, and set the password. For more information, see To add a computer account.
  2. Set the remote access permission on the Dial-in tab to Allow access. For more information, see To grant remote access permission to a user.

2. Create the L2TP connection.

  1. On CLIENT1, use the New Connection Wizard to create a new L2TP/IPSec connection named L2TPtoCorpnet, using the IP address of 10.0.0.2. For more information, see To make a virtual private network (VPN) connection.
  2. Obtain properties on the newly created L2TPtoCorpnet connection, and click the Networking tab.
  3. Under Type of VPN server I am calling, select L2TP IPSec VPN, and click OK.

3. Make the L2TP connection.

  1. On CLIENT1, double-click the L2TPtoCorpnet connection.
  2. When prompted for credentials, type L2TPUser as the user name, testlab.microsoft.com as the domain name, and the password.

4. Access Web server and file share on the intranet.

  1. On CLIENT1, run your Web browser.
  2. When prompted by the Internet Connection Wizard, configure it for a LAN connection. In your Web browser, type http://IIS1.testlab.microsoft.com/wnetStndS_v_s_rgb.gif.

    3. You should see a XOX, graphic.

    XOX
  3. On CLIENT1, click Start, click Run, type \\IIS1\ROOT, and then click OK.

    4. You should see the contents of the Local Drive (C:) on IIS1.

5. Disconnect the L2TP connection.

  • On CLIENT1, right-click the L2TPtoCorpnet connection, and then click Disconnect.

RADIUS authentication and accounting

To configure RADIUS authentication and accounting for VPN connections, perform the following steps:

1. Configure IAS1 for VPN1 as a RADIUS client.

  • On IAS1, add VPN1 as a RADIUS client with the Microsoft Client-Vendor, at the IP address of 172.16.0.4, and set the shared secret. For more information, see Add RADIUS clients.

2. Configure IAS1 to log authentication events.

  • On IAS1, enable the logging of accounting and authentication requests in the Internet Authentication Service console, in the Remote Access Logging folder, in the properties of the Local File object, on the Settings tab.

3. Configure VPN1 for IAS1 as a RADIUS server.

  • On VPN1, add IAS1 as a RADIUS server for both the authentication and accounting provider, at the IP address of 172.16.0.2, and set the shared secret. For more information, see To use RADIUS authentication and To use RADIUS accounting.

4. Make a PPTP connection.

  1. On CLIENT1, create a PPTP connection with VPN1 using the PPTPtoCorpnet connection.
  2. Disconnect the connection. For more information, see To disconnect from the network.

5. Make an L2TP connection.

  1. On CLIENT1, create an L2TP connection with VPN1 using the L2TPtoCorpnet connection.
  2. Disconnect the connection. For more information, see To disconnect from the network .

6. Check the system event log for RADIUS events.

  • On IAS1, use Event Viewer to view IAS events in the system event log for the PPTP and L2TP connections that were recently created using CLIENT1.

7. Check RADIUS authentication and accounting logs.

  • On IAS1, use Windows Explorer to open the systemroot\System32\Logfiles\Iaslog.log file. Note the authentication and accounting entries for the PPTP and L2TP connection. For more information on the IAS log file format, see IAS-formatted log files.

Remote access policies for both PPTP and L2TP connections

To create separate remote access policies for PPTP and L2TP connections, perform the following steps:

1. On IAS1, create a new remote access policy with the following settings:

  • Policy name: PPTP connections
  • Policy Conditions:

    NAS-Port-Type matches Virtual (VPN)

    Tunnel-Type matches Point-to-Point Tunneling Protocol (PPTP)

  • If a connection request matches the specified conditions: Grant remote access permission
  • Profile settings, IP tab, output packet filter:

    Filter action: Deny all traffic except those listed below

    Destination network, IP address: 172.16.0.1

    Destination network, Subnet mask: 255.255.255.255

    Protocol: Any

  • Profile settings, IP tab, input packet filter:

    Filter action: Deny all traffic except those listed below

    Source network, IP address: 172.16.0.1

    Destination network, Subnet mask: 255.255.255.255

    Protocol: Any

2. On IAS1, create a new custom remote access policy with the following settings:

  • Policy name: L2TP connections
  • Policy Conditions:

    NAS-Port-Type matches Virtual (VPN)

    Tunnel-Type matches Layer Two Tunneling Protocol (L2TP)

  • If a connection request matches the specified conditions: Grant remote access permission
  • Profile settings, IP tab, output packet filter:

    Filter action: Deny all traffic except those listed below

    Destination network, IP address: 172.16.0.2

    Destination network, Subnet mask: 255.255.255.255

    Protocol: Any

  • Profile settings, IP tab, input packet filter:

    Filter action: Deny all traffic except those listed below

    Source network, IP address: 172.16.0.2

    Destination network, Subnet mask: 255.255.255.255

    Protocol: Any

3. Make a PPTP connection and test connectivity.

  1. On CLIENT1, make a VPN connection with VPN1 using the PPTPtoCorpnet connection.
  2. Use the ping command to ping DC1 at its IP address of 172.16.0.1.
  3. Use the ping command to ping IAS1 at its IP address of 172.16.0.2. This command fails because packet filtering for all connections that match the PPTP connections policy allows only traffic sent to and from the IP address of 172.16.0.1.
  4. Disconnect the PPTPtoCorpnet connection.

4. Make an L2TP connection and test connectivity.

  1. On CLIENT1, make a VPN connection with VPN1 using the L2TPtoCorpnet connection.
  2. Use the ping command to ping IAS1 at its IP address of 172.16.0.2.
  3. Use the ping command to ping DC1 at its IP address of 172.16.0.1. This command fails because packet filtering for all connections that match the L2TP connections policy allows only traffic sent to and from the IP address of 172.16.0.2.
  4. Disconnect the L2TPtoCorpnet connection.

5. Check the system event log for IAS events.

  • On IAS1, use Event Viewer to view the IAS events in the system event log for the PPTP and L2TP connections that were recently created by CLIENT1. Note that the authentication event message text contains the name of the remote access policy that accepted the connection.


Resources

The Microsoft Windows Server 2003 Deployment Kit contains advanced information about virtual private networks (VPNs).

  • For more information about configuring, administering, and optimizing VPNs, see "Internetworking Guide" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
  • For more information about designing remote access solutions, see "Designing Network Services" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
  • For additional information, see VPN Technical White Papers at the Microsoft Web site. (http://www.microsoft.com/)

For additional information about troubleshooting with the remote access server, see Troubleshooting tools.


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 user account used by the remote access client is locked out, expired, disabled, or the time the connection is being made does not correspond to the configured logon hours.

Solution: Modify the account properties of the user account.

See also: Manage users, groups, and computers

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 ports, 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, remote access VPN clients running XOX or a Windows Server 2003 operating system use the Automatic server type option, which means that they try to establish a PPTP-based VPN connection first, and then they try an L2TP/IPSec–based VPN connection. If VPN clients use either the Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP) server type option, verify that the selected tunneling protocol is supported by the VPN server.

By default, a computer running a Windows Server 2003 operating system 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 0. To create an L2TP-only server, set the number of PPTP ports to 1 and disable remote access inbound connections and demand-dial connections.

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

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.

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 or RADIUS to authenticate the credentials of the VPN client.

See also: To use RADIUS authentication

Cause: The VPN server cannot access Active Directory.

Solution: For a VPN server that is a member server in a Windows 2000 mixed domain or a Windows 2000 native domain that is configured for Windows 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 the VPN server computer to (or remove the VPN server computer from) the RAS and IAS Servers security group, the change does not take effect immediately (due to the way that Active Directory information is cached). For the change to take effect immediately, you need to restart the VPN server computer.

  • For a Windows 2000 native domain, the VPN server has joined the domain.

See also: To create a new group; To verify permissions for the RAS and IAS security group; Netsh commands for remote access; Domain and forest functionality

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 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: Domain and forest functionality

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

For more information on troubleshooting remote access connections, see Troubleshooting.

Note

  • XOX


Troubleshooting router-to-router VPNs

What problem are you having?

Unable to establish a router-to-router VPN connection.

Cause: The user account used by the calling router is locked out, expired, disabled, or the time the connection is being made does not correspond to the configured logon hours.

Solution: Modify the account properties of the user account.

See also: Manage user accounts

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 ports, 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, demand-dial interfaces on a computer running a Windows Server 2003 operating system use the Automatic server type option, which means that they try to establish an L2TP/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 a Windows Server 2003 operating system 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 0. To create an L2TP-only router, set the number of PPTP ports to 1 and disable remote access inbound connections and demand-dial connections.

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

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: To create a static IP address pool

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 or RADIUS to authenticate the credentials of the VPN client.

See also: To use RADIUS authentication

Cause: The answering router cannot access Active Directory.

Solution: For an answering router that is a member server in a Windows 2000 mixed domain or a Windows 2000 native domain that is configured for the Windows authentication provider, 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 the answering router computer to (or remove the answering router from) the RAS and IAS Servers security group, the change does not take effect immediately (due to the way that Active Directory information is cached). For the change to take effect immediately, you need to restart the answering router computer.

  • For a Windows 2000 native domain, the answering router has joined the domain.

See also: To add a group; To verify permissions for the RAS and IAS security group; Netsh commands for remote access; Domain and forest functionality

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 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: Domain and forest functionality

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/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 input and output filters to control the exact nature of TCP/IP 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 on troubleshooting demand-dial connections, see Troubleshooting demand-dial routing.


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