How VPN Works

5/29/2017 HowVPNWorks:VirtualPrivateNetwork(VPN)
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 pointtopoint 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 pointtopoint 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 ondemand sitetosite VPN connection also known as a routertorouter VPN connection.
https://technet.microsoft.com/enus/library/cc779919(d=printer,v=ws.10).aspx 1/29
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 sitetosite connections, VPNs enable an organization to replace long distance dialup or
leased lines with local dialup 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.
Sitetosite VPN
A sitetosite 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 sitetosite 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.
Internetbased VPN Connections

Using an Internetbased VPN connection, an organization can avoid longdistance 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 dialup 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
SitetoSite 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 datalink layer link.
VPN Connecting Two Remote Sites Across the Internet
Intranetbased VPN Connections

The intranetbased 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
SitetoSite VPN Connections over an Intranet

Two networks can be connected over an intranet using a sitetosite 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 PointtoPoint 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 datagrambased 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 dialup.
In a dialup situation, the client must establish a dialup 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 dialup Internet user, who must dial an ISP and obtain an Internet
connection before a tunnel over the Internet can be created.
For a LANattached 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 alwayson broadband Internet
connection.
It is a common misconception that VPN connections require a dialup connection. They require only IP connectivity between the
VPN client and VPN server. Some clients such as home computers use dialup 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
Compulsory Tunneling
In compulsory tunneling, a VPNcapable 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 dialup 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 dialup access servers have implemented the ability to create a tunnel on behalf of a dialup 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 dialup call to a tunnelingenabled 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 dialup 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 dialup 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
PointtoPoint Tunneling Protocol PPTP encapsulates PointtoPoint Protocol PPP frames into IP datagrams for transmission
over an IPbased 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 dialup connection to a NAS to establish IP connectivity as in
the case of dialup Internet users.
Authentication that occurs during the creation of a PPTPbased VPN connection uses the same authentication mechanisms as
PPP connections, such as Extensible Authentication Protocol EAP, Microsoft ChallengeHandshake Authentication Protocol MS
CHAP, Microsoft ChallengeHandshake Authentication Protocol version 2 MSCHAP 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, EAPTransport Layer Security EAPTLS, MSCHAP, or MSCHAP v2 must be used for the PPP
payloads to be encrypted using Microsoft PointtoPoint Encryption MPPE.
MPPE provides only link encryption between the VPN client and the VPN server. It does not provide endtoend 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 endtoend encryption is required, IPSec can be used to encrypt IP traffic from endtoend 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 EchoRequest
and PPTP EchoReply 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 datalink 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
StartControl Sent by the PPTP client to establish the control connection. Each PPTP tunnel requires a control
Connection connection to be established before any other PPTP messages can be issued.
Request
StartControl Sent by the PPTP server to reply to the StartControlConnectionRequest message.

Connection
Reply
OutgoingCall Sent by the PPTP client to create a PPTP tunnel. Included in the OutgoingCallRequest message is a Call
Request ID that is used in the GRE header to identify the tunneled traffic of a specific tunnel.
OutgoingCall Sent by the PPTP server in response to the OutgoingCallRequest message.

Reply
EchoRequest Sent by either the PPTP client or PPTP server as a keepalive mechanism. If the EchoRequest is not
answered, the PPTP tunnel is eventually terminated.
EchoReply The reply to an EchoRequest. The PPTP Echoand EchoReply messages are not related to the ICMP Echo
Request and Echo Reply messages.
WANError Sent by the PPTP server to all VPN clients to indicate error conditions on the PPP interface of the PPTP
Notify server.
SetLinkInfo Sent by the PPTP client or PPTP server to set PPPnegotiated options.
CallClear Sent by the PPTP client, indicating that a tunnel is to be terminated.

