Remote access VPN

Site-to-site VPN

A remote access VPN connection over the Internet enables a remote access client to initiate a dial-up connection to a local ISP instead of connecting to a corporate or outsourced network access server (NAS). 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. When the VPN connection is created, the remote access client can access the resources of the private intranet. The following figure shows remote access over the Internet.

VPN Connecting a Remote Client to a Private Intranet

When networks are connected over the Internet, as shown in the following figure, a router forwards packets to another router across a VPN connection. To the routers, the VPN connection operates as a data-link layer link.

VPN Connecting Two Remote Sites Across the Internet

In some organization intranets, the data of a department, such as human resources, is so sensitive that the network segment of the department is physically disconnected from the rest of the intranet. While this protects the data of the human resources department, it creates information accessibility problems for authorized users not physically connected to the separate network segment.

VPN connections help provide the required security to enable the network segment of the human resources department to be physically connected to the intranet. In this configuration, a VPN server can be used to separate the network segments. The VPN server does not provide a direct routed connection between the corporate intranet and the separate network segment. Users on the corporate intranet with appropriate permissions can establish a remote access VPN connection with the VPN server and gain access to the protected resources. Additionally, all communication across the VPN connection is encrypted for data confidentiality. For those users who are not authorized to establish a VPN connection, the separate network segment is hidden from view.

The following figure shows remote access over an intranet.

VPN Connection Allowing Remote Access to a Secured Network over an Intranet

Two networks can be connected over an intranet using a site-to-site VPN connection. This type of VPN connection might be necessary, for example, for two departments in separate locations, whose data is highly sensitive, to communicate with each other. For instance, the finance department might need to communicate with the human resources department to exchange payroll information.

The finance department and the human resources department are connected to the common intranet with computers that can act as VPN clients or VPN servers. When the VPN connection is established, users on computers on either network can exchange sensitive data across the corporate intranet.

The following figure shows two networks connected over an intranet.

VPN Connecting Two Networks over an Intranet

A user or client computer can issue a VPN request to configure and create a voluntary tunnel. In this case, the users computer is a tunnel endpoint and acts as the tunnel client.

Voluntary tunneling occurs when a client computer or routing server creates a virtual connection to the target tunnel server. To accomplish this, tunneling client software and the appropriate tunneling protocol must be installed on the client computer. For the protocols discussed in this technical reference, voluntary tunnels require an IP connection (either LAN or dial-up).

In a dial-up situation, the client must establish a dial-up connection to the network before the client can set up a tunnel. This is the most common case. The best example of this is the dial-up Internet user, who must dial an ISP and obtain an Internet connection before a tunnel over the Internet can be created.

For a LAN-attached client computer, there is already a connection to the network that can provide routing of encapsulated payloads to the chosen LAN tunnel server. This would be the case for a client that is using an always-on broadband Internet connection.

It is a common misconception that VPN connections require a dial-up connection. They require only IP connectivity between the VPN client and VPN server. Some clients (such as home computers) use dial-up connections to the Internet to establish IP transport. This is a preliminary step in preparation for creating a tunnel and is not part of the tunnel protocol itself.

In compulsory tunneling, a VPN-capable remote access server configures and creates a compulsory tunnel. With a compulsory tunnel, the user's computer is not a tunnel endpoint. Another device, the dial-up access server, between the user's computer and the tunnel server is the tunnel endpoint and acts as the tunnel client.

A number of vendors that sell dial-up access servers have implemented the ability to create a tunnel on behalf of a dial-up client. The computer or network device providing the tunnel for the client computer is variously known as a Front End Processor (FEP) for PPTP or an L2TP Access Concentrator (LAC) for L2TP. For the purposes of this reference, the term FEP is used to describe this functionality, regardless of the tunneling protocol. To carry out its function, the FEP must have the appropriate tunneling protocol installed and must be capable of establishing the tunnel when the client computer connects.

