共用方式為

Chapter 14 - Virtual Private Networking

  • 發行項

Published: December 27, 2005 | Updated: January 03, 2006

Writer: Joe Davies

Abstract

This chapter describes the virtual private network (VPN) technologies included with Microsoft® Windows® XP and Windows Server™ 2003 operating systems to connect remote users to an intranet or to connect remote offices to each other. As a network administrator, you must understand how to configure and use VPN connections so that you can leverage the global connectivity of the Internet to provide ubiquitous, yet relatively secure, connectivity.

For a download of the entire "TCP/IP Fundamentals for Microsoft Windows" online book, which contains a version of this chapter that has been updated for Windows Vista and Windows Server 2008, click here.

On This Page

Chapter Objectives
Virtual Private Networking Overview
VPN Protocols
Remote Access VPN Connections
Site-to-Site VPN Connections
Using RADIUS for Network Access Authentication
Chapter Summary
Chapter Glossary

Chapter Objectives

After completing this chapter, you will be able to:

  • Define a virtual private network (VPN) in terms of its benefits, components, and attributes.

  • Describe the two types of VPN connections and how routing works for each.

  • Explain the roles of the different VPN protocols, including Point-to-Point Protocol (PPP), Point-to-Point Tunneling Protocol (PPTP), and Layer Two Tunneling Protocol with Internet Protocol security (L2TP/IPsec).

  • Describe the process for creating a PPP connection, a PPTP connection, and an L2TP/IPsec connection.

  • Configure remote access and site-to-site VPN connections.

  • Use Remote Authentication Dial-in User Service (RADIUS) for VPN connections and use Internet Authentication Service (IAS) as a RADIUS server and proxy.

Virtual Private Networking Overview

A VPN extends a private network to encompass links across shared or public networks like the Internet. By using a VPN, you can 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, creating, and using a VPN 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 that allows packets to traverse a shared or public internetwork. To emulate a private link, the data being sent is encrypted for confidentiality. Anyone who intercepts packets on the shared or public network cannot decipher them without the encryption keys. The logical link over which private data is encrypted is known as a VPN connection.

By using VPN connections, users working at home or on the road can connect to an organization server from a remote location using the infrastructure that a public internetwork, such as the Internet. From the user's perspective, the VPN is a logical point-to-point connection between a computer (the VPN client) and an organization server (the VPN server).

Organizations that use VPN connections can create routed site-to-site connections with geographically separate offices or with other organizations over a public internetwork while maintaining relatively secure communication. A routed VPN connection across the Internet logically operates as a dedicated wide area network (WAN) link.

For both remote access and routed connections, organizations that configure, create, and use VPN connections can replace long distance dial-up or leased lines with local dial-up or leased lines to an Internet service provider (ISP).

Components of a VPN

A Windows-based VPN includes the following components:

  • VPN server

    A computer that accepts remote access or site-to-site connections from VPN clients.

  • VPN client

    A computer that initiates a connection to a VPN server. A VPN client can be an individual computer that initiates a VPN connection from a remote location (called a remote access VPN connection) or a router that initiates a site-to-site VPN connection. Computers running Windows XP and Windows Server 2003 can create remote access VPN connections to a server running Windows Server 2003 or Windows XP. A computer running Windows Server 2003 can create site-to-site connections to a server running Windows Server 2003. Clients from companies other than Microsoft can also create remote access or site-to-site connections to VPN servers running Windows Server 2003 as long as the clients support PPTP or L2TP/IPsec.

  • Tunnel

    The portion of the connection in which data is encapsulated.

  • VPN connection

    The portion of the connection in which data is encrypted. You can send data through a tunnel without encryption, but this configuration is not a VPN connection because you would send private data across a shared or public network in an unencrypted and easily readable form.

    In most cases, the tunnel and the VPN connection are defined between the same two endpoints: the VPN client and the VPN server. However, there are configurations known as compulsory tunnels in which the tunnel is defined between a dial-up service provider's tunnel server and the VPN server and the VPN connection is defined between the client and the server.

  • Tunneling protocols

    Communication standards for managing tunnels and encapsulating private data. Windows Server 2003 and Windows XP include the PPTP and L2TP tunneling protocols. For detailed information about these protocols, see "Point-to-Point Tunneling Protocol (PPTP)" and "Layer Two Tunneling Protocol with Internet Protocol Security (L2TP/IPsec)" later in this chapter.

  • Tunneled data

    Data that is sent through a VPN tunnel.

  • Transit internetwork

    A shared or public internetwork crossed by encapsulated data. For Windows Server 2003 and Windows XP, the transit internetwork is always an IPv4 internetwork, either the Internet or a private intranet.

Figure 14-1 shows the components of a VPN connection based on Windows XP or Windows Server 2003.

Bb727019.ch14xx01(en-us,TechNet.10).gif

Figure 14-1 Components of a Windows-based VPN

Attributes of a VPN Connection

Windows-based VPNs have the following attributes:

  • User authentication

  • Encapsulation

  • Encryption

User Authentication

Before the VPN connection is established, the VPN server authenticates the security credentials of the user that is using the VPN client computer. If mutual authentication is being used, the VPN client also either authenticates the security credentials of the VPN server or verifies that the VPN server has access to the user credentials of the VPN client. Mutual authentication provides protection against masquerading VPN servers.

Encapsulation

VPN technology encapsulates private data with additional headers that allow it to traverse the transit internetwork.

Encryption

To ensure confidentiality of the data as it traverses the shared or public transit internetwork, the sender encrypts the data, and the receiver decrypts it. Encryption and decryption depend on both the sender and the receiver determining a shared encryption key.

Anyone who intercepts packets sent along the VPN connection in the transit internetwork must have the encryption key to decipher them. 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 longer. Therefore, you should use the largest possible key size.

In addition, the more information that you encrypt with the same key, the easier it is to decipher the encrypted data. With some encryption technologies, you can configure how often the encryption keys are changed during a connection.

For VPN connections that are based on PPTP, Windows supports Microsoft Point-to-Point Encryption (MPPE) with 40-bit, 56-bit, or 128-bit encryption keys. For VPN connections that are based on L2TP/IPsec, Windows supports Data Encryption Standard (DES) with a 56-bit key or Triple-DES with three 56-bit keys.

Types of VPN Connections

Windows-based VPNs support both remote access and site-to-site VPN connections.

Remote Access

A remote access VPN connection is made by a remote access VPN client (a single computer) when connecting to a private network. The VPN server provides access not only to the resources of the server but also to the entire network to which the server is attached. The packets sent across the VPN connection originate at the remote access client.

The remote access VPN client authenticates itself to the remote access VPN server, and, for mutual authentication, the server authenticates itself to the client or provides proof that it has access to the client's credentials.

When a remote access VPN client connects to the Internet, the client is configured with a default route that points to the Internet. This default route makes all the destinations of the Internet reachable. For permanent connections to the Internet (such as those using a Digital Subscriber Line [DSL] or a cable modem), the default route is automatically added to the IPv4 routing table when the Internet connection is configured with a default gateway IPv4 address (either statically or dynamically). For dial-up connections to the Internet, a default route is automatically added to the IPv4 routing table when the connection is made.

