What Is VPN?
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
What Is VPN?
In this section
VPN Connection Properties
Routing for VPN
VPN and Firewalls Overview
Technologies Related to VPN
The virtual private network (VPN) technology included in Windows Server 2003 helps enable cost-effective, secure remote access to private networks. VPN allows administrators to take advantage of the Internet to help provide the functionality and security of private WAN connections at a lower cost. In Windows Server 2003, VPN is enabled using the Routing and Remote Access service. VPN is part of a comprehensive network access solution that includes support for authentication and authorization services, and advanced network security technologies.
There are two main strategies that help provide secure connectivity between private networks and enabling network access for remote users.
Dial-up or leased line connections
A dial-up or leased line connection creates a physical connection to a port on a remote access server on a private network. However, using dial-up or leased lines to provide network access is expensive when compared to the cost of providing network access using a VPN connection.
VPN connections use either Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol/Internet Protocol security (L2TP/IPSec) over an intermediate network, such as the Internet. By using the Internet as a connection medium, VPN saves the cost of long-distance phone service and hardware costs associated with using dial-up or leased line connections. A VPN solution includes advanced security technologies such as data encryption, authentication, authorization, and Network Access Quarantine Control.
- Network Access Quarantine Control is used to delay remote access to a private network until the configuration of the remote access computer has been examined and validated.
Using VPN, administrators can connect remote or mobile workers (VPN clients) to private networks. Remote users can work as if their computers are physically connected to the network. To accomplish this, VPN clients can use a Connection Manager profile to initiate a connection to a VPN server. The VPN server can communicate with an Internet Authentication Service (IAS) server to authenticate and authorize a user session and maintain the connection until it is terminated by the VPN client or by the VPN server. All services typically available to a LAN-connected client (including file and print sharing, Web server access, and messaging) are enabled by VPN.
VPN clients can use standard tools to access resources. For example, clients can use Windows Explorer to make drive connections and to connect to printers. Connections are persistent: Users do not need to reconnect to network resources during their VPN sessions. Because drive letters and universal naming convention (UNC) names are fully supported by VPN, most commercial and custom applications work without modification.
Virtual private networks are point-to-point connections across a private or public network such as the Internet. A VPN client uses special TCP/IP-based protocols, called tunneling protocols, to make a virtual call to a virtual port on a VPN server. In a typical VPN deployment, a client initiates a virtual point-to-point connection to a remote access server over the Internet. The remote access server answers the call, authenticates the caller, and transfers data between the VPN client and the organization’s private network.
To emulate a point-to-point link, data is encapsulated, or wrapped, with a header. The header provides routing information that enables the data to traverse the shared or public network 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 VPN connection.
A VPN Connection
There are two types of VPN connections:
Remote access VPN
Remote Access VPN
Remote access VPN connections enable users working at home or on the road to access a server on a private network using the infrastructure provided by a public network, 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’s 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.
Site-to-site VPN connections (also known as router-to-router VPN connections) enable organizations to have routed connections between separate offices or with other organizations over a public network while helping to maintain secure communications. A routed VPN connection across the Internet logically operates as a dedicated WAN link. When networks are connected over the Internet, as shown in the following figure, a router forwards packets to another router across a VPN connection. To the routers, the VPN connection operates as a data-link layer link.
A site-to-site VPN connection connects two portions of a private network. The VPN server provides a routed connection to the network to which the VPN server is attached. 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. In a site-to site VPN connection, the packets sent from either router across the VPN connection typically do not originate at the routers.
VPN Connecting Two Remote Sites Across the Internet
VPN Connection Properties
PPTP-based VPN and L2TP/IPSec-based VPN connection properties are described in the following sections.
VPN technology provides a way of encapsulating private data with a header that allows the data to traverse the network.
There are three types of authentication for VPN connections:
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.
The user attempting the PPTP or L2TP/IPSec connection is authenticated using Point-to-Point (PPP)-based user authentication protocols such as Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP), Microsoft Challenge-Handshake Authentication Protocol version 2 (MS-CHAP v2), Shiva Password Authentication Protocol (SPAP), and Password Authentication Protocol (PAP). For PPTP connections, you must use EAP-TLS, MS-CHAP, or MS-CHAP v2. EAP-TLS using smart cards or MS-CHAP v2 is highly recommended, as they provide mutual authentication and are the most secure methods of exchanging credentials.
Computer authentication with L2TP/IPSec
By performing computer-level authentication with IPSec, L2TP/IPSec connections also verify that the remote access client computer is trusted.
Data authentication and integrity
To verify that the data being sent on an L2TP/IPSec VPN connection originated at the other end of the connection and was not modified in transit, L2TP/IPSec packets include a cryptographic checksum based on an encryption key known only to the sender and the receiver.
Data can be encrypted for protection between the endpoints of the VPN connection. Data encryption should always be used for VPN connections where private data is sent across a public network such as the Internet. Data that is not encrypted is vulnerable to unauthorized interception. For VPN connections, Routing and Remote Access uses Microsoft Point-to-Point Encryption (MPPE) with PPTP and IPSec encryption with L2TP.
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 the 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). Otherwise, a static pool of IP addresses can be configured to define one or more address ranges, with each range defined by an IP network ID and a subnet mask or start and end IP addresses.
Name server assignment, the assignment of Domain Name System (DNS) and Windows Internet Name Service (WINS) servers to the VPN connection, also occurs during the process of establishing the VPN connection.
Tunneling is a method of using a network infrastructure to transfer data for one network over another network. The data (or payload) to be transferred can be the frames (or packets) of another protocol. Instead of sending a frame as it is produced by the originating node, the tunneling protocol encapsulates the frame in an additional header. The additional header provides routing information so that the encapsulated payload can traverse the intermediate network.
The encapsulated packets are then routed between tunnel endpoints over the network. The logical path through which the encapsulated packets travel through the network is called a tunnel. After the encapsulated frames reach their destination on the network, the frame is de-encapsulated (the header is removed) and the payload is forwarded to its final destination. Tunneling includes this entire process (encapsulation, transmission, and de-encapsulation of packets).
Tunneling enables the encapsulation of a packet from one type of protocol within the datagram of a different protocol. For example, VPN uses PPTP to encapsulate IP packets over a public network such as the Internet. A VPN solution based on either PPTP or L2TP can be configured.
PPTP and L2TP depend heavily on the features originally specified for PPP. PPP was designed to send data across dial-up or dedicated point-to-point connections. For IP, PPP encapsulates IP packets within PPP frames and then transmits the encapsulated PPP-packets across a point-to-point link. PPP was originally defined as the protocol to use between a dial-up client and a network access server (NAS).
PPTP allows multiprotocol traffic to be encrypted and then encapsulated in an IP header to be sent across an organization’s IP network or a public IP network such as the Internet. PPTP encapsulates Point-to-Point Protocol (PPP) frames in IP datagrams for transmission over the network. PPTP can be used for remote access and site-to-site VPN connections. PPTP is documented in RFC 2637 in the IETF RFC Database.
PPTP uses a TCP connection for tunnel management and a modified version of Generic Routing Encapsulation (GRE) to encapsulate PPP frames for tunneled data. The payloads of the encapsulated PPP frames can be encrypted, compressed, or both. The following figure shows the structure of a PPTP packet containing an IP datagram.
Structure of a PPTP Packet Containing an IP Datagram
When using the Internet as the public network for VPN, the PPTP server is a PPTP-enabled VPN server with one interface on the Internet and a second interface on the intranet.
L2TP allows multiprotocol traffic to be encrypted and then sent over any medium that supports point-to-point datagram delivery, such as IP, X.25, frame relay, or asynchronous transfer mode (ATM). L2TP is a combination of PPTP and Layer 2 Forwarding (L2F), a technology developed by Cisco Systems, Inc. L2TP represents the best features of PPTP and L2F. L2TP encapsulates PPP frames to be sent over IP, X.25, frame relay, or ATM networks. When configured to use IP as its datagram transport, L2TP can be used as a tunneling protocol over the Internet. L2TP is documented in RFC 2661 in the IETF RFC Database.
L2TP over IP networks uses User Datagram Protocol (UDP) and a series of L2TP messages for tunnel management. L2TP also uses UDP to send L2TP-encapsulated PPP frames as tunneled data. The payloads of encapsulated PPP frames can be encrypted, compressed, or both, although the Microsoft implementation of L2TP does not use MPPE to encrypt the PPP payload. The following figure shows the structure of an L2TP packet containing an IP datagram.
Structure of an L2TP Packet Containing an IP Datagram
L2TP with IPSec (L2TP/IPSec)
In the Microsoft implementation of L2TP, IPSec Encapsulating Security Payload (ESP) in transport mode is used to encrypt L2TP traffic. The combination of L2TP (the tunneling protocol) and IPSec (the method of encryption) is known as L2TP/IPSec. L2TP/IPSec is described in RFC 3193 in the IETF RFC Database.
The result after applying ESP to an IP packet containing an L2TP message is shown in the following figure.
Encryption of L2TP Traffic with IPSec ESP
Routing for VPN
Routing for remote access and site-to-site VPN connections is described in the following sections.
Routing for Remote Access VPN Connections
Conventional routing occurs between routers over either LAN-based shared access technologies, such as Ethernet or Token Ring, or WAN-based point-to-point technologies, such as T1 or frame relay.
The preferred method for directing packets to a remote network is to create a default route on the remote access client that directs packets to the remote network (the default configuration for VPN remote access clients). Any packet that is not intended for the neighboring LAN segment is sent to the remote network. When a connection is made, the remote access client, by default, adds a default route to its routing table and increases the metric of the existing default route to ensure that the newest default route is used. The newest default route points to the new connection, which ensures that any packets that are not addressed to the local LAN segment are sent to the remote network.
Under this configuration, when a VPN client connects and creates a new default route, Internet sites that have been accessible are no longer accessible (unless Internet access is available through the organization’s intranet). This poses no problem for remote VPN clients that require access only to the organization’s network. However, it is not acceptable for remote clients that need access to the Internet while they are connected to the organization’s network.
Split tunneling enables remote access VPN clients to route corporate-based traffic over the VPN connection while sending Internet-based traffic using the user’s local Internet connection. This prevents the use of corporate bandwidth for access to Internet sites.
However, a split tunneling implementation can introduce a security issue. If a remote access client has reachability to both the Internet and a private organization network simultaneously, the possibility exists that the Internet connection could be exploited to gain access to the private organization network through the remote access client. Security-sensitive companies can choose to use the default routing model to help ensure that all VPN client communications are protected by the corporate firewall.
Routing for Site-to-Site VPN Connections
With conventional WAN technologies, IP packets are forwarded between two routers over a physical or logical point-to-point connection. This connection is dedicated to the customer across a private data network that is provided by the WAN service provider.
With the advent of the Internet, packets can now be routed between routers that are connected to the Internet across a virtual connection that emulates the properties of a dedicated, private, point-to-point connection. This type of connection is known as a site-to-site VPN connection. Site-to-site VPN connections can be used to replace expensive long-haul WAN links with short-haul WAN links to a local Internet service provider (ISP).
A site-to-site VPN connection 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 site-to-site VPN connection, the packets sent from either router across the VPN connection typically do not originate at the routers.
To facilitate routing between the sites, each VPN server and the routing infrastructure of its connected site must have a set of routes that represent the address space of the other site. These routes can be added manually, or routing protocols can be used to automatically add and maintain a set of routes.
Site-to-Site Routing Protocols
There are two routing protocols that can be used in a site-to-site VPN deployment:
Routing Information Protocol (RIP)
Open Shortest Path First (OSPF)
RIP is designed for exchanging routing information within a small to medium-size network. RIP routers dynamically exchange routing table entries.
The Windows Server 2003 implementation of RIP has the following features:
The ability to select which RIP version to run on each interface for incoming and outgoing packets.
Split-horizon, poison-reverse, and triggered-update algorithms that are used to avoid routing loops and speed recovery of the network when topology changes occur.
Route filters for choosing which networks to announce or accept.
Peer filters for choosing which router’s announcements are accepted.
Configurable announcement and route-aging timers.
Simple password authentication support.
The ability to disable subnet summarization.
OSPF is designed for exchanging routing information within a large or very large network. Instead of exchanging routing table entries like RIP routers, OSPF routers maintain a map of the network that is updated after any change to the network topology. This map, called the link state database, is synchronized between all the OSPF routers and is used to compute the routes in the routing table. Neighboring OSPF routers form an adjacency, which is a logical relationship between routers to synchronize the link state database.
VPN and Firewalls Overview
The routing service supports a variety of inbound and outbound packet-filtering features that block certain types of traffic. The filtering options include the following: TCP port, UDP port, IP protocol ID, Internet Control Message Protocol (ICMP) type, ICMP code, source address, and destination address. A VPN server can be placed behind a firewall or in front of a firewall. These two approaches are described in the following sections.
VPN Server Behind a Firewall
In the most common configuration, the firewall is connected to the Internet, and the VPN server is an intranet resource that is attached to the perimeter network. The VPN server has an interface on both the perimeter network and the intranet. In this scenario, the firewall must be configured with input and output filters on its Internet interface that allow tunnel maintenance traffic and tunneled data to pass to the VPN server. Additional filters can allow traffic to pass to Web, FTP, and other types of servers on the perimeter network. For an additional layer of security, the VPN server should also be configured with PPTP or L2TP/IPSec packet filters on its perimeter network interface.
VPN Server in Front of a Firewall
When the VPN server is in front of the firewall and connected to the Internet, packet filters must be added to the VPN server’s Internet interface to allow only VPN traffic to and from the IP address of that interface.
For inbound traffic, when the tunneled data is decrypted by the VPN server, it is forwarded to the firewall. Through the use of its filters, the firewall allows the traffic to be forwarded to intranet resources. Because the only traffic that crosses the VPN server is generated by authenticated VPN clients, in this scenario, firewall filtering can be used to prevent VPN users from accessing specific intranet resources. Because Internet traffic allowed on the intranet must pass through the VPN server, this approach also prevents the sharing of FTP or Web intranet resources with non-VPN Internet users.
Technologies Related to VPN
Integrating VPN with the other network infrastructure components is an important part of VPN design and implementation. VPN has to be integrated with directory, authentication, and security services, as well as with IP address assignment and name server assignment services. Without proper design, VPN clients are unable to obtain proper IP addresses and resolve intranet names, and packets cannot be forwarded between VPN clients and intranet resources.
VPN-related technologies are described in the following sections:
Name Server Assignment (DNS and WINS)
Connection Manager is a service profile that can be used to provide customized remote access to a network through a VPN connection. The advanced features of Connection Manager are a superset of basic dial-up networking. Connection Manager provides support for local and remote connections by using a network of points of presence (POPs), such as those available worldwide through ISPs. Windows Server 2003 includes a set of tools that enable a network manager to deliver pre-configured connections to network users. These tools are:
The Connection Manager Administration Kit (CMAK)
Connection Point Services (CPS)
A network administrator can tailor the appearance and behavior of a connection made with Connection Manager by using CMAK. With CMAK, an administrator can develop client dialer and connection software that allows users to connect to the network by using only the connection features that the administrator defines for them. Connection Manager supports a variety of features that both simplify and enhance implementation of connection support, most of which can be incorporated using the Connection Manager Administration Kit Wizard.
CMAK enables administrators to build profiles that customize the Connection Manager installation package so that it reflects an organization’s identity. CMAK allows administrators to determine which functions and features to include and how Connection Manager appears to end-users. Administrators can do this by using the CMAK wizard to build custom service profiles.
Connection Point Services (CPS) automatically distributes and updates custom phone books. These phone books contain one or more Point of Presence (POP) entries, with each POP supplying a telephone number that provides dial-up access to an Internet access point for VPN connections. The phone books give users complete POP information, so when they travel they can connect to different Internet POPs rather than being restricted to a single POP.
Without the ability to update phone books (a task CPS handles automatically), users would have to contact their organization’s technical support staff to be informed of changes in POP information and to reconfigure their client-dialer software. CPS has two components:
Phone Book Administrator
Phone Book Service
Phone Book Administrator
Phone Book Administrator is a tool used to create and maintain the phone book database and to publish new phone book information to the Phone Book Service.
Phone Book Service
The Phone Book Service runs on an IIS server and responds to requests from Connection Manager clients to verify the current version of subscribers’ or corporate employees’ current phone books and, if necessary, downloads a phone book update to the Connection Manager client.
For both PPTP and L2TP connections, the data being tunneled is a PPP frame. A PPP connection must be established before data can be sent. The VPN server must have IP addresses available in order to assign them to a VPN server’s virtual interface and to VPN clients during the IP Control Protocol (IPCP) negotiation phase that is part of the process of establishing a PPP connection. The IP address assigned to a VPN client is also assigned to the virtual interface of that VPN client.
For Windows Server 2003-based VPN servers, the IP addresses assigned to VPN clients are obtained through DHCP by default. A static IP address pool can also be configured. DHCP is also used by remote access VPN clients to obtain additional configuration settings after the PPP connection is established.
EAP-RADIUS is the passing of EAP messages of any EAP type by an authenticator to a Remote Authentication Dial-In User Service (RADIUS) server for authentication. For example, for a remote access server that is configured for RADIUS authentication, the EAP messages sent between the remote access client and remote access server are encapsulated and formatted as RADIUS messages between the remote access server (the authenticator) and the RADIUS server (the authenticator).
EAP-RADIUS is used in environments where RADIUS is the authentication provider. An advantage of using EAP-RADIUS is that EAP types only need to be installed at the RADIUS server, not at each remote access server. In the case of an IAS server, only EAP types need to be installed.
In a typical use of EAP-RADIUS, a server running Routing and Remote Access is configured to use EAP and to use an IAS server for authentication. When a connection is made, the remote access client negotiates the use of EAP with the remote access server. When the client sends an EAP message to the remote access server, the remote access server encapsulates the EAP message as a RADIUS message and sends it to its configured IAS server. The IAS server processes the EAP message and sends a RADIUS-encapsulated EAP message back to the remote access server. The remote access server then forwards the EAP message to the remote access client. In this configuration, the remote access server is only a pass-through device. All processing of EAP messages occurs at the remote access client and the IAS server.
Routing and Remote Access can be configured to authenticate locally or to a RADIUS server. If Routing and Remote Access is configured to authenticate locally, all EAP methods will be authenticated locally. If Routing and Remote Access is configured to authenticate to a RADIUS server, then all EAP messages will be forwarded to the RADIUS server with EAP-RADIUS.
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, and the connection attempt is authorized using local remote access policies.
If RADIUS is selected and configured as the authentication provider on the VPN server, user credentials and parameters of the connection request are sent as RADIUS request messages to a RADIUS server.
The RADIUS server receives a user-connection request from the VPN server and authenticates and authorizes the connection attempt. In addition to a yes or no response to an authentication request, RADIUS can inform the VPN server of other applicable connection parameters for this user such as maximum session time, static IP address assignment, and so on.
RADIUS can respond to authentication requests based on its own user account database, or it can be a front end to another database server, such as a Structured Query Language (SQL) server or a Windows domain controller (DC). The DC can be located on the same computer as the RADIUS server, or elsewhere. In addition, a RADIUS proxy can be used to forward requests to a remote RADIUS server.
IAS is the Windows implementation of a RADIUS server and proxy.
Name Server Assignment (DNS and WINS)
Name server assignment, the assignment of Domain Name System (DNS) and Windows Internet Name Service (WINS) servers, occurs during the process of establishing a VPN connection. 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.
The VPN server must be configured with DNS and WINS server addresses to assign to the VPN client during IPCP negotiation. For NetBIOS name resolution, you do not have to use WINS and can enable the NetBIOS over TCP/IP (NetBT) proxy on the VPN server.
A network address translator (NAT) translates the IP addresses and Transmission Control Protocol/User Datagram Protocol (TCP/UDP) port numbers of packets that are forwarded between a private network and the Internet. The NAT on the private network can also provide IP address configuration information to the other computers on the private network.
PPTP-based VPN clients can be located behind a NAT if the NAT includes an editor that can translate PPTP packets. PPTP-based VPN servers can be located behind a NAT if the NAT is configured with static mappings for PPTP traffic. If the L2TP/IPSec-based VPN clients or servers are positioned behind a NAT, both client and server must support IPSec NAT traversal (NAT-T).
The following resources contain additional information that is relevant to this section.