In compulsory tunneling, the client computer places a dial-up call to a tunneling-enabled NAS at the ISP. For example, a corporation might have contracted with an ISP to deploy a nationwide set of FEPs. These FEPs can establish tunnels across the Internet to a tunnel server connected to the organization’s private network, thus consolidating calls from geographically diverse locations into a single Internet connection at the organization network.

This configuration is known as compulsory tunneling because the client is compelled to use the tunnel created by the FEP. Once the initial connection is made, all network traffic to and from the client is automatically sent through the tunnel. With compulsory tunneling, the client computer makes a single PPP connection. When a client dials into the NAS, a tunnel is created and all traffic is automatically routed through the tunnel. An FEP can be configured to tunnel all dial-up clients to a specific tunnel server. The FEP could also tunnel individual clients, based on the user name or destination.

Unlike the separate tunnels created for each voluntary client, multiple dial-up clients can share a tunnel between the FEP and the tunnel server. When a second client dials into the access server (FEP) to reach a destination for which a tunnel already exists, there is no need to create a new instance of the tunnel between the FEP and tunnel server. Instead, the data traffic for the new client is carried over the existing tunnel. Since there can be multiple clients in a single tunnel, the tunnel is not terminated until the last user of the tunnel disconnects.

There is a PPTP control connection between the IP address of the PPTP client using a dynamically allocated TCP port and the IP address of the PPTP server using the reserved TCP port 1723. The PPTP control connection carries the PPTP call control and management messages that are used to maintain the PPTP tunnel. This includes the transmission of periodic PPTP Echo-Request and PPTP Echo-Reply messages to detect a connectivity failure between the PPTP client and PPTP server. PPTP control connection packets consist of an IP header, a TCP header, a PPTP control message, and a data-link trailer and header as shown in the following figure:

PPTP Control Connection Packet

The following table lists the primary PPTP control messages that are sent over the PPTP control connection. For all of the PPTP control messages, the specific PPTP tunnel is identified by the TCP connection.

PPTP Call Control and Connection Management Messages

For information about the exact structure of PPTP control messages, see RFC 2637 in the IETF RFC Database.

PPTP data tunneling is performed through multiple levels of encapsulation. The following figure shows the resulting structure of tunneled PPTP data.

Tunneled PPTP Data

PPP and GRE encapsulation

Encapsulation of the data-link layer

Processing of the tunneled PPTP data

The following figure shows the path that tunneled PPTP data takes through the Windows Server 2003 networking architecture from a VPN client over a remote access VPN connection using an analog modem. The following steps outline this process:

1. An IP datagram is submitted by its appropriate protocol to the virtual interface that represents the VPN connection using Network Driver Interface Specification (NDIS).
   
   
2. NDIS submits the packet to NDISWAN, which encrypts and optionally compresses the data and provides a PPP header consisting of only the PPP Protocol ID field. This assumes that address and control field compression were negotiated during the Link Control Protocol (LCP) phase of the PPP connection process. 
   
   
3. NDISWAN submits the data to the PPTP protocol driver, which encapsulates the PPP frame with a GRE header. In the GRE header, the Call ID field is set to the appropriate value to identify the tunnel.
   
   
4. The PPTP protocol driver then submits the resulting packet to the TCP/IP protocol driver.
   
   
5. The TCP/IP protocol driver encapsulates the tunneled PPTP data with an IP header and submits the resulting packet to the interface that represents the dial-up connection to the local ISP using NDIS.
   
   
6. NDIS submits the packet to NDISWAN, which provides PPP headers and trailers.
   
   
7. NDISWAN submits the resulting PPP frame to the appropriate WAN miniport driver representing the dial-up hardware (for example, the asynchronous port for a modem connection).
   
   

PPTP Packet Development

Note

• It is possible to negotiate an encrypted PPP connection for the dial-up connection with the ISP. This is unnecessary and not recommended because the private data being sent, the tunneled PPP frame, is already encrypted. The additional level of encryption is not needed and can impact performance.
  
  

