VPN Architecture

8/8/2019 VPN Architecture

1/29

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 encapsulatingprivate network traffic and moving it through an intermediate network. Data is encrypted forconfidentiality, and packets that might be intercepted on the shared or public network areindecipherable without the correct encryption keys. Data is also encapsulated, or wrapped, with anIP header containing routing information.

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

There are a number of ways to use VPN. The most common scenario is when a remote useraccesses a private network across the Internet using a remote access VPN connection. In anotherscenario, 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 extranetscenario to communicate securely with business partners. An extranet functions as an intranet thatcan be securely shared with a designated business partner.

With both the remote access and site-to-site connections, VPNs enable an organization to replacelong 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 asingle computer user who connects to a private network from a remote location. The VPN serverprovides access to the resources of the network to which the VPN server is connected. The packetssent across the VPN connection originate at the VPN client.

The VPN client authenticates itself to the VPN server and, for mutual authentication, the VPN serverauthenticates 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 withother organizations, over the Internet. A routed VPN connection across the Internet logicallyoperates 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 connectiontypically do not originate at the routers. The calling router (the VPN client) authenticates itself tothe 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 whiletaking advantage of the global availability of the Internet.

Remote Access VPN Connections over the Internet


2/29

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 accessserver (NAS). By using the established physical connection to the local ISP, the remote access clientinitiates a VPN connection across the Internet to the organizations VPN server. When the VPNconnection is created, the remote access client can access the resources of the private intranet. Thefollowing 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 forwardspackets to another router across a VPN connection. To the routers, the VPN connection operates asa 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 LocalArea Network (LAN).

Remote Access VPN Connections over an Intranet

In some organization intranets, the data of a department, such as human resources, is so sensitivethat 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 accessibilityproblems 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 humanresources department to be physically connected to the intranet. In this configuration, a VPN servercan be used to separate the network segments. The VPN server does not provide a direct routedconnection between the corporate intranet and the separate network segment. Users on thecorporate intranet with appropriate permissions can establish a remote access VPN connection withthe VPN server and gain access to the protected resources. Additionally, all communication acrossthe VPN connection is encrypted for data confidentiality. For those users who are not authorized toestablish a VPN connection, the separate network segment is hidden from view.


3/29

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, whosedata is highly sensitive, to communicate with each other. For instance, the finance departmentmight 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 isestablished, users on computers on either network can exchange sensitive data across thecorporate 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 packetwithin 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 asTCP/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 thetunnel endpoints must agree to the tunnel and must negotiate configuration variables, such asaddress assignment, encryption, or compression parameters. In most cases, data transferred acrossthe tunnel is sent using a datagram-based protocol. A tunnel management protocol is used as themechanism to create, maintain, and terminate the tunnel.

After the tunnel is established, data can be sent. The tunnel client or server uses a tunnel datatransfer protocol to prepare the data for transfer. For example, when the tunnel client sends apayload to the tunnel server, the tunnel client first appends a tunnel data transfer protocol headerto the payload. The client then sends the resulting encapsulated payload across the network, whichroutes it to the tunnel server. The tunnel server accepts the packets, removes the tunnel data


4/29

transfer protocol header, and forwards the payload to the target network. Information sent betweenthe 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 thiscase, 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 tothe target tunnel server. To accomplish this, tunneling client software and the appropriate tunnelingprotocol must be installed on the client computer. For the protocols discussed in this technicalreference, 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 Internetuser, who must dial an ISP and obtain an Internet connection before a tunnel over the Internet canbe created.

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

It is a common misconception that VPN connections require a dial-up connection. They require onlyIP connectivity between the VPN client and VPN server. Some clients (such as home computers) usedial-up connections to the Internet to establish IP transport. This is a preliminary step inpreparation 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 compulsorytunnel. With a compulsory tunnel, the user's computer is not a tunnel endpoint. Another device, thedial-up access server, between the user's computer and the tunnel server is the tunnel endpoint andacts as the tunnel client.

A number of vendors that sell dial-up access servers have implemented the ability to create a tunnelon behalf of a dial-up client. The computer or network device providing the tunnel for the clientcomputer is variously known as a Front End Processor (FEP) for PPTP or an L2TP AccessConcentrator (LAC) for L2TP. For the purposes of this reference, the term FEP is used to describethis functionality, regardless of the tunneling protocol. To carry out its function, the FEP must havethe appropriate tunneling protocol installed and must be capable of establishing the tunnel when theclient 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 theorganizations private network, thus consolidating calls from ge ographically diverse locations into asingle Internet connection at the organization network.

This configuration is known as compulsory tunneling because the client is compelled to use thetunnel created by the FEP. Once the initial connection is made, all network traffic to and from theclient is automatically sent through the tunnel. With compulsory tunneling, the client computermakes a single PPP connection. When a client dials into the NAS, a tunnel is created and all traffic isautomatically routed through the tunnel. An FEP can be configured to tunnel all dial-up clients to a