When the remote access VPN connection is made, a new default route is added to the routing table and the existing default route has its routing metric increased. Now all default route traffic is sent over the VPN connection to the private intranet, rather than to the Internet. When the VPN connection is terminated, the newly created default route is removed and the original default route's routing metric is returned to its previous value.

This behavior produces the following results:

  • Before the VPN connection is made, all the locations on the Internet are reachable, but intranet locations are not.

  • After the VPN connection is made, all the locations on the intranet are reachable, but Internet locations are not (with the exception of the VPN server on the Internet).

You can control the automatic creation of the new default route by opening the properties of the Internet Protocol (TCP/IP) component of a dial-up or VPN connection, clicking Advanced, and selecting or clearing the Use default gateway on remote network check box on the General tab, as Figure 14-2 shows.

Figure 14-2 The Advanced TCP/IP Settings dialog box for a VPN connection

Figure 14-2 The Advanced TCP/IP Settings dialog box for a VPN connection

VPN client users typically engage in either intranet or Internet communication, not both simultaneously. These users do not have a problem with mutually exclusive access to either Internet locations or to intranet locations. However, in some cases, users need simultaneous access to intranet and Internet resources.

If your VPN users need simultaneous access to intranet and Internet resources when the VPN connection is active, you can do one of the following:

  • Select the Use default gateway on remote network check box (the default setting), and allow Internet access through the organization intranet. Internet traffic between the VPN client and Internet hosts passes though firewalls or proxy servers as if the VPN client were physically connected to the organization intranet. Although performance may be decreased, this method allows you to filter and monitor Internet access according to your organization's network policies while the VPN client is connected to the organization network.

  • When the VPN server assigns an IPv4 address to the VPN client, ensure that the subnet mask is set to the same class-based subnet mask of the Internet address class of the IPv4 address. If the addressing within your intranet is based on a single class-based address prefix, clear the Use default gateway on remote network check box. The best example is when your intranet is using the private IPv4 address prefix of 10.0.0.0/8.

  • If the addressing within your intranet is not based on a single class-based address prefix, you can use one of the following solutions:

    • The DHCPInform message sent by VPN clients running Windows XP or Windows Server 2003 includes a request for the Classless Static Routes DHCP option. On your DHCP server running Windows Server 2003, configure the Classless Static Routes DHCP option for the appropriate scope to contain a set of routes that represent the address space of your intranet. These routes are automatically added to the routing table of the requesting VPN client.

    • By using the Connection Manager Administration Kit (CMAK) for Windows Server 2003, you can configure specific routes as part of the Connection Manager profile that you distribute to VPN users. You can also specify a Uniform Resource Locator (URL) that contains the current set of organization intranet routes or additional routes beyond those that you configure in the profile.

Site-to-Site

A site-to-site VPN connection (also known as 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 server is attached. On a site-to-site VPN connection, the packets that either router sends across the VPN connection typically do not typically 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 or provides proof that it has access to the calling router's credentials.

Site-to-site VPN connections can be initiated by only one router (a one-way initiated VPN connection) or by either router (a two-way initiated VPN connection). One-way initiated connections are well suited to a spoke-and-hub topology in which only the branch office router can initiate the connection. Site-to-site VPN connections can be permanent (always connected) or on-demand (a router makes a connection when it has traffic to send and disconnects after a configured idle timeout).

To support site-to-site connections, Routing and Remote Access in Windows Server 2003 allows you to create demand-dial interfaces. A demand-dial interface is a logical interface that represents the point-to-point connection between the two routers. You can use a demand-dial interface in the same way as a physical interface. For example, you can assign routes and configure packet filters on demand-dial interfaces.

Routing for site-to-site connections consists of a set of routes in the routing table of both the calling router and the answering router. These routes summarize the addresses that are available across the site-to-site connection. Each separate route specifies:

  • An address prefix (the combination of the destination and a subnet mask)

  • The routing metric

  • A demand-dial interface

If each router in a site-to-site connection has the set of routes that represent the addresses available across the site-to-site connection, all of the locations on the intranet consisting of multiple sites are reachable from each site.

VPN Protocols

Computers running Windows XP or Windows Server 2003 use the following protocols to create VPN connections:

  • Point-to-Point Protocol (PPP)

  • PPTP

  • L2TP/IPsec

Point-to-Point Protocol (PPP)

PPTP and L2TP depend heavily on the features specified for PPP, which was designed to send data across dial-up or dedicated point-to-point connections. For IPv4, PPP encapsulates IPv4 packets within PPP frames and then transmits the packets across a point-to-point link. PPP was originally defined as the protocol to use between dial-up clients and remote access servers.

The four phases of negotiation in a PPP connection are the following:

  • Phase 1: PPP Link Establishment

  • Phase 2: User Authentication

  • Phase 3: PPP Callback Control

  • Phase 4: Invoking Network Layer Protocol(s)

Each of these four phases must complete successfully before the PPP connection can transfer user data.

Note Neither Windows Server 2003 nor Windows XP supports IPv6 traffic over PPP links, so you cannot send native IPv6 traffic across a dial-up or VPN connection from a computer running one of these operating systems. You can, however, send tunneled IPv6 traffic that is encapsulated with an IPv4 header. For more information about IPv6 tunneling, see Chapter 15 "IPv6 Transition Technologies."

PPP uses the Link Control Protocol (LCP) to establish, maintain, and terminate the logical point-to-point connection. During Phase 1, basic communication options are selected. For example, authentication protocols are selected, but they are not used for authentication until the connection authentication phase (Phase 2). Similarly, during Phase 1, the two peers negotiate the use of compression or encryption. The actual choice of compression and encryption algorithms and other details occurs during Phase 4.

Phase 2: User Authentication

In Phase 2, the client computer sends the user’s credentials to the remote access server. An authentication scheme should provide protection against replay attacks and remote client impersonation. A replay attack occurs when an attacker monitors a successful connection and uses captured packets to play back the remote client’s response so that the attacker can gain an authenticated connection. Remote client impersonation occurs when an attacker takes over an authenticated connection.

Windows Server 2003 and Windows XP support the following PPP authentication protocols:

  • Password Authentication Protocol (PAP)

    PAP is a plaintext password authentication mechanism that provides no protection from an attacker that captures a PAP authentication exchange.

  • Challenge-Handshake Authentication Protocol (CHAP)

    CHAP is an encrypted password authentication mechanism that avoids transmitting the password on the connection.

  • Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP)

    MS-CHAP is an encrypted password authentication mechanism similar to CHAP, but MS-CHAP is more secure.

  • MS-CHAP version 2 (MS-CHAP v2)

    MS-CHAP v2 is an enhanced version of MS-CHAP that provides stronger protection for the exchange of user name and password credentials, determination of encryption keys, and mutual authentication.

  • Extensible Authentication Protocol (EAP)

    EAP is a PPP authentication infrastructure that allows authentication mechanisms to be installed on PPP clients and servers. During the authentication phase, EAP does not authenticate users. Phase 2 for EAP only negotiates the use of a common EAP authentication mechanism known as an EAP type. The actual authentication for the negotiated EAP type is performed during Phase 4.

