How VPN Works

Updated: March 28, 2003

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server
2003 with SP2

How VPN Works

In this section

VPN Architecture

VPN Tunneling

VPN Authentication

VPN Encryption

VPN Addressing and Routing

VPN and Firewalls

VPN and NAT

Related Information

Microsoft Windows Server2003 includes extensive support for virtual private network (VPN) technology, which
leverages the IP connectivity of the Internet to connect remote clients and remote sites.

A VPN connection is the extension of a private network that includes links across shared or public networks, such
as the Internet. VPN connections (VPNs) enable organizations to send data between two computers across the
Internet in a manner that emulates the properties of a point-to-point private link.

VPN Architecture
Using VPNs, an organization can help secure private network traffic over an unsecured network, such as the
Internet. VPN helps provide a secure mechanism for encrypting and encapsulating private network traffic and
moving it through an intermediate network. Data is encrypted for confidentiality, and packets that might be
intercepted on the shared or public network are indecipherable without the correct encryption keys. Data is also
encapsulated, or wrapped, with an IP header containing routing information.

VPNs help enable users working at home, on the road, or at a branch office to connect in a secure fashion to a
remote corporate server using the Internet. From the users perspective, the VPN is a point-to-point connection
between the user's computer and a corporate server. The nature of the intermediate network, the Internet, is
irrelevant to the user because it appears as if the data is being sent over a dedicated private link.

There are a number of ways to use VPN. The most common scenario is when a remote user accesses a private
network across the Internet using a remote access VPN connection. In another scenario, a remote office connects
to the corporate network using either a persistent or an on-demand site-to-site VPN connection (also known as a
router-to-router VPN connection).

Each of these VPN scenarios can be deployed to provide connectivity over a public network, such as the Internet,
or over a private intranet. VPN connections can also be deployed in an extranet scenario to communicate
securely with business partners. An extranet functions as an intranet that can be securely shared with a
designated business partner.

With both the remote access and site-to-site connections, VPNs enable an organization to replace long distance
dial-up or leased lines with local dial-up or leased lines to an Internet service provider (ISP).

Remote access VPN

A remote access VPN connection is made by a remote access client. A remote access client is a single computer
user who connects to a private network from a remote location. The VPN server provides access to the resources
of the network to which the VPN server is connected. The packets sent across the VPN connection originate at
the VPN client.

The VPN client authenticates itself to the VPN server and, for mutual authentication, the VPN server authenticates
itself to the VPN client.

Site-to-site VPN
A site-to-site VPN connection connects two portions of a private network or two private networks. For example,
this allows an organization to have routed connections with separate offices, or with other organizations, over
the Internet. A routed VPN connection across the Internet logically operates as a dedicated Wide Area Network
(WAN) link.

The VPN server provides a routed connection to the network to which the VPN server is attached. On a site-to-
site 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.

Internet-based VPN Connections

Using an Internet-based VPN connection, an organization can avoid long-distance charges while taking
advantage of the global availability of the Internet.

Remote Access VPN Connections over the Internet

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

Site-to-Site VPN Connections Over the Internet
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

Intranet-based VPN Connections

The intranet-based VPN connection takes advantage of IP connectivity in an organizations Local Area Network
(LAN).

Remote Access VPN Connections over an Intranet

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

Site-to-Site VPN Connections 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

VPN Tunneling
Tunneling is a network technology that enables the encapsulation of one type of protocol packet within the
datagram of a different protocol. For example, Windows VPN connections can use Point-to-Point Tunneling
Protocol (PPTP) packets to encapsulate and send private network traffic, such as TCP/IP traffic over a public
network such as the Internet.

For PPTP and Layer Two Tunneling Protocol (L2TP), a tunnel is similar to a session. Both of the tunnel endpoints
must agree to the tunnel and must negotiate configuration variables, such as address assignment, encryption, or
compression parameters. In most cases, data transferred across the tunnel is sent using a datagram-based
protocol. A tunnel management protocol is used as the mechanism to create, maintain, and terminate the tunnel.

After the tunnel is established, data can be sent. The tunnel client or server uses a tunnel data transfer protocol
to prepare the data for transfer. For example, when the tunnel client sends a payload to the tunnel server, the
tunnel client first appends a tunnel data transfer protocol header to the payload. The client then sends the
resulting encapsulated payload across the network, which routes it to the tunnel server. The tunnel server accepts
the packets, removes the tunnel data transfer protocol header, and forwards the payload to the target network.
Information sent between the tunnel server and the tunnel client behaves similarly.

There are two types of tunneling:

Voluntary tunneling

Compulsory tunneling

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

Compulsory Tunneling
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 organizations 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.

PPTP
Point-to-Point Tunneling Protocol (PPTP) encapsulates Point-to-Point Protocol (PPP) frames into IP datagrams
for transmission over an IP-based network, such as the Internet or over a private intranet. PPTP is described in
RFC 2637 in the IETF RFC Database.

PPTP uses a TCP connection, known as the PPTP control connection, to create, maintain, and terminate the
tunnel. PPTP uses a modified version of Generic Routing Encapsulation (GRE) to encapsulate PPP frames as
tunneled data. The payloads of the encapsulated PPP frames can be encrypted, compressed, or both.

