Designing a Remote Access Server Solution


After choosing the remote access to deploy, begin the design process. The design for a remote access server solution encompasses hardware requirements, outsourcing options, placement of remote access servers on the network, routing for remote access clients, and a security plan. Before deploying your remote access server solution, optimize and test your design. Figure 8.5 shows the process for designing a remote access server solution.

click to expand
Figure 8.5: Designing a Remote Access Server Solution

Determining Hardware Requirements

The first step in designing a remote access solution is to determine hardware requirements. Determine the capacity required for your dial-up or VPN servers, as well as additional hardware required, such as modem banks for a dial-up solution. When selecting server hardware, consider central processing unit (CPU), RAM, and network hardware requirements. For optimal performance, run lab tests on each model of equipment to be used in your production environment.

Determining Hardware Requirements for Dial-up Networking

Use the following guidelines when determining hardware requirements for your dial-up networking design:

  • A dial-up remote access server must have a modem or a multiport adapter, and it must have access to an analog telephone line. Based on the maximum number of dial-up remote access clients that will dial in at one time, install modem bank equipment and phone lines that meet your organization's needs.

  • Each server-side modem requires a serial port on the remote access server. For multiple modems (modem banks), use a multiport serial adapter or a high-density combination card. A multiport serial adapter can connect a large number of analog modems or Integrated Services Digital Network (ISDN) modems to one remote access server. A high-density combination card combines multiple modems and serial adapters in one device.

  • For best performance, consider using intelligent communications adapters (multiport serial boards) to offload processing from the remote access server.

Determining Hardware Requirements for VPN

Use the following guidelines when determining network hardware requirements for your VPN design:

  • For interfaces on the public network, use network adapters capable of IPSec hardware offload.

  • Assuming that you have a 10/100 Ethernet infrastructure, set all devices to 100 Mbps Full Duplex.

  • Connect interfaces on the private network directly to a high-capacity switch that also connects the data servers and routers that remote access clients will access frequently.

CPU Requirements

Use the following guidelines when determining CPU requirements for your VPN design:

  • Processing inbound and outbound packets requires CPU cycles. By increasing the available processing power, you can increase throughput.

  • Doubling the speed of a single processor is more effective than doubling the number of processors.

  • In the case of multiprocessor platforms, binding one CPU to each network adapter can increase the efficiency of interrupt handling, freeing cycles and shrinking the performance gap between the use of a large number of less powerful CPUs and a few faster, more expensive CPUs.

RAM Requirements

Use the following guidelines when determining the RAM needed for VPN servers:

  • Each active connection consumes a small block of nonpageable memory (approximately 40 KB). If you do not need to handle more than 1,000 concurrent calls from remote access users, 512 MB of RAM is adequate.

  • If you require the capacity to handle more than 1,000 concurrent calls, for every 1,000 concurrent calls provide an extra 128 MB of RAM over recommended RAM capacity for the server, plus a base of 128 MB more for remote access and related services.

    For example, for a dedicated remote access server that will support as many as 2,000 simultaneous VPN calls, if the recommended RAM capacity for Windows Server 2003 is 256 MB, provide 768 MB of RAM:

    • 256 MB + (128 MB * 2) + (128 MB * 2)

Performing Capacity Planning

The two greatest potential performance constraints in your remote access server solution are the number of simultaneous connections and the overall data throughput.

The number of simultaneous connections that a VPN server can support is determined by the available nonpaged pool memory as well as other factors, such as the use of data compression. With compression, each connection uses more nonpaged pool memory and requires more processing. Turning off compression can improve performance.

The processing power that is available to a VPN server determines the server's data throughput capacity. Tunneling protocols also have an impact on data throughput. PPTP connections require less processing power than L2TP/IPSec connections do; however, L2TP/IPSec connections are the most secure. You can mitigate the impact of L2TP/IPSec on processing power by using IPSec hardware offload.

Considering Outsourcing Options

Outsourcing part or all of a remote access solution through a wholesale contract with an Internet service provider (ISP) can provide some organizations significant cost savings, minimizing both setup and operations costs. You can purchase a wholesale contract with an ISP that provides a guaranteed level of service for some or all components of your remote access solution. An ISP can provide access to an extensive network of connections across a wide geographical area for a fixed cost. Many ISPs provide a guaranteed level of service that rivals those of dial-up wide area network (WAN) connections.

If you are deploying a dial-up networking solution, consider outsourcing your deployment to avoid the long-distance charges that you are likely to accrue.

If you are deploying a VPN solution, an ISP can provide many of the components required to support VPN access, including:

  • Network access servers (NASs) for access from various geographical access points.

    If you outsource support, ensure that the NASs that the ISP provides meet your access requirements. VPN users dial first into a NAS. Unless your outsourcing agreement specifies the support required from the ISP's NASs, including connection speeds, device support, and levels of service, the NASs can be the weak link in your VPN solution.

  • RADIUS proxy servers for routing of access requests to the enterprise.

    You can either contract with the ISP to provide authentication services or have the ISP use a RADIUS proxy and send authentication requests to a RADIUS server that you manage.

  • Phone book support for delivering the latest access numbers either to the enterprise or directly to the client.