5/29

specific tunnel server. The FEP could also tunnel individual clients, based on the user name ordestination.

Unlike the separate tunnels created for each voluntary client, multiple dial-up clients can share atunnel 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 newinstance 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 tunnelis 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 IPdatagrams for transmission over an IP-based network, such as the Internet or over a privateintranet. 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, andterminate the tunnel. PPTP uses a modified version of Generic Routing Encapsulation (GRE) toencapsulate PPP frames as tunneled data. The payloads of the encapsulated PPP frames can beencrypted, compressed, or both.

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

Authentication that occurs during the creation of a PPTP-based VPN connection uses the sameauthentication mechanisms as PPP connections, such as Extensible Authentication Protocol (EAP),Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP), Microsoft Challenge-HandshakeAuthentication Protocol version 2 (MS-CHAP v2), CHAP, Shiva Password Authentication Protocol(SPAP), and Password Authentication Protocol (PAP). PPTP inherits encryption, compression, or bothof 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 provideend-to-end encryption, which is data encryption between the client application and the serverhosting the resource or service that is being accessed by the client application. If end-to-endencryption is required, IPSec can be used to encrypt IP traffic from end-to-end after the PPTP tunnelis established.

Tunnel Maintenance with the PPTP Control Connection

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

PPTP Control Connection Packet


6/29

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

PPTP Call Control and Connection Management Messages

Message Type Purpose

Start-Control-Connection-Request

Sent by the PPTP client to establish the control connection. Each PPTPtunnel requires a control connection to be established before any otherPPTP messages can be issued.

Start-Control-Connection-Reply

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

Outgoing-Call-Request

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

Outgoing-Call-Reply

Sent by the PPTP server in response to the Outgoing-Call-Requestmessage.

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

Echo-Reply The reply to an Echo-Request. The PPTP Echo-and Echo-Reply messagesare 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 onthe 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-

Notify

Sent by the PPTP server in response to a Call-Clear-Request or for other

reasons to indicate that a tunnel is to be terminated. If the PPTP serverterminates the tunnel, a Call-Disconnect-Notify is sent.

Stop-Control-Connection-Request

Sent by the PPTP client or the PPTP server to inform the other that thecontrol connection is being terminated.

Stop-Control-Connection-Reply

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

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

PPTP Data Tunneling

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

Tunneled PPTP Data

PPP and GRE encapsulation


7/29

The initial PPP payload is encrypted and encapsulated with a PPP header to create a PPP frame. ThePPP frame is then encapsulated with a modified GRE header. GRE is described in RFC 1701 and RFC1702 in the IETF RFC Database and was designed to provide a simple, general purpose mechanismfor 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 andsignificant.

The Key field is replaced with a 16-bit Payload Length field and a 16-bit Call ID field. The Call IDfield 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. Toprevent 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 containingthe 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 aheader 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 anEthernet header and trailer. When IP datagrams are sent over a point-to-point WAN link, such as ananalog 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 WindowsServer 2003 networking architecture from a VPN client over a remote access VPN connection usingan analog modem. The following steps outline this process:


8/29

1. An IP datagram is submitted by its appropriate protocol to the virtual interface thatrepresents the VPN connection using Network Driver Interface Specification (NDIS).

2. NDIS submits the packet to NDISWAN, which encrypts and optionally compresses thedata and provides a PPP header consisting of only the PPP Protocol ID field. Thisassumes that address and control field compression were negotiated during the LinkControl Protocol (LCP) phase of the PPP connection process.

3. NDISWAN submits the data to the PPTP protocol driver, which encapsulates the PPPframe with a GRE header. In the GRE header, the Call ID field is set to the appropriatevalue to identify the tunnel.

4. The PPTP protocol driver then submits the resulting packet to the TCP/IP protocoldriver.

5. The TCP/IP protocol driver encapsulates the tunneled PPTP data with an IP header andsubmits the resulting packet to the interface that represents the dial-up connection tothe 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 driverrepresenting the dial-up hardware (for example, the asynchronous port for a modemconnection).

PPTP Packet Development

Note

It is possible to negotiate an encrypted PPP connection for the dial-up connection with theISP. 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), atechnology developed by Cisco Systems, Inc. Rather than having two incompatible tunnelingprotocols competing in the marketplace and causing customer confusion, the Internet EngineeringTask Force (IETF) mandated that the two technologies be combined into a single tunneling protocol


9/29

that represents the best features of PPTP and L2F. L2TP is described in RFC 2661 in the IETF RFCDatabase.