PPTP assumes the availability of an IP network between a PPTP client (a VPN client using the PPTP tunneling
protocol) and a PPTP server (a VPN server using the PPTP tunneling protocol). The PPTP client might already be
attached to an IP network that can reach the PPTP server, or the PPTP client might have to use a dial-up
connection to a NAS to establish IP connectivity as in the case of dial-up Internet users.
Authentication that occurs during the creation of a PPTP-based VPN connection uses the same authentication
mechanisms as PPP connections, such as Extensible Authentication Protocol (EAP), Microsoft Challenge-
Handshake Authentication Protocol (MS-CHAP), Microsoft Challenge-Handshake Authentication Protocol version
2 (MS-CHAP v2), CHAP, Shiva Password Authentication Protocol (SPAP), and Password Authentication Protocol
(PAP). PPTP inherits encryption, compression, or both of PPP payloads from PPP. For PPTP connections, EAP-
Transport Layer Security (EAP-TLS), MS-CHAP, or MS-CHAP v2 must be used for the PPP payloads to be
encrypted using Microsoft Point-to-Point Encryption (MPPE).

MPPE provides only link encryption between the VPN client and the VPN server. It does not provide end-to-end
encryption, which is data encryption between the client application and the server hosting the resource or service
that is being accessed by the client application. If end-to-end encryption is required, IPSec can be used to
encrypt IP traffic from end-to-end after the PPTP tunnel is established.

Tunnel Maintenance with the PPTP Control Connection

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

Message Type Purpose

Start-Control- Sent by the PPTP client to establish the control connection. Each PPTP tunnel
Connection-Request requires a control connection to be established before any other PPTP messages can
be issued.

Start-Control- Sent by the PPTP server to reply to the Start-Control-Connection-Request message.

Connection-Reply

Outgoing-Call- Sent by the PPTP client to create a PPTP tunnel. Included in the Outgoing-Call-
Request Request message is a Call ID that is used in the GRE header to identify the tunneled
traffic of a specific tunnel.

Outgoing-Call-Reply Sent by the PPTP server in response to the Outgoing-Call-Request message.

Echo-Request Sent by either the PPTP client or PPTP server as a keep-alive mechanism. If the Echo-
Request is not answered, the PPTP tunnel is eventually terminated.

Echo-Reply
 The reply to an Echo-Request. The PPTP Echo-and Echo-Reply messages are not
related to the ICMP Echo Request and Echo Reply messages.

WAN-Error-Notify Sent by the PPTP server to all VPN clients to indicate error conditions on the PPP
interface of the PPTP server.

Set-Link-Info Sent by the PPTP client or PPTP server to set PPP-negotiated options.

Call-Clear-Request Sent by the PPTP client, indicating that a tunnel is to be terminated.

Call-Disconnect- Sent by the PPTP server in response to a Call-Clear-Request or for other reasons to
Notify indicate that a tunnel is to be terminated. If the PPTP server terminates the tunnel, a
Call-Disconnect-Notify is sent.

Stop-Control- Sent by the PPTP client or the PPTP server to inform the other that the control
Connection-Request connection is being terminated.

Stop-Control- The reply to the Stop-Control-Connection-Request message.

Connection-Reply

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

PPTP Data Tunneling

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

The initial PPP payload is encrypted and encapsulated with a PPP header to create a PPP frame. The PPP frame is
then encapsulated with a modified GRE header. GRE is described in RFC 1701 and RFC 1702 in the IETF RFC
Database and was designed to provide a simple, general purpose mechanism for encapsulating data sent over IP
networks. GRE is a client protocol of IP using IP protocol 47.

For PPTP, the GRE header is modified in the following ways:

An acknowledgement bit is used to indicate that a 32-bit acknowledgement field is present and significant.

The Key field is replaced with a 16-bit Payload Length field and a 16-bit Call ID field. The Call ID field is set by the
PPTP client during the creation of the PPTP tunnel.

A 32-bit Acknowledgement field is added.

Within the GRE header, the Protocol Type is set to 0x880B, the EtherType value for a PPP frame.

Note

GRE is sometimes used by ISPs to forward routing information within an ISP's network. To prevent the
routing information from being forwarded to Internet backbone routers, ISPs filter out GRE traffic on the
interfaces connected to the Internet backbone. As a result of this filtering, PPTP tunnels can be created
 using PPTP control messages, but tunneled PPTP data is not forwarded.

The resulting encapsulated GRE and PPP payload is then encapsulated with an IP header containing the
appropriate source and destination IP addresses for the PPTP client and PPTP server.

Encapsulation of the data-link layer

To be sent on a local area network (LAN) or WAN link, the IP datagram is finally encapsulated with a header and
trailer for the data-link layer technology of the outgoing physical interface. For example, when IP datagrams are
sent on an Ethernet interface, the IP datagram is encapsulated with an Ethernet header and trailer. When IP
datagrams are sent over a point-to-point WAN link, such as an analog phone line or ISDN, the IP datagram is
encapsulated with a PPP header and trailer.

Processing of the tunneled PPTP data