Placing Remote Access Servers

In deciding where to place remote access servers on your network, consider firewall placement and the placement of other network resources. Place remote access servers close to the network resources that remote access clients need. These resources might include a CA, a RADIUS server, a domain controller, or file and application servers.

In a dial-up remote access design, servers usually are placed behind the firewall. Because a VPN design involves Internet connectivity, server placement relative to the firewall is a greater issue.

If you are designing a VPN remote access solution, choose between two options for server placement, each with different design requirements:

  • VPN server behind the firewall. The firewall is attached to the Internet, with the VPN server between the firewall and the intranet. This is the placement used in a perimeter network configuration, in which one firewall is positioned between the VPN server and the intranet, with another between the VPN server and the Internet.

  • VPN server in front of the firewall. The VPN server is connected to the Internet, with the firewall between the VPN server and the intranet.

VPN Server Behind the Firewall

The most common configuration for a VPN remote access design is to locate the VPN server behind a firewall. In this configuration, the firewall is connected to the Internet, and the VPN server is an intranet resource that is connected to the perimeter network. The VPN server has an interface on both the perimeter network and the intranet. The Internet firewall (the firewall between the Internet and the VPN server) filters all traffic from Internet clients. The intranet firewall (the firewall between the VPN server and the intranet) filters intranet traffic from VPN clients.

Placing a VPN server behind the firewall requires the following configuration:

  • Configure the Internet interface on the firewall with inbound and outbound filters that allow traffic to the VPN server. You can specify additional filters to allow traffic to the Web servers, File Transfer Protocol (FTP) servers, and other types of servers on the perimeter network.

  • For an added layer of security, configure the perimeter network interface on the VPN server with PPTP or L2TP/IPSec packet filters.

VPN Server in Front of the Firewall

Another option is to place the VPN server in front of the firewall, directly connected to the Internet. For inbound traffic, the VPN server decrypts the tunneled data and forwards it to the firewall. The firewall acts as a filter for intranet traffic, and it can prevent access to specific resources, scan data for viruses, perform intrusion detection, and carry out other functions.

To place a VPN server in front of the firewall, you must configure inbound and outbound filters on the VPN server to allow only VPN traffic to and from the IP address of the VPN server's Internet interface.

Note

To enable access to services running on the VPN server, make sure that the network BIOS (NetBIOS) and DNS names of the VPN server's Internet interface are not registered in the intranet namespaces. This is the default behavior for Windows Server 2003 VPN servers.

Determining Routing for VPN Remote Access Clients

Because VPN remote access clients typically do not support routing protocols such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF), the clients often have very simple routing tables. Your remote access design must provide a method for routing packets from the remote access clients to the intranet and the Internet — in some cases simultaneously, depending on the needs of the remote user.

For example, a computer on a small local area network (LAN) has a route to its own subnet on the LAN, and it might have a default route to a gateway router on the LAN for all other traffic. Without routing protocol support, remote access clients cannot automatically determine the best route to a destination.

Choosing Between Routing Approaches

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. This poses no problem for VPN remote access users who only require access to the organization's network. However, it is not acceptable for remote users who need access to the Internet while they are connected to the organization's network.

Based on whether or not the default route is added, the client has broad access either to Internet locations or to locations on the intranet, but not to both:

  • If the default gateway on the remote network is not being used, Internet locations are reachable, but only intranet locations matching the address class of the assigned IP address can be reached.

  • If the default gateway on the remote network is being used, all intranet locations are reachable, but only the IP address of the VPN server and locations available through other routes can be reached on the Internet.

For most VPN clients with an Internet connection, this does not present a problem, because the client is typically engaged in either intranet communication or Internet communication, but not both.

To work around this problem, instead of having the client create a new default route when a connection is made, you can configure the client's routing table with specific routes that direct packets to the organization's network over the VPN connection. While connected to the intranet, the client can obtain Internet access using the existing default route over the connection to the ISP. This configuration is known as split tunneling.

Choosing Among Split Tunneling Options

The VPN client can obtain the routes needed for split tunneling in several ways:

  • If the VPN client has a configured connection without a default route, the client adds a route that it infers from the class of the IP address assigned to it for the current connection. For a simple target network, such as a small office, this one route is sufficient to allow packets to be routed to the target network. However, for a complex network, you need to configure multiple routes to successfully direct packets to the remote network.

  • A client running the Microsoft Windows XP or Windows Server 2003 operating systems uses a DHCPINFORM message after the connection to obtain additional information about the connection, such as a DNS name or a set of routes for the target network. This additional information is only available if the DHCP server has been configured to provide the DHCP Classless Static Routes option, and if the remote access server has been configured to relay the DHCPINFORM message to the DHCP server.

  • If the remote access client is managed using the Connection Manager component of Windows Server 2003, the network administrator can prepare a routing table for the remote access client and associate a post-connect action with the managed connection to update the client's routing table when a connection is made. For more information about using Connection Manager, see "Deploying Remote Access Clients Using Connection Manager" in this book.

  • If none of the above approaches meets your needs, the end user or network administrator can write a program or batch file that updates the routing table on the client with the necessary routes to the remote network.