L2TP encapsulates PPP frames to be sent over IP, X.25, frame relay, or ATM networks. When sentover 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. Thepayloads of encapsulated PPP frames can be encrypted or compressed (or both); however, L2TPclients do not negotiate the use of MPPE for L2TP connections. Encryption for L2TP connections isprovided 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 isalready not encrypted. Non-encrypted L2TP connections can be used temporarily to troubleshoot anL2TP 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 clientusing the L2TP tunneling protocol and IPSec) and an L2TP server (a VPN server using the L2TPtunneling protocol and IPSec). The L2TP client might already be attached to an IP network that canreach the L2TP server, or the L2TP client might have to use a dial-up connection to a NAS toestablish IP connectivity as in the case of dial-up Internet users.

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

An Internet-based L2TP server is an L2TP-enabled remote access server with one interface on theInternet 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 theL2TP 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 WindowsServer 2003 L2TP server supports L2TP clients that use a UDP port other than 1701.

L2TP control messages over IP connections are sent as UDP datagrams. In the WindowsServer 2003 implementation, L2TP control messages sent as UDP datagrams are sent as theencrypted 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 L2TPmessages. Within the L2TP control message, the Next-Received field (similar to the TCPAcknowledgment field) and the Next-Sent field (similar to the TCP Sequence Number field) are usedto maintain the sequence of control messages. Out-of-sequence packets are dropped. The Next-


10/29

Sent and Next-Received fields can also be used for sequenced delivery and flow control for tunneleddata.

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

The following table lists the primary L2TP control messages.

L2TP Control Messages

Message Type Purpose

Start-Control-Connection-Request

Sent by the L2TP client to establish the control connection. Each L2TPtunnel requires a control connection to be established before any otherL2TP messages can be issued. It includes an Assigned Tunnel-ID that isused to identify the tunnel.

Start-Control-Connection-Reply

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

Start-Control-Connection-Connected

Sent in reply to a Start-Control-Connection-Reply message to indicate thattunnel establishment was successful.

Outgoing-Call-Request

Sent by the L2TP client to create an L2TP tunnel. Included in theOutgoing-Call-Request message is an Assigned Call ID that is used toidentify a call within a specific tunnel.

Outgoing-Call-Reply

Sent by the L2TP server in response to the Outgoing-Call-Requestmessage.

Start-Control-Connection-Connected

Sent in reply to a received Outgoing-Call-Reply message to indicate thatthe call was successful.

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 onthe PPP interface of the L2TP server.

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

Call-Disconnect-Notify

Sent by either the L2TP server or L2TP client to indicate that a call within atunnel is to be terminated.

Stop-Control-Connection-Notification

Sent by either the L2TP server or L2TP client to indicate that a tunnel is tobe terminated.

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 showsthe resulting structure of tunneled L2TP over IPSec data.

L2TP Packet Encapsulation


11/29

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 anddestination ports set to 1701.

IP encapsulation