During Phase 2 of PPP link configuration, the VPN server running Windows Server 2003 collects the authentication credentials and then validates them against one of the following:

  • The VPN server's own user accounts database (if the VPN server is not a member of a domain)

  • A domain controller for the Active Directory® directory service (if the VPN server is a member of a domain)

  • A Remote Authentication Dial-in User Service (RADIUS) server

A VPN server running Windows XP validates authentication credentials against the local user account database.

VPN connections that are based on PPTP require the use of MS-CHAP, MS-CHAP v2, or the EAP-Transport Layer Security (TLS) authentication protocol. These authentication methods generate encryption key material that is used to encrypt the data sent over the PPTP-based VPN connection. L2TP/IPsec connections can use any of the authentication protocols because the authentication protocol exchange is encrypted with IPsec. However, the use of MS-CHAP v2 or EAP-TLS is recommended because they are the most secure user authentication protocols and they provide mutual authentication.

Phase 3: PPP Callback Control

The Windows implementation of PPP includes an optional callback control phase. This phase uses the Callback Control Protocol (CBCP) immediately after the authentication phase. If configured for callback, both the remote client and remote access server disconnect after authentication. The remote access server then calls the remote client back at a specified phone number. This behavior makes dial-up connections more secure because the remote access server allows connections only from remote clients that are using specific phone numbers. Callback is used only for dial-up connections, not for VPN connections.

Phase 4: Invoking Network Layer Protocol(s)

When the first three phases have been completed, PPP invokes the various network control protocols (NCPs) that were selected during the link establishment phase (Phase 1) to configure protocols used by the remote client. For example, during this phase, the Internet Protocol Control Protocol (IPCP) assigns an IPv4 address to the PPP client. In the Windows implementation of PPP, the Compression Control Protocol (CCP) is used to negotiate both data compression, known as Microsoft Point-to-Point Compression (MPPC), and data encryption with MPPE.

Data-Transfer Phase

When the four phases of PPP negotiation have been completed, PPP begins to forward packets containing data between the PPP client and the server. Each transmitted data packet is wrapped in a PPP header that is removed by the receiver. If data compression was selected in Phase 1 and negotiated in Phase 4, the sender compresses the data before transmitting it. If data encryption is negotiated, the sender encrypts the data before transmitting it. If both encryption and compression are negotiated, the sender compresses the data before encrypting and transmitting it.

Point-to-Point Tunneling Protocol (PPTP)

Request for Comments (RFC) 2637 defines PPTP, which encapsulates PPP frames in IPv4 packets for transmission over an IPv4 internetwork, such as the Internet. PPTP can be used for remote access and site-to-site VPN connections.

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. Figure 14-3 shows the structure of a PPTP packet that contains an IPv4 packet.

Bb727019.ch14xx03(en-us,TechNet.10).gif

Figure 14-3 Structure of a PPTP packet that contains an IPv4 packet

Layer Two Tunneling Protocol with IPsec (L2TP/IPsec)

RFC 2661 defines L2TP, which encapsulates PPP frames to be sent over IPv4, X.25, Frame Relay, or Asynchronous Transfer Mode (ATM) networks. If you configure L2TP for IPv4 networks, you can use it as a tunneling protocol over the Internet.

L2TP over IPv4 internetworks uses a User Datagram Protocol (UDP) header and a series of L2TP messages for tunnel management. L2TP also uses UDP to send L2TP-encapsulated PPP frames as the tunneled data. The payloads of encapsulated PPP frames can be encrypted, compressed, or both, although the Windows implementation of L2TP does not use MPPE to encrypt the PPP payload. Figure 14-4 shows the structure of an L2TP packet that contains an IPv4 packet.

Bb727019.ch14xx04(en-us,TechNet.10).gif

Figure 14-4 Structure of an L2TP packet that contains an IPv4 packet

The Windows implementation of L2TP uses IPsec with Encapsulating Security Payload (ESP) to encrypt L2TP traffic. The combination of L2TP (the tunneling protocol) and IPsec (the method of encryption) is known as L2TP/IPsec, as RFC 3193 describes. For more information about ESP, see Chapter 13, "Internet Protocol Security and Packet Filtering."

Figure 14-5 shows the result after ESP is applied to an IPv4 packet that contains an L2TP frame.

Bb727019.ch14xx05(en-us,TechNet.10).gif

Figure 14-5 Encryption of L2TP traffic using IPsec with ESP

Remote Access VPN Connections

Both Windows Server 2003 and Windows XP include a remote access VPN client and a remote access VPN server.

VPN Client Support

Windows XP and Windows Server 2003 include a built-in VPN client that supports PPTP and L2TP/IPsec. You can configure a remote access VPN connection by using either the Network Connections folder or Connection Manager.

Network Connections Folder

If you have a small number of VPN clients, you can manually configure a VPN connection for each client. For clients running Windows XP or Windows Server 2003, use the New Connection Wizard in the Network Connections folder to create the VPN connection. Within the New Connection Wizard, click Connect to the network at my workplace on the Network Connection Type page and click Virtual Private Network connection on the Network Connection page.

Connection Manager

If you try to manually configure remote access VPN connections for thousands of clients in an enterprise organization, you will probably experience one or more of the following problems:

  • The exact procedure to configure a VPN connection varies depending on the version of Windows running on the client computer, so training end users to configure these connections will require multiple sets of training materials.

  • To prevent configuration errors, the information technology (IT) staff should manually configure the VPN connection rather than end users, placing a large administrative burden on the IT staff.

  • A VPN connection may need a double-dial configuration, in which a user must connect to the Internet before connecting to the organization intranet. This requirement makes training end users even more complicated.

To configure VPN connections for an enterprise organization, you can use the following components:

  • Connection Manager

  • Connection Manager Administration Kit

  • Connection Point Services

Connection Manager is a client dialer with advanced features that offer a superset of basic dial-up and VPN networking. Windows Server 2003 includes a set of tools that you can use deliver pre-configured connections to network users. These tools are the Connection Manager Administration Kit (CMAK) and Connection Point Services (CPS).

You can use CMAK to tailor the appearance and behavior of a connection made with Connection Manager. With CMAK, you can develop client dialer and connection software that allows users to connect to the network by using only the connection features that you define for them. Connection Manager supports a variety of features that both simplify and enhance the deployment of connection support for you and your users, and you can incorporate most of those features using the Connection Manager Administration Kit Wizard. By using CMAK, you can create custom profiles that reflect the identity, online help, and support infrastructure of your organization.