Security considerations for split tunneling

Some network administrators consider split tunneling to be a needless security risk. Their concern is that an attacker might be able to compromise the network by enabling traffic to be routed between the Internet and the network using the remote access client. To prevent this, you can add packet filters to the remote access policy profile settings for the VPN connection to allow only inbound traffic that originates from remote access clients. The default remote access policy named Connections to Microsoft Routing and Remote Access server has these packet filters already configured.

Obtaining IP Addresses for Remote Access Clients

Use either of the following methods to obtain IP addresses to assign to remote access clients:

  • Let Routing and Remote Access assign IP addresses obtained from a DHCP server to remote access clients.

  • Configure a static pool of IP addresses to assign to remote access clients. You can specify either an on-subnet or off-subnet range of IP addresses for the static pool.

Planning Security for a VPN

Because a dial-up networking solution provides a secure data path over a circuit-switched connection, security is not a critical issue in your design for a dial-up remote access solution. In contrast, a VPN remote access solution routes data over a packet-switched connection that does not intrinsically provide the same level of security. Therefore, security is an important part of your VPN remote access server design.

The security of a VPN is based on the tunneling and authentication protocols that you use and the level of encryption that you apply to VPN connections. For the highest level of security, use a remote access VPN based on L2TP/IPSec with certificate-based IPSec authentication and Triple-DES for encryption. If you decide to use a PPTP-based VPN solution to reduce costs and improve manageability and interoperability, use Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2) as the authentication protocol.

In designing security for your VPN remote access server solution, perform the following tasks:

  • Select a VPN protocol.

  • Select authentication protocols.

  • Select the scope and level of encryption.

  • If needed, plan a certificate infrastructure to support client authentication for remote access.

  • Optionally, plan for Network Access Quarantine Control.

  • Optionally, enhance security by using remote access account lockout.

Note

You can increase the security and manageability of your remote access server solution by using IAS to centralize VPN or dial-up networking authentication, authorization, and accounting. In operating systems in the Windows 2000 Server family, IAS is an implementation of a RADIUS server; in Windows Server 2003, IAS is an implementation of a RADIUS server and proxy. For information about designing and deploying Internet Authentication Service (IAS), see "Deploying IAS" in this book.

Selecting a VPN Protocol

Tunneling and authentication protocols, and the encryption levels applied to VPN connections, determine VPN security. L2TP/IPSec provides the highest level of security. For a VPN design, determine which VPN protocol best meets your requirements. Windows Server 2003 supports two VPN protocols: Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol with Internet Protocol security (L2TP/IPSec).

PPTP

PPTP uses Point-to-Point Protocol (PPP) user authentication methods and Microsoft Point-to-Point Encryption (MPPE) to encrypt IP traffic. When used with MS-CHAP v2 for password-based authentication and strong passwords, PPTP is a secure VPN technology. For stronger authentication for PPTP connections, you can implement a PKI using smart cards or certificates and Extensible Authentication Protocol — Transport Level Security (EAP-TLS).

PPTP is widely supported and easily deployed, and it works with most network address translators (NATs).

L2TP/IPSec

The more secure of the two VPN protocols, L2TP/IPSec uses PPP user authentication methods and IPSec encryption to encrypt IP traffic. This combination uses certificate-based computer identity authentication to create IPSec security associations in addition to PPP-based user authentication. L2TP/IPSec provides data integrity, data origin authentication, data confidentiality, and replay protection for each packet.

Support for L2TP/IPSec is provided with Windows Server 2003, as well as with Windows 2000 and Windows XP. To use L2TP/IPSec with the Microsoft Windows 98, Windows Millennium Edition (Windows Me), or Windows NT Workstation 4.0 operating system, download and install Microsoft L2TP/IPSec VPN Client (Mls2tp.exe). For information about Mls2tp.exe, see the Microsoft L2TP/IPSec VPN Client link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Table 8.1 summarizes the advantages and constraints associated with the use of the PPTP and L2TP/IPSec protocols.

Table 8.1: Advantages and Constraints of the PPTP and L2TP/IPSec VPN Protocols

Factor

PPTP Advantages and Constraints

L2TP/IPSec Advantages and Constraints

Client operating systems supported

Supported on clients running Windows 2000, Windows XP, Windows Server 2003, Windows NT Workstation 4.0, Windows Me, or Windows 98.

Natively supported on clients running Windows 2000, Windows XP, or Windows Server 2003.

With Mls2tp.exe installed, supported on clients running Windows 98, Windows Me, or Windows NT Workstation 4.0.

Certificate support

For EAP-TLS authentication to issue computer certificates to the authenticating server and user certificates to all VPN clients or to issue smart cards to all users, PPTP requires a certificate infrastructure.

To issue computer certificates to the VPN server and all VPN clients, L2TP/IPSec requires a certificate infrastructure or a preshared key (PSK).

