NPS and Tunneling

Applies To: Windows Server 2008, Windows Server 2008 R2

The entire process of packet encapsulation, transmission, and de-encapsulation is called tunneling. More specifically, tunneling is a method of using an internetwork infrastructure of one protocol to transfer a payload. Sometimes, the payload consists of the frames (or packets) of another protocol. Instead of being sent as the originating host produces it, the frame is encapsulated with an additional header. The additional header provides routing information so that the encapsulated payload can traverse an intermediate internetwork (also known as a transit internetwork). The encapsulated packets are then routed between tunnel endpoints over the transit internetwork. After the encapsulated payload packets reach their destination on the transit internetwork, the frame is de-encapsulated and forwarded to its final destination.

The logical path in the transit internetwork through which the encapsulated packets travel is called a tunnel.

With remote access virtual private network (VPN) connections, there are two types of tunneling: Voluntary and compulsory.

Voluntary tunneling

When a client computer is configured with the appropriate tunneling protocol, the user or client computer can issue a VPN request to create and configure a voluntary tunnel from the client computer to the VPN server. In this case, the user’s computer is a tunnel endpoint that acts as the tunnel client, and the VPN server is the tunnel server.

A simple example of voluntary tunneling occurs when a user with a dial-up connection to the Internet through an Internet service provider (ISP) connects to an organization VPN server that is also connected to the Internet. In this scenario, the user has two separate accounts, each account having its own set of credentials:

• A set of credentials for an account with an ISP

• A set of credentials for an account with the organization

To connect to the organization VPN server, the client computer uses a dial-up modem to attempt to connect to the ISP dial-up server. The user supplies his ISP account credentials, is authenticated by the ISP Remote Authentication Dial-IN User Service (RADIUS) server against the ISP user accounts database, and is authorized by the ISP RADIUS server to connect to the ISP and the Internet.

After the dial-up connection is established and the client computer is on the Internet, the user initiates a VPN connection to his organization VPN server. The VPN server is configured as a RADIUS client to an NPS server at the organization. The user supplies organization account credentials for the connection attempt, and the organization NPS server uses the credentials to authenticate and authorize the user against an Active Directory Domain Services (AD DS) user accounts database. After the user is authenticated and authorized, the VPN tunnel is established and the user can access organization resources.

In another example, NPS is used in an outsourced bulk-dial scenario for voluntary tunneling. In the outsourced bulk dial scenario, an ISP is providing both dial-up and non-dedicated broadband digital subscriber line (DSL) Internet access for all the employees of an organization. Rather than providing the ISP with a copy of its user accounts database, the organization and the ISP use a server running NPS as a RADIUS proxy so that users, when connecting to the ISP, can be authenticated and authorized using the organization RADIUS servers and AD DS user accounts database on the organization network. This provides strong security and prevents exposure of sensitive information contained in the user accounts database to the ISP and its employees.

When the organization employee attempts to connect to the organization VPN server, the following process occurs:

1. The client computer establishes the dial-up or DSL connection to the ISP network access server (NAS).

2. Based on the connection parameters, the NAS sends an Access-Request message to an NPS server that is configured as a RADIUS proxy.

3. The RADIUS proxy processes the Access-Request message and determines where to send it based on the realm portion of the User-Name attribute. The RADIUS proxy forwards the Access-Request message to the organization NPS server, which is accessible on the Internet through a firewall configured to allow traffic on the default RADIUS UDP ports of 1812 (authentication) and 1813 (accounting).

4. The organization NPS server authenticates and authorizes the connection attempt of the client computer and sends an Access-Accept message back to the RADIUS proxy.

5. The RADIUS proxy forwards the Access-Accept message to the ISP NAS, and then the ISP NAS connects the client computer to the Internet.

6. After it is on the Internet, the client computer initiates a VPN tunnel connection with the organization VPN tunnel server on the Internet.

7. Based on the tunnel connection parameters, the tunnel server sends an Access-Request message to the organization NPS server.

8. The organization NPS server authenticates and authorizes the connection attempt of the tunnel client and sends an Access-Accept message back to the tunnel server.

9. The tunnel server completes the tunnel creation, and then the tunnel client can send packets to the organization intranet through the tunnel across the Internet.