Upon receipt of the tunneled PPTP data, the PPTP client or PPTP server:

Processes and removes the data-link header and trailer.

Processes and removes the IP header.

Processes and removes the GRE and PPP headers.

Decrypts and, if needed, decompresses the PPP payload.

Processes the payload for receipt or forwarding.

PPTP Packet Development

The following figure shows the path that tunneled PPTP data takes through the Windows Server2003 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.

L2TP
Layer Two Tunneling Protocol (L2TP) is a combination of PPTP and Layer 2 Forwarding (L2F), a technology
developed by Cisco Systems, Inc. Rather than having two incompatible tunneling protocols competing in the
marketplace and causing customer confusion, the Internet Engineering Task Force (IETF) mandated that the two
technologies be combined into a single tunneling protocol that represents the best features of PPTP and L2F.
L2TP is described in RFC 2661 in the IETF RFC Database.

L2TP encapsulates PPP frames to be sent over IP, X.25, frame relay, or ATM networks. When sent over an IP
network, L2TP frames are encapsulated as User Datagram Protocol (UDP) messages. L2TP can be used as a
tunneling protocol over the Internet or over private intranets.

L2TP uses UDP messages over IP networks for both tunnel maintenance and tunneled data. The payloads of
encapsulated PPP frames can be encrypted or compressed (or both); however, L2TP clients do not negotiate the
use of MPPE for L2TP connections. Encryption for L2TP connections is provided by IPSec Encapsulating Security
Payload (ESP) in transport mode.

It is possible to create Windows-based L2TP connections that are not encrypted by IPSec. However, this does not
apply to a VPN connection because the private data being encapsulated by L2TP is already not encrypted. Non-
encrypted L2TP connections can be used temporarily to troubleshoot an L2TP over IPSec connection by
eliminating the IPSec authentication and negotiation process.

L2TP for Windows assumes the availability of an IP network between an L2TP client (a VPN client using the L2TP
tunneling protocol and IPSec) and an L2TP server (a VPN server using the L2TP tunneling protocol and IPSec).
The L2TP client might already be attached to an IP network that can reach the L2TP server, or the L2TP client
might have to use a dial-up connection to a NAS to establish IP connectivity as in the case of dial-up Internet
users.

Authentication that occurs during the creation of L2TP tunnels must use the same authentication mechanisms as
PPP connections.

An Internet-based L2TP server is an L2TP-enabled remote access server with one interface on the Internet and a
second interface on a private intranet.
L2TP tunnel maintenance and tunneled data have the same packet structure.

Tunnel Maintenance with L2TP Control Messages

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

Message Type Purpose

Start-Control- Sent by the L2TP client to establish the control connection. Each L2TP tunnel requires
Connection-Request a control connection to be established before any other L2TP messages can be
issued. It includes an Assigned Tunnel-ID that is used to identify the tunnel.

Start-Control- Sent by the L2TP server to reply to the Start-Control-Connection-Request message.

Connection-Reply

Start-Control- Sent in reply to a Start-Control-Connection-Reply message to indicate that tunnel

Connection- establishment was successful.
Connected
 Outgoing-Call- Sent by the L2TP client to create an L2TP tunnel. Included in the Outgoing-Call-
Request Request message is an Assigned Call ID that is used to identify a call within a specific
tunnel.

Outgoing-Call-Reply Sent by the L2TP server in response to the Outgoing-Call-Request message.

Start-Control- Sent in reply to a received Outgoing-Call-Reply message to indicate that the call was
Connection- successful.
Connected

Hello Sent by either the L2TP client or L2TP server as a keep-alive mechanism. If the Hello is
not acknowledged, the L2TP tunnel is eventually terminated.

WAN-Error-Notify Sent by the L2TP server to all VPN clients to indicate error conditions on the PPP
interface of the L2TP server.

Set-Link-Info Sent by the L2TP client or L2TP server to set PPP-negotiated options.

Call-Disconnect- Sent by either the L2TP server or L2TP client to indicate that a call within a tunnel is
Notify to be terminated.

Stop-Control- Sent by either the L2TP server or L2TP client to indicate that a tunnel is to be
Connection- terminated.
Notification

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

L2TP Data Tunneling

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
The initial PPP payload is encapsulated with a PPP header and an L2TP header.

UDP encapsulation
The encapsulated L2TP packet is then encapsulated with a UDP header with the source and destination ports set
to 1701.

IP encapsulation
The UDP message is encrypted and encapsulated with an IPSec ESP header and trailer and an ESP Authentication
(Auth) trailer.

Encapsulation of the data-link layer

To send on a LAN or WAN link, the IP datagram is finally encapsulated with a header and trailer for the data-link
layer technology of the outgoing physical interface. For example, when an IP datagram is sent on an Ethernet
interface, the IP datagram is encapsulated with an Ethernet header and trailer. When an IP datagram is sent over
a point-to-point WAN link such as an analog phone line or ISDN, the IP datagram is encapsulated with a PPP
header and trailer.

Processing of the tunneled L2TP/IPSec data

Upon receipt of the tunneled L2TP/IPSec data, the L2TP client or L2TP server:

Processes and removes the data-link header and trailer.