In contrast to PPTP, L2TP tunnel maintenance is not performed over a separate TCP connection. L2TP call control and management traffic is sent as UDP messages between the L2TP client and the L2TP server. In Windows, the L2TP client and the L2TP server both use UDP port 1701.

Note

• The L2TP client and L2TP server in Windows always use UDP port 1701. The Windows Server 2003 L2TP server supports L2TP clients that use a UDP port other than 1701.
  
  

L2TP control messages over IP connections are sent as UDP datagrams. In the Windows Server 2003 implementation, L2TP control messages sent as UDP datagrams are sent as the encrypted payload of IPSec ESP transport mode as shown in the following figure.

L2TP Control Message

Because a TCP connection is not used, L2TP uses message sequencing to ensure delivery of L2TP messages. Within the L2TP control message, the Next-Received field (similar to the TCP Acknowledgment field) and the Next-Sent field (similar to the TCP Sequence Number field) are used to maintain the sequence of control messages. Out-of-sequence packets are dropped. The Next-Sent and Next-Received fields can also be used for sequenced delivery and flow control for tunneled data.

L2TP supports multiple calls for each tunnel. In the L2TP control message and the L2TP header for tunneled data is a Tunnel ID that identifies the tunnel and a Call ID that identifies a call within the tunnel.

The following table lists the primary L2TP control messages.

L2TP Control Messages

For the exact structure of L2TP control messages, see RFC 2661 in the IETF RFC Database.

L2TP data tunneling is performed using multiple levels of encapsulation. The following figure shows the resulting structure of tunneled L2TP over IPSec data.

L2TP Packet Encapsulation

L2TP encapsulation

UDP encapsulation

IP encapsulation

Encapsulation of the data-link layer

Processing of the tunneled L2TP/IPSec data

L2TP with Internet Protocol security (L2TP/IPSec)

IPSec ESP encapsulation protocol

The figure below shows the path that tunneled L2TP data takes through the Windows Server 2003 networking architecture from a VPN client over a remote access VPN connection using an analog modem. The following steps outline the process:

1. An IP datagram is submitted by the appropriate protocol to the virtual interface that represents the VPN connection using NDIS.
   
   
2. NDIS submits a packet to NDISWAN, which optionally compresses and provides a PPP header consisting of only the PPP Protocol ID field. This assumes that address and control field compression were negotiated during the LCP phase of the PPP connection process.
   
   
3. NDISWAN submits the PPP frame to the L2TP protocol driver, which encapsulates the PPP frame with an L2TP header. In the L2TP header, the Tunnel ID and the Call ID are set to the appropriate value identifying the specific L2TP connection.
   
   
4. The L2TP protocol driver then submits the resulting packet to the TCP/IP protocol driver with information to send the L2TP packet as a UDP message from UDP port 1701 to UDP port 1701 with the IP addresses of the VPN client and the VPN server.
   
   
5. The TCP/IP protocol driver constructs an IP packet with the appropriate IP header and UDP header. IPSec then analyzes the IP packet and matches it with a current IPSec policy. Based on the settings in the policy, IPSec encapsulates and encrypts the UDP message portion of the IP packet using the appropriate ESP headers and trailers.
   
   
6. The original IP header with the Protocol field set to 50 is added to the front of the ESP payload.
   
   
7. Using NDIS, the TCP/IP protocol driver then submits the resulting packet to the interface that represents the dial-up connection to the local ISP using NDIS.
   
   
8. NDIS submits the packet to NDISWAN.
   
   
9. NSIDWAN provides PPP headers and trailers and submits the resulting PPP frame to the appropriate WAN miniport driver representing the dial-up hardware.
   
   L2TP Packet Development
   
   Note
   
   
   • It is possible to negotiate an encrypted PPP connection for the dial-up connection with an ISP. This is not necessary and not recommended because the private data being sent, the tunneled PPP frame, is already encrypted with IPSec. The additional level of encryption is not needed and can impact performance.
     
     