The following figure illustrates the establishment of a voluntary VPN tunnel by a dial-up client.

Voluntary tunneling is not different from other types of network access, and NPS can be used for authentication, authorization, and accounting when the tunnel server is configured as a RADIUS client to the NPS server.

Compulsory tunneling

Compulsory tunneling is the creation of a secure tunnel by another computer or network device on behalf of the client computer. Compulsory tunnels are configured and created automatically for the user without their knowledge or intervention. With a compulsory tunnel, the user’s computer is not a tunnel endpoint. Another device between the user’s computer and the tunnel server — the dial-up access server dialed by the client — is the tunnel endpoint, acting as the tunnel client.

A number of vendors that sell dial-up access servers have implemented the ability to create a tunnel on behalf of a dial-up client. The computer or network device providing the tunnel for the client computer is known as a Front End Processor (FEP) in PPTP, an Access Concentrator in Layer Two Tunneling Protocol (L2TP), or an IP Security Gateway in Internet Protocol security (IPsec).

In this section, “How NPS Works,” the acronym FEP describes this functionality, regardless of the tunneling protocol. To carry out its function, the FEP must have the appropriate tunneling protocol installed and must be capable of establishing the tunnel when the client computer attempts a connection.

An organization can contract with an ISP to deploy a nationwide set of FEPs. These FEPs can establish tunnels across the Internet to a tunnel server connected to the private network of the organization, thereby consolidating calls from geographically diverse locations into a single Internet connection at the organization network.

The following figure shows the outsourced bulk-dial scenario for compulsory tunneling.

In the outsourced bulk-dial scenario for compulsory tunneling, a dial-up client establishes a dial-up connection to an ISP that is providing tunneled access across the Internet for all the employees of an organization. Based on the dial-up connection parameters, the ISP NAS sends an Access-Request message to an NPS server. The ISP NPS server authorizes, but does not authenticate, the tunnel connection. The ISP NPS server sends an Access-Accept message to the ISP NAS with a series of VPN tunnel attributes. The ISP NAS then acts as a tunnel client and creates a VPN tunnel to the VPN server of the organization that faces the Internet.

The ISP NAS then sends a PPP message to the dial-up client to restart the authentication process so that the dial-up user can be authenticated by the organization NPS server through the tunnel. The dial-up client sends the authentication information to the ISP NAS, which encapsulates the user account credentials and sends them through the tunnel to the organization tunnel server.

After the user account credentials are received by the tunnel server, the tunnel server sends an Access-Request message to the organization NPS server. The organization NPS server authenticates and authorizes the connection of the dial-up client to the tunnel server and sends an Access-Accept message to the tunnel server. The tunnel server then completes the connection to the dial-up client.

All data that is sent by the dial-up client is automatically sent through the tunnel to the tunnel server by the ISP NAS.

This configuration is known as compulsory tunneling because the client is compelled to use the tunnel created by the FEP. After the initial connection is made, all network traffic to and from the client is automatically sent through the tunnel.

In addition, you can configure NPS to instruct an FEP to tunnel different remote access clients to different tunnel servers.

Unlike the separate tunnels created for each voluntary client, a compulsory tunnel between the FEP and organization VPN server can be shared by multiple dial-up clients. When a second client dials into the same access server (the FEP) to reach a destination for which a tunnel already exists, the data traffic for the new client is carried over the existing VPN tunnel.

The following RADIUS attributes are used to carry the tunneling information from the NPS server to the NAS.

Used in authorization only:

• Tunnel-Assignment-ID

• Tunnel-Client-Auth-ID

• Tunnel-Password

• Tunnel-Preference

• Tunnel-Pvt-Group-ID

• Tunnel-Server-Auth-ID

Used in authorization and accounting:

• Tunnel-Client-Endpt

• Tunnel-Medium-Type (X.25, ATM, Frame Relay, IP, and so on)

• Tunnel-Server-Endpt

• Tunnel-Type (such as PPTP and L2TP)

Used for accounting only:

• Acct-Tunnel-Connection

The Windows Server 2003 or Windows 2000 Routing and Remote Access service cannot be used as a FEP for compulsory tunneling.