Security

Provides data confidentiality. (Captured packets cannot be interpreted without the encryption key.)

Does not provide data integrity (proof that the data was not modified in transit) or data origin authentication (proof that the data was sent by the authorized user).

To increase security, use MS-CHAP v2 as the authentication protocol with strong passwords.

Offers the highest level of security, providing data confidentiality, data integrity, data origin authentication, and replay protection.

Performance

A VPN server supports more PPTP connections than L2TP/IPSec connections.

Because IPSec encryption is processing intensive, a VPN server supports fewer L2TP connections than PPTP connections. To support additional L2TP connections, increase CPU processing power or use offload network adapters.

NAT support

PPTP-based VPN clients can be located behind a NAT if the NAT includes an editor that can translate PPTP.

If you locate L2TP/IPSec-based clients or servers behind a NAT, both client and server must support IPSec NAT traversal (NAT-T).

NAT Requirements for VPN Protocols

If you are using a NAT with your VPN remote access server solution, your security plan for remote access must include the required setup for placing VPN clients behind a NAT. The VPN protocol that you deploy affects the NAT requirements.

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 provide IP address configuration information to the other computers on the private network.

The NAT can act as a simplified DHCP server that allocates an IP address, a subnet mask, a default gateway, and the IP address of a DNS server. The NAT can become the DNS proxy for the computers on the private network. When the NAT receives name resolution requests from a computer on the private network, it forwards the request to a specified Internet-based DNS server and returns a response to the requesting computer on the private network.

Using a NAT with PPTP connections If a VPN client that uses a PPTP connection is behind a NAT, the NAT must include a NAT editor that can translate PPTP traffic. The NAT editor is required, because PPTP tunneled data has a Generic Routing Encapsulation (GRE) header rather than a TCP header or a UDP header. The NAT editor uses the Call ID field in the GRE header to identify the PPTP data stream and translate IP addresses and call IDs for PPTP data packets that are forwarded between a private network and the Internet.

The NAT/Basic Firewall routing protocol component of the Routing and Remote Access service includes a NAT editor for PPTP traffic.

Using a NAT with L2TP connections IPSec NAT Traversal (NAT-T) enables IPSec peers to communicate when behind a NAT. IPSec NAT-T provides UDP encapsulation of IPSec packets to enable Internet Key Exchange (IKE) and Encapsulating Security Payload (ESP)-protected traffic to pass through a NAT. IKE automatically detects that a NAT is present and uses User Datagram Protocol — Encapsulating Security Payload (UDP-ESP) encapsulation to enable ESP-protected IPSec traffic to pass through the NAT.

To use NAT-T, both the remote access VPN client and the remote access server must support IPSec NAT-T. IPSec NAT-T is supported by Windows Server 2003 and Microsoft L2TP/IPSec VPN Client.

Selecting an Authentication Protocol

Because L2TP/IPSec user authentication occurs after the VPN client and the VPN server have established a secure channel of communication, your choice of authentication protocol has no effect on VPN security if you use L2TP/IPSec. However the use of MS-CHAP v2 and EAP-TLS is recommended.

To use encryption on a PPTP connection, you must use one of the following authentication protocols:

  • MS-CHAP

  • MS-CHAP v2

  • EAP-TLS

Authentication Protocols for PPTP VPN Connections

PPTP VPN connections require the use of the MS-CHAP, MS-CHAP v2, or EAP-TLS authentication protocols. Only these three authentication protocols provide a mechanism to generate the same encryption key on both the VPN client and the VPN server. MPPE uses this encryption key as a basis for encrypting all PPTP data sent over the VPN connection.

MS-CHAP and MS-CHAP v2 MS-CHAP and MS-CHAP v2 are password-based authentication protocols. In the absence of certificates or smart cards, use MS CHAP v2, a stronger authentication protocol than MS CHAP, which provides mutual authentication. With mutual authentication, the VPN server authenticates the VPN client, and the VPN client authenticates the VPN server.

Note

If you must use a password-based authentication protocol, enforce the use of strong passwords on your network. A strong password has more than eight characters and a random mixture of uppercase and lowercase letters, numbers, and punctuation marks. For example, "f3L*q02~>xR3w#4o" is a strong password. In an Active Directory domain, use Group Policy settings to enforce strong user passwords.

EAP-TLS The EAP-TLS authentication protocol is designed for use with a certificate infrastructure and either certificates or smart cards. With EAP-TLS, the VPN client sends its user certificate for authentication, and the authenticating server for the VPN server sends a computer certificate for authentication. This is the strongest authentication method, because it does not rely on passwords. For more information about EAP-TLS authentication, see "Connecting Remote Sites" in this book.

You can use Certificate Services in Windows Server 2003 as the CA for your organization, or you can use a third-party CA when you deploy EAP-TLS as your authentication method. For information about certificate requirements with Certificate Services, see "Network access authentication and certificates" in Help and Support Center for Windows Server 2003.