Password Authentication Protocol (PAP) is a clear-text authentication scheme. The NAS requests the user name and password, and PAP returns them in clear text (unencrypted). Obviously, this authentication scheme is not secure because a malicious user could capture the user's name and password and use it to get subsequent access to the NAS and all of the resources provided by the NAS. PAP provides no protection against replay attacks or remote client impersonation once the user's password is compromised.

The Shiva Password Authentication Protocol (SPAP) is a reversible encryption mechanism employed by Shiva Corporation. A computer running Windows XP Professional uses SPAP when connecting to a Shiva LAN Rover. A Shiva client that connects to a server running Routing and Remote Access also uses SPAP. Currently, this form of authentication is more secure than plaintext but less secure than CHAP or MS-CHAP.

Challenge Handshake Authentication Protocol (CHAP) is an encrypted authentication mechanism that prevents transmission of the actual password on the connection. The NAS sends a challenge, which consists of a session ID and an arbitrary challenge string, to the remote client. The remote client must use the MD5 one-way hashing algorithm to return the user name and a hash of the challenge, session ID, and the client’s password. The user name is sent as plain text.

CHAP is an improvement over PAP because the clear-text password is not sent over the link. Instead, the password is used to create a hash from the original challenge. The server knows the client’s clear-text password and can, therefore, replicate the operation and compare the result to the password sent in the client’s response. CHAP protects against replay attacks by using an arbitrary challenge string for each authentication attempt. CHAP protects against remote-client impersonation by unpredictably sending repeated challenges to the remote client throughout the duration of the connection.

Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) is an encrypted authentication mechanism very similar to CHAP. As in CHAP, the NAS sends a challenge, which consists of a session ID and an arbitrary challenge string, to the remote client. The remote client must return the user name and an encrypted form of the challenge string, the session ID, and the MD4-hashed password. This design, which uses the MD4 hash of the password, helps provides an additional level of security because it allows the server to store hashed passwords instead of clear-text passwords or passwords that are stored using reversible encryption. MS-CHAP also provides additional error codes, including a password-expired code, and additional encrypted client-server messages that permit users to change their passwords during the authentication process. In MS-CHAP, both the client and the NAS independently generate a common initial encryption key for subsequent data encryption by MPPE.

MS-CHAP version 2 (MS-CHAP v2) is an updated encrypted authentication mechanism that provides stronger security for the exchange of user name and password credentials and determination of encryption keys. With MS-CHAP v2, the NAS sends a challenge to the client that consists of a session identifier and an arbitrary challenge string. The remote access client sends a response that contains the user name, an arbitrary peer challenge string, and an encrypted form of the received challenge string, the peer challenge string, the session identifier, and the user's password. The NAS checks the response from the client and sends back a response containing an indication of the success or failure of the connection attempt and an authenticated response based on the sent challenge string, the peer challenge string, the encrypted response of the client, and the user's password. The remote access client verifies the authentication response and, if correct, uses the connection. If the authentication response is not correct, the remote access client terminates the connection.

Using this process, MS-CHAP v2 provides mutual authentication — the NAS verifies that the client has knowledge of the user’s password, and the client verifies that the NAS has knowledge of the user’s password. MS-CHAP v2 also determines two MPPE encryption keys, one for data sent and one for data received.

Extensible Authentication Protocol (EAP) is a PPP authentication protocol that allows for an arbitrary authentication method. EAP differs from the other authentication protocols in that, during the authentication phase, EAP does not actually perform authentication. Phase 2 for EAP only negotiates the use of a common EAP authentication method (known as an EAP type). The actual authentication for the negotiated EAP type is performed after Phase 2.