By using Connection Point Services (CPS), you can automatically create, distribute, and update custom phone books. These phone books contain one or more Point of Presence (POP) entries, with each POP entry storing a telephone number that provides dial-up access to a local ISP. Phone books give users complete POP information so that, when they travel, they can connect to different Internet access points 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 for changes in POP information and to reconfigure their client dialer software.

CPS has two components:

  1. Phone Book Administrator

    A tool used to create and maintain the phone book database and to publish new phone book information to Phone Book Service.

  2. Phone Book Service

    An Internet Information Services (IIS) extension that automatically checks subscribers' or corporate employees' current phone books and, if necessary, downloads a phone book update.

VPN Server Support

Using Routing and Remote Access in Windows Server 2003, you can configure a VPN server that supports PPTP and L2TP/IPsec. To configure a computer running Windows Server 2003 to act as a VPN server, do the following:

  1. Configure your server with a static IPv4 address on each of its intranet interfaces.

  2. Click Start, point to Programs, point to Administrative Tools, and then click Routing And Remote Access.

  3. Right-click your server name, and then click Configure and enable Routing And Remote Access. Click Next.

  4. On the Configuration page, click Remote Access (dial-up or VPN), and then click Next.

  5. On the Remote Access page, click VPN, and then click Next.

  6. On the VPN Connection page, click the connection that corresponds to the interface connected to the Internet or your perimeter network, and then click Next.

  7. On the IP Address Assignment page, click Automatically if the VPN server should use DHCP to obtain IPv4 addresses for remote access VPN clients. Or, click From a specified range of addresses to use one or more static ranges of addresses. When IP address assignment is complete, click Next.

  8. On the Managing Multiple Remote Access Servers page, if you are using RADIUS for authentication and authorization, click Yes, set up this server to work with a RADIUS server, and then click Next.

    • On the RADIUS Server Selection page, configure the primary (mandatory) and alternate (optional) RADIUS servers and the shared secret, and then click Next.

  9. Click Finish.

  10. When you are prompted to configure the DHCP Relay Agent, click OK.

  11. In the tree of Routing and Remote Access, open IP Routing.

  12. Right-click DHCP Relay Agent, and click Properties.

  13. On the General tab of the DHCP Relay Agent Properties dialog box, add the IPv4 addresses that correspond to your intranet DHCP servers, and click OK.

By default, Routing and Remote Access creates 128 PPTP and 128 L2TP/IPsec logical ports. If you need more ports, configure the WAN Miniport (PPTP) or WAN Miniport (L2TP) devices from the properties of the Ports object in the tree of Routing and Remote Access.

By default, the Routing and Remote Access Server Setup Wizard enables the MS-CHAP, MS-CHAP v2, and EAP authentication protocols.

VPN Server Support in Windows XP

You can configure a computer running Windows XP as a remote access VPN server by running the Create a New Connection Wizard in the Network Connections folder. On the Network Connection Type page of the wizard, click Set up an advanced connection. On the Advanced Connection Options page, click Accept incoming connections. These options will cause the computer running Windows XP to act as a VPN server. However, the server will support only a single remote access connection (dial-up, PPTP, or L2TP/IPsec-based).

IP Address Assignment and Routing and Remote Access

The VPN server obtains the IPv4 addresses that it assigns to VPN clients from either a DHCP server or a static pool of IPv4 addresses. The type of address that Routing and Remote Access can assign to a VPN client can be either an on-subnet address or an off-subnet address. The type of address that you use can affect reachability, unless you make additional changes to the routing infrastructure.

The IPv4 addresses assigned to VPN clients can be from an:

  • On-subnet address range

    An address range of an intranet subnet to which the VPN server is attached. The VPN server is using an on-subnet address range when it obtains IPv4 addresses for VPN clients from a DHCP server or when the manually configured static pool contains IPv4 addresses that are within the range of addresses of an attached subnet.

    The advantage to using on-subnet addresses is that they require no changes to routing infrastructure.

  • Off-subnet address range

    An address range that represents a different subnet that is logically attached to the VPN server. The VPN server is using an off-subnet address range when the static pool contains IPv4 addresses that are located on a separate subnet.

    The advantage to using off-subnet addresses is that the IPv4 addresses of remote access clients are more easily identified when they are connecting and communicating with resources on the intranet. However, you must change the routing infrastructure so that the clients are reachable from the intranet.

Obtaining IPv4 Addresses via DHCP

When configured to obtain IPv4 addresses from a DHCP server, Routing and Remote Access obtains 10 IPv4 addresses at a time. Routing and Remote Access attempts to obtain the first set of addresses when the first remote access client connects, rather than when the Routing and Remote Access service starts. Routing and Remote Access uses the first IPv4 address and allocates subsequent addresses to clients as they connect. When clients disconnect, Routing and Remote Access can reassign their IPv4 addresses to other clients. When all 10 of the initial set of addresses are being concurrently used and another remote access client attempts a connection, Routing and Remote Access obtains 10 more addresses.

If the DHCP Client service cannot contact a DHCP server, the service returns addresses from the Automatic Private IP Addressing (APIPA) range of 169.254.0.0/16 (from 169.254.0.1 through 169.254.255.254). APIPA addresses are off-subnet addresses that, by default, have no corresponding route in the intranet routing infrastructure. Remote access clients that are assigned an APIPA address cannot communicate beyond the remote access server.

Routing and Remote Access attempts to obtain DHCP-allocated addresses using the interface that you specify by opening the properties of the server running Routing and Remote Access, clicking the IP tab, and clicking the name of the interface in Adapter, as Figure 14-6 shows.

Figure 14-6 The IP tab for the properties of the server running Routing and Remote Access

Figure 14-6 The IP tab for the properties of the server running Routing and Remote Access

You can also specify this adapter on the Network Selection page of the Routing and Remote Access Server Setup Wizard (if you have more than one intranet interface). If you specify the wrong adapter, attempts to contact the DHCP server using that adapter could fail and return APIPA addresses. If you specify Allow RAS to select adapter in Adapter, Routing and Remote Access randomly picks a LAN interface to use at startup, which could also result in the use of the wrong adapter.

When the Routing and Remote Access service is stopped, it sends DHCPRelease messages to release all of the IPv4 addresses obtained through DHCP.

Obtaining IPv4 Addresses from a Static Address Pool

A static address pool comprises one or more ranges of manually configured IPv4 addresses. When you configure a static IPv4 address pool, the VPN server uses the first address in the first range. The server allocates subsequent addresses to TCP/IP-based remote access clients as they connect. When the clients disconnect, the server can reassign those addresses to other clients.

An address range in the static IPv4 address pool can be an on-subnet range, an off-subnet range, or a mixture of on-subnet and off-subnet addresses.

If any of the addresses in any of the address ranges are off-subnet, you must add the route or routes that summarize those addresses to the intranet routing infrastructure. This step helps ensure that traffic destined to remote access clients is forwarded to the VPN server, which forwards the traffic to the appropriate client. To provide the best summarization of address ranges for routes, you should choose address ranges that you can express using a single address prefix. For example, the address range 192.168.2.1 through 192.168.2.254 can be expressed as 192.168.2.0 with the subnet mask 255.255.255.0 (192.168.2.0/24).