Request
CallDisconnect Sent by the PPTP server in response to a CallClearRequest or for other reasons to indicate that a tunnel
Notify is to be terminated. If the PPTP server terminates the tunnel, a CallDisconnectNotify is sent.
StopControl Sent by the PPTP client or the PPTP server to inform the other that the control connection is being
Connection terminated.
Request
StopControl The reply to the StopControlConnectionRequest 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 32bit acknowledgement field is present and significant.
The Key field is replaced with a 16bit Payload Length field and a 16bit Call ID field. The Call ID field is set by the PPTP client
during the creation of the PPTP tunnel.
A 32bit 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 datalink 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
datalink 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 pointtopoint 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 datalink 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 dialup 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 dialup 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 dialup 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 Windowsbased 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. Nonencrypted 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 dialup connection to
a NAS to establish IP connectivity as in the case of dialup Internet users.
Authentication that occurs during the creation of L2TP tunnels must use the same authentication mechanisms as PPP
connections.
An Internetbased L2TP server is an L2TPenabled 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 NextReceived field similar to the TCP Acknowledgment field and the NextSent field similar to the TCP
Sequence Number field are used to maintain the sequence of control messages. Outofsequence packets are dropped. The
NextSent and NextReceived 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
StartControl Sent by the L2TP client to establish the control connection. Each L2TP tunnel requires a control connection
Connection to be established before any other L2TP messages can be issued. It includes an Assigned TunnelID that is
Request used to identify the tunnel.
StartControl Sent by the L2TP server to reply to the StartControlConnectionRequest message.

Connection
Reply
StartControl Sent in reply to a StartControlConnectionReply message to indicate that tunnel establishment was
Connection successful.
Connected
OutgoingCall Sent by the L2TP client to create an L2TP tunnel. Included in the OutgoingCallRequest message is an
Request Assigned Call ID that is used to identify a call within a specific tunnel.
OutgoingCall Sent by the L2TP server in response to the OutgoingCallRequest message.

Reply
StartControl Sent in reply to a received OutgoingCallReply message to indicate that the call was successful.
Connection
Connected
Hello Sent by either the L2TP client or L2TP server as a keepalive mechanism. If the Hello is not acknowledged,
the L2TP tunnel is eventually terminated.
WANError Sent by the L2TP server to all VPN clients to indicate error conditions on the PPP interface of the L2TP
Notify server.
SetLinkInfo Sent by the L2TP client or L2TP server to set PPPnegotiated options.
Call Sent by either the L2TP server or L2TP client to indicate that a call within a tunnel is to be terminated.
Disconnect
Notify
StopControl Sent by either the L2TP server or L2TP client to indicate that a tunnel is to be terminated.
Connection
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 datalink layer

To send on a LAN or WAN link, the IP datagram is finally encapsulated with a header and trailer for the datalink 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 pointtopoint 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 datalink 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

L2TP with Internet Protocol security L2TP/IPSec

Tunneling protocols such as PPTP and L2TP are implemented at the datalink 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 dialup
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 dialup hardware.
L2TP Packet Development
Note
It is possible to negotiate an encrypted PPP connection for the dialup 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 DialIn 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 userconnection 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 snapin. 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 industrystandard 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 cleartext 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 MSCHAP.
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 oneway 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 cleartext 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 cleartext 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 remoteclient impersonation by unpredictably
sending repeated challenges to the remote client throughout the duration of the connection.
MSCHAP
Microsoft Challenge Handshake Authentication Protocol MSCHAP 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 cleartext passwords or passwords that are stored using reversible
encryption. MSCHAP also provides additional error codes, including a passwordexpired code, and additional encrypted client
server messages that permit users to change their passwords during the authentication process. In MSCHAP, both the client and
the NAS independently generate a common initial encryption key for subsequent data encryption by MPPE.
MSCHAP v2
MSCHAP version 2 MSCHAP 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 MSCHAP 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, MSCHAP 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. MSCHAP v2 also determines two MPPE
encryption keys, one for data sent and one for data received.
EAP
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 plugin 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.
EAPMD5 Challenge
Extensible Authentication ProtocolMessage Digest 5 Challenge EAPMD5 Challenge is a required EAP type that uses the same
challenge handshake protocol as PPPbased CHAP, but the challenges and responses are sent as EAP messages. A typical use for
EAPMD5 Challenge is to authenticate the credentials of remote access clients by using user name and password security
systems. EAPMD5 Challenge can be used to test EAP interoperability.
EAPTLS
Extensible Authentication ProtocolTransport Layer Security EAPTLS is an EAP type that is used in certificatebased security
environments. If smart cards are used for remote access authentication, EAPTLS 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. EAPTLS provides the strongest authentication and key
determination method.
When the Routing and Remote Access service is configured to use Windows authentication, EAPTLS is supported only when the
VPN server is a member of a domain. A VPN server running as a standalone server or a member of a workgroup does not
support EAPTLS.
EAPTLS is an IETF standard RFC 2716 in the IETF RFC Database for a strong authentication method based on publickey
certificates. With EAPTLS, 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 somethingyouknowplussomethingyouhave criteria recommended by most
security experts.
EAPTLS is supported in Windows Server2003 and Windows XP. Like MSCHAP and MSCHAP v2, EAPTLS returns an encryption
key to enable subsequent data encryption by MPPE.
RADIUS
The Remote Authentication DialIn User Service RADIUS protocol is used to provide centralized administration of
authentication, authorization, and accounting AAA and an industrystandard 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 dialup
remote access and VPNbased 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 dialup client and its Internet service provider ISP. For example, a
mobile user uses a dialup 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
dialup networking connection between the client and the ISP.
Remote access data encryption does not provide endtoend data encryption. Endtoend 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 endto
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 MSCHAP, MSCHAP v2, or EAPTLS is used as the authentication
protocol. Data encryption for L2TP connections relies on IPSec, which does not require a specific PPPbased 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 userlevel PPP authentication methods and Microsoft PointtoPoint Encryption MPPE for data encryption.
Data Encryption with MPPE