Processes and removes the IP header.

Uses the IPSec ESP Auth trailer to authenticate the IP payload and the IPSec ESP header.

Uses the IPSec ESP header to decrypt the encrypted portion of the packet.

Processes the UDP header and sends the L2TP packet to the L2TP driver.

Uses the Tunnel ID and Call ID in the L2TP header to identify the specific L2TP tunnel.

Uses the PPP header to identify the PPP payload and forward it to the proper protocol driver for
processing.

L2TP with Internet Protocol security (L2TP/IPSec)

Tunneling protocols such as PPTP and L2TP are implemented at the data-link layer of the Open Systems
Interconnection (OSI) reference model and provide data security by helping to create secure tunnels. In contrast,
the IPSec protocol is implemented at the network layer and helps secure data at the packet level. IPSec provides
two security protocols: Authentication Header (AH) and ESP.

IPSec ESP encapsulation protocol

To provide maximum security for L2TP/IPSec packets, ESP can also be used to encapsulate IPSec packets.

L2TP Packet Development

The figure below shows the path that tunneled L2TP data takes through the Windows Server2003 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.

VPN Authentication
The VPN server can be configured to use either Windowsor Remote Authentication Dial-In User Service
(RADIUS) as an authentication provider. If Windowsis selected as the authentication provider, the user
credentials sent by users attempting VPN connections are authenticated using typical Windowsauthentication
mechanisms, and the connection attempt is authorized using the VPN clients user account properties and local
remote access policies.

If RADIUS is selected and configured as the authentication provider on the VPN server, user credentials and
parameters of the connection request are sent as RADIUS request messages to a RADIUS server.

The RADIUS server receives a user-connection request from the VPN server and authenticates and authorizes the
connection attempt. In addition to a yes or no response to an authentication request, RADIUS can inform the
VPN server of other applicable connection parameters for this user such as maximum session time, static IP
address assignment, and so on.

RADIUS can respond to authentication requests based on its own user account database, or it can be a front end
to another database server, such as a Structured Query Language (SQL) server or a Windowsdomain controller
(DC). The DC can be located on the same computer as the RADIUS server or elsewhere. In addition, a RADIUS
server can act as a proxy client to a remote RADIUS server.

The RADIUS protocol is described in RFC 2865 and RFC 2866 in the IETF RFC Database.

The VPN server can be configured to use either Windowsor RADIUS as an accounting provider. If Windows is
selected as the accounting provider, the accounting information accumulates on the VPN server for later analysis.
Logging options can be specified from the properties of the Local File or SQL Server objects in the Remote
Access Logging folder in the Routing and Remote Access snap-in. If RADIUS is selected, RADIUS accounting
messages are sent to the RADIUS server for accumulation and later analysis.

Most RADIUS servers can be configured to place authentication request records into an audit file. A number of
third parties have written billing and audit packages that read RADIUS accounting records and produce various
useful reports. For more information about RADIUS accounting, see RFC 2866 in the IETF RFC Database.

The VPN server can be managed using industry-standard network management protocols and infrastructure. The
computer acting as the VPN server can participate in a Simple Network Management Protocol (SNMP)
environment as an SNMP agent if the Windows Server2003 SNMP service is installed. The VPN server records
management information in various object identifiers of the Internet Management Information Base (MIB) II,
which is installed with the Windows Server2003 SNMP service. Objects in the Internet MIB II are documented in
RFC 1213 in the IETF RFC Database.

Authentication Protocols
The following authentication protocols are used to identify VPN users and grant or deny user access to network
resources based on the user's credentials.

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

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

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 clients 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 clients clear-text password
and can, therefore, replicate the operation and compare the result to the password sent in the clients 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.
MS-CHAP
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 v2
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 users password, and the client verifies that the NAS has knowledge of the users password.
MS-CHAP v2 also determines two MPPE encryption keys, one for data sent and one for data received.

EAP
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 Server2003,
WindowsXP, and Windows2000.

EAP-MD5 Challenge
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.
EAP-TLS
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 users 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 Server2003 and Windows XP. Like MS-CHAP and MS-CHAP v2, EAP-TLS
returns an encryption key to enable subsequent data encryption by MPPE.

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

VPN Encryption
To help ensure confidentiality of the data as it traverses the shared or public transit network, it is encrypted by
the sender and decrypted by the receiver. Because data encryption is performed between the VPN client and
VPN server, it is not necessary to use data encryption on the communication link between a dial-up client and its
Internet service provider (ISP). For example, a mobile user uses a dial-up networking 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, there is no need to use encryption on the dial-up networking
connection between the client and the ISP.

Remote access data encryption does not provide end-to-end data encryption. End-to-end encryption is data
encryption between the client application and the server that hosts the resource or service being accessed by the
client application. To get end-to-end data encryption, use IPSec to help create a secure connection after the
remote access connection has been made.