Using a third-party CA requires the following setup:

  • The certificate in the computer store of the authenticating server must contain the Server Authentication certificate purpose in Enhanced Key Usage (EKU) extensions. A certificate purpose is identified with an object identifier (OID). The object identifier for Server Authentication is 1.3.6.1.5.5.7.3.1.

  • The Subject Alternative Name property of the computer certificate must contain the fully qualified domain name (FQDN) of the computer account of the authenticating server.

  • The cryptographic service provider for the computer certificates on the authenticating server must support the secure channel (Schannel) security package. Without support for Schannel, the authenticating server cannot use the certificate, and the certificate will not be available for use in the remote access policy.

  • The certificate installed on a remote access client that is running Windows Server 2003 must contain the Client Authentication certificate purpose (OID 1.3.6.1.5.5.7.3.2).

  • The Subject Alternative Name property of the user certificate must contain the FQDN of the user account of the VPN client.

  • Both the certificate in the computer store of the authenticating server and the user certificate of the remote access client must contain a private key.

Authentication Protocols for L2TP/IPSec Connections

For L2TP/IPSec connections, you can use any user authentication protocol, because the authentication occurs after the VPN client and VPN server have established a secure channel of communication. This is referred to as an IPSec security association (SA). It is strongly recommended that you use either MS-CHAP v2 or EAP-TLS to provide the most secure user authentication that is available.

Guidelines for Selecting Authentication Protocols

Consider the following factors when choosing an authentication protocol for VPN connections:

  • If you use smart cards or have a certificate infrastructure that issues user and computer certificates, use the EAP-TLS authentication protocol for both PPTP and L2TP connections. EAP-TLS is supported by VPN clients running Windows 2000, Windows XP, or Windows Server 2003.

  • If you must use a password-based authentication protocol, use MS-CHAP v2, and enforce strong passwords using Group Policy. MS-CHAP v2 is supported by VPN clients running Windows XP, Windows Server 2003, Windows 2000, Windows NT Workstation 4.0 with Service Pack 4 (SP4) and later, Windows Millennium Edition, or Windows 98.

  • Use the most secure protocols that your network access servers and clients can support. If you need a high level of security, configure the remote access server and the authenticating server to accept only a few very secure authentication protocols. Alternatively, if flexibility is more important than maintaining a high level of security, configure the authenticating server to accept less secure authentication protocols. For more information about designing and deploying IAS, see "Deploying IAS" in this book.

Selecting the Scope and Level of Encryption

On a VPN, you protect your data by encrypting it between the VPN client and the VPN server. Always use data encryption for VPN connections when private data is sent across a public network, which always presents a risk of interception. For VPN connections, Windows Server 2003 uses MPPE for PPTP connections and IPSec encryption for L2TP connections.

Note

Nonencrypted PPTP connections (over which the PPP frame is sent in plaintext) and nonencrypted non-IPSec-based L2TP connections (over which the PPP frame is sent in plaintext) are not secure, and they are not recommended for VPN connections over the Internet.

To ensure successful encryption and decryption, the sender and the receiver must use a common encryption key. The length of the encryption key is an important security parameter, especially over public networks. To ensure the highest level of encryption, use the largest key size.

Protection Provided by Link Encryption

In link encryption, data is encrypted only on the link between the VPN client and the VPN server. A VPN connection has link encryption, regardless of the VPN protocol in use. PPTP connections use MPPE with MS-CHAP, MS-CHAP v2, or EAP-TLS authentication. For L2TP/IPSec connections, IPSec provides encryption on the link between the VPN client and the VPN server.

When data encryption is performed between the VPN client and the VPN server, you do not need to encrypt the data on the communication link between a dial-up client and its ISP. For example, a mobile user might use a dial-up networking connection to dial in to a local ISP. After the Internet connection is made, the user creates a VPN connection with the enterprise VPN server. Because the VPN connection is encrypted, no encryption is needed on the dial-up networking connection between the user and the ISP.

Providing End-to-End Encryption

For an additional layer of security, configure end-to-end encryption. End-to-end encryption encrypts the data between the source host and the destination host. After a VPN connection is made, IPSec can be used to provide end-to-end encryption. For an L2TP/IPSec connection, IPSec end-to-end encryption is used in addition to IPSec link encryption.

Table 8.2 shows which authentication methods support specific encryption requirements.

Table 8.2: Encryption Support Provided Under CHAP, MS-CHAP, and EAP-TLS

Requirement

Authentication Protocols

Encryption Enforcement

Secured password with no data encryption

CHAP, MS-CHAP, MS-CHAP v2

Optional encryption. (Connect even if no encryption.)

Secured password with MPPE data encryption

MS-CHAP, MS-CHAP v2

Required encryption. (Disconnect if server declines.)

Smart card with no data encryption

EAP-TLS

Optional encryption. (Connect even if no encryption.)

Smart card with data encryption

EAP-TLS

Require encryption. (Disconnect if server declines.)

Data encryption for L2TP connections relies on IPSec, which does not require any specific authentication protocol. IPSec enforces the encryption; if the server declines data encryption, the connection is denied.