PPTP inherits MPPE encryption, which uses the RivestShamirAdleman RSA RC4 stream cipher. MPPE is available only for PPTP
based VPN connections when the EAPTLS, MSCHAP, or MSCHAP 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 40bit the Basic setting, 56bit the Strong setting, or 128bit the Strongest setting
encryption keys. Administrators should use 40bit MPPE encryption keys to connect with older operating systems that do not
support 56bit or 128bit encryption keys this includes older Windows operating systems and operating systems from
companies other than Microsoft. Otherwise, use 128bit encryption keys. Encryption strengths for L2TP/IPSec connections use
56bit DES the Basic or Strong setting or 168bit 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 pointtopoint 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 XPbased 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 antivirus 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 DHCPenabled 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.
AutoStatic 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 demanddial interfaces is known as making autostatic updates and is supported by the server running
Routing and Remote Access. Autostatic updates are supported by Routing Information Protocol RIP for IP, but not by OSPF.
Autostatic 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 demanddial interface is in a connected state. Autostatic updates are not automatically performed every time a demanddial
connection is made.
When instructed, a demanddial interface that is configured for autostatic 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 autostatic
update is a onetime, oneway exchange of routing information.
Administrators can automate and schedule autostatic updates by executing the update as a scheduled task. When an auto
static update is requested, the existing autostatic 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. SPFcalculated routes are always loopfree.
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.
SingleAdapter model
With the singleadapter 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.
MultipleAdapter model
With the multipleadapter model, each frame relay virtual circuit appears as a pointtopoint 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 pointtopoint
connection, administrators can configure the interface for the pointtopoint network type.
Virtual links
An OSPFrouted 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 pointtopoint 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 directlyconnected 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 Allows PPTP tunnel maintenance traffic from the PPTP client to the PPTP server.
IP address =
Perimeter
network
interface of
VPN server
TCP
destination
port = 1723
0x6BB
Inbound Destination Allows tunneled PPTP data from the PPTP client to the PPTP server.
IP address =
Perimeter
network
interface of
VPN server
IP Protocol ID
= 47 0x2F
Inbound Destination Required only when the VPN server is acting as a VPN client a calling router in a siteto
IP address = site VPN connection. If all traffic from TCP port 1723 is allowed to reach the VPN server,
Perimeter network attacks can emanate from sources on the Internet that use this port.
network Administrators should only use this filter in conjunction with the PPTP filters that are also
interface of configured on the VPN server.
VPN server
TCP source
port = 1723
0x6BB
Outbound Source IP Allows PPTP tunnel maintenance traffic from the PPTP server to the PPTP client.
address =
Perimeter
network
interface of
VPN server
TCP source
port = 1723
0x6BB
Outbound Source IP Allows tunneled PPTP data from the PPTP server to the PPTP client.
address =
Perimeter
network
interface of
VPN server
IP Protocol ID
= 47 0x2F
Outbound Source IP Required only when the VPN server is acting as a VPN client a calling router in a siteto
address = site VPN connection. If all traffic from the VPN server is allowed to reach TCP port 1723,
Perimeter network attacks can emanate from sources on the Internet using this port. Administrators
network should only use this filter in conjunction with the PPTP filters that are also configured on
interface of the VPN server.
VPN server
TCP
destination
port = 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
Inbound Source IP address = Allows PPTP tunnel maintenance traffic from the VPN server to the VPN client.
Perimeter network
interface of VPN
server
TCP source port =