Data encryption for PPP or PPTP connections is available only if MS-CHAP, MS-CHAP v2, or EAP-TLS is used as
the authentication protocol. Data encryption for L2TP connections relies on IPSec, which does not require a
specific PPP-based authentication protocol.
The encryption and decryption processes depend on both the sender and the receiver having knowledge of a
common encryption key. Intercepted packets sent along the VPN connection in the transit network are
unintelligible to any computer that does not have the common encryption key. The length of the encryption key
is an important security parameter. Computational techniques can be used to determine the encryption key. Such
techniques require more computing power and computational time as the encryption key gets larger. Therefore,
it is important to use the largest possible key size.

In addition, the more information that is encrypted with the same key, the easier it is to decipher the encrypted
data. With some encryption technologies, administrators are given the option to configure how often the
encryption keys are changed during a connection.

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

Data Encryption with MPPE

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.

VPN Addressing and Routing

Based on whether or not a route is added by default, a VPN client has broad access to Internet locations or to
locations on the intranet, but not to both:

If the currently active default route is pointing to the Internet (and the gateway on the remote network is
not being used), Internet locations are reachable, but only intranet locations matching the network ID
corresponding to the Internet address class of the assigned IP address can be reached.

If the currently active default route is pointing to the intranet (and the gateway on the remote network is
being used), all intranet locations are reachable, but only the IP address of the VPN server and locations
available through other routes can be reached on the Internet.
For most VPN clients with an Internet connection, this does not present a problem, because the client is typically
engaged in either intranet communication or Internet communication, but not both.

To work around this problem, instead of having the client create a new default route when a connection is made,
administrators can configure the clients routing table with specific routes that direct packets to the
organizations network over the VPN connection. While connected to the intranet, the client can obtain Internet
access using the default route that points to the Internet. This configuration is known as split tunneling.

Split Tunneling
The VPN client can obtain the routes needed for split tunneling in several ways:

If the VPN client has a configured connection without a default route, the client adds a route that it infers
from the Internet address class of the IP address assigned to it for the current connection. For a simple
target network, such as a small office, this one route is sufficient to allow packets to be routed to the
target network. However, for a complex network, administrators need to configure multiple routes to
successfully direct packets to the remote network.

A client running the Microsoft WindowsXP or Windows Server2003 operating systems uses a
DHCPINFORM message after the connection to request the DHCP Classless Static Routes option. This
DHCP option contains a set of routes that are automatically added to the routing table of the requesting
client. This additional information is available only if the Windows Server2003 DHCP server has been
configured to provide the DHCP Classless Static Routes option and if the VPN server has the DHCP Relay
Agent routing protocol component configured with the IP address of the DHCP server.

If the remote access client is managed using the Connection Manager component of Windows
Server2003, the network administrator can configure routing table updates from the Routing Table
Update page of the Connection Manager Administration Kit when creating the Connection Manager
profile.

If none of the approaches discussed above is an option, a batch file or program can be written that updates the
routing table on the client with the necessary routes to the private intranet.

Security Considerations for Split Tunneling

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

DHCP Classless Static Routes Option

Classless static routes are implemented using DHCP scope option 249. Using classless static routes, each DHCP
client can be configured with the route to any destination on the network, and the subnet mask can be specified.
Because each scope represents a physical subnet, the scope can be viewed as the start location for any message
that is to be sent by a client to another subnet. The parameters used to configure option 249 are Destination,
Mask, and Router. One or more static routes can be configured with option 249. All DHCP-enabled clients on the
network can be provided with routes to all other subnets using option 249.

This option is configured as a scope option because the Router IP address, like the DHCP Router option that
defines the default gateway for a DHCP client, is different for each subnet. For example, subnets A and D each
use a router. The routers they use will be different, and the Router IP address will be different in each case.

Static Routing
Static routing requires that routing tables be configured and maintained manually. Static routers do not
exchange information. Because of this limitation, when compared to dynamic routing, static routing is typically
implemented in small networks or in networks that require the highest level of security.

Auto-Static Updates
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.

Dynamic Routing
By implementing a dynamic routing protocol, such as RIP or Open Shortest Path First (OSPF), administrators can
configure routers to exchange routing information with each other as needed.
RIP
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 is15.
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 version1 uses IP broadcast packets for its announcements. RIP version2 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 versions1 and2. RIP version2 supports multicast announcements,
simple password authentication, and more flexibility in subnetted and Classless InterDomain Routing (CIDR)
environments.

OSPF
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
With the single-adapter model, also known as the NBMA model, the network for the frame relay service provider
(also known as the frame relay cloud) is treated as an IP network and the endpoints on the cloud are assigned IP
addresses from a designated IP network ID. To ensure that OSPF traffic is received by all of the appropriate
endpoints on the cloud, the frame relay interface must be configured to send unicast OSPF announcements to all
of the appropriate endpoints. For the server running Routing and Remote Access, this is done by designating the
interface as an NBMA network and adding OSPF neighbors.

In addition, in a spoke and hub frame relay topology, the frame relay interface for the hub router must have a
router priority set to1 or greater and the frame relay interfaces for the spoke routers must have a router priority
set to0. Otherwise, the hub router, which is the only router that can communicate with all of the spoke routers,
cannot become the designated router and adjacencies cannot form across the frame relay network.
Multiple-Adapter model
With the multiple-adapter model, each frame relay virtual circuit appears as a point-to-point link with its own
network ID, and the endpoints are assigned IP addresses from a designated IP network ID. Because each virtual
circuit is its own point-to-point connection, administrators can configure the interface for the point-to-point
network type.