The strength of link encryption is set through the remote access policies that govern PPTP and L2TP connections on the server. A remote access policy is a collection of conditions and settings that define authorization and access privileges for connection attempts. For IAS servers and servers running Routing and Remote Access, remote access policies are used to determine whether a connection attempt is accepted or rejected.

Table 8.3 shows the encryption support provided for PPTP and L2TP/IPSec connections by each level of encryption that is set in a remote access policy.

Table 8.3: Encryption Required at Each Encryption Level for PPTP and L2TP/IPSec Connections

Encryption Level

PPTP Encryption Required

L2TP Encryption Required

No Encryption

No encryption required.

No encryption required.

Basic

MPPE 40-bit data encryption

IPSec 56-bit Data Encryption Standard (DES)

Strong

MPPE 56-bit data encryption

IPSec 56-bit DES

Strongest

MPPE 128-bit encryption

IPSec 168-bit Triple DES (3DES)

For a procedure for setting the encryption level in a remote access policy, see "Configuring authentication and data encryption" in Help and Support Center for Windows Server 2003. For more information about using Windows Server 2003 remote access policies, see "Introduction to remote access policies" in Help and Support Center for Windows Server 2003.

Planning a Certificate Infrastructure to Support Client Authentication

The authentication methods that are deployed for remote access clients determine whether or not your remote access design requires a certificate infrastructure.

A certificate infrastructure is required for L2TP/IPSec-based VPN connections, because certificates are used to negotiate IPSec peer authentication. For PPTP-based VPN connections, a certificate infrastructure is required if either smart cards or certificates and EAP-TLS authentication are in use. Password-based authentication protocols, such as MS-CHAP v2, do not use certificates in authentication; therefore, a certificate infrastructure is not required.

Table 8.4 shows where you must install certificates to support remote access clients over L2TP/IPSec-based VPN connections and over PPTP-based connections using EAP-TLS. For EAP-TLS authentication, L2TP/IPSec-based VPN connections require one more certificate on the VPN client than PPTP-based VPN connections require.

Table 8.4: Certificate Infrastructures Required for Remote Access Client Authentication

VPN/Authentication Protocol

Required Certificate Infrastructure

L2TP/IPSec-based VPN connection

  • Install a computer certificate on the VPN server.

  • Install a computer certificate on each VPN client.

PPTP-based VPN connection using smart cards and EAP-TLS

  • Install a computer certificate on the authenticating server for the VPN server.

  • Install a user certificate on each smart card.

PPTP-based VPN connection using registry-based user certificates and EAP-TLS

  • Install a computer certificate on the authenticating server for the VPN server.

  • Install a user certificate on each VPN client.

If your PPTP-based VPN connections require a certificate infrastructure, install a computer certificate on the authenticating server for the VPN server. If you are using smart cards, install a user certificate on each smart card distributed to a VPN client user. If you are using registry-based user certificates with EAP-TLS authentication, install a user certificate on each VPN client.

For an L2TP/IPSec-based VPN connection, install a computer certificate on all VPN clients and on the VPN server. A certificate infrastructure is also required when you are using either smart cards or certificates and EAP-TLS for user authentication.

For more information about certificate requirements, see "Network access authentication and certificates" in Help and Support Center for Windows Server 2003.

For more information about deploying certificate services to support L2TP/IPSec, see "Designing a Public Key Infrastructure" in Designing and Deploying Directory and Security Services of this kit.

Planning for Network Access Quarantine Control

Because typical remote access connections only validate the credentials of a remote access user, a remote access client that connects to a private network can access network resources even if the configuration of the remote access client does not comply with corporate network policies. You can implement Network Access Quarantine Control to delay normal remote access to a private network until the configuration of the remote access client has been examined and validated by a client-side script.

When a remote access client initiates a connection to a remote access server, the user is authenticated, and the remote access client is assigned an IP address. If Network Access Quarantine Control is in use, the connection is placed in quarantine mode until a client-side script is run on the remote access client and the configuration of the remote access client is validated against current network policies. While the remote access connection is in quarantine mode, network access is limited. When the remote access server is notified that the configuration of the remote access client is validated against current network policies, quarantine mode is removed, and the remote access client is granted normal remote access.

The components for Network Access Quarantine Control are included in the Microsoft Windows Server 2003 Resource Kit. For instructions on setting up Network Access Quarantine Control, see "Configuring Network Access Quarantine Control" later in this chapter.

Note

Network Access Quarantine Control is designed to prevent clients with unsafe configurations from attaching to a private network. It does not protect a private network from malicious users who have obtained a valid set of credentials.

Processing a Connection Attempt Under Network Access Quarantine Control

Under Network Access Quarantine Control, the user on a quarantine-compatible remote access client uses an installed Connection Manager profile to connect with a quarantine-compatible remote access server. The remote access client passes its authentication credentials to the remote access server. The Routing and Remote Access service sends a RADIUS Access-Request message to the IAS server. The IAS server validates the authentication credentials of the remote access client and, assuming valid credentials, checks its remote access policies. If the connection attempt matches the quarantine policy, the connection is accepted with quarantine attributes and the connection is placed in quarantine mode.