The UDP message is encrypted and encapsulated with an IPSec ESP header and trailer and an ESPAuthentication (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 forthe data-link layer technology of the outgoing physical interface. For example, when an IP datagramis sent on an Ethernet interface, the IP datagram is encapsulated with an Ethernet header andtrailer. When an IP datagram is sent over a point-to-point WAN link such as an analog phone line orISDN, 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 driverfor processing.

L2TP with Internet Protocol security (L2TP/IPSec)

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


12/29

IPSec ESP encapsulation protocol

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

L2TP Packet Development

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

1. An IP datagram is submitted by the appropriate protocol to the virtual interface thatrepresents the VPN connection using NDIS.

2. NDIS submits a packet to NDISWAN, which optionally compresses and provides a PPPheader consisting of only the PPP Protocol ID field. This assumes that address andcontrol field compression were negotiated during the LCP phase of the PPP connectionprocess.

3. NDISWAN submits the PPP frame to the L2TP protocol driver, which encapsulates thePPP 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 protocoldriver with information to send the L2TP packet as a UDP message from UDP port1701 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 andUDP header. IPSec then analyzes the IP packet and matches it with a current IPSecpolicy. Based on the settings in the policy, IPSec encapsulates and encrypts the UDPmessage 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 ESPpayload.

7.

Using NDIS, the TCP/IP protocol driver then submits the resulting packet to theinterface 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 tothe appropriate WAN miniport driver representing the dial-up hardware.

L2TP Packet Development


13/29

Note

It is possible to negotiate an encrypted PPP connection for the dial-up connectionwith 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 Windows or Remote Authentication Dial-In UserService (RADIUS) as an authentication provider. If Windows is selected as the authenticationprovider, the user credentials sent by users attempting VPN connections are authenticated usingtypical Windows authentication mechanisms, and the connection attempt is authorized using theVPN clients user account properties and local remote access policies.

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

The RADIUS server receives a user-connection request from the VPN server and authenticates andauthorizes 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 asmaximum session time, static IP address assignment, and so on.

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

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 Windows or RADIUS as an accounting provider. If Windows is selected as the accounting provider, the accounting information accumulates on the VPNserver for later analysis. Logging options can be specified from the properties of the Local File orSQL Server objects in the Remote Access Logging folder in the Routing and Remote Accesssnap-in. If RADIUS is selected, RADIUS accounting messages are sent to the RADIUS server foraccumulation and later analysis.

Most RADIUS servers can be configured to place authentication request records into an audit file. Anumber of third parties have written billing and audit packages that read RADIUS accounting


14/29

records and produce various useful reports. For more information about RADIUS accounting, seeRFC 2866 in the IETF RFC Database.

The VPN server can be managed using industry-standard network management protocols andinfrastructure. The computer acting as the VPN server can participate in a Simple NetworkManagement Protocol (SNMP) environment as an SNMP agent if the Windows Server 2003 SNMPservice 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 WindowsServer 2003 SNMP service. Objects in the Internet MIB II are documented in RFC 1213 in the IETFRFC Database.

Authentication Protocols

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

PAP

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

SPAP

The Shiva Password Authentication Protocol (SPAP) is a reversible encryption mechanism employedby Shiva Corporation. A computer running Windows XP Professional uses SPAP when connecting to aShiva LAN Rover. A Shiva client that connects to a server running Routing and Remote Access alsouses SPAP. Currently, this form of authentication is more secure than plaintext but less secure thanCHAP 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 remoteclient must use the MD5 one-way hashing algorithm to return the user name and a hash of thechallenge, 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 theclients clear -text password and can, therefore, replicate the operation and compare the result tothe password sent in the clients response. CHAP protects against replay attacks by using anarbitrary challenge string for each authentication attempt. CHAP protects against remote-clientimpersonation by unpredictably sending repeated challenges to the remote client throughout theduration of the connection.

MS-CHAP

Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) is an encrypted authenticationmechanism very similar to CHAP. As in CHAP, the NAS sends a challenge, which consists of asession ID and an arbitrary challenge string, to the remote client. The remote client must return theuser name and an encrypted form of the challenge string, the session ID, and the MD4-hashedpassword. This design, which uses the MD4 hash of the password, helps provides an additional levelof security because it allows the server to store hashed passwords instead of clear-text passwordsor passwords that are stored using reversible encryption. MS-CHAP also provides additional errorcodes, including a password-expired code, and additional encrypted client-server messages thatpermit users to change their passwords during the authentication process. In MS-CHAP, both the


15/29

client and the NAS independently generate a common initial encryption key for subsequent dataencryption by MPPE.

MS-CHAP v2

MS-CHAP version 2 (MS-CHAP v2) is an updated encrypted authentication mechanism that providesstronger 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 asession identifier and an arbitrary challenge string. The remote access client sends a response thatcontains the user name, an arbitrary peer challenge string, and an encrypted form of the receivedchallenge string, the peer challenge string, the session identifier, and the user's password. The NASchecks the response from the client and sends back a response containing an indication of thesuccess or failure of the connection attempt and an authenticated response based on the sentchallenge string, the peer challenge string, the encrypted response of the client, and the user'spassword. The remote access client verifies the authentication response and, if correct, uses theconnection. If the authentication response is not correct, the remote access client terminates theconnection.

Using this process, MS-CHAP v2 provides mutual authentication the NAS verifies that the clienthas knowled ge of the users password, and the client verifies that the NAS has knowledge of theusers password. MS -CHAP v2 also determines two MPPE encryption keys, one for data sent and onefor data received.

EAP

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

During phase 2 of PPP link configuration, the NAS collects the authentication data and then validatesthe data against its own user database or a central authentication database server, such as onemaintained 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 authenticationmechanisms for the validation of a PPP connection. EAP was designed to allow the dynamic additionof authentication plug-in modules at both the client and authentication server. This allows vendorsto supply a new authentication scheme at any time. EAP provides the highest flexibility inauthentication uniqueness and variation.

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

EAP-MD5 Challenge

Extensible Authentication Protocol-Message Digest 5 Challenge (EAP-MD5 Challenge) is a requiredEAP type that uses the same challenge handshake protocol as PPP-based CHAP, but the challengesand responses are sent as EAP messages. A typical use for EAP-MD5 Challenge is to authenticatethe 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 incertificate-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 providesmutual authentication, negotiation of the encryption method, and encrypted key determinationbetween the remote access client and the authenticator. EAP-TLS provides the strongestauthentication and key-determination method.


16/29

When the Routing and Remote Access service is configured to use Windows authentication, EAP-TLSis 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 authenticationmethod based on public-key certificates. With EAP-TLS, a client presents a user certificate to theserver, 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 atrusted VPN server. Both systems rely on a chain of trusted certification authorities (CAs) to verifythe validity of the offered certificate.

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

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

RADIUS

The Remote Authentication Dial-In User Service (RADIUS) protocol is used to provide centralizedadministration of authentication, authorization, and accounting (AAA) and an industry-standardsecurity 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 accountinginformation, and access an account database from a central location.

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