Virtual links
An OSPF-routed network can be subdivided into areas, which are collections of contiguous networks. All areas
are connected together through a common area called the backbone area. A router that connects an area to the
backbone area is called an area border router (ABR). Normally, ABRs have a physical connection to the backbone
area. When it is not possible or practical to have an ABR physically connected to the backbone area,
administrators can use a virtual link to connect the ABR to the backbone.

A virtual link is a logical point-to-point connection between an ABR of an area and an ABR that is physically
connected to the backbone area. For example, a virtual link is configured between the ABR of Area2 and the ABR
of Area1. The ABR of Area1 is physically connected to the backbone area. Area1 is known as the transit area,
the area across which the virtual link is created in order to logically connect Area2 to the backbone.

To create a virtual link, both routers, called virtual link neighbors, are configured with the transit area, the router
ID of the virtual link neighbor, matching hello and dead intervals, and a matching password.

External routes and ASBRs

The set of OSPF routers in an organization defines an OSPF autonomous system (AS). By default, only OSPF
routes corresponding to directly-connected network segments are propagated within the AS. An external route is
any route that is not within the OSPF AS. External routes can come from many sources:

Other routing protocols such as RIP for IP (version 1 and version 2)

Static routes

Routes set on the router through SNMP

External routes are propagated throughout the OSPF AS through one or more autonomous system boundary
routers (ASBRs). An ASBR advertises external routes within the OSPF AS. For example, if the static routes of a
server running Routing and Remote Access need to be advertised, that router must be enabled as an ASBR.

External route filters

By default, OSPF routers acting as ASBRs import and advertise all external routes. Administrators might want to
filter out external routes to keep the ASBR from advertising improper routes. External routes can be filtered on
the ASBR by:

External route source

Administrators can configure the ASBR to accept or ignore the routes of certain external sources such as routing
protocols (RIPversion 2) or other sources (static routes or SNMP).

Individual route
Administrators can configure the ASBR to accept or discard specific routes by configuring one or multiple
destination, network mask pairs.

VPN and Firewalls

A firewall uses packet filtering to allow or disallow the flow of specific types of network traffic. IP packet filtering
provides a way for administrators to define precisely what IP traffic is allowed to cross the firewall. IP packet
filtering is important when private intranets are connected to public networks, such as the Internet. There are two
approaches to using a firewall with a VPN server:

A firewall is between the VPN server and the Internet. In this configuration, the VPN server is behind the
firewall.

The VPN server is connected to the Internet and the firewall is between the VPN server and the intranet. In
this configuration, the VPN server is in front of the firewall.

VPN Server Behind a Firewall

In the configuration shown in the following figure, the firewall is connected to the Internet and the VPN server is
another intranet resource connected to the perimeter network, also known as a screened subnet or demilitarized
zone (DMZ). The perimeter network is an IP network segment that typically contains resources available to
Internet users such as Web servers and FTP servers. The VPN server has an interface on the perimeter network
and an interface on the intranet.

In this approach, the firewall must be configured with input and output filters on its Internet and perimeter
network interfaces to allow the passing of tunnel maintenance traffic and tunneled data to the VPN server.
Additional filters can allow the passing of traffic to Web servers, FTP servers, and other types of servers on the
perimeter network. As an added layer of security, the VPN server should also be configured with PPTP or
L2TP/IPSec packet filters on its perimeter network interface as described in VPN Server in Front of a Firewall in
this section.

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

VPN Server Behind the Firewall

Packet Filters for a VPN Server Behind a Firewall

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

The following table shows the inbound and outbound PPTP filters on the firewalls Internet interface.

VPN Server Behind a Firewall: PPTP Filters on the Firewalls Internet Interface
Filter Type Filter Action

Inbound Destination IP Allows PPTP tunnel maintenance traffic from the PPTP client to the
address = Perimeter PPTP server.
network interface of
VPN server

TCP destination port

= 1723 (0x6BB)

Inbound Destination IP Allows tunneled PPTP data from the PPTP client to the PPTP server.
address = Perimeter
network interface of
VPN server

IP Protocol ID = 47
(0x2F)

Inbound Destination IP Required only when the VPN server is acting as a VPN client (a
address = Perimeter calling router) in a site-to-site VPN connection. If all traffic from TCP
network interface of port 1723 is allowed to reach the VPN server, network attacks can
VPN server emanate from sources on the Internet that use this port.
Administrators should only use this filter in conjunction with the
TCP source port = PPTP filters that are also configured on the VPN server.
1723 (0x6BB)

Outbound Source IP address = Allows PPTP tunnel maintenance traffic from the PPTP server to the
Perimeter network PPTP client.
interface of VPN
server

TCP source port =

1723 (0x6BB)

Outbound Source IP address = Allows tunneled PPTP data from the PPTP server to the PPTP client.
Perimeter network
interface of VPN
server

IP Protocol ID = 47
(0x2F)