During phase 2 of PPP link configuration, the NAS collects the authentication data and then validates the data against its own user database or a central authentication database server, such as one maintained by a Windows domain controller, or the authentication data is sent to a RADIUS server.

As stated previously, most implementations of PPP provide a limited number of authentication methods. EAP is an IETF standard extension to PPP that allows for arbitrary authentication mechanisms for the validation of a PPP connection. EAP was designed to allow the dynamic addition of authentication plug-in modules at both the client and authentication server. This allows vendors to supply a new authentication scheme at any time. EAP provides the highest flexibility in authentication uniqueness and variation.

EAP is documented in RFC 2284 in the IETF RFC Database, and is supported in Windows Server 2003, Windows XP, and Windows 2000.

Extensible Authentication Protocol-Message Digest 5 Challenge (EAP-MD5 Challenge) is a required EAP type that uses the same challenge handshake protocol as PPP-based CHAP, but the challenges and responses are sent as EAP messages. A typical use for EAP-MD5 Challenge is to authenticate the credentials of remote access clients by using user name and password security systems. EAP-MD5 Challenge can be used to test EAP interoperability.

Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) is an EAP type that is used in certificate-based security environments. If smart cards are used for remote access authentication, EAP-TLS is the required authentication method. The EAP-TLS exchange of messages provides mutual authentication, negotiation of the encryption method, and encrypted key determination between the remote access client and the authenticator. EAP-TLS provides the strongest authentication and key-determination method.

When the Routing and Remote Access service is configured to use Windows authentication, EAP-TLS is supported only when the VPN server is a member of a domain. A VPN server running as a stand-alone server or a member of a workgroup does not support EAP-TLS.