VPN Encryption

To help ensure confidentiality of the data as it traverses the shared or public transit network, it isencrypted by the sender and decrypted by the receiver. Because data encryption is performedbetween the VPN client and VPN server, it is not necessary to use data encryption on thecommunication link between a dial-up client and its Internet service provider (ISP). For example, amobile user uses a dial-up networking connection to dial in to a local ISP. Once the Internetconnection is made, the user creates a VPN connection with the corporate VPN server. If the VPNconnection is encrypted, there is no need to use encryption on the dial-up networking connectionbetween the client and the ISP.

Remote access data encryption does not provide end-to-end data encryption. End-to-end encryptionis data encryption between the client application and the server that hosts the resource or servicebeing accessed by the client application. To get end-to-end data encryption, use IPSec to helpcreate 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, whichdoes not require a specific PPP-based authentication protocol.

The encryption and decryption processes depend on both the sender and the receiver havingknowledge of a common encryption key. Intercepted packets sent along the VPN connection in thetransit 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 canbe used to determine the encryption key. Such techniques require more computing power andcomputational time as the encryption key gets larger. Therefore, it is important to use the largestpossible key size.


17/29

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

PPTP uses user-level PPP authentication methods and Microsoft Point-to-Point Encryption (MPPE) fordata 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-CHAPv2 authentication protocols are used.

For the Routing and Remote Access service, MPPE encryption strengths are configured on theEncryption 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 use40-bit MPPE encryption keys to connect with older operating systems that do not support 56-bit or128-bit encryption keys (this includes older Windows operating systems and operating systems fromcompanies other than Microsoft). Otherwise, use 128-bit encryption keys. Encryption strengths forL2TP/IPSec connections use 56-bit DES (the Basic or Strong setting) or 168-bit 3DES (the Strongestsetting).

Encryption keys are determined at the time of the connection. By default, the highest key strengthsupported by the VPN client and VPN server is negotiated during the process of establishing aconnection. 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 thesame 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 orderfrom the one in which they were sent, and a higher proportion of packets can be lost. Therefore, forVPN connections, MPPE changes the encryption key for each packet. The decryption of each packetis 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 Internetlocations 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 theremote 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 theremote 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 theclient is typically engaged in either intranet communication or Internet communication, but notboth.


18/29

To work around this problem, instead of having the client create a new default route when aconnection is made, administrators can configure the clients routing table with specific routes thatdirect packets to the organizations network over the VPN connection. While connected to theintranet, 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 aroute 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 Windows XP or Windows Server 2003 operating systems usesa 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 Server 2003 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 Server 2003, 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 thatupdates 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 routesthat allow it to reach both networks, the possibility exists that a malicious Internet user might usethe connected VPN client computer to reach the private intranet through the authenticated VPNconnection. This is possible if the VPN client computer has IP routing enabled. IP routing is enabledon Windows XP-based computers by setting theHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Tcpip \Parameters\IPEnableRouterregistry entry to 1 (data type is REG_DWORD).

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

Use the Network Access Quarantine Control feature in Windows Server 2003 to checkwhether 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 trafficon the VPN connection that has not been sent from the VPN client and outbound traffic


19/29

that is not destined to the VPN client. The default remote access policy, named

Connections to Microsoft Routing and Remote Access server in Windows Server 2003

has these packet filters configured and enabled by default.

Note

Using the methods above does not prevent unwanted traffic if a malicious Internetuser 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 beviewed as the start location for any message that is to be sent by a client to another subnet. Theparameters used to configure option 249 are Destination, Mask, and Router. One or more staticroutes can be configured with option 249. All DHCP-enabled clients on the network can be providedwith routes to all other subnets using option 249.

This option is configured as a scope option because the Router IP address, like the DHCP Routeroption 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 addresswill be different in each case.

Static Routing

Static routing requires that routing tables be configured and maintained manually. Static routers donot exchange information. Because of this limitation, when compared to dynamic routing, staticrouting 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 asstatic routes. The static routes that correspond to the network IDs available across the interface areentered manually or automatically. The automatic entering of static routes for demand-dialinterfaces is known as making auto-static updates and is supported by the server running Routingand 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 routingtable. 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 connectedstate. Auto-static updates are not automatically performed every time a demand-dial connection ismade.

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


20/29

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

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 biggestdisadvantage of RIP is its inability to scale to large or very large networks. The maximum hop countused by RIP routers is 15. Networks that are 16 hops or more away are considered unreachable. Asnetworks grow larger in size, the periodic announcements by each RIP router can cause excessivetraffic. 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 networktopology. While the network reconfigures itself, routing loops might form that result in lost orundeliverable 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 otherlocal RIP routers of the networks it can reach. RIP version 1 uses IP broadcast packets for itsannouncements. RIP version 2 can use multicast or broadcast packets for its announcements.

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