Outbound Source IP address = Required only when the VPN server is acting as a VPN client (a
Perimeter network calling router) in a site-to-site VPN connection. If all traffic from the
interface of VPN VPN server is allowed to reach TCP port 1723, network attacks can
server emanate from sources on the Internet using this port.
Administrators should only use this filter in conjunction with the
TCP destination port PPTP filters that are also configured on the VPN server.
= 1723 (0x6BB)
PPTP connections for the perimeter network interface of the firewall
The following table shows the inbound and outbound PPTP filters on the firewalls perimeter network interface.

VPN Server Behind a Firewall: PPTP Filters on the Perimeter Network Interface

Filter Type Filter Action

Inbound Source IP address = Allows PPTP tunnel maintenance traffic from the VPN server to
Perimeter network the VPN client.
interface of VPN server

TCP source port = 1723

(0x6BB)

Inbound Source IP address = Allows tunneled PPTP data from the VPN server to the VPN
Perimeter network client.
interface of VPN server

IP Protocol ID = 47
(0x2F)

Inbound Source IP address = Required only when the VPN server is acting as a VPN client (a
Perimeter network calling router) in a site-to-site VPN connection. If all traffic from
interface of VPN server TCP port 1723 is allowed to reach the VPN server, network
attacks can emanate from sources on the Internet using this
TCP destination port = port.
1723 (0x6BB)

Outbound Destination IP address Allows PPTP tunnel maintenance traffic from the PPTP client to
= Perimeter network the PPTP server.
interface of VPN server

TCP source port = 1723

(0x6BB)

Outbound Destination IP address Allows tunneled PPTP data from the PPTP client to the PPTP
= Perimeter network server.
interface of VPN server

IP Protocol ID = 47
(0x2F)

Outbound Destination IP address Required only when the VPN server is acting as a VPN client (a
= Perimeter network calling router) in a site-to-site VPN connection. If all traffic from
interface of VPN server the VPN server is allowed to reach TCP port 1723, network
attacks can emanate from sources on the Internet using this
TCP source port = 1723 port.
(0x6BB)
L2TP/IPSec connections for the Internet interface of the firewall
The following table shows the inbound and outbound L2TP/IPSec filters on the firewalls Internet interface.

VPN Server Behind a Firewall: L2TP/IPSec Filters on the Firewalls Internet Interface

Filter Type Filter Action

Inbound Destination IP address = Perimeter network Allows IKE traffic to the VPN server.
interface of VPN server

UDP destination port = 500 (0x1F4)

Inbound Destination IP address = Perimeter network Allows IPSec NAT-T traffic to the VPN
interface of VPN server server.

UDP destination port = 4500 (0x1194)

Inbound Destination IP address = Perimeter network Allows IPSec ESP traffic to the VPN
interface of VPN server server.

IP Protocol ID = 50 (0x32)

Outbound Source IP address = Perimeter network interface of Allows IKE traffic from the VPN
VPN server server.

UDP source port = 500 (0x1F4)

Outbound Source IP address = Perimeter network interface of Allows IPSec NAT-T traffic from the
VPN server VPN server.

UDP source port = 4500 (0x1194)

Outbound Source IP address = Perimeter network interface of Allows IPSec ESP traffic from the VPN
VPN server server.

IP Protocol ID = 50 (0x32)

No filters are required for L2TP traffic at UDP port 1701. All L2TP traffic at the firewall, including tunnel
maintenance and tunneled data, is encrypted with IPSec ESP.

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

The following table shows the inbound and outbound L2TP/IPSec filters on the firewalls perimeter network
interface.

VPN Server Behind a Firewall: L2TP/IPSec Filters on the Firewalls Perimeter Network Interface

Filter Type Filter Action

 Inbound Source IP address = Perimeter network interface of Allows IKE traffic from the VPN
VPN server server.

UDP source port = 500 (0x1F4)

Inbound Source IP address = Perimeter network interface of Allows IPSec NAT-T traffic from the
VPN server VPN server.

UDP source port = 4500 (0x1194)

Inbound Source IP address = Perimeter network interface of Allows IPSec ESP traffic from the VPN
VPN server server.

IP Protocol ID = 50 (0x32)

Outbound Destination IP address = Perimeter network Allows IKE traffic to the VPN server.
interface of VPN server

UDP destination port = 500 (0x1F4)

Outbound Destination IP address = Perimeter network Allows IPSec NAT-T traffic to the VPN
interface of VPN server server.

UDP destination port = 4500 (0x1194)

Outbound Destination IP address = Perimeter network Allows IPSec ESP traffic to the VPN
interface of VPN server server.

IP Protocol ID = 50 (0x32)

VPN Server in Front of a Firewall

With the VPN server in front of the firewall and connected to the Internet, as shown in the following figure,
administrators need to add packet filters to the Internet interface that allow only VPN traffic to and from the IP
address of the VPN servers interface on the Internet.

For inbound traffic, when the tunneled data is decrypted by the VPN server it is forwarded to the firewall, which
employs its filters to allow the traffic to be forwarded to intranet resources. Because the only traffic that is
crossing the VPN server is traffic generated by authenticated VPN clients, firewall filtering in this scenario can be
used to prevent VPN users from accessing specific intranet resources.