EAP-TLS is an IETF standard (RFC 2716 in the IETF RFC Database for a strong authentication method based on public-key certificates. With EAP-TLS, a client presents a user certificate to the server, and the server presents a server certificate to the client. The first provides strong user authentication to the server; the second provides assurance that the VPN client has reached a trusted VPN server. Both systems rely on a chain of trusted certification authorities (CAs) to verify the validity of the offered certificate.

The user’s certificate could be stored on the VPN client computer or in an external smart card. In either case, the certificate cannot be accessed without some form of user identification (PIN number or name/password credentials) between the user and the client computer. This approach meets the something-you-know-plus-something-you-have criteria recommended by most security experts.

EAP-TLS is supported in Windows Server 2003 and Windows XP. Like MS-CHAP and MS-CHAP v2, EAP-TLS returns an encryption key to enable subsequent data encryption by MPPE.

The Remote Authentication Dial-In User Service (RADIUS) protocol is used to provide centralized administration of authentication, authorization, and accounting (AAA) and an industry-standard security infrastructure. RADIUS is defined in RFCs 2138 and 2139 in the IETF RFC Database. RADIUS enables administrators to manage a set of authorization policies, accumulate accounting information, and access an account database from a central location.

Because it is impossible to update separate user accounts on separate servers for the same user simultaneously, most administrators set up a master account database at a domain controller or on a RADIUS server. This enables the VPN server to send the authentication credentials to a central authenticating device, and the same user account can be used for both dial-up remote access and VPN-based remote access.

PPTP inherits MPPE encryption, which uses the Rivest-Shamir-Adleman (RSA) RC4 stream cipher. MPPE is available only for PPTP-based VPN connections when the EAP-TLS, MS-CHAP, or MS-CHAP v2 authentication protocols are used.

For the Routing and Remote Access service, MPPE encryption strengths are configured on the Encryption tab on the properties of a remote access policy to use 40-bit (the Basic setting), 56-bit (the Strong setting), or 128-bit (the Strongest setting) encryption keys. Administrators should use 40-bit MPPE encryption keys to connect with older operating systems that do not support 56-bit or 128-bit encryption keys (this includes older Windows operating systems and operating systems from companies other than Microsoft). Otherwise, use 128-bit encryption keys. Encryption strengths for L2TP/IPSec connections use 56-bit DES (the Basic or Strong setting) or 168-bit 3DES (the Strongest setting).

Encryption keys are determined at the time of the connection. By default, the highest key strength supported by the VPN client and VPN server is negotiated during the process of establishing a connection. If the VPN server requires a higher key strength than is supported by the VPN client, the connection attempt is rejected.

MPPE was originally designed for encryption across a point-to-point link where packets arrive in the same order in which they were sent with little packet loss. For this environment, the decryption of each packet depends on the decryption of the previous packet.

For VPN connections, however, IP datagrams sent across the Internet can arrive in a different order from the one in which they were sent, and a higher proportion of packets can be lost. Therefore, for VPN connections, MPPE changes the encryption key for each packet. The decryption of each packet is independent of the previous packet. MPPE includes a sequence number in the MPPE header. If packets are lost or arrive out of order, the encryption keys are changed relative to the sequence number.

When a VPN client computer is connected to both the Internet and a private intranet and has routes that allow it to reach both networks, the possibility exists that a malicious Internet user might use the connected VPN client computer to reach the private intranet through the authenticated VPN connection. This is possible if the VPN client computer has IP routing enabled. IP routing is enabled on Windows XP-based computers by setting the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Tcpip \Parameters\IPEnableRouter registry entry to 1 (data type is REG_DWORD).

If split tunneling is required, administrators can help prevent a malicious user from gaining access over the Internet by doing the following:

• Use the Network Access Quarantine Control feature in Windows Server 2003 to check whether VPN clients have IP routing enabled and, if so, do not allow VPN access until it has been disabled.
  
  
• Use IP packet filters on the VPN remote access policy profile to discard both inbound traffic on the VPN connection that has not been sent from the VPN client and outbound traffic that is not destined to the VPN client. The default remote access policy, named “Connections to Microsoft Routing and Remote Access server in Windows Server 2003” has these packet filters configured and enabled by default.
  
  Note
  
  
  • Using the methods above does not prevent unwanted traffic if a malicious Internet user is remotely controlling the VPN client computer. To prevent this, ensure that the VPN client computer has a firewall enabled (such as Internet Connection Firewall in Windows XP) and an anti-virus program installed and running with the latest virus signature file installed. These are also settings that can be enabled and enforced when using Network Access Quarantine Control.
    
    

If routing protocols are not used to update the routing tables, then the routes must be entered as static routes. The static routes that correspond to the network IDs available across the interface are entered manually or automatically. The automatic entering of static routes for demand-dial interfaces is known as making auto-static updates and is supported by the server running Routing and Remote Access. Auto-static updates are supported by Routing Information Protocol (RIP) for IP, but not by OSPF.

Auto-static refers to the automatic adding of the requested routes as static routes in the routing table. The sending of the request for routes is performed through an explicit action, either through Routing and Remote Access or the Netsh utility while the demand-dial interface is in a connected state. Auto-static updates are not automatically performed every time a demand-dial connection is made.

When instructed, a demand-dial interface that is configured for auto-static updates sends a request across an active connection to request all of the routes of the router on the other side of the connection. In response to the request, all of the routes of the requested router are automatically entered as static routes in the routing table of the requesting router. The static routes are persistent: They are kept in the routing table even if the interface becomes disconnected or the router is restarted. An auto-static update is a one-time, one-way exchange of routing information.

Administrators can automate and schedule auto-static updates by executing the update as a scheduled task. When an auto-static update is requested, the existing auto-static routes are deleted before the update is requested from other routers. If there is no response to the request, then the router cannot replace the routes it has deleted. This might lead to a loss of connectivity to remote networks.

The biggest advantage of RIP is that it is extremely simple to configure and deploy. The biggest disadvantage of RIP is its inability to scale to large or very large networks. The maximum hop count used by RIP routers is 15. Networks that are 16 hops or more away are considered unreachable. As networks grow larger in size, the periodic announcements by each RIP router can cause excessive traffic. Another disadvantage of RIP is its high recovery time. When the network topology changes, it might take several minutes before the RIP routers reconfigure themselves to the new network topology. While the network reconfigures itself, routing loops might form that result in lost or undeliverable data.

Initially, the routing table for each router includes only the networks that are physically connected. A RIP router periodically sends announcements that contain its routing table entries to inform other local RIP routers of the networks it can reach. RIP version 1 uses IP broadcast packets for its announcements. RIP version 2 can use multicast or broadcast packets for its announcements.

RIP routers can also communicate routing information through triggered updates. Triggered updates occur when the network topology changes and updated routing information is sent that reflects those changes. With triggered updates, the update is sent immediately rather than waiting for the next periodic announcement. For example, when a router detects a link or router failure, it updates its own routing table and sends updated routes. Each router that receives the triggered update modifies its own routing table and propagates the change.

Routing and Remote Access supports RIP versions 1 and 2. RIP version 2 supports multicast announcements, simple password authentication, and more flexibility in subnetted and Classless InterDomain Routing (CIDR) environments.

The biggest advantage of OSPF is that it is efficient; OSPF requires very little network overhead even in very large networks. The biggest disadvantage of OSPF is its complexity; OSPF requires proper planning and is more difficult to configure and administer.

OSPF uses a Shortest Path First (SPF) algorithm to compute routes in the routing table. The SPF algorithm computes the shortest (least cost) path between the router and all the subnets of the network. SPF-calculated routes are always loop-free.

Changes to network topology are efficiently flooded across the entire network to ensure that the link state database on each router is synchronized and accurate at all times. Upon receiving changes to the link state database, the routing table is recalculated.

As the size of the link state database increases, memory requirements and route computation times increase. To address this scaling problem, OSPF divides the network into areas (collections of contiguous networks) that are connected to each other through a backbone area. Each router only keeps a link state database for those areas that are connected to the router. Area border routers (ABRs) connect the backbone area to other areas.

Single-Adapter model

Multiple-Adapter model

Virtual links

External routes and ASBRs

External route filters

If the VPN server is behind a firewall, packet filters must be configured for both an Internet interface and a perimeter network interface. In this scenario, the firewall is connected to the Internet, and the VPN server is an intranet resource that is connected to the perimeter network. The VPN server has an interface on both the perimeter network and the Internet.

PPTP connections for the Internet interface of the firewall

PPTP connections for the perimeter network interface of the firewall

L2TP/IPSec connections for the Internet interface of the firewall

L2TP/IPSec connections for the perimeter network interface of the firewall

When a VPN server is in front of a firewall and connected to the Internet, inbound and outbound packet filters on the VPN server need to be configured to allow only VPN traffic to and from the IP address of the VPN server’s Internet interface. Use this configuration if the VPN server is in a perimeter network, with one firewall positioned between the VPN server and the intranet and another between the VPN server and the Internet.

All of the following packet filters are configured, using the Routing and Remote Access snap-in, as IP packet filters on the Internet interface. Depending on the configuration decisions made when running the Routing and Remote Access Server Setup Wizard, these packet filters might already be configured.

PPTP connections for the inbound and outbound filters

L2TP/IPSec connections

If a VPN client that uses a PPTP connection is behind a NAT, the NAT must include a NAT editor that can translate PPTP traffic. The NAT editor is required because tunneled PPTP data has a GRE header rather than a TCP header or a UDP header. The NAT editor uses the Call ID field in the GRE header to identify the PPTP data stream and translate IP addresses and call IDs for PPTP data packets that are forwarded between a private network and the Internet.

PPTP NAT editor

To use L2TP-based VPN connections behind a NAT, IPSec NAT Traversal (NAT-T) must be implemented at both ends of the VPN connection.

IPSec NAT-T

User Datagram Protocol-Encapsulating Security Payload (UDP-ESP)