Routing and Remote Access supports RIP versions 1 and 2. RIP version 2 supports multicastannouncements, 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 overheadeven in very large networks. The biggest disadvantage of OSPF is its complexity; OSPF requiresproper 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 SPFalgorithm computes the shortest (least cost) path between the router and all the subnets of thenetwork. SPF-calculated routes are always loop-free.

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

As the size of the link state database increases, memory requirements and route computation timesincrease. 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 onlykeeps 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


21/29

With the single-adapter model, also known as the NBMA model, the network for the frame relayservice provider (also known as the frame relay cloud) is treated as an IP network and theendpoints on the cloud are assigned IP addresses from a designated IP network ID. To ensure thatOSPF traffic is received by all of the appropriate endpoints on the cloud, the frame relay interfacemust be configured to send unicast OSPF announcements to all of the appropriate endpoints. Forthe server running Routing and Remote Access, this is done by designating the interface as anNBMA network and adding OSPF neighbors.

In addition, in a spoke and hub frame relay topology, the frame relay interface for the hub routermust have a router priority set to 1 or greater and the frame relay interfaces for the spoke routersmust have a router priority set to 0. Otherwise, the hub router, which is the only router that cancommunicate with all of the spoke routers, cannot become the designated router and adjacenciescannot 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 linkwith its own network ID, and the endpoints are assigned IP addresses from a designated IP networkID. Because each virtual circuit is its own point-to-point connection, administrators can configurethe 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 thatconnects an area to the backbone area is called an area border router (ABR). Normally, ABRs havea physical connection to the backbone area. When it is not possible or practical to have an ABRphysically connected to the backbone area, administrators can use a virtual link to connect the ABRto the backbone.

A virtual link is a logical point-to-point connection between an ABR of an area and an ABR that isphysically connected to the backbone area. For example, a virtual link is configured between theABR of Area 2 and the ABR of Area 1. The ABR of Area 1 is physically connected to the backbonearea. Area 1 is known as the transit area, the area across which the virtual link is created in orderto logically connect Area 2 to the backbone.

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

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 theAS. An external route is any route that is not within the OSPF AS. External routes can come frommany 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 systemboundary 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 routermust be enabled as an ASBR.

External route filters


22/29

By default, OSPF routers acting as ASBRs import and advertise all external routes. Administratorsmight want to filter out external routes to keep the ASBR from advertising improper routes. Externalroutes 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 (RIP version 2) or other sources (static routes or SNMP).

Individual route

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

VPN and Firewalls

A firewall uses packet filtering to allow or disallow the flow of specific types of network traffic. IPpacket filtering provides a way for administrators to define precisely what IP traffic is allowed tocross the firewall. IP packet filtering is important when private intranets are connected to publicnetworks, 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 serveris behind the firewall.

The VPN server is connected to the Internet and the firewall is between the VPN server andthe 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 theVPN server is another intranet resource connected to the perimeter network, also known as ascreened subnet or demilitarized zone (DMZ). The perimeter network is an IP network segment thattypically 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 andperimeter network interfaces to allow the passing of tunnel maintenance traffic and tunneled data tothe VPN server. Additional filters can allow the passing of traffic to Web servers, FTP servers, andother types of servers on the perimeter network. As an added layer of security, the VPN servershould also be configured with PPTP or L2TP/IPSec packet filters on its perimeter network interfaceas 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 onthe plaintext headers of the tunneled data, meaning that all tunneled data passes through thefirewall. However, this is not a security concern because the VPN connection requires anauthentication process that prevents unauthorized access beyond the VPN server.

VPN Server Behind the Firewall


23/29

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 Internetinterface and a perimeter network interface. In this scenario, the firewall is connected to theInternet, and the VPN server is an intranet resource that is connected to the perimeter network. TheVPN 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

FilterType Filter Action

Inbound Destination IPaddress =Perimeter networkinterface of VPNserver

TCP destinationport = 1723(0x6BB)

Allows PPTP tunnel maintenance traffic from the PPTP clientto the PPTP server.

Inbound Destination IPaddress =Perimeter networkinterface of VPNserverIP Protocol ID =47 (0x2F)

Allows tunneled PPTP data from the PPTP client to the PPTPserver.

Inbound Destination IPaddress =Perimeter network

interface of VPNserverTCP source port =1723 (0x6BB)

Required only when the VPN server is acting as a VPN client(a calling router) in a site-to-site VPN connection. If all trafficfrom TCP port 1723 is allowed to reach the VPN server,

network attacks can emanate from sources on the Internetthat use this port. Administrators should only use this filterin conjunction with the PPTP filters that are also configuredon the VPN server.

Outbound Source IP address = Perimeternetwork interface of VPN serverTCP source port =1723 (0x6BB)