1723 0x6BB
Inbound Source IP address = Allows tunneled PPTP data from the VPN server to the VPN client.
Perimeter network
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 calling router in a
Perimeter network sitetosite VPN connection. If all traffic from TCP port 1723 is allowed to reach the
interface of VPN VPN server, network attacks can emanate from sources on the Internet using this
server port.
TCP destination
port = 1723 0x6BB
Outbound Destination IP Allows PPTP tunnel maintenance traffic from the PPTP client to the PPTP server.
address = Perimeter
network interface of
VPN server
TCP source port =

1723 0x6BB
Outbound 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
Outbound Destination IP Required only when the VPN server is acting as a VPN client a calling router in a
address = Perimeter sitetosite VPN connection. If all traffic from the VPN server is allowed to reach TCP
network interface of port 1723, network attacks can emanate from sources on the Internet using this
VPN server port.
TCP source port =

1723 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
Inbound Destination IP address = Perimeter network interface of VPN Allows IKE traffic to the VPN server.
server
UDP destination port = 500 0x1F4
Inbound Destination IP address = Perimeter network interface of VPN Allows IPSec NATT traffic to the VPN
server server.
UDP destination port = 4500 0x1194
Inbound Destination IP address = Perimeter network interface of VPN Allows IPSec ESP traffic to the VPN server.
server
IP Protocol ID = 50 0x32
Outbound Source IP address = Perimeter network interface of VPN Allows IKE traffic from the VPN server.
server
UDP source port = 500 0x1F4
Outbound Source IP address = Perimeter network interface of VPN Allows IPSec NATT traffic from the VPN
server server.
UDP source port = 4500 0x1194
Outbound Source IP address = Perimeter network interface of VPN Allows IPSec ESP traffic from the VPN
server server.
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
Inbound Source IP address = Perimeter network interface of VPN Allows IKE traffic from the VPN server.
server
UDP source port = 500 0x1F4
Inbound Source IP address = Perimeter network interface of VPN Allows IPSec NATT traffic from the VPN
server server.
UDP source port = 4500 0x1194
Inbound Source IP address = Perimeter network interface of VPN Allows IPSec ESP traffic from the VPN
server server.
Outbound Destination IP address = Perimeter network interface of VPN Allows IKE traffic to the VPN server.
server
UDP destination port = 500 0x1F4
Outbound Destination IP address = Perimeter network interface of VPN Allows IPSec NATT traffic to the VPN
server server.
UDP destination port = 4500 0x1194
Outbound Destination IP address = Perimeter network interface of VPN Allows IPSec ESP traffic to the VPN server.
server
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 nonVPN 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 snapin, 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
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 a calling router in a
= Internet interface of sitetosite VPN connection. Accepts TCP traffic only when a VPN server initiates
VPN server 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 a calling router in a
Internet interface of sitetosite VPN connection. Sends TCP traffic only when a VPN server initiates
VPN server 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
Inbound Destination IP address = Internet interface of Allows IKE traffic to the VPN server.
VPN server
Subnet mask = 255.255.255.255
UDP destination port = 500
Inbound Destination IP address = Internet interface of Allows L2TP traffic from the VPN client to the VPN
VPN server server.
Subnet mask = 255.255.255.255
Inbound Destination IP address = Internet interface of Allows IPSec NATT traffic from the VPN client to the
VPN server VPN server.
Subnet mask = 255.255.255.255
Outbound Source IP address = Internet interface of VPN Allows IKE traffic from the VPN server.
server
Subnet mask = 255.255.255.255
UDP source port = 500
Outbound Source IP address = Internet interface of VPN Allows L2TP traffic from the VPN server to the VPN
server client.
Subnet mask = 255.255.255.255
Outbound Source IP address = Internet interface of VPN Allows IPSec NATT traffic from the VPN server to the
server VPN client
Subnet mask = 255.255.255.255
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 L2TPbased VPN connections behind a NAT, IPSec NAT Traversal NATT must be implemented at both ends of the VPN
connection.
IPSec NATT
IPSec NATT addresses the difficulty of using IPSecbased 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 NATT enables IPSec peers to negotiate and communicate when they are behind a NAT. To use IPSec NATT, both the
remote access VPN client and the remote access VPN server must support IPSec NATT. IPSec NATT is supported by the
Windows Server2003 Microsoft L2TP/IPSec VPN Client and by the L2TP/IPSec NATT Update for Windows XP and the L2TP/IPSec
NATT Update for Windows 2000. During the IPSec negotiation process, IPSec NATTcapable peers automatically determine
whether both the initiating IPSec peer typically a client computer and responding IPSec peer typically a server can perform
IPSec NATT. In addition, IPSec NATTcapable 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 NATT to send IPSecprotected traffic.
User Datagram ProtocolEncapsulating Security Payload UDPESP