The Process for Setting Up a Remote Access VPN Connection

The creation of a remote access VPN connection occurs in the following three steps:

  1. Logical link setup

    Creates the point-to-point link between the client and the server for the purposes of sending PPP frames. The logical link used for VPN connections is the VPN tunnel that represents a logical point-to-point link. If the client is running Windows XP or Windows Server 2003, the message that appears during the logical link setup is "Connecting."

  2. PPP connection setup

    Uses PPP protocols to negotiate the parameters of the PPP link, authenticate the credentials of the remote access user, and negotiate the use of and the parameters for the protocols that will operate over the PPP link. If the client is running Windows XP or Windows Server 2003, the message that appears during the PPP connection setup is "Verifying user name and password."

  3. Remote access VPN client registration

    The client obtains additional configuration parameters and registers itself in the Domain Name System (DNS) and the Windows Internet Name Service (WINS) for name resolution. If the client is running Windows XP or Windows Server 2003, the message that appears during the remote access client registration is "Registering your computer on the network."

The process for the logical link setup depends on whether the VPN connection is using PPTP or L2TP/IPsec.

PPTP-based connections are established in the following two phases:

  • Phase 1

    The client initiates a TCP connection from a dynamically allocated TCP port to TCP port 1723 on the remote access VPN server.

  • Phase 2

    The remote access VPN client and the server exchange a series of PPTP messages to negotiate the use of a PPTP tunnel and a specific call identifier (ID) for the connection, which is used in the PPTP GRE header.

L2TP/IPSec-based connections are established in the following two phases:

  • Phase 1

    The IPsec security associations (SAs) needed to protect IPsec-based communications and data are negotiated and created. IPsec uses the Internet Key Exchange (IKE) protocol to negotiate the IKE main mode and quick mode SAs. The main mode SA protects IPsec negotiations. The quick mode SAs—one for inbound packets and one for outbound packets—protect L2TP data using UDP port 1701. The main mode SA is authenticated using either certificates or a preshared key.

    For certificate authentication, the VPN server sends the VPN client a list of acceptable root certification authorities (CAs) from which the server will accept a certificate for authentication. The VPN client responds with a certificate chain (ending at a root CA certificate for a root CA from the list that the server sent) and its own list of acceptable root CAs. The server verifies the certificate chain of the client and then sends its own certificate chain (ending at a root CA certificate for a root CA from the list that the client sent) to the client. The client verifies the certificate chain that the server sent.

    For preshared key authentication, both the client and the server send a hash value that incorporates the value of the preshared key. The server verifies the hash value that the client sent, and the client verifies the hash value that the server sent.

    For more information about main mode and quick mode negotiations, see Chapter 13, "Internet Protocol Security and Packet Filtering."

  • Phase 2

    The client and the server exchange a series of L2TP messages to negotiate the use of an L2TP tunnel and a specific call ID to identify a connection within the L2TP tunnel.

When the L2TP/IPsec connection setup begins, the client must already be connected to the Internet. If the client is not already connected, the user can create a dial-up connection to an ISP before initiating the L2TP/IPsec connection.

Step 2: PPP Connection Setup

The PPP connection process follows the four phases described in the "Point-to-Point Protocol" section of this chapter.

Step 3: Remote Access VPN Client Registration

Each remote access VPN client sends a DHCPInform message to obtain additional TCP/IP configuration parameters and performs name registration.

To obtain additional TCP/IP configuration parameters, the client performs the following process:

  1. The client sends a DHCPInform message on the PPP link to the VPN server.

  2. The VPN server, configured with the DHCP Relay Agent routing protocol component and at least one IPv4 address of a DHCP server, relays the DHCPInform message to the DHCP server.

  3. The DHCP server sends back a DHCPAck message that contains the requested options.

  4. The VPN server relays the DHCPAck message to the client.

The principal use of the DHCPInform message is to obtain TCP/IP configuration parameters that are not obtained using IPCP, such as the DNS domain name assigned to the VPN connection. Only remote access VPN clients running Microsoft Windows 2000, Windows XP, or Windows Server 2003 send the DHCPInform message.

Before nodes on the intranet can resolve the names of remote access VPN clients while they are connected, the names and IPv4 addresses of the clients must be registered in the DNS and network basic input/output system (NetBIOS) namespaces of the private network. Because a remote access VPN client is typically assigned a different IPv4 address every time it connects, names in the namespaces should be dynamic, rather than static. Dynamic name registration for remote access clients consists of the following:

  • The remote access VPN client sends DNS dynamic update messages to its configured DNS server to register its DNS names.

  • The client also sends NetBIOS name registration messages to its configured WINS server to register its NetBIOS names.

Site-to-Site VPN Connections

Routing and Remote Access in Windows Server 2003 supports demand-dial routing (also known as dial-on-demand routing) over both dial-up connections (such as analog phone lines or ISDN) and VPN connections. Demand-dial routing forwards packets across a PPP link, which is represented inside Routing and Remote Access as a demand-dial interface. You can use demand-dial interfaces to create on-demand connections across dial-up, non-permanent, or permanent media.

Demand-dial routing is not the same as remote access. Remote access connects a single computer to a network, whereas demand-dial routing connects entire networks. However, both use PPP as the protocol through which they negotiate and authenticate the connection and encapsulate the data sent over it. With Routing and Remote Access in Windows Server 2003, you can enable remote access and demand-dial connections separately. However, they share the following attributes:

  • Dial-in properties of user accounts

  • Security (authentication protocols and encryption)

  • Windows or RADIUS authentication, authorization, and accounting

  • IPv4 address assignment and configuration

  • PPP features, such as MPPC and MPPE

Although the concept of demand-dial routing is fairly simple, the actual configuration is relatively complex due to the following factors:

  • Connection endpoint addressing

    The connection must be made over public data networks, such as the analog phone system or the Internet. You specify the endpoint of the connection using a phone number for dial-up connections and either a host name or an IPv4 address for VPN connections.

  • Authentication and authorization of the caller

    Anyone who calls the router must be authenticated and authorized. Authentication is based on the caller's set of credentials, which are passed to the router while the connection is being established. The credentials that are passed must correspond to a Windows user account. The router authorizes the connection based on the dial-in properties of the Windows user account and the remote access policies for the organization network.

  • Differentiation between remote access VPN clients and calling routers

    Both routing and remote access capabilities coexist on the same computer running Windows Server 2003. Both remote access clients and demand-dial routers can initiate a connection. For demand-dial connections, the computer initiating the demand-dial connection is the calling router. The computer answering the connection attempt of a calling router is the answering router. The computer running Windows Server 2003 must be able to distinguish between a connection attempt from a remote access client and one from a calling router.

    The computer identifies the connection attempt as a remote access connection unless the authentication credentials include a user name that matches the name of a demand-dial interface on the answering router.

  • Configuration of both ends of the connection

    You must configure both ends of the connection to enable two-way communication, even if only one end of the connection always initiates a demand-dial connection. If you configure only one end of the connection, packets will route in only one direction.

  • Configuration of static routes

    You should not use dynamic routing protocols over on-demand demand-dial connections. Therefore, you must add routes for address prefixes that are available across the demand-dial interface as static routes to the routing tables of the demand-dial routers.

