|
Microsoft® Windows® 2000 includes extensive
support for virtual private networking
technology, which leverages the IP connectivity
of the Internet to connect remote clients and
remote offices. As a network professional, you
should understand the important uses of virtual
private networking for your organization and the
underlying technologies that make it work:
Point-to-Point Tunneling Protocol (PPTP), Layer
Two Tunneling Protocol (L2TP), virtual private
networks and security, virtual private networks
and routing and translation, virtual private
networks and firewalls, and the troubleshooting
of virtual private network connections. You
should already be familiar with TCP/IP, IP
routing, IP Security (IPSec), and the Windows
2000 remote access server.
| In
This Chapter |
 |
 |
Virtual Private Networking Overview
Point-to-Point Tunneling Protocol
Layer Two Tunneling Protocol and Internet
Protocol Security
VPN Security
Addressing and Routing for VPNs
VPNs and Firewalls
VPNs and Network Address Translators
Pass-Through VPN Scenario
Troubleshooting VPNs
Related Information in the
Resource Kit
- For more
information about TCP/IP, see
"Introduction to TCP/IP" in the Microsoft®
Windows® 2000 Server Resource Kit
TCP/IP Core Networking Guide.
- For more
information about IPSec, see "Internet
Protocol Security" in the TCP/IP
Core Networking Guide.
- For more
information about unicast IP routing, see
"Unicast IP Routing" in this book.
- For more
information about demand-dial routing, see
"Demand-Dial Routing" in this
book.
- For more
information about the Windows 2000 remote
access server, see "Remote Access
Server" in this book.
| Virtual
Private Networking Overview |
|
|
A virtual private network (VPN) is the
extension of a private network that encompasses
links across shared or public networks like the
Internet. A VPN enables you to send data between
two computers across a shared or public
internetwork in a manner that emulates the
properties of a point-to-point private link. The
act of configuring and creating a virtual
private network is known as virtual private
networking.
To emulate a point-to-point link, data is
encapsulated, or wrapped, with a header that
provides routing information allowing it to
traverse the shared or public internetwork to
reach its endpoint. To emulate a private link,
the data being sent is encrypted for
confidentiality. Packets that are intercepted on
the shared or public network are indecipherable
without the encryption keys. The link in which
the private data is encapsulated and encrypted
is known as a virtual private network (VPN)
connection.
Figure 9.1 illustrates the logical concept of
a VPN.
Figure 9.1 Virtual Private Network (VPN)
VPN connections allow users working at home
or on the road to obtain a remote access
connection to an organization server using the
infrastructure provided by a public internetwork
such as the Internet. From the user's
perspective, the VPN is a point-to-point
connection between the computer, the VPN client,
and an organization server, the VPN server. The
exact infrastructure of the shared or public
network is irrelevant because it appears
logically as if the data is sent over a
dedicated private link.
VPN connections also allow organizations to
have routed connections with geographically
separate offices or with other organizations
over a public internetwork such as the Internet
while maintaining secure communications. A
routed VPN connection across the Internet
logically operates as a dedicated WAN link.
With both the remote access connection and
with the routed connection, VPN connections
allow an organization to trade in long distance
dial-up or leased lines for local dial-up or
leased lines to an Internet service provider
(ISP).
| Elements
of a VPN Connection |
|
|
A Microsoft® Windows® 2000 VPN connection
includes the following components as illustrated
in Figure 9.2:
VPN server. A computer that accepts
VPN connections from VPN clients. A VPN server
can provide a remote access VPN connection or a
router-to-router VPN connection. For more
information, see "VPN Connections"
later in this chapter.
VPN client. A computer that initiates
a VPN connection to a VPN server. A VPN client
can be an individual computer that obtains a
remote access VPN connection or a router that
obtains a router-to-router VPN connection.
Microsoft® Windows NT® version 4.0, Windows
2000, Microsoft® Windows® 95, and Microsoft®
Windows® 98-based computers can create remote
access VPN connections to a Windows 2000-based
VPN server. Microsoft® Windows® 2000 Server
and Microsoft® Windows NT® Server 4.0-based
computers running the Routing and Remote Access
service (RRAS) can create router-to-router VPN
connections to a Windows 2000-based VPN server.
VPN clients can also be any non-Microsoft
Point-to-Point Tunneling Protocol (PPTP) client
or Layer Two Tunneling Protocol (L2TP) client
using IPSec.
Tunnel. The portion of the connection
in which your data is encapsulated.
VPN connection. The portion of the
connection in which your data is encrypted. For
secure VPN connections, the data is encrypted
and encapsulated along the same portion of the
connection.
Note It is possible to create a tunnel
and send the data through the tunnel without
encryption. This is not a VPN connection because
the private data is sent across a shared or
public network in an unencrypted and easily
readable form.
Tunneling protocols. Communication
standards used to manage tunnels and encapsulate
private data. (Data that is tunneled must also
be encrypted to be a VPN connection.) Windows
2000 includes the PPTP and L2TP tunneling
protocols. For detailed information about these
protocols, see "Point-to-Point Tunneling
Protocol" and "Layer Two Tunneling
Protocol and Internet Protocol Security"
later in this chapter.
Tunneled data. Data that is usually
sent across a private point-to-point link.
Transit internetwork. The shared or
public internetwork crossed by the encapsulated
data. For Windows 2000, the transit internetwork
is always an IP internetwork. The transit
internetwork can be the Internet or a private
IP-based intranet.
Figure 9.2 Components of a VPN Connection
| VPN
Connections |
|
|
Creating the VPN is very similar to
establishing a point-to-point connection using
dial-up networking and demand-dial routing
procedures. There are two types of VPN
connections: the remote access VPN connection
and the router-to-router VPN connection.
Remote Access VPN
Connection
A remote access VPN connection is made by a
remote access client, or a single user computer,
that connects to a private network. The VPN
server provides access to the resources of the
VPN server or to the entire network to which the
VPN server is attached. The packets sent across
the VPN connection originate at the remote
access client.
The remote access client (the VPN client)
authenticates itself to the remote access server
(the VPN server) and, for mutual authentication,
the server authenticates itself to the client.
Router-to-Router VPN Connection
A router-to-router VPN connection is made by
a router and connects two portions of a private
network. The VPN server provides a routed
connection to the network to which the VPN
server is attached. On a router-to-router VPN
connection, the packets sent from either router
across the VPN connection typically do not
originate at the routers.
The calling router (the VPN client)
authenticates itself to the answering router
(the VPN server), and, for mutual
authentication, the answering router
authenticates itself to the calling router.
| Properties
of VPN Connections |
|
|
VPN connections that use PPTP and L2TP over
IPSec have the following properties:
- Encapsulation
- Authentication
- Data encryption
- Address and name
server assignment
Encapsulation
VPN technology provides a way of
encapsulating private data with a header that
allows the data to traverse the transit
internetwork.
Authentication
Authentication for VPN connections takes two
forms:
- User
authentication
For the VPN
connection to be established, the VPN server
authenticates the VPN client attempting the
connection and verifies that the VPN client
has the appropriate permissions. If mutual
authentication is being used, the VPN client
also authenticates the VPN server, providing
protection against masquerading VPN servers.
- Data
authentication and integrity
To verify that
the data being sent on the VPN connection
originated at the other end of the
connection and was not modified in transit,
the data can contain a cryptographic
checksum based on an encryption key known
only to the sender and the receiver.
Data Encryption
To ensure confidentiality of the data as it
traverses the shared or public transit
internetwork, it is encrypted by the sender and
decrypted by the receiver. 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 internetwork are
unintelligible to anyone who 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, you are given the
option to configure how often the encryption
keys are changed during a connection.
For more information about how encryption
keys are managed for the VPN technologies in
Windows 2000, see "VPN Security" later
in this chapter.
Address and Name Server Allocation
When a VPN server is configured, it creates a
virtual interface that represents the interface
on which all VPN connections are made. When a
VPN client establishes a VPN connection, a
virtual interface is created on the VPN client
that represents the interface connected to the
VPN server. The virtual interface on VPN client
is connected to the virtual interface on the VPN
server creating the point-to-point VPN
connection.
The virtual interfaces of the VPN client and
the VPN server must be assigned IP addresses.
The assignment of these addresses is done by the
VPN server. By default, the VPN server obtains
IP addresses for itself and VPN clients using
the Dynamic Host Configuration Protocol (DHCP).
You can also configure a static pool of IP
addresses defined by an IP network ID and a
subnet mask.
Name server assignment, the assignment of
domain name system (DNS) and Windows Internet
Name Service (WINS) servers, also occurs during
the VPN connection establishment process. The
VPN client obtains the IP addresses of the DNS
and WINS servers from the VPN server for the
intranet to which the VPN server is attached.
| Internet
and Intranet-Based VPN Connections |
|
|
VPN connections can be used whenever a secure
point-to-point connection is needed to connect
users or networks. Typical VPN connections are
either Internet-based or intranet-based.
Internet-Based VPN
Connections
Using an Internet-based VPN connection, you
can avoid long-distance and 1-800 telephone
charges while taking advantage of the global
availability of the Internet.
Remote Access over the Internet
Rather than a remote access client having to
make a long distance or 1-800 call to a
corporate or outsourced network access server
(NAS), the client can call a local ISP. By using
the established physical connection to the local
ISP, the remote access client initiates a VPN
connection across the Internet to the
organization's VPN server. When the VPN
connection is created, the remote access client
can access the resources of the private
intranet.
Figure 9.3 illustrates remote access over the
Internet.
Figure 9.3 VPN Connection Connecting a
Remote Client to a Private Intranet
Connecting Networks over the Internet
When networks are connected over the Internet
(illustrated in Figure 9.4), a router forwards
packets to another router across a VPN
connection. To the routers, the VPN operates as
a data-link layer link.
If your browser does not support inline frames, click
here to view on a separate page.
Figure 9.4 VPN Connecting Two Remote Sites
Across the Internet
Connecting Networks Using Dedicated WAN
Links Rather than using an expensive
long-distance dedicated WAN link between
offices, the office routers are connected to the
Internet using local dedicated wide area network
(WAN) links to a local ISP. A router-to-router
VPN connection is then initiated by either
router across the Internet. When connected,
routers can forward directed or routing protocol
traffic to each other using the VPN connection.
Connecting Networks Using Dial-Up WAN
Links Rather than having a branch office
router make a long distance or 1-800 call to a
corporate or outsourced NAS, the branch office
router calls a local ISP. Using the established
connection to the local ISP, a router-to-router
VPN connection is initiated by the branch office
router to the corporate hub router across the
Internet. The corporate hub router acting as a
VPN server must be connected to a local ISP
using a dedicated WAN link.
For more information about configuring VPN
connections using a dial-up connection to a
local ISP, see "Addressing and Routing for
VPNs" later in this chapter.
It is possible to have both offices connected
to the Internet using a dial-up WAN link.
However, this is only feasible if the ISP
supports demand-dial routing to customers; the
ISP calls the customer router when an IP
datagram is to be delivered to the customer.
Demand-dial routing to customers is not widely
supported by ISPs.
Intranet-Based VPN Connections
The intranet-based VPN connection takes
advantage of IP connectivity in an organization
intranet.
Remote Access over an Intranet
In some organization intranets, the data of a
department, such as a human resources
department, is so sensitive that the
department's network segment is physically
disconnected from the rest of the organization's
intranet. While this protects the department's
data, it creates information accessibility
problems for those users not physically
connected to the separate network segment.
VPN connections allow the sensitive
department's network segment to be physically
connected to the organization intranet but
separated by a VPN server. 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
the appropriate permissions can establish a
remote access VPN connection with the VPN server
and can gain access to the protected resources
of the sensitive department's network.
Additionally, all communication across the VPN
connection is encrypted for data
confidentiality. For those users who do not have
permissions to establish a VPN connection, the
separate network segment is hidden from view.
Figure 9.5 illustrates remote access over an
intranet.
Figure 9.5 VPN Connection Allowing
Remote Access to a Secured Network over an
Intranet
Connecting Networks over an Intranet
You can also connect two networks over an
intranet using a router-to-router 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.
Figure 9.6 illustrates networks connected
over an intranet.
Figure 9.6 VPN Connection Connecting Two
Networks over an Intranet
Combined Internet and Intranet VPN
Connections
A VPN connection is a networking tool that
can provide secured point-to-point connections
in whatever manner you see fit. A less common
combined Internet and intranet VPN connection,
called a pass-through VPN connection,
illustrated in Figure 9.7, allows a remote
access client connected to one company's
intranet to access the resources of another
company's intranet using the Internet. In this
scenario, a remote access VPN connection passes
through one intranet and the Internet to access
a second intranet.
Figure 9.7 Pass-Through VPN Connection
For more information about pass-through VPNs,
see "Pass-Through VPN Scenario" later
in this chapter.
| Managing
Virtual Private Networking |
|
|
Virtual private networking must be managed
just like any other network resource, and VPN
security issues, particularly with Internet VPN
connections, must be addressed carefully.
Consider the following questions:
- Where is the user
account data to be stored?
- How are addresses
assigned to VPN clients?
- Who is allowed to
create VPN connections?
- How does the VPN
server verify the identity of the user
attempting the VPN connection?
- How does the VPN
server record the VPN activity?
- How can the VPN
server be managed using industry-standard
network management protocols and
infrastructure?
Managing Users
Because it is administratively unsupportable
to have separate user accounts on separate
servers for the same user and try to keep them
all simultaneously current, most administrators
set up a master account database at a domain
controller (PDC) or on a Remote Authentication
Dial-in User Service (RADIUS) server. This
allows the VPN server to send the authentication
credentials to a central authenticating device.
The same user account is used for both dial-in
remote access and VPN-based remote access.
Managing Addresses and Name Servers
The VPN server must have IP addresses
available in order to assign them to the VPN
server's virtual interface and to VPN clients
during the IP Control Protocol (IPCP)
negotiation phase of the connection
establishment process. The IP address assigned
to the VPN client is assigned to the virtual
interface of the VPN client.
For Windows 2000-based VPN servers, the IP
addresses assigned to VPN clients are obtained
through DHCP by default. You can also configure
a static IP address pool.
The VPN server must also be configured with
DNS and WINS server addresses to assign to the
VPN client during IPCP negotiation. For more
information about how the VPN server assigns the
IP addresses of DNS and WINS servers, see
"Remote Access Server" in this book.
Managing Access
For Windows 2000, configure the dial-in
properties on user accounts and remote access
policies to manage access for dial-up networking
and VPN connections.
Access by User Account
If you are managing remote access on a user
basis, set the remote access permission on those
user accounts that are allowed to create VPN
connections to Allow access. If the VPN
server is only allowing VPN connections, delete
the default remote access policy called Allow
access if dial-in permission is enabled.
Then create a new remote access policy with a
descriptive name such as VPN access if
allowed by user account.
If the VPN server is also allowing dial-up
remote access services, do not delete the
default policy, but move it so that it is the
last policy to be evaluated.
As an example of typical settings, configure
the remote access policy permission to Deny
remote access permission and set the
conditions and profile settings as listed in
Tables 9.1 and 9.2. For detailed information
about configuring these settings, see Windows
2000 Server Help.
Table 9.1 Remote Access Policy Conditions
for VPN Access by User Account
Conditions
|
Setting
|
NAS-Port-Type
|
Virtual
|
Table 9.2 Remote Access Policy Profile
Settings for VPN Access by User Account
Profile
settings
|
Setting
|
Authentication
tab
|
Enable
Microsoft encrypted authentication
version 2 (MS-CHAP v2) and Microsoft
encrypted authentication (MS-CHAP).
|
Encryption
tab
|
Select
Basic, Strong, or Strongest.
Clear No Encryption.
|
If you want to define different
authentication, encryption, or other settings
for PPTP or L2TP connections, create separate
remote access policies using the Tunnel-Type
remote access policy condition set to either the
Point-to-Point Tunneling Protocol or the Layer
Two Tunneling Protocol.
Access by Group Membership
If you are managing remote access on a group
basis, set the remote access permission on all
user accounts to Control access through
Remote Access Policy. Create a Windows 2000
group with members who are allowed to create VPN
connections. If the VPN server only allows VPN
connections, delete the default remote access
policy called Allow access if dial-in
permission is enabled. Then create a new
remote access policy with a descriptive name
such as VPN access if member of VPN-allowed
group.
If the VPN server also allows dial-up
networking remote access services, do not delete
the default policy but move it so that it is the
last policy to be evaluated.
As an example of typical settings, configure
the remote access policy permission to Grant
remote access permission and set the
conditions and profile settings as listed in
Tables 9.3 and 9.4. For detailed information
about configuring these settings, see Windows
2000 Server Help.
Table 9.3 Remote Access Policy Conditions
for VPN Access by Windows 2000 Group
Conditions
|
Setting
|
NAS-Port-Type
|
Virtual
|
Windows-Groups
|
Windows
2000 group whose members are allowed to
create VPN connections.
|
Table 9.4 Remote Access Policy Profile
Settings for VPN Access by Windows 2000 Group
Profile
Settings
|
Setting
|
Authentication
tab
|
Enable
Microsoft encrypted authentication
version 2 (MS-CHAP v2) and Microsoft
encrypted authentication (MS-CHAP).
|
Encryption
tab
|
Select
Basic, Strong, or Strongest.
Clear No Encryption.
|
Managing Authentication
The VPN server can be configured to use
either Windows or RADIUS as an authentication
provider. If Windows is selected as the
authentication provider, the user credentials
sent by users attempting VPN connections are
authenticated using typical Windows
authentication mechanisms.
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 a series of RADIUS request
messages to a RADIUS server.
The RADIUS server receives a user-connection
request from the VPN server and authenticates
the user using its authentication database. A
RADIUS server can also maintain a central
storage database of other relevant user
properties. 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 database, or it can be a front
end to another database server, such as a
generic Open Database Connectivity (ODBC) server
or a Windows 2000 PDC. The latter example 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 2138
and RFC 2139. For more information about the
RADIUS protocol and the Windows 2000-based
RADIUS server known as Internet Authentication
Service, see "Internet Authentication
Service" in this book.
Managing Accounting
You can configure the VPN server to use
either Windows or RADIUS as an accounting
provider. If you select Windows as the
accounting provider, the accounting information
accumulates on the VPN server for later
analysis. If you select RADIUS, RADIUS
accounting messages are sent to the RADIUS
server for accumulation and later analysis.
You can configure most RADIUS servers to
place authentication request records into an
accounting 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 2139.
Network Management
The computer acting as the VPN server can
participate in a Simple Network Management
Protocol (SNMP) environment as an SNMP agent if
the Windows 2000 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 2000 SNMP service.
Objects in the Internet MIB II are documented in
RFC 1213.
| Point-to-Point
Tunneling Protocol |
|
|
The Point-to-Point Tunneling Protocol (PPTP)
encapsulates Point-to-Point Protocol (PPP)
frames into IP datagrams for transmission over
an IP-based internetwork, such as the Internet
or a private intranet. PPTP is documented in RFC
2637.
The PPTP uses a TCP connection known as the
PPTP control connection to create, maintain, and
terminate the tunnel and 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 or compressed or both.
PPTP assumes the availability of an IP
internetwork 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 internetwork that can reach
the PPTP server, or the PPTP client might have
to dial into a network access server (NAS) to
establish IP connectivity as in the case of
dial-up Internet users.
Authentication that occurs during the
creation of a PPTP-based VPN connection uses the
same authentication mechanisms as PPP
connections, such as Extensible Authentication
Protocol (EAP), Microsoft Challenge-Handshake
Authentication Protocol (MS-CHAP), CHAP, Shiva
Password Authentication Protocol (SPAP), and
Password Authentication Protocol (PAP). PPTP
inherits encryption or compression, or both, of
PPP payloads from PPP. For Windows 2000, either
EAP-Transport Level Security (EAP-TLS) or
MS-CHAP must be used in order for the PPP
payloads to be encrypted using Microsoft
Point-to-Point Encryption (MPPE).
MPPE provides only link encryption, not
end-to-end encryption. End-to-end encryption is
data encryption between the client application
and the server hosting the resource or service
being accessed by the client application. If
end-to-end encryption is required, IPSec can be
used to encrypt IP traffic from end-to-end after
the PPTP tunnel is established.
For Internet-based PPTP servers, the PPTP
server is a PPTP-enabled VPN server with one
interface on the Internet and a second interface
on the intranet.
Tunnel Maintenance with the
PPTP Control Connection
The PPTP control connection is between the IP
address of the PPTP client using a dynamically
allocated TCP port and the IP address of the
PPTP server using the reserved TCP port 1723.
The PPTP control connection carries the PPTP
call control and management messages that are
used to maintain the PPTP tunnel. This includes
the transmission of periodic PPTP Echo-Request
and PPTP Echo-Reply messages to detect a
connectivity failure between the PPTP client and
PPTP server. PPTP control connection packets
consist of an IP header, a TCP header, and a
PPTP control message as illustrated in Figure
9.8. The PPTP control connection packet in
Figure 9.8 also includes a data-link layer
header and trailer.
Figure 9.8 PPTP Control Connection Packet
Table 9.5 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.
Table 9.5 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 PPTP tunnel
requires a control connection to be
established before any other PPTP
messages can be issued.
|
Start-Control-Connection-Reply
|
Sent
by the PPTP server to reply to the
Start-Control-Connection-Request
message.
|
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 to
identify the tunneled traffic of a
specific tunnel.
|
Outgoing-Call-Reply
|
Sent
by the PPTP server in response to the
Outgoing-Call-Request message.
|
Echo-Request
|
Sent
by either the PPTP client or PPTP server
as a keep-alive mechanism. If the
Echo-Request is not answered, the PPTP
tunnel is eventually terminated.
|
Echo-Reply
|
The
reply to an Echo-Request.
Note: The PPTP Echo-Request and
Echo-Reply messages are not related to
the ICMP Echo Request and Echo Reply
messages.
|
WAN-Error-Notify
|
Sent
by the PPTP server to all VPN clients to
indicate error conditions on the PPP
interface of the PPTP server.
|
Set-Link-Info
|
Sent
by the PPTP client or PPTP server to set
PPP-negotiated options.
|
Call-Clear-Request
|
Sent
by the PPTP client indicating that a
tunnel is to be terminated.
|
Call-Disconnect-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 server
terminates 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 the control
connection is being terminated.
|
Stop-Control-Connection-Reply
|
Used
to reply to the
Stop-Control-Connection-Request message.
|
For information about the exact structure of
PPTP control connection messages, see RFC 2637.
PPTP Data Tunneling
PPTP data tunneling is performed through
multiple levels of encapsulation.
Figure 9.9 shows the resulting structure of
PPTP tunneled data.
Figure 9.9 PPTP Tunneled Data
Encapsulation of PPP Frame
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 documented in RFC
1701 and RFC 1702 and was designed to provide a
simple, lightweight, general purpose mechanism
for encapsulating data sent over IP
internetworks. GRE is a client protocol of IP
using IP protocol 47.
For PPTP, the GRE header is modified in the
following ways:
- An acknowledgement
bit is used to indicate that a 32-bit
acknowledgement field is present and
significant.
- The Key field is
replaced with a 16-bit Payload Length field
and a 16-bit Call ID field. The Call ID
field is set by the PPTP client during the
creation of the PPTP tunnel.
- A 32-bit
Acknowledgement field is added.
Within the GRE header, the Protocol Type is
set to 0x880B, the EtherType value for a PPP
frame.
Note GRE is sometimes used by ISPs to
forward routing information within an ISP's
network. To prevent the routing information from
being forwarded to Internet backbone routers,
ISPs filter out GRE traffic on the interfaces
connected to the Internet backbone. As a result
of this filtering, PPTP tunnels can be created
using PPTP control messages, but PPTP tunneled
data is not forwarded. If you suspect that this
is a problem, contact your ISP.
Encapsulation of GRE Packet
The resulting GRE and PPP-encapsulated
payload is then encapsulated with an IP header
containing the appropriate source and
destination IP addresses for the PPTP client and
PPTP server.
Data-Link Layer Encapsulation
To be sent on a local area network (LAN) or
WAN link, the IP datagram is finally
encapsulated with a header and trailer for the
data-link layer technology of the outgoing
physical interface. For example, when IP
datagrams are sent on an Ethernet interface, the
IP datagram is encapsulated with an Ethernet
header and trailer. When IP datagrams are sent
over a point-to-point WAN link, such as an
analog phone line or ISDN, the IP datagram is
encapsulated with a PPP header and trailer.
Processing of the PPTP Tunneled Data
Upon receipt of the PPTP tunneled 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 or
decompresses, or both, the PPP payload (if
needed).
- Processes the
payload for receipt or forwarding.
PPTP Packets and Windows 2000 Networking
Architecture
Figure 9.10 illustrates the path that
tunneled data takes through the Windows 2000
networking architecture from a VPN client over a
remote access VPN connection using an analog
modem. The following steps outline this process:
- An IP datagram,
IPX datagram, or NetBEUI frame is submitted
by its appropriate protocol to the virtual
interface that represents the VPN connection
using Network Driver Interface Specification
(NDIS).
- NDIS submits the
packet to NDISWAN, which encrypts or
compresses the data, or both, and provides a
PPP header consisting of only the PPP
Protocol ID field. No Flags or Frame Check
Sequence (FCS) fields are added. This
assumes that address and control field
compression were negotiated during the Link
Control Protocol (LCP) phase of the PPP
connection process. For more information
about PPP and LCP, see "Remote Access
Server" in this book.
- 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.
- The PPTP protocol
driver then submits the resulting packet to
the TCP/IP protocol driver.
- The TCP/IP
protocol driver encapsulates the PPTP
tunneled data with an IP header and submits
the resulting packet to the interface that
represents the dial-up connection to the
local ISP using NDIS.
- NDIS submits the
packet to NDISWAN, which provides PPP
headers and trailers.
- NDISWAN submits
the resulting PPP frame to the appropriate
WAN miniport driver representing the dial-up
hardware (for example, the asynchronous port
for a modem connection).
Figure 9.10 PPTP Packet Development
Note It is possible to negotiate an
encrypted PPP connection for the dial-up
connection with the ISP. This is unnecessary and
not recommended because the private data being
sent, the tunneled PPP frame, is already
encrypted. The additional level of encryption is
not needed and can impact performance.
| Using
Network Load Balancing with PPTP |
|
|
Windows 2000 Network Load Balancing allows
you to build a cluster of PPTP servers to
enhance the availability of PPTP servers for VPN
connections. To create a load-balanced cluster
of PPTP servers:
- Configure each
member of the cluster as a Windows 2000 PPTP
server. For more information about
configuring a Windows 2000 Server computer
as PPTP a server, see Windows 2000 Server
Help.
- Configure the
collection of PPTP server computers as a
Network Load Balancing cluster. For more
information about configuring Network Load
Balancing, see Windows 2000 Advanced Server
Help. When configuring Network Load
Balancing on each PPTP server, enable
Network Load Balancing on the interface that
is receiving PPTP connection requests.
- In configuring
Network Load Balancing on each PPTP server,
both a cluster IP address and a dedicated IP
address are configured as multiple IP
addresses on the interface that is receiving
PPTP connection requests. To prevent
problems creating PPTP connections with
Windows 95, Windows NT 4.0, and Windows 98
PPTP clients, remove the dedicated IP
address from the interface that is receiving
PPTP connection requests using the
properties of the TCP/IP protocol in Network
and Dial-up Connections for each PPTP server
in the cluster.
- Removing the
dedicated IP address will prevent individual
servers from being remotely administered
using the dedicated IP address. To allow
remote administration of individual PPTP
servers in the cluster, ensure that you have
an additional LAN interface on each server
in the cluster that is connected to a
different network segment as the interface
receiving PPTP connection requests. For
Internet-connected PPTP servers, there is
usually an additional interface connected to
the intranet that is connected to a
different network segment. After removing
the dedicated IP address from the Internet
interface, you can remotely administer the
individual PPTP server from the intranet,
but not from the Internet.
Note Windows 95, Windows NT 4.0, and
Windows 98 PPTP clients may not be able to
connect to the PPTP cluster unless the dedicated
IP address is removed because these clients send
their PPTP connection requests to the cluster IP
address. An individual PPTP server may reply to
the PPTP connection request from the dedicated
IP address rather than the cluster IP address.
If so, the PPTP client notices the change in IP
address between the request and the reply,
assumes the behavior is a violation of the
security of the PPTP connection, and drops the
connection.
| Layer
Two Tunneling Protocol and Internet
Protocol Security |
|
|
Layer Two Tunneling Protocol (L2TP) is a
combination of PPTP and Layer 2 Forwarding
(L2F), a technology proposed by Cisco® Systems,
Inc. Rather than having two incompatible
tunneling protocols competing in the marketplace
and causing customer confusion, the IETF
mandated that the two technologies be combined
into a single tunneling protocol that represents
the best features of PPTP and L2F. L2TP is
documented in RFC 2661.
L2TP encapsulates PPP frames to be sent over
IP, X.25, Frame Relay, or ATM networks.
Currently, only L2TP over IP networks is
defined. When sent over an IP internetwork, 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 internetworks
for both tunnel maintenance and tunneled data.
The payloads of encapsulated PPP frames can be
encrypted or compressed, or both; however,
Windows 2000 L2TP clients do not negotiate the
use of MPPE for L2TP connections. Encryption for
L2TP connections is provided by IPSec ESP.
It is possible to create L2TP connections in
Windows 2000 that are not encrypted by IPSec.
However, this is not a VPN connection because
the private data being encapsulated by L2TP is
not encrypted. Non-encrypted L2TP connections
can be used temporarily to troubleshoot an L2TP
over IPSec connection by eliminating the IPSec
authentication and negotiation process.
L2TP assumes the availability of an IP
internetwork between a L2TP client (a VPN client
using the L2TP tunneling protocol and IPSec) and
a L2TP server (a VPN server using the L2TP
tunneling protocol and IPSec). The L2TP client
might already be attached to an IP internetwork
that can reach the L2TP server, or the L2TP
client might have to dial into a NAS to
establish IP connectivity as in the case of
dial-up Internet users.
Authentication that occurs during the
creation of L2TP tunnels must use the same
authentication mechanisms as PPP connections
such as EAP, MS-CHAP, CHAP, SPAP, and PAP.
For Internet-based L2TP servers, the L2TP
server is an L2TP-enabled dial-up server with
one interface on the external network, the
Internet, and a second interface on the target
private network.
L2TP tunnel maintenance and tunneled data
have the same packet structure.
Tunnel Maintenance with
L2TP Control Messages
Unlike 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 2000, the L2TP client
and the L2TP server both use UDP port 1701.
Note The L2TP client and L2TP server
in Windows 2000 always use UDP port 1701. The
Windows 2000 L2TP server supports L2TP clients
that use a UDP port other than 1701.
L2TP control messages over IP are sent as UDP
datagrams. In the Windows 2000 implementation,
L2TP control messages sent as UDP datagrams are
sent as the encrypted payload of IPSec ESP as
illustrated in Figure 9.11.
Figure 9.11 L2TP Control Message
Because a TCP connection is not used, L2TP
uses message sequencing to ensure delivery of
L2TP messages. Within the L2TP control message,
the Next-Received field (similar to the TCP
Acknowledgment field) and the Next-Sent field
(similar to the TCP Sequence Number field) are
used to maintain the sequence of control
messages. Out-of-sequence packets are dropped.
The Next-Sent and Next-Received fields can also
be used for sequenced delivery and flow control
for tunneled data.
L2TP supports multiple calls for each tunnel.
In the L2TP control message and the L2TP header
for tunneled data is a Tunnel ID that identifies
the tunnel and a Call ID that identifies a call
within the tunnel.
Table 9.6 lists the primary L2TP control
messages.
Table 9.6 L2TP Control Messages
Message
Type
|
Purpose
|
Start-Control-Connection-Request
|
Sent
by the L2TP client to establish the
control connection. Each L2TP tunnel
requires a control connection to be
established before any other L2TP
messages can be issued. It includes an
Assigned Tunnel-ID that is used to
identify the tunnel.
|
Start-Control-Connection-Reply
|
Sent
by the L2TP server to reply to the
Start-Control-Connection-Request
message.
|
Start-Control-Connection-Connected
|
Sent
in reply to a
Start-Control-Connection-Reply message
to indicate that the tunnel
establishment was successful.
|
Outgoing-Call-Request
|
Sent
by the L2TP client to create an L2TP
tunnel. Included in the
Outgoing-Call-Request message is an
Assigned Call ID that is used to
identify a call within a specific
tunnel.
|
Outgoing-Call-Reply
|
Sent
by the L2TP server in response to the
Outgoing-Call-Request message.
|
Start-Control-Connection-Connected
|
Sent
in reply to a received
Outgoing-Call-Reply message to indicate
that the 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 on the PPP
interface of the L2TP server.
|
Set-Link-Info
|
Sent
by the L2TP client or L2TP server to set
PPP-negotiated options.
|
Call-Disconnect-Notify
|
Sent
by either the L2TP server or L2TP client
to indicate that a call within a tunnel
is to be terminated.
|
Stop-Control-Connection-Notification
|
Sent
by either the L2TP server or L2TP client
to indicate that a tunnel is to be
terminated.
|
For the exact structure of L2TP control
messages, please see the L2TP Internet draft.
L2TP Data Tunneling
L2TP data tunneling is performed through
multiple levels of encapsulation.
Figure 9.12 shows the resulting structure of
L2TP over IPSec tunneled data.
If your browser does not support inline frames, click
here to view on a separate page.
Figure 9.12 L2TP Packet Encapsulation
L2TP Encapsulation
The initial PPP payload is encapsulated with
a PPP header and an L2TP header.
UDP Encapsulation
The L2TP encapsulated packet is then
encapsulated with a UDP header with the source
and destination ports set to 1701.
IPSec Encapsulation
Based on IPSec policy, the UDP message is
encrypted and encapsulated with an IPSec
Encapsulating Security Payload (ESP) header and
trailer and an IPSec Authentication (Auth)
trailer.
IP Encapsulation
The IPSec packet is encapsulated with a final
IP header containing the source and destination
IP addresses of the VPN client and VPN server.
Data-Link Layer Encapsulation
To be sent on a LAN or WAN link, the IP
datagram is finally encapsulated with a header
and trailer for the data-link layer technology
of the outgoing physical interface. For example,
when IP datagrams are sent on an Ethernet
interface, the IP datagram is encapsulated with
an Ethernet header and trailer. When IP
datagrams are sent over a point-to-point WAN
link such as an analog phone line or ISDN, the
IP datagram is encapsulated with a PPP header
and trailer.
De-encapsulation of L2TP over IPSec Tunneled
Data
Upon receipt of the L2TP over IPSec tunneled
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 L2TP.
- L2TP 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 over IPSec Packets and Windows 2000
Networking Architecture
Figure 9.13 illustrates the path that
tunneled data takes through the Windows 2000
networking architecture from a VPN client over a
remote access VPN connection using an analog
modem. The following steps outline the process:
- An IP datagram,
IPX datagram, or NetBEUI frame is submitted
by the appropriate protocol to the virtual
interface that represents the VPN connection
using NDIS.
- NDIS submits a
packet to NDISWAN, which optionally
compresses and provides a PPP header
consisting of only the PPP Protocol ID
field. No Flags or FCS fields are added.
- NDISWAN submits
the PPP frame to the L2TP protocol driver,
which encapsulates the PPP frame with a L2TP
header. In the L2TP header, the Tunnel ID
and the Call ID are set to the appropriate
value identifying the tunnel.
- 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.
- 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.
The original IP
header with the Protocol field set to 50 is
added to the front of the ESP packet.
The TCP/IP
protocol driver then submits the resulting
packet to the interface that represents the
dial-up connection to the local ISP using
NDIS.
- NDIS submits the
packet to NDISWAN.
- NSIDWAN provides
PPP headers and trailers and submits the
resulting PPP frame to the appropriate WAN
miniport driver representing the dial-up
hardware.
If your browser does not support inline frames, click
here to view on a separate page.
| 
Virtual Private Networking Overview