Allows PPTP tunnel maintenance traffic from the PPTP serverto the PPTP client.


24/29

Outbound Source IP address = Perimeternetwork interface of VPN serverIP Protocol ID =47 (0x2F)

Allows tunneled PPTP data from the PPTP server to the PPTPclient.

Outbound Source IP address= Perimeternetwork interface of VPN serverTCP destinationport = 1723(0x6BB)

Required only when the VPN server is acting as a VPN client(a calling router) in a site-to-site VPN connection. If all trafficfrom the VPN server is allowed to reach TCP port 1723,network attacks can emanate from sources on the Internetusing this port. Administrators should only use this f ilter inconjunction with the PPTP filters that are also configured onthe VPN server.

PPTP connections for the perimeter network interface of the firewall

The following table shows the inbound and outbound PPTP filters on the firewalls perimeter networkinterface.

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


Inbound Source IP address =Perimeter networkinterface of VPN serverTCP source port =1723 (0x6BB)

Allows PPTP tunnel maintenance traffic from the VPNserver to the VPN client.

Inbound Source IP address =Perimeter networkinterface of VPN serverIP Protocol ID = 47(0x2F)

Allows tunneled PPTP data from the VPN server to theVPN client.

Inbound Source IP address =Perimeter networkinterface of VPN serverTCP destination port = 1723 (0x6BB)

Required only when the VPN server is acting as a VPNclient (a calling router) in a site-to-site VPN connection. If all traffic from TCP port 1723 is allowed to reach the VPNserver, network attacks can emanate from sources on theInternet using this port.

Outbound Destination IPaddress = Perimeternetwork interface of VPN serverTCP source port =1723 (0x6BB)

Allows PPTP tunnel maintenance traffic from the PPTPclient to the PPTP server.

Outbound Destination IP

address = Perimeternetwork interface of VPN serverIP Protocol ID = 47(0x2F)

Allows tunneled PPTP data from the PPTP client to the

PPTP server.

Outbound Destination IPaddress = Perimeternetwork interface of VPN server

Required only when the VPN server is acting as a VPNclient (a calling router) in a site-to-site VPN connection. If all traffic from the VPN server is allowed to reach TCPport 1723, network attacks can emanate from sources on


25/29

TCP source port =1723 (0x6BB)

the Internet using this port.

L2TP/IPSec connections for the Internet interface of the firewall

The following table shows the inbound and outbound L2TP/IPSec filters on the firewalls Internetinterface.

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


Inbound Destination IP address = Perimeter networkinterface of VPN serverUDP destination port = 500 (0x1F4)

Allows IKE traffic to the VPNserver.

Inbound Destination IP address = Perimeter networkinterface of VPN serverUDP destination port = 4500 (0x1194)

Allows IPSec NAT-T traffic to theVPN server.

Inbound Destination IP address = Perimeter networkinterface of VPN serverIP Protocol ID = 50 (0x32)

Allows IPSec ESP traffic to theVPN server.

Outbound Source IP address = Perimeter networkinterface of VPN serverUDP source port = 500 (0x1F4)

Allows IKE traffic from the VPNserver.

Outbound Source IP address = Perimeter networkinterface of VPN serverUDP source port = 4500 (0x1194)

Allows IPSec NAT-T traffic fromthe VPN server.

Outbound Source IP address = Perimeter networkinterface of VPN serverIP Protocol ID = 50 (0x32)

Allows IPSec ESP traffic fromthe VPN server.

No filters are required for L2TP traffic at UDP port 1701. All L2TP traffic at the firewall, includingtunnel 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 perimeternetwork interface.

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


Inbound Source IP address = Perimeter networkinterface of VPN serverUDP source port = 500 (0x1F4)

Allows IKE traffic from the VPNserver.

Inbound Source IP address = Perimeter networkinterface of VPN serverUDP source port = 4500 (0x1194)

Allows IPSec NAT-T traffic fromthe VPN server.


26/29

Inbound Source IP address = Perimeter networkinterface of VPN serverIP Protocol ID = 50 (0x32)

Allows IPSec ESP traffic fromthe VPN server.

Outbound Destination IP address = Perimeter networkinterface of VPN serverUDP destination port = 500 (0x1F4)

Allows IKE traffic to the VPNserver.

Outbound Destination IP address = Perimeter networkinterface of VPN serverUDP destination port = 4500 (0x1194)

Allows IPSec NAT-T traffic to theVPN server.

Outbound Destination IP address = Perimeter networkinterface of VPN serverIP Protocol ID = 50 (0x32)

Allows IPSec ESP traffic to theVPN 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 followingfigure, administrators need to add packet filters to the Internet interface that allow only VPN trafficto 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 thefirewall, which employs its filters to allow the traffic to be forwarded to intranet resources. Becausethe 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 intranetresources.