While the connection attempt is in quarantine mode, the remote access server implements a set of network restrictions for the connection. These network restrictions are configured in IAS. The IAS server sends a RADIUS Access-Accept message that contains the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout attributes. The remote access client completes the remote access connection, obtaining an IP address and other configuration settings, and the Windows Server 2003 Routing and Remote Access service configures the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout settings for the connection. At this point, the remote access client can only successfully send traffic that matches the quarantine filters. The client must notify the remote access server that the client has passed network compliance testing within the time limit (in seconds) specified by the MS-Quarantine-Session-Timeout attribute in the quarantine remote access policy.

Note

The process described in this section incorporates the use of both the MS-Quarantine-IPFilter attribute and the MS-Quarantine-Session-Timeout attribute. Both attributes are optional.

The Connection Manager profile initiates a post-connect action, which runs the embedded client-side script. The script verifies that the remote access computer's configuration complies with network policy requirements. If the script runs successfully, the script runs the notification component, Rqc.exe, which notifies the remote access server that the remote access client complies with network policy.

The listener component on the remote access server, known as the Remote Access Quarantine Agent service (Rqs.exe), receives the notification. Routing and Remote Access removes the MS-Quarantine-IP Filter and MS-Quarantine-Session-Timeout settings from the connection, giving the remote access client normal access to the intranet.

Components of Network Access Quarantine Control

Figure 8.6 shows the components of Windows remote access for Network Access Quarantine Control.

click to expand
Figure 8.6: Components of Network Access Quarantine Control for Remote Access

This configuration consists of the following components:

  • Quarantine-compatible access clients

  • Quarantine-compatible access server

  • Quarantine-compatible RADIUS server

  • Quarantine resources

  • Accounts database

  • Quarantine remote access policy

Quarantine-compatible access clients

The remote access client must be a computer running one of the following operating systems: Microsoft Windows XP Professional, Windows XP Home Edition, Windows 2000, Windows Millennium Edition, Windows 98 Second Edition, or Windows Server 2003.

These versions of Windows support Connection Manager profiles that are created by the Connection Manager Administration Kit (CMAK) provided with Windows Server 2003 and contain:

  • A post-connect action setting that runs a network policy requirements script.

    The post-connect action setting is configured when the CM profile is created with CMAK.

  • A network policy requirements script

    The network policy requirements script performs validation checks on the remote access client computer to verify that it conforms to network policies. The script can be a custom executable file or as simple as a command file (also known as a batch file).

  • A notifier component.

    When the script has run successfully and the connecting computer has satisfied all of the network policy requirements verified by the script, the script executes a notifier component (an executable file) with the appropriate parameters. The notifier component sends a message to the quarantine-compatible remote access server that indicates a successful execution of the script. You can use your own notifier component or you can use Rqc.exe, which is provided with the Windows Server 2003 Resource Kit.

With these components installed, the remote access client computer uses the CM profile to perform its own network policy requirements check and indicate its success to the remote access server as part of the connection setup.

Quarantine-compatible access server

A quarantine-compatible remote access server requires the following components:

  • A computer running Windows Server 2003 and the Routing and Remote Access service.

    Routing and Remote Access with Windows Server 2003 supports the use of a listener component and the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout RADIUS vendor-specific attributes (VSAs), which are used to specify quarantine settings.

  • A listener component.

    The listener component listens for messages from quarantine-compatible remote access clients that indicate that their scripts have run successfully. You can create your own custom listener component (matched with your own custom notifier component) or you can install the Remote Access Quarantine Agent service (Rqs.exe) from the Kit.

With these components installed, the remote access server implements quarantine mode for connecting remote access clients and listens for notifier messages that the clients have satisfied network policy requirements and can be taken out of quarantine mode.

Quarantine-compatible RADIUS server

A quarantine-compatible RADIUS server requires a computer running Windows Server 2003 and IAS, which supports the configuration of the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout RADIUS vendor-specific attributes (VSAs) to specify quarantine settings for the quarantine-compatible remote access server.

Quarantine resources

In quarantine mode, a remote access client must have access to the following resources:

  • To perform name resolution, the client must have access to DNS servers.

  • To obtain the latest version of the script, the client must have access to file servers with anonymous access allowed.

  • To obtain instructions and components needed to bring the remote access client into compliance with network policies, the client must have access to Web servers with anonymous access allowed.

Accounts database

For Windows Server 2003-based networks, the Active Directory service is used as the accounts database to store user accounts and their dial-in properties.

Quarantine remote access policy