Because the only Internet traffic allowed on the intranet must go through the VPN server, this approach also
prevents the sharing of intranet resources with non-VPN Internet users.

VPN Server in Front of the Firewall

Packet Filters for a VPN Server in Front of a 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 servers
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

The following table shows the VPN servers inbound and outbound filters for PPTP.

VPN Server in Front of a Firewall: PPTP Packet Filters on the Internet Interface

Filter Type Filter Action

Inbound Destination IP address = Allows PPTP tunnel maintenance to the VPN server.
Internet interface of VPN
server

Subnet mask =
255.255.255.255

TCP destination port =

1723

Inbound Destination IP address = Allows tunneled PPTP data to the VPN server.
Internet interface of VPN
server

Subnet mask =
255.255.255.255

IP Protocol ID = 47

Inbound Destination IP address = Required only when the VPN server is acting as a VPN client
Internet interface of VPN (a calling router) in a site-to-site VPN connection. Accepts
server TCP traffic only when a VPN server initiates the TCP
connection.
Subnet mask =
255.255.255.255

TCP (established) source

port = 1723

Outbound Source IP address = Allows PPTP tunnel maintenance traffic from the VPN server.
Internet interface of VPN
server

Subnet mask =
255.255.255.255
 TCP source port = 1723

Outbound Source IP address = Allows tunneled PPTP data from the VPN server.
Internet interface of VPN
server

Subnet mask =
255.255.255.255

IP Protocol ID = 47

Outbound Source IP address = Required only when the VPN server is acting as a VPN client
Internet interface of VPN (a calling router) in a site-to-site VPN connection. Sends TCP
server traffic only when a VPN server initiates the TCP connection.

Subnet mask =
255.255.255.255

TCP (established)
destination port = 1723

L2TP/IPSec connections
The following table shows the VPN servers inbound and outbound filters for L2TP/IPSec.

VPN Server in Front of a Firewall: L2TP/IPSec Packet Filters on the Internet Interface

Filter Type Filter Action

Inbound Destination IP address = Internet Allows IKE traffic to the VPN server.
interface of VPN server

Subnet mask = 255.255.255.255

UDP destination port = 500

Inbound Destination IP address = Internet Allows L2TP traffic from the VPN client to the
interface of VPN server VPN server.

Subnet mask = 255.255.255.255

UDP destination port = 1701

Inbound Destination IP address = Internet Allows IPSec NAT-T traffic from the VPN client
interface of VPN server to the VPN server.

Subnet mask = 255.255.255.255

UDP destination port = 4500

Outbound Allows IKE traffic from the VPN server.

 Source IP address = Internet interface of
VPN server

Subnet mask = 255.255.255.255

UDP source port = 500

Outbound Source IP address = Internet interface of Allows L2TP traffic from the VPN server to the
VPN server VPN client.

Subnet mask = 255.255.255.255

UDP source port = 1701

Outbound Source IP address = Internet interface of Allows IPSec NAT-T traffic from the VPN server
VPN server to the VPN client

Subnet mask = 255.255.255.255

UDP source port = 4500

VPN and NAT

A network address translator (NAT) is a device that is typically used to provide shared access for private networks
to a public network such as the Internet. Because NAT does not work with protocols that use encryption, a VPN
solution that includes a NAT can add a layer of complexity to a VPN deployment.

NAT with PPTP 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

The NAT/Basic Firewall routing protocol component of the Routing and Remote Access service and the Internet
Connection Sharing feature of Network Connections includes a NAT editor for PPTP traffic.

NAT with L2TP Connections

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
IPSec NAT-T addresses the difficulty of using IPSec-based VPNs across a NAT. Windows Server2003 allows an
L2TP/IPSec connection to pass through a NAT. This capability is based on the latest IETF standards.

IPSec NAT-T enables IPSec peers to negotiate and communicate when they are behind a NAT. To use IPSec
NAT-T, both the remote access VPN client and the remote access VPN server must support IPSec NAT-T. IPSec
NAT-T is supported by the Windows Server2003 Microsoft L2TP/IPSec VPN Client and by the L2TP/IPSec NAT-T
Update for Windows XP and the L2TP/IPSec NAT-T Update for Windows 2000. During the IPSec negotiation
process, IPSec NAT-T-capable peers automatically determine whether both the initiating IPSec peer (typically a
client computer) and responding IPSec peer (typically a server) can perform IPSec NAT-T. In addition, IPSec NAT-
T-capable peers automatically determine if there are any NATs in the path between them. If both of these
conditions are true, the peers automatically use IPSec NAT-T to send IPSec-protected traffic.
User Datagram Protocol-Encapsulating Security Payload (UDP-ESP)
IPSec NAT-T provides UDP encapsulation of IPSec packets to enable IKE and ESP-protected traffic to pass
through a NAT. IKE automatically detects that a NAT is present and uses UDP-ESP encapsulation to enable ESP-
protected IPSec traffic to pass through the NAT.

Related Information
The following resources contain additional information that is relevant to this section.

RFC 2637, 1701, 1702, 2661, 2865, 2866, 1213, 2284, 2716, 2138, and 2139 in the IETF RFC Database.

Community Additions

2016 Microsoft