Configuring a Site-to-Site VPN Connection

To configure a site-to-site VPN connection, you must do the following:

  • Enable and configure Routing and Remote Access on the answering router.

    Use the same procedure as described in the "VPN Server Support" section of this chapter.

  • Configure a demand-dial interface on the answering router.

  • Enable and configure Routing and Remote Access on the calling router.

    Use the same procedure as described in the "VPN Server Support" section of this chapter.

  • Configure a demand-dial interface on the calling router.

Configuring a Demand-dial Interface

From Routing and Remote Access on either the answering router or the calling router, perform the following steps:

  1. In the tree, right-click Network Interfaces, and then click New Demand-dial Interface.

  2. On the Welcome to the Demand-Dial Interface Wizard page, click Next.

  3. On the Interface Name page, type a name for the demand-dial interface, and then click Next.

  4. On the Connection Type page, click Connect using Virtual Private Networking (VPN), and then click Next.

  5. On the VPN Type page, click Automatic selection, Point to Point Tunneling Protocol (PPTP), or Layer 2 Tunneling Protocol (L2TP) (as needed), and then click Next.

  6. On the Destination Address page, type the IPv4 address of the other router's Internet interface, and then click Next.

  7. On the Protocols And Security page, select the Route IP packets on this interface and Add a user account so that a remote router can dial in check boxes, and then click Next.

  8. On the Static Routes for Remote Networks page, click Add to add static routes that are assigned to the demand-dial interface and that represent the address prefixes of the site across the site-to-site VPN connection (as needed). Click Next.

  9. On the Dial In Credentials page, type the password of the user account used by the calling router in Password and Confirm password, and then click Next.

    This step automatically creates a user account with the same name as the demand-dial interface that you are creating. You are also configuring the router to use this account name in its dial in credentials. When a calling router initiates a connection to an answering router, the calling router is using a user account name that matches the name of a demand-dial interface. Therefore, the answering router can determine that the incoming connection from the calling router is a demand-dial connection, rather than a remote access connection.

  10. On the Dial Out Credentials page, type the user name in User name, the user account domain name in Domain, and the user account password in both Password and Confirm password.

    If this router might call the other router, for a two-way-initiated, router-to-router VPN connection, configure the name, domain, and password when this router is acting as the calling router. If this router never calls the other router, you can type any name in User name and skip the rest of the fields.

  11. On the Completing the Demand-Dial Interface Wizard page, click Finish.

Connection Example for a Site-to-Site VPN

The complete configuration required for a site-to-site VPN connection is best illustrated by example. Figure 14-7 shows an example configuration of two offices that must connect to each other's networks across the Internet by using a site-to-site VPN connection.

Bb727019.ch14xx07(en-us,TechNet.10).gif

Figure 14-7 Example configuration for connecting two offices across the Internet

The Seattle office has a computer that is running Windows Server 2003 and that acts as both a remote access VPN server and a demand-dial router. All computers in the Seattle office are connected to the 172.16.1.0/24 network (subnet mask 255.255.255.0). The Seattle router (Router 1) has an Internet interface that is assigned the public IPv4 address 131.107.21.178.

The New York office has a computer that is running Windows Server 2003 and that acts as both a remote access VPN server and a demand-dial router. All computers in the New York office are connected to the 172.16.2.0/24 network (subnet mask 255.255.255.0). The New York router (Router 2) has an Internet interface that is assigned the public IPv4 address 157.60.234.17. All computers in both offices are in the example.com domain.

To configure demand-dial routing for the site-to-site VPN connection for this example, you must perform the following steps:

  • Configure and enable Routing and Remote Access on Router 1.

  • Configure a demand-dial interface on Router 1 with the following settings:

    • Name: DD_NewYork

    • Destination Address: 157.60.234.17

    • Routes: 172.16.2.0 with the subnet mask 255.255.255.0

    • Dial In Credentials: User account name of DD_NewYork with the password of h8#dW@93z~[Fc6$Q (example password)

    • Dial Out Credentials: User account name of DD_Seattle, domain name of example.com, and the password of 7%uQv45l?p!kWy9* (example password)

  • Configure and enable Routing and Remote Access on Router 2.

  • Configure a demand-dial interface on Router 2.

    • Name: DD_Seattle

    • Destination Address: 131.107.21.178

    • Routes: 172.16.1.0/24

    • Dial In Credentials: User account name of DD_Seattle with the password 7%uQv45l?p!kWy9*

    • Dial Out Credentials: User account name of DD_NewYork, domain name of example.com, and the password of h8#dW@93z~[Fc6$Q

Because you have configured a two-way initiated site-to-site VPN connection, you can initiate the connection by performing the following steps on either Router 1 or Router 2:

  1. In the tree of Routing and Remote Access, click Routing Interfaces.

  2. In the details pane, right-click the demand-dial interface, and then click Connect.

Figure 14-8 shows the resulting demand-dial routing configuration in terms of the demand-dial interfaces, static routes, and user accounts for the Seattle and New York offices.

Bb727019.ch14xx08(en-us,TechNet.10).gif

Figure 14-8 Resulting example configuration for a site-to-site VPN connection

This example shows a correct configuration for demand-dial routing. The user name from the user credentials of the demand-dial interface on the calling router must match the name of a demand-dial interface on the answering router in order for the incoming connection attempt to be considered a demand-dial connection. This relationship is summarized in Table 14-1.

Table 14-1 Connection example of a site-to-site VPN

Router

Demand-dial interface name

User account name in dial out credentials

Router 1

DD_NewYork

DD_Seattle

Router 2

DD_Seattle

DD_NewYork

The Connection Process for Site-to-Site VPNs

A site-to-site VPN connection uses the same connection process as a remote access connection, as described in "The Process for Setting Up a Remote Access VPN Connection" section of this chapter, with the following exceptions:

  • Both routers request an IPv4 address from the other router.

  • The calling router does not register itself as a remote access client.

Using RADIUS for Network Access Authentication

You can configure a VPN server running Windows Server 2003 to perform its own authentication, authorization, and accounting (AAA) for VPN connections or to use Remote Authentication Dial-in User Service (RADIUS). RFCs 2865 and 2866 define RADIUS, a widely deployed protocol that enables centralized AAA for network access.

Originally developed for dial-up remote access, RADIUS is now supported by VPN servers, wireless access points (APs), authenticating Ethernet switches, Digital Subscriber Line (DSL) access servers, and other types of network access servers.

RADIUS Components

A RADIUS AAA infrastructure consists of the following components:

  • Access clients

  • Access servers (RADIUS clients)

  • RADIUS servers

  • User account databases

  • RADIUS proxies