For Network Access Quarantine Control, you must configure a quarantine remote access policy with the appropriate conditions for remote access connections, and with profile settings that specify the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout attributes (configured on the Advanced tab of the profile).

  • The MS-Quarantine-IPFilter attribute is used to configure inbound and outbound packet filters to allow only the traffic generated by the notifier component. If you are using Rqc.exe, configure a single inbound packet filter to only allow traffic from TCP port 7250 and to TCP port 7250 (the default TCP port for Rqc.exe), and specify that all other traffic be discarded. Additional packet filters are needed in order for the quarantined remote access client to access the quarantine resources. These include filters that allow the remote access client to access DNS servers, file shares, and Web servers.

    The packet filters configured for the MS-Quarantine-IPFilter attribute provide the quarantine, or isolation, of the traffic of the remote access client until the notifier component on the remote access client indicates that the computer is in compliance with network policies.

  • The MS-Quarantine-Session-Timeout attribute specifies how long the remote access server waits to receive the notification that the script has executed successfully before terminating the connection.

Enhancing Security by Using Remote Access Account Lockout

To prevent dictionary attacks on remote server accounts, you can use remote access account lockout. When deciding whether or not to use remote access account lockout, remember that if you enable remote access account lockout, a malicious user can intentionally attempt multiple authentications for a user account to force the account to be locked out, thereby preventing the authorized user from being able to create a remote access connection.

Remote access account lockout is configured in the registry in Windows Server 2003. It is not related to the account lockout policy for domain or local user accounts.

To enable remote access account lockout, modify the following subkey in the registry on the server that authenticates remote access requests:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess \Parameters\AccountLockout

If the remote access server is configured for Windows authentication, modify the registry on that server. If the remote access server is configured for RADIUS authentication, and you are using IAS, modify the registry on the IAS server.

For more information about modifying the AccountLockout subkey, see "Configuring Remote Access Account Lockout for a VPN Solution" later in this chapter.

Caution

Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Referenceon the Microsoft Windows Server 2003 Deployment Kit companion CD or at http://www.microsoft.com/reskit.

If your organization is using smart cards, the smart card manufacturer controls account lockout for personal identification numbers (PINs) that are not valid. Recovery from account lockout as a result of an invalid PIN might require smart card replacement.

For more information about remote access account lockout, see the Internetworking Guide of the Windows Server 2003 Resource Kit (or see the Internetworking Guide on the Web at http://www.microsoft.com/reskit).

Optimizing Your Remote Access Server Design

In addition to increasing performance by upgrading server hardware, consider increasing availability, security, and performance by incorporating the following elements in your remote access design:

  • Redundant servers for increased availability

  • Network Load Balancing for increased availability and performance

Increasing Availability by Using Redundant Servers

Remote access solutions with redundant servers can provide higher availability for remote access clients. If degradation of service is not a critical issue, you can use your primary remote access servers as backups for each other. If service degradation is not acceptable, provide redundancy by enlisting an extra server to provide failure protection.

If one or more user groups require high-priority access, consider using separate remote access servers for these user groups.

Increasing Performance by Using Network Load Balancing

By using Network Load Balancing, which is available in Windows Server 2003, you can increase VPN server performance and availability. Network Load Balancing distributes traffic from remote access VPN clients among multiple VPN servers.

Network Load Balancing also provides immediate failover if a VPN server fails. If a VPN server fails, client sessions handled by that server also fail. Clients are prompted to log on again, and their new session is handled by one of the remaining hosts.

To provide load balancing for VPN clients, use the default port rule in configuring all hosts, as follows:

  • Set the port range to 0-65535 (the default). The default range covers all of the ports, so the port rule remains valid even if there is a change in the port numbers that you want to cover.

  • Accept the default filtering mode, load weight/equal load distribution, and affinity settings.

For more information about using Network Load Balancing in a VPN scenario, see "Deploying Network Load Balancing" in Planning Server Deployments of this kit.

Testing Your Remote Access Server Design

When you complete the design of your remote access server solution, test the design. Testing the design includes testing individual VPN client access to VPN servers, as well as comprehensive testing of the entire external connectivity design. If you are integrating multiple remote access solutions, test them together after testing them individually.

Because of vulnerabilities that exposure to the Internet might introduce, isolate your network perimeter from your intranet during testing. Do not integrate your network perimeter with your intranet until you are confident that you have addressed all security issues.

Be sure to test the ISP infrastructure, including the RADIUS proxy (if applicable), and a representative sampling of access points.

Testing is critical to the security of any external connectivity solution, and it is important for ensuring that the connections function as planned. Before testing, simulate both internal and external connections to prevent exposure and corruption of any part of your network.

Tools for Testing a Remote Access Server Design

The following tools are useful in testing a remote access server design:

  • TCP/IP troubleshooting tools, including Netsh, Ping, Pathping, Route, and Tracert.

  • Remote access logging in the Routing and Remote Access snap-in. The log includes authentication and accounting information.

  • Event Viewer. This is an administrative tool for Windows Server 2003 that displays monitoring and troubleshooting information from Windows and other programs.

  • Network Monitor. This is an optional networking component for Windows Server 2003 that allows a system administrator to capture and examine packets on a LAN and save the packets to a capture file.

  • Remote Access Event Tracing. This is enabled through Netsh.




Microsoft Corporation Microsoft Windows Server 2003 Deployment Kit(c) Deploying Network Services 2003
Microsoft Corporation Microsoft Windows Server 2003 Deployment Kit(c) Deploying Network Services 2003
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 146

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net