IPSec NATT provides UDP encapsulation of IPSec packets to enable IKE and ESPprotected traffic to pass through a NAT. IKE
automatically detects that a NAT is present and uses UDPESP encapsulation to enable ESPprotected 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
etc
192.168.1.2
SAD
3/1/2016
2017 Microsoft

How VPN Works - Virtual Private Network (VPN)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

How VPN Works - Virtual Private Network (VPN)

Uploaded by

Copyright:

Available Formats

5/29/2017 HowVPNWorks:VirtualPrivateNetwork(VPN)

How VPN Works

VPN Addressing and Routing

VPN and Firewalls

VPN and NAT

Remote access VPN

Internetbased VPN Connections

Remote Access VPN Connections over the Internet

VPN Connecting a Remote Client to a Private Intranet

SitetoSite VPN Connections Over the Internet

VPN Connecting Two Remote Sites Across the Internet

Intranetbased VPN Connections

Remote Access VPN Connections over an Intranet

The following figure shows remote access over an intranet.

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

SitetoSite VPN Connections over an Intranet

The following figure shows two networks connected over an intranet.

VPN Connecting Two Networks over an Intranet

There are two types of tunneling:

Tunnel Maintenance with the PPTP Control Connection

PPTP Control Connection Packet

PPTP Call Control and Connection Management Messages

Message Type Purpose

StartControl Sent by the PPTP server to reply to the StartControlConnectionRequest message.

OutgoingCall Sent by the PPTP server in response to the OutgoingCallRequest message.

CallClear Sent by the PPTP client, indicating that a tunnel is to be terminated.

StopControl The reply to the StopControlConnectionRequest message.

PPTP Data Tunneling

Tunneled PPTP Data

PPP and GRE encapsulation

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

A 32bit Acknowledgement field is added.

Encapsulation of the datalink layer

Processing of the tunneled PPTP data

Processes and removes the datalink 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

PPTP Packet Development

Tunnel Maintenance with L2TP Control Messages

L2TP Control Message

The following table lists the primary L2TP control messages.

L2TP Control Messages

Message Type Purpose

StartControl Sent by the L2TP server to reply to the StartControlConnectionRequest message.

OutgoingCall Sent by the L2TP server in response to the OutgoingCallRequest message.

L2TP Data Tunneling

L2TP Packet Encapsulation

Encapsulation of the datalink layer

Processing of the tunneled L2TP/IPSec data

Processes and removes the datalink header and trailer.

Processes and removes the IP header.

L2TP with Internet Protocol security L2TP/IPSec

L2TP with Internet Protocol security L2TP/IPSec

IPSec ESP encapsulation protocol

L2TP Packet Development

8. NDIS submits the packet to NDISWAN.

L2TP Packet Development

Data Encryption with MPPE

VPN Addressing and Routing