Figure 14-9 shows these components.

Bb727019.ch14xx09(en-us,TechNet.10).gif

Figure 14-9 The components of a RADIUS infrastructure

The following sections describe these components in detail.

Access Clients

An access client requires access to a network or to another part of the network. Examples of access clients are dial-up or VPN remote access clients, wireless clients, or LAN clients connected to an authenticating switch.

Access Servers

An access server provides access to a network. An access server using a RADIUS infrastructure is also a RADIUS client, sending connection requests and accounting messages to a RADIUS server. Examples of access servers are the following:

  • Network access servers (remote access servers) that provide remote access to an organization network or to the Internet. An example is a computer that is running Windows Server 2003 and Routing and Remote Access and that provides either dial-up or VPN-based remote access to an organization's intranet.

  • Wireless APs that provide physical access to an organization's network by using wireless-based transmission and reception technologies.

  • Switches that provide physical access to an organization's network by using LAN technologies such as Ethernet.

RADIUS Servers

A RADIUS server receives and processes connection requests or accounting messages sent by RADIUS clients or RADIUS proxies. During a connection request, the RADIUS server processes the list of RADIUS attributes in the connection request. Based on a set of authorization rules and the information in the user account database, the RADIUS server either authenticates and authorizes the connection and sends back a RADIUS Access-Accept message or, if either authentication or authorization fails, sends back a RADIUS Access-Reject message. The RADIUS Access-Accept message can contain connection restrictions that the access server enforces for the duration of the connection.

The IAS component of Windows Server 2003 is an industry-standard RADIUS server.

User Account Databases

A user account database is a list of user accounts and their properties that a RADIUS server can check to verify authentication credentials and to obtain user account properties that contain information about authorization and connection parameters.

IAS can use the local Security Accounts Manager (SAM), a domain based on Microsoft Windows NT® 4.0 operating systems, or Active Directory as a user account database. For Active Directory, IAS can provide authentication and authorization for user or computer accounts in the domain of which the IAS server is a member, two-way trusted domains, and trusted forests with domain controllers running Windows Server 2003.

If the user accounts for authentication reside in a different type of database, you can use a RADIUS proxy to forward the authentication request to a RADIUS server that does have access to the user account database.

RADIUS Proxies

A RADIUS proxy routes RADIUS connection requests and accounting messages between RADIUS clients (or other RADIUS proxies) and RADIUS servers (or other RADIUS proxies). A RADIUS proxy uses information within the RADIUS message to route it to the appropriate RADIUS client or server. You can use a RADIUS proxy as a forwarding point for RADIUS messages when AAA must occur at multiple RADIUS servers in different organizations.

With the RADIUS proxy, the definition of RADIUS client and RADIUS server becomes blurred. A RADIUS client to a RADIUS proxy can be an access server (that originates connection request or accounting messages) or another RADIUS proxy. There can be multiple RADIUS proxies between the originating RADIUS client and the final RADIUS server using chained RADIUS proxies. In a similar way, a RADIUS server to a RADIUS proxy can be the final RADIUS server (which performs the authentication and authorization evaluation) or another RADIUS proxy. Therefore, from a RADIUS proxy perspective, a RADIUS client is the RADIUS entity from which the proxy receives RADIUS request messages, and a RADIUS server is the RADIUS entity to which the proxy forwards RADIUS request messages.

The IAS component of Windows Server 2003 is an industry-standard RADIUS proxy.

IAS as a RADIUS Server

You can use IAS as a RADIUS server to perform AAA for RADIUS clients. A RADIUS client can be either an access server or a RADIUS proxy. Figure 14-10 shows IAS as a RADIUS server.

Bb727019.ch14xx10(en-us,TechNet.10).gif

Figure 14-10 IAS as a RADIUS server

The access server and the RADIUS proxy exchange RADIUS messages with the IAS server. IAS uses a secure communications channel to communicate with an Active Directory domain controller.

When IAS is used as a RADIUS server, it provides the following:

  • A central authentication and authorization service for all access requests that RADIUS clients and RADIUS proxies send.

    IAS uses either a Windows NT Server 4.0 domain, an Active Directory–based domain, or the local SAM to authenticate user credentials for a connection attempt. IAS uses the dial-in properties of the account and remote access policies to authorize a connection and enforce connection constraints.

  • A central accounting recording service for all accounting requests that RADIUS clients send.

    For Windows Server 2003, accounting requests are stored in a local log file or sent to a structured query language (SQL) server database for analysis.

You can use IAS as a RADIUS server in the following circumstances:

  • You use a Windows NT Server 4.0 domain, an Active Directory–based domain, or the local SAM as your user account database for access clients.

  • You use Routing and Remote Access in Windows Server 2003 on multiple dial-up servers, VPN servers, or site-to-site routers and you want to centralize both the configuration of remote access policies and the accounting of connection information.

  • You outsource your dial-up, VPN, or wireless access to a service provider. The access servers use RADIUS to authenticate and authorize connections that members of your organization make.

  • You want to centralize AAA for a heterogeneous set of access servers.

To send RADIUS messages to an IAS-based RADIUS server, you must configure your access servers or RADIUS proxies to use the IAS server as their RADIUS server. To receive RADIUS messages from access servers or RADIUS proxies, you must configure the IAS server with RADIUS clients. For example, if your VPN server is using IAS servers for RADIUS authentication or accounting, you must do the following:

  • Configure the VPN server with RADIUS servers that correspond to the IAS servers.

  • Configure the IAS servers with a RADIUS client that corresponds to the VPN server.

To install IAS on a computer running Windows Server 2003, do the following:

  1. Click Start, click Control Panel, and then double-click Add or Remove Programs.

  2. Click Add/Remove Windows Components.

  3. In the Windows Components Wizard dialog box, click Networking Services, and then click Details.

  4. In the Networking Services dialog box, select the Internet Authentication Service check box, click OK, and then click Next.

  5. If prompted, insert the Windows Server 2003 product disk.

  6. After IAS is installed, click Finish, and then click Close.

To create a RADIUS client on an IAS server, do the following:

  1. Click Start, click Control Panel, double-click Administrative Tools, and then double-click Internet Authentication Service.

  2. In the tree, right-click RADIUS Clients, and then click New RADIUS Client.

The New RADIUS Client Wizard will guide you through creating and configuring a RADIUS client.

For more information about using IAS as a RADIUS server, see Help and Support for Windows Server 2003.

Remote Access Policies

For a connection attempt to be accepted, it must be both authenticated and authorized. Authentication verifies the credentials of the access client. Authorization verifies that the connection attempt is allowed and is granted on the basis of account dial-in properties and remote access policies. Remote access policies are an ordered set of rules that define how connections are either authorized or rejected. Each rule has one or more conditions, a set of profile settings, and a setting for remote access permission.

When a connection is authorized, the remote access policy profile specifies a set of connection restrictions. The dial-in properties of the account also provide a set of restrictions. Where applicable, connection restrictions from the account properties override those from the remote access policy profile.