Because the only Internet traffic allowed on the intranet must go through the VPN server, thisapproach 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 outboundpacket filters on the VPN server need to be configured to allow only VPN traffic to and from the IPaddress of the VPN servers Internet interface. Use this configuration if the VPN server is in aperimeter network, with one firewall positioned between the VPN server and the intranet andanother between the VPN server and the Internet.

All of the following packet filters are configured, using the Routing and Remote Access snap-in, asIP packet filters on the Internet interface. Depending on the configuration decisions made whenrunning the Routing and Remote Access Server Setup Wizard, these packet filters might already beconfigured.

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


27/29


Inbound Destination IP address = Internet interface of VPNserverSubnet mask =255.255.255.255TCP destination port =1723

Allows PPTP tunnel maintenance to the VPN server.

Inbound Destination IP address = Internet interface of VPNserverSubnet mask =255.255.255.255IP Protocol ID = 47

Allows tunneled PPTP data to the VPN server.

Inbound Destination IP address= Internet interface of VPNserverSubnet mask =

255.255.255.255TCP (established)source port = 1723

Required only when the VPN server is acting as a VPNclient (a calling router) in a site-to-site VPNconnection. Accepts TCP traffic only when a VPNserver initiates the TCP connection.

Outbound Source IP address =Internet interface of VPNserverSubnet mask =255.255.255.255TCP source port = 1723

Allows PPTP tunnel maintenance traffic from the VPNserver.

Outbound Source IP address =Internet interface of VPNserverSubnet mask =

255.255.255.255IP Protocol ID = 47

Allows tunneled PPTP data from the VPN server.

Outbound Source IP address =Internet interface of VPNserverSubnet mask =255.255.255.255TCP (established)destination port = 1723

Required only when the VPN server is acting as a VPNclient (a calling router) in a site-to-site VPNconnection. Sends TCP traffic only when a VPN serverinitiates the TCP connection.

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 = Internetinterface of VPN serverSubnet mask = 255.255.255.255UDP destination port = 500

Allows IKE traffic to the VPN server.


28/29

Inbound Destination IP address = Internetinterface of VPN serverSubnet mask = 255.255.255.255UDP destination port = 1701

Allows L2TP traffic from the VPN clientto the VPN server.

Inbound Destination IP address = Internetinterface of VPN server

Subnet mask = 255.255.255.255UDP destination port = 4500

Allows IPSec NAT-T traffic from the VPNclient to the VPN server.

Outbound Source IP address = Internet interfaceof VPN serverSubnet mask = 255.255.255.255UDP source port = 500

Allows IKE traffic from the VPN server.

Outbound Source IP address = Internet interfaceof VPN serverSubnet mask = 255.255.255.255UDP source port = 1701

Allows L2TP traffic from the VPN serverto the VPN client.

Outbound Source IP address = Internet interfaceof VPN server

Subnet mask = 255.255.255.255UDP source port = 4500

Allows IPSec NAT-T traffic from the VPNserver to the VPN client

VPN and NAT

A network address translator (NAT) is a device that is typically used to provide shared access forprivate networks to a public network such as the Internet. Because NAT does not work withprotocols that use encryption, a VPN solution that includes a NAT can add a layer of complexity to aVPN 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 thatcan translate PPTP traffic. The NAT editor is required because tunneled PPTP data has a GRE headerrather than a TCP header or a UDP header. The NAT editor uses the Call ID field in the GRE headerto identify the PPTP data stream and translate IP addresses and call IDs for PPTP data packets thatare 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 andthe Internet Connection Sharing feature of Network Connections includes a NAT editor for PPTPtraffic.

NAT with L2TP Connections

To use L2TP-based VPN connections behind a NAT, IPSec NAT Traversal (NAT-T) must beimplemented 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 Server 2003allows an L2TP/IPSec connection to pass through a NAT. This capability is based on the latest IETFstandards.

IPSec NAT-T enables IPSec peers to negotiate and communicate when they are behind a NAT. Touse IPSec NAT-T, both the remote access VPN client and the remote access VPN server mustsupport IPSec NAT-T. IPSec NAT-T is supported by the Windows Server 2003 Microsoft L2TP/IPSec


29/29

VPN Client and by the L2TP/IPSec NAT-T Update for Windows XP and the L2TP/IPSec NAT-T Updatefor Windows 2000. During the IPSec negotiation process, IPSec NAT-T-capable peers automaticallydetermine whether both the initiating IPSec peer (typically a client computer) and responding IPSecpeer (typically a server) can perform IPSec NAT-T. In addition, IPSec NAT-T-capable peersautomatically determine if there are any NATs in the path between them. If both of these conditionsare 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 topass through a NAT. IKE automatically detects that a NAT is present and uses UDP-ESPencapsulation 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 IETFRFC Database.

Tags: 2003 how vpn

Community Content

VPN Architecture

Documents

Transcript of VPN Architecture