Remote Access Policy Conditions and Restrictions

Before authorizing the connection, remote access policies can validate a number of connection settings, including the following:

  • Group membership

  • Type of connection

  • Time of day

  • Authentication method

  • Identity of the access server

After authorizing the connection, remote access policies can specify connection restrictions, including the following:

  • Idle timeout time

  • Maximum session time

  • Encryption strength

  • Authentication method

  • IPv4 packet filters

For example, you can have policies that specify different maximum session times for different types of connections or groups. Additionally, you can have policies that specify restricted access for business partners or vendors.

If Routing and Remote Access is configured to use Windows for authentication, you configure remote access policies on the computer running Routing and Remote Access by opening Routing and Remote Access and opening the Remote Access Policies folder in the tree. If Routing and Remote Access is configured to use RADIUS for authentication and an IAS server as its RADIUS server, you configure remote access policies on the computer running IAS by opening Internet Authentication Service and opening the Remote Access Policies folder in the tree.

To create a remote access policy by using Internet Authentication Service, do the following:

  1. Click Start, click Control Panel, double-click Administrative Tools, and then double-click Internet Authentication Service.

  2. In the tree, right-click Remote Access Policies, and then click New Remote Access Policy.

The New Remote Access Policy Wizard will guide you through creating a remote access policy.

IAS as a RADIUS Proxy

You can use IAS as a RADIUS proxy to route RADIUS messages between RADIUS clients (access servers) and RADIUS servers that perform AAA for the connection attempt. When you use IAS as a RADIUS proxy, IAS acts as a central switching or routing point through which RADIUS access and accounting messages flow. IAS records information in an accounting log about the messages that it forwards. Figure 14-11 shows IAS as a RADIUS proxy.

Bb727019.ch14xx11(en-us,TechNet.10).gif

Figure 14-11 IAS as a RADIUS proxy

Connection Request Processing

To determine whether a RADIUS client message should be processed locally or forwarded to another RADIUS server, an IAS server running Windows Server 2003 uses connection request processing. Connection request processing consists of the following:

  • Connection request policies

    For any incoming RADIUS request message, connection request policies determine whether the IAS server processes the message locally or forwards it to another RADIUS server. Connection request policies are rules that specify conditions and profile settings, which give you flexibility to configure how the IAS server handles incoming authentication and accounting request messages. With connection request policies, you can create a series of policies so that an IAS server processes some RADIUS request messages locally (acting as a RADIUS server) and forwards other types of messages to another RADIUS server (acting as a RADIUS proxy).

  • Remote RADIUS server groups

    When an IAS server forwards RADIUS messages, remote RADIUS server groups specify the set of RADIUS servers to which the server forwards the messages. A remote RADIUS server group is a named group that contains one or more RADIUS servers. When you configure a connection request policy to forward RADIUS traffic, you must specify a remote RADIUS server group. This group facilitates the common configuration of both a primary and a secondary RADIUS server. You can specify various settings either to determine the order in which the servers are used or to distribute the RADIUS messages across all servers in the group.

You can configure connection request policies and remote RADIUS server groups from the Connection Request Processing folder in Internet Authentication Service.

To create a connection request policy, do the following:

  1. Click Start, click Control Panel, double-click Administrative Tools, and then double-click Internet Authentication Service.

  2. In the tree, right-click Connection Request Policies, and then click New Connection Request Policy.

The New Connection Request Policy Wizard will guide you through creating a connection request policy and remote RADIUS server group.

Chapter Summary

The chapter includes the following pieces of key information:

  • A virtual private network (VPN) extends a private network to encompass links across shared or public networks like the Internet. With authentication, encapsulation, and encryption, you can use a VPN connection 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.

  • A remote access VPN connection connects a single client computer to a private network across a public or shared network. Either a default route or a set of routes that summarize the addresses of the private intranet facilitates routing for remote access VPN connections.

  • A site-to-site VPN connection connects two portions of a private network across a public or shared network. A set of routes associated with the demand-dial interfaces that represent the point-to-point VPN connection facilitates routing for site-to-site VPN connections.

  • Both Windows XP and Windows Server 2003 support both a VPN client and a VPN server for remote access VPN connections. A computer running Windows Server 2003 can act as a calling or answering router in a site-to-site VPN connection.

  • RADIUS is a standard protocol that you can use for authorization, authentication, and accounting of network access, including VPN connections. IAS in Windows Server 2003 is the Microsoft implementation of a RADIUS server and proxy.

  • IAS uses remote access policies to determine authorization of network access and connection request policies to determine whether an IAS server should process an incoming RADIUS request message locally or forward it to another RADIUS server.

For additional resources about VPNs in Windows Server 2003 and Windows XP, see the Microsoft Virtual Private Networks Web page.

Chapter Glossary

access client – A network device that requires access to a network or another part of the network.

access server – A network device that provides access to a network. An access server that uses a RADIUS server for authentication, authorization, and accounting is also a RADIUS client.

answering router – The router that answers the demand-dial connection attempt (the VPN server).

calling router – The router that initiates the demand-dial connection (the VPN client).

Layer Two Tunneling Protocol (L2TP) – A VPN tunneling protocol that uses UDP and an L2TP header to encapsulate PPP frames sent across an IPv4 network.

Point-to-Point Protocol (PPP) – An industry standard suite of protocols for the use of point-to-point links to transport multiprotocol packets.

Point-to-Point Tunneling Protocol (PPTP) – A VPN tunneling protocol that uses a TCP connection for tunnel maintenance and a Generic Routing Encapsulation (GRE) header to encapsulate PPP frames.

RADIUS – See Remote Authentication Dial-In User Service (RADIUS).

RADIUS proxy – A RADIUS-capable device that routes RADIUS connection requests and accounting messages between RADIUS clients (and RADIUS proxies) and RADIUS servers (and RADIUS proxies).

RADIUS server – A server that receives and processes connection requests or accounting messages sent by RADIUS clients or RADIUS proxies.

remote access VPN connection – A VPN connection that connects a single client computer to a private network across a public or shared network.

Remote Authentication Dial-In User Service (RADIUS) – An industry standard protocol that you can use to send messages between access servers, RADIUS servers, and RADIUS proxies to provide authentication, authorization, and accounting (AAA) of network access.

site-to-site VPN connection – A VPN connection that connects two portions of a private network together across a public or shared network.

user account database – A list of user accounts and their properties that a RADIUS server can check to verify authentication credentials and obtain user account properties that contain information about authorization and connection parameters.

virtual private network (VPN) – The extension of a private network that encompasses encapsulated, encrypted, and authenticated links across shared or public networks. VPN connections can provide remote access and routed connections to private networks over a public or shared network, such as the Internet.

VPN – See virtual private network (VPN).

VPN client – A computer that initiates a connection to a VPN server.

VPN server – A computer that accepts virtual private network (VPN) connections from VPN clients. A VPN server can provide a remote access or a site-to-site VPN connection.