Deploying Dial-Up and VPN Remote Access Servers

C H A P T E R 8
Deploying Dial-up and

VPN Remote Access
Servers
You can use the remote access and security technologies in the Microsoft® Windows® Server 2003 operating
systems to provide remote users with secure and reliable access to your network resources. By using the
Routing and Remote Access service in Windows Server 2003, you can design and deploy a dial-up solution
or you can take advantage of the Internet by deploying a virtual private network (VPN) solution.
In This Chapter
Overview of Deploying Dial-up and VPN Remote Access Servers......................124
Process for Deploying Dial-up and VPN Remote Access Servers........................125
Choosing Dial-up or VPN................................................................................... .126
Designing a Remote Access Server Solution.....................................................130
Deploying a VPN Remote Access Server Solution................................ ..............156
Deploying a Dial-up Remote Access Server Solution.........................................176
Additional Resources........................................................................ .................179
Related Information
• For information about designing and deploying a public key infrastructure (PKI), see
“Designing a Public Key Infrastructure” in Designing and Deploying Directory and Security
Services of this kit.
• For more information about deploying smart cards, see “Planning a Smart Card
Deployment” in Designing and Deploying Directory and Security Services of this kit.
• For information about designing and deploying Internet Authentication Service (IAS), see
“Deploying IAS” in this book.
124 Chapter 8 Deploying Dial-up and VPN Remote Access Servers
Overview of Deploying Dial-up

and VPN Remote Access Servers
To support users who require access to your network from remote locations, you can deploy a dial-up
network, a VPN, or a combination of both. Dial-up networking enables remote users to dial in directly to a
remote access server on your network using a phone line. A virtual private network (VPN) enables remote
users who are connected to the Internet to establish a connection to a VPN server on your network.
In deciding which solution will best serve your organization, consider the relative cost-effectiveness of each
solution and how well it meets your organization’s requirements for security and availability. Also consider
the network infrastructure of the intranet needed to support your remote access server design. Without proper
design of the supporting infrastructure, remote access clients cannot obtain IP addresses and resolve intranet
names, and packets cannot be forwarded between remote access clients and intranet resources.
Use the process described in this chapter to design and deploy a new remote access solution or to reexamine
and improve your existing infrastructure. If you already have a dial-up or VPN infrastructure, you might
benefit from replacing existing components because of anticipated obsolescence or failure of components,
scalability limitations, or increased security requirements.
Before you begin work on your remote access server design, your organization should have deployed the
following supporting technologies.
• Active Directory® directory service to store and manage information about network
resources.
• A Public key infrastructure (PKI) to enable the use of certificate-based authentication.
• Internet Authentication Service (IAS) to provide authentication and authorization for dial-up
and VPN network access. As a RADIUS server, Windows Server 2003 IAS performs
authentication and authorization on behalf of any remote access server configured as a
RADIUS client.
All editions of Windows Server 2003 support VPN connections. However, some limitations apply to the
Microsoft® Windows® Server 2003, Web Edition, and Windows® Server 2003, Standard Edition, operating
systems. On computers running either of these operating systems, you can create as many as 1,000
connections, using Point-to-Point Tunneling Protocol (PPTP) ports or Layer Two Tunneling Protocol (L2TP)
ports. Windows Server 2003, Standard Edition, can accept 1,000 concurrent VPN connections; however,
Windows Server 2003, Web Edition, accepts only one VPN connection at a time. For more information about
features included in Windows Server 2003, Web Edition, see “Overview of Windows Server 2003, Web
Edition” in Help and Support for Windows Server 2003.
Additional Resources 125
Process for Deploying Dial-up

and VPN Remote Access Servers
The key to providing a secure and reliable remote access solution that meets your organization’s needs is to
carefully plan and test your remote access design after deciding whether to deploy a dial-up network, a VPN,
or a combination of both. Deploying a VPN remote access server involves different tasks than are required to
deploy a dial-up remote access server; however, often your remote access solution will involve elements of
both. Figure 8.1 shows the process for designing and deploying dial-up and VPN remote access servers.
Figure 8.1 Deploying Dial-up and VPN Remote Access Servers
Choosing Dial-up or VPN

With a secure network architecture based on Windows Server 2003 in place, the first step in designing a
remote access server solution is deciding whether to provide network access to remote clients by using
dial-up networking, a VPN solution, or a combination of both. Figure 8.2 shows the placement of this design
decision in the process for designing and deploying dial-up and VPN remote access servers.
Figure 8.2 Choosing Dial-up or VPN
Each method for providing remote access has advantages and disadvantages that you must weigh based on
the needs of your organization. A dial-up networking solution provides a secure data path over a circuit-
switched connection, and it provides the convenience of direct dial-up connectivity to your network for
mobile users. In contrast, a VPN solution, by using the Internet as a connection medium, saves the cost of
long-distance phone service and hardware costs. To mitigate the public nature of the Internet, VPNs use a
variety of security technologies, including tunneling, encryption, and authentication.
Using Dial-up Networking for Remote Access

In a dial-up networking solution, remote users call in to a remote access server on your network. Dial-up
lines are inherently more private than a solution that uses a public network such as the Internet. However,
with dial-up networking, your organization faces a large initial investment and continuing expenses
throughout the life cycle of the solution. These expenses include:
• Hardware purchase and installation. Dial-up networking requires an initial investment in
modems or other communication hardware, server hardware, and phone line installation.
• Monthly phone costs. Each phone line that is used for remote access increases the cost of
dial-up networking. If you use toll-free numbers or the callback feature to defray long
distance charges for your users, these costs can be substantial. Most businesses can arrange
a bulk rate for long distance, which is preferable to reimbursing users individually at their
more expensive residential rates.
• Ongoing support. The number of remote access users and the complexity of your remote
access design significantly affect the ongoing support costs for dial-up networking. Support
costs include network support engineers, testing equipment, training, and help desk
personnel to support and manage the deployment. These costs represent the largest portion of
your organization’s investment.
Figure 8.3 shows an example of a simple dial-up remote access networking design.
Figure 8.3 Dial-up Remote Access Design
Providing Remote Access over a VPN

In a VPN solution for remote access, users connect to your corporate network over the Internet. VPNs use a
combination of tunneling, authentication, and encryption technologies to create secure connections. To
ensure the highest level of security for a VPN deployment, use Layer Two Tunneling Protocol with Internet
Protocol security (L2TP/IPSec).
Many organizations with extensive remote access requirements implement a VPN solution. VPNs reduce
remote access expenses by using the existing Internet infrastructure. You can use a VPN to partially or
entirely replace your centralized, in-house, dial-up remote access infrastructure and legacy services.
VPNs offer two primary benefits:

• Reduced costs. Using the Internet as a connection medium saves long-distance phone
expenses and requires less hardware than a dial-up networking solution does.
• Sufficient security. Authentication prevents unauthorized users from connecting. Strong
encryption methods make it extremely difficult for a hacker to interpret the data sent across a
VPN connection.
Figure 8.4 shows an example of a simple VPN remote access networking design.
Figure 8.4 VPN Remote Access Design
Note
Regardless of the approach that you choose, you can increase
manageability of your remote access server solution by using IAS to
centralize VPN or dial-up networking authentication, authorization, and
accounting. For the Microsoft® Windows® 2000 Server family, IAS is a
RADIUS server; for the Windows Server 2003 family, IAS is a RADIUS
server and proxy. For information about designing and deploying IAS,
see “Deploying IAS” in this book.
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.
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
L2TP/IPSec
PPTP Advantages
Factor Advantages and
and Constraints
Constraints
Client operating Supported on clients running Natively supported on
systems Windows 2000, Windows XP, clients running
supported Windows Server 2003, Windows 2000,
Windows NT Workstation 4.0, Windows XP, or Windows
Windows Me, or Windows 98. Server 2003.
With Mls2tp.exe installed,
supported on clients
running Windows 98,
Windows Me, or
Windows NT
Workstation 4.0.
(continued)
Table 8.1 Advantages and Constraints of the PPTP and L2TP/IPSec VPN Protocols
(continued)
L2TP/IPSec
PPTP Advantages
Factor Advantages and
and Constraints
Constraints
Certificate For EAP-TLS authentication to To issue computer
support issue computer certificates to certificates to the VPN
the authenticating server and server and all VPN clients,
user certificates to all VPN L2TP/IPSec requires a
clients or to issue smart cards certificate infrastructure or
to all users, PPTP requires a a preshared key (PSK).
certificate infrastructure.
Security Provides data confidentiality. Offers the highest level of
(Captured packets cannot be security, providing data
interpreted without the confidentiality, data
encryption key.) integrity, data origin
Does not provide data integrity authentication, and replay
(proof that the data was not protection.
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.
Performance A VPN server supports more Because IPSec encryption
PPTP connections than is processing intensive, a
L2TP/IPSec connections. 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 If you locate L2TP/IPSec–
be located behind a NAT if the based clients or servers
NAT includes an editor that behind a NAT, both client
can translate PPTP. 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 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 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 CHAP, MS-CHAP, Optional encryption.
no data encryption MS-CHAP v2 (Connect even if no
encryption.)
Secured password with MS-CHAP, MS-CHAP v2 Required encryption.
MPPE data encryption (Disconnect if server
declines.)
Smart card with no data EAP-TLS Optional encryption.
encryption (Connect even if no
encryption.)
Smart card with data EAP-TLS Require encryption.
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 IPSec 56-bit Data
encryption Encryption Standard (DES)
Strong MPPE 56-bit data IPSec 56-bit DES
encryption
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
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 • Install a computer certificate on the
smart cards and EAP-TLS authenticating server for the VPN server.
• Install a user certificate on each smart
card.
PPTP-based VPN connection using • Install a computer certificate on the
registry-based user certificates and authenticating server for the VPN server.
EAP-TLS • 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.
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 Windows Server 2003
Resource 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.
Deploying a VPN Remote Access

Server Solution
Deploying a remote access server solution involves configuring the server as a VPN remote access server;
configuring routing on the VPN server and the VPN clients; and implementing security — installing any
certificates required for the authentication of remote clients, configuring encryption in requirements the
remote access policy for VPN connections, and optionally configuring remote access account lockout.
Figure 8.7 shows the process for deploying a VPN remote access server solution.
Figure 8.7 Deploying a VPN Remote Access Server Solution
Important
The procedures for deploying a VPN remote access server solution
assume that you have deployed Active Directory on the server, have a
PKI in place, and have deployed an IAS server.
For information about designing and deploying a PKI, see “Designing a
Public Key Infrastructure” in Designing and Deploying Directory and
Security Services of this kit. For information about designing and
deploying IAS, see “Deploying IAS” in this book. For more information
about Active Directory, see “Designing the Active Directory Logical
Structure” in Designing and Deploying Directory and Security Services
of this kit.
Configuring a VPN Remote Access Server

The configuration of a VPN remote access server involves the following tasks:
• Configure the server as a VPN remote access server.
• Configure TCP/IP on the server.
• Configure name resolution on the server.
• Configure packet filters for the server.
• Optionally, configure Network Access Quarantine Control.
Configuring the Server as a VPN Remote Access Server

To configure the server as a VPN remote access server, use the Configure Your Server Wizard and select
Remote access/VPN server as the server role, or use the Rounting and Remote Access snap-in. For
instructions on using the wizard, see “Remote access/VPN server role: Configuring a remote access/VPN
server” in Help and Support Center for Windows Server 2003.
Configuring TCP/IP on the VPN Server

After configuring the server as a remote access server, configure the TCP/IP settings for the Internet or
perimeter network interface and for the intranet interface.
Note
Because of routing issues related to configuring TCP/IP automatically,
it is recommended that you not configure a VPN server as a DHCP
client. Instead, manually configure TCP/IP on the intranet interfaces of
a VPN server. For a full discussion of the routing options for a VPN
server, see “Configuring Routing on a VPN Server” later in this chapter.
Manually configure the Internet or perimeter network interface of the VPN server with a default gateway.
Configure the TCP/IP settings with a public IP address, a subnet mask, and the default gateway of either the
firewall (if the VPN server is connected to a perimeter network) or an ISP router (if the VPN server is
connected directly to the Internet).
To configure TCP/IP for the Internet or perimeter network interface
1. In Control Panel, double-click Network Connections, and then double-click the network
adapter for the Internet or perimeter network interface.
2. In the network adapter status dialog box (for example, Local Area Connection Status),
click Properties.
3. Select Internet Protocol (TCP/IP), and then click Properties.
4. On the General tab, configure the IP address, subnet mask, and default gateway.
The IP address must be a public IP address assigned by an ISP. As an option, you can
configure the VPN server with a private IP address but assign it a published static IP address
by which it is known on the Internet. When packets are sent to and from the VPN server, a
NAT that is positioned between the Internet and the VPN server translates the published IP
address to the private IP address.
When you configure a VPN connection, give your VPN servers names that can be resolved
to IP addresses using DNS.
5. Click Advanced to display the Advanced TCP/IP Settings dialog box.
6. To prevent the VPN server from dynamically registering the public IP address of its Internet
interface with an intranet DNS server, on the DNS tab, clear the Register this connection’s
addresses in DNS check box. This check box is cleared by default.
7. To prevent the VPN server from registering the public IP address of its Internet interface
with intranet WINS servers, on the WINS tab, select the Disable NetBIOS over TCP/IP
check box. This check box is selected by default.
When you configure TCP/IP for the VPN server’s intranet interface, do not configure the default gateway on
the intranet connection. This will prevent default route conflicts with the default route pointing to the
Internet.
To configure TCP/IP for the intranet interface
1. In Control Panel, double-click Network Connections, and then double-click the network
adapter for intranet interface.
2. In the network adapter status dialog box (for example, Local Area Connection 2 Status),
click Properties.
4. On the General tab, configure the IP address, subnet mask, and DNS server address.
To prevent default route conflicts with the default route pointing to the Internet, do not
configure the default gateway on the intranet connection.
5. Click Advanced to display the Advanced TCP/IP Settings dialog box.
6. On the WINS tab, configure the IP addresses of your WINS servers.
Configuring Name Resolution on a VPN Server

If you use Domain Name System (DNS) to resolve intranet host names or Windows Internet Name Service
(WINS) to resolve intranet NetBIOS names, manually configure the VPN server with the IP addresses of the
appropriate DNS and WINS servers.
During the PPP connection setup process, VPN clients receive the IP addresses of DNS and WINS servers.
By default, the VPN clients inherit the DNS and WINS server IP addresses configured on the VPN server.
However, VPN clients that are capable of sending a DHCPINFORM message (computers running
Windows 2000, Windows XP, or Windows Server 2003) get their DNS and WINS server IP addresses from
the DHCP server.
Configuring Packet Filters for a VPN Server

The firewall is configured with rules to filter the packets that a VPN server sends and receives and control
intranet traffic to and from VPN clients, based on your network security policies. Packet filtering is based on
the fields of inbound and outbound packets.
The Routing and Remote Access Server Setup Wizard for Windows Server 2003 and Windows Server 2000
Service Pack 2 (SP2) or later automatically configures the appropriate packet filters for VPN traffic.
Alternatively, you can use the Routing and Remote Access snap-in to configure the packet filters.
The following sections summarize the packet filters that are required when the VPN server is placed behind a
firewall or in front of a firewall. For procedures explaining how to enter the packet filter configurations, see
“VPN servers and firewall configuration” in Help and Support Center for Windows Server 2003.
Configuring Filters for a VPN Server Behind a Firewall

If the VPN server is behind a firewall, you must configure packet filters for both an Internet interface and a
perimeter network interface. 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 Internet.
PPTP connections
For a PPTP connection, configure the following packet filters on the Internet and perimeter network
interfaces of the firewall.
Internet interface of the firewallOn the firewall’s Internet interface, configure the inbound and
outbound filters in Table 8.5, specifying that all packets are dropped except those that are selected by the
filters.
Table 8.5 VPN Server Behind a Firewall: PPTP Filters on the Firewall’s Internet Interface
Filter Action
Destination IP address = Allows PPTP tunnel maintenance
Perimeter network interface of traffic from the PPTP client to the
VPN server PPTP server.
TCP destination port = 1723
(0x6BB)
Destination IP address = Allows PPTP tunneled data from
Perimeter network interface of the PPTP client to the PPTP
VPN server server.
IP Protocol ID = 47 (0x2F)
Destination IP address = Required only when the VPN
Inbound Perimeter network interface of server is acting as a VPN client (a
VPN server calling router) in a site-to-site
TCP source port = 1723 (also known as router-to-router)
(0x6BB) VPN connection. If you allow all
traffic to the VPN server from TCP
port 1723, network attacks can
emanate from sources on the
Internet that use this port. You
should only use this filter in
conjunction with the PPTP filters
that are also configured on the
VPN server.
Source IP address = Perimeter Allows PPTP tunnel maintenance

network interface of VPN server traffic from the PPTP server to the
TCP source port = 1723 PPTP client.
(0x6BB)
Source IP address = Perimeter Allows PPTP tunneled data from
network interface of VPN server the PPTP server to the PPTP
IP Protocol ID = 47 (0x2F) client.
Source IP address = Perimeter Required only when the VPN

Outbound network interface of VPN server server is acting as a VPN client (a
TCP destination port = 1723 calling router) in a site-to-site
traffic from the VPN server to TCP
Internet using this port. You
should only use this filter in
conjunction with the PPTP filters
that are also configured on the
VPN server.
Perimeter network interface of the firewall On the firewall’s perimeter network interface,
configure the inbound and outbound filters in Table 8.6, specifying that all packets are dropped except those
that are specified by the filters.
Table 8.6 VPN Server Behind a Firewall: PPTP Filters on the Perimeter Network Interface
Filter Action
Source IP address = Perimeter Allows PPTP tunnel maintenance
network interface of VPN server traffic from the VPN server to the
TCP source port = 1723 (0x6BB) VPN client.
Source IP address = Perimeter Allows PPTP tunneled data from

network interface of VPN server the VPN server to the VPN client.
IP Protocol ID = 47 (0x2F)
Inbound Source IP address = Perimeter Required only when the VPN
network interface of VPN server server is acting as a VPN client (a
TCP destination port = 1723 calling router) in a site-to-site
traffic from the VPN server to TCP
Internet using this port.
Destination IP address = Allows PPTP tunnel maintenance
Perimeter network interface of traffic from the PPTP client to the
VPN server PPTP server.
TCP source port = 1723 (0x6BB)
Destination IP address = Allows PPTP tunneled data from
Perimeter network interface of the PPTP client to the PPTP
VPN server server.
Outbound IP Protocol ID = 47 (0x2F)
Destination IP address = Required only when the VPN
Perimeter network interface of server is acting as a VPN client (a
VPN server calling router) in a site-to-site
TCP source port = 1723 (0x6BB) VPN connection. If you allow all
traffic to the VPN server from TCP
Internet using this port.
L2TP/IPSec connections
For an L2TP/IPSec connection, configure the following packet filters on the Internet and perimeter network
interfaces of the firewall.
Internet interface of the firewallOn the firewall’s Internet interface, configure the inbound and
outbound filters in Table 8.7, specifying that all packets are dropped except those that are specified by the
filters.
Table 8.7 VPN Server Behind a Firewall: L2TP/IPSec Filters on the Firewall’s Internet
Interface
Filter Action
Destination IP address = Allows IKE traffic to the VPN
Perimeter network interface of server.
VPN server
UDP destination port = 500
(0x1F4)
Destination IP address = Allows IPSec NAT-T traffic to the
Perimeter network interface of VPN server.
Inbound VPN server
(0x1194)
Destination IP address = Allows IPSec ESP traffic to the
VPN server
IP Protocol ID = 50 (0x32)
Source IP address = Perimeter Allows IKE traffic from the VPN
network interface of VPN server server.
UDP source port = 500 (0x1F4)
Source IP address = Perimeter Allows IPSec NAT-T traffic from
network interface of VPN server the VPN server.
Outbound
UDP source port = 4500
(0x1194)
Source IP address = Perimeter Allows IPSec ESP traffic from the
network interface of VPN server VPN server.
No filters are required for L2TP traffic at UDP port 1701. All L2TP traffic at the firewall, including tunnel
maintenance and tunneled data, is encrypted as an IPSec ESP payload.
Perimeter network interface of the firewall On the firewall’s perimeter network interface,
configure the inbound and outbound filters in Table 8.8, specifying that all packets are dropped except those
that are selected by the filters.
Table 8.8 VPN Server Behind a Firewall: L2TP/IPSec Filters on the Firewall’s Perimeter
Network Interface
Filter Action
Source IP address = Perimeter Allows IKE traffic from the VPN
network interface of VPN server server.
UDP source port = 500 (0x1F4)
Source IP address = Perimeter Allows IPSec NAT-T traffic from
network interface of VPN server the VPN server.
Inbound
(0x1194)
Source IP address = Perimeter Allows IPSec ESP traffic from the
network interface of VPN server VPN server.
Destination IP address = Allows IKE traffic to the VPN
Perimeter network interface of server.
VPN server
(0x1F4)
Destination IP address = Allows IPSec NAT-T traffic to the
Outbound VPN server
(0x1194)
Destination IP address = Allows IPSec ESP traffic to the
VPN server
Configuring Filters for a VPN Server in Front of a Firewall

When a VPN server is in front of a firewall and connected to the Internet, configure inbound and outbound
packet filters on the VPN server to allow only VPN traffic to and from the IP address of the VPN server’s
Internet interface. Use this configuration if your VPN server is in a perimeter network, with one firewall
positioned between the VPN server and the intranet and another between the VPN server and the Internet.
PPTP connections
For a PPTP connection, configure the VPN server with the inbound and outbound filters in Table 8.9,
specifying that all packets be dropped except those that are specified by the filters. These filters are
automatically configured when you:
• Rrun the Routing and Remote Access Server Setup Wizard and choose the Remote access
(dial-up or VPN) option.
• Select the correct interface.
• Select the Enable security on the selected interface by setting up packet filters option on
the VPN Connection page. This setting is enabled by default.
Table 8.9 VPN Server in Front of a Firewall: Packet Filters for PPTP
Filter Action
Destination IP address = Internet Allows PPTP tunnel maintenance
interface of VPN server to the VPN server.
Subnet mask = 255.255.255.255
TCP destination port = 1723
Destination IP address = Internet Allows PPTP tunneled data to the
interface of VPN server VPN server.
Inbound Subnet mask = 255.255.255.255
IP Protocol ID = 47
Destination IP address = Internet Required only when the VPN
interface of VPN server server is acting as a VPN client (a
Subnet mask = 255.255.255.255 calling router) in a site-to-site
VPN connection. Accepts TCP
TCP (established) source port =
traffic only when a VPN server
1723
initiates the TCP connection.
Source IP address = Internet Allows PPTP tunnel maintenance
interface of VPN server traffic from the VPN server.
Subnet mask = 255.255.255.255
TCP source port = 1723
Source IP address = Internet Allows PPTP tunneled data from
interface of VPN server the VPN server.
Outbound Subnet mask = 255.255.255.255
IP Protocol ID = 47
Source IP address = Internet Required only when the VPN
interface of VPN server server is acting as a VPN client (a
Subnet mask = 255.255.255.255 calling router) in a site-to-site
VPN connection. Sends TCP
TCP (established) destination
traffic only when a VPN server
port = 1723
initiates the TCP connection.
L2TP/IPSec connections
For an L2TP/IPSec connection, configure the VPN server with the inbound and outbound filters in
Table 8.10, specifying that all packets be dropped except those that are specified by the filters.
Table 8.10 VPN Server in Front of a Firewall: Packet Filters for L2TP/IPSec
Filter Action
Destination IP address = Internet Allows IKE traffic to the VPN
interface of VPN server server.
Subnet mask = 255.255.255.255
Destination IP address = Internet Allows L2TP traffic from the VPN
interface of VPN server client to the VPN server.
Inbound
Subnet mask = 255.255.255.255
Destination IP address = Internet Allows IPSec NAT-T traffic from
interface of VPN server the VPN client to the VPN server.
Subnet mask = 255.255.255.255
Source IP address = Internet Allows IKE traffic from the VPN
interface of VPN server server.
Subnet mask = 255.255.255.255
Source IP address = Internet Allows L2TP traffic from the VPN
interface of VPN server server to the VPN client.
Outbound
Subnet mask = 255.255.255.255
Source IP address = Internet Allows IPSec NAT-T traffic from
interface of VPN server the VPN server to the VPN client
Subnet mask = 255.255.255.255
Configuring Network Access Quarantine Control

Perform the following steps to configure Network Access Quarantine Control:
1. Create quarantine resources.
a. Configure a DNS server, a file server and share point for updated scripts, and a Web
server as quarantine resources.
b. Create Web pages containing network policy compliance instructions.
2. Create a notification component that notifies the remote access server that the remote access
client complies with network policy requirements. The notification component sends a
notifier message that indicates that a client-side script has run successfully on the remote
access client, network policy requirements have been met, and the remote access connection
quarantine restrictions can be removed. If you do not want to create your own notification
component, you can use Rqc.exe in the Windows Server 2003 Resource Kit.
3. Create a client-side script that validates the client configuration based on your network
policy requirements. If all of the verification checks in the script are successful, the script
executes the notification component with the appropriate parameters.
4. Create a listener component that receives the network policy compliance notification from
the notification component. If you do not want to create a listener component, use Rqs.exe in
the Windows Server 2003 Resource Kit.
Note
Rqs.exe and Rqc.exe use TCP port 7250 by default. When you create
the quarantine policy, you must configure quarantine inbound filters to
allow network traffic on TCP port 7250. Otherwise, Rqc.exe, which runs
on client computers, cannot notify Rqs.exe that the client-side script
has run successfully. If you specify another TCP port for Rqc.exe and
Rqs.exe, you must configure the filter to allow traffic on that TCP port.
5. Create a quarantine Connection Manager profile, to be installed on all remote access clients
that access servers participating in Network Access Quarantine Control. Only those remote
access clients that have the quarantine Connection Manager profile installed can obtain a
full-access connection.
Use the Windows Server 2003 Connection Manager Administration Kit (CMAK) to create a
profile with the following elements:
• Specify a post-connect action to run the client-side script with the appropriate
parameters.
• Embed the client-side script and the notification component within the profile.
For information about creating a Connection Manager profile using CMAK, see “Deploying
Remote Access Clients Using Connection Manager” in this book.
6. Install the Quarantine Connection Manager profile on all remote access clients that access
servers participating in Network Access Quarantine Control.
7. Use the New Remote Access Policy Wizard to create a quarantine remote access policy that
restricts a remote access client’s access while the client computer’s configuration is verified
against network policy requirements. The quarantine remote access policy can contain the
following attributes:
• MS-Quarantine-IPFilter, to restrict a quarantined remote access client’s access to only
quarantine resources and the port designated for notification traffic.
• MS-Quarantine-Session-Timeout, to restrict the length of time during which a client can
remain connected in quarantine mode before being disconnected.
To be quarantine-compatible, a remote access server must be 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 RADIUS vendor-specific attributes (VSAs) MS-Quarantine-IP Filter and
MS-Quarantine-Session-Timeout, which are used to specify quarantine settings.
Note
For an overview of Network Access Quarantine Control, see “Planning
for Network Access Quarantine Control” earlier in this chapter.
Configuring Routing for a VPN Solution

Configure routing on your intranet to allow computers to reach VPN clients. After either configuring static
routing on the VPN server or configuring the server as a dynamic router, configure routing on the VPN
clients.
Configuring Routing on a VPN Server

To enable a VPN server to correctly forward traffic to locations on your intranet, perform one of two routing
configurations:
• Configure the server with static routes that summarize all possible IP addresses on the
intranet.
• Configure the server with routing protocols that enable it to act as a dynamic router,
automatically adding routes for intranet subnets to its routing table.
In a small, stable networking environment, static routing might be an appropriate choice for a VPN solution.
However, in most corporate networking environments, the increased administrative overhead required to
maintain static routes is prohibitive. The preferred method for a VPN solution is to configure the VPN server
as a dynamic router.
Configuring Static Routes on the Server

If you manually configure IP address ranges for a static address pool on any of your VPN servers, and if any
of the ranges is an off-subnet range, your intranet routing infrastructure must include routes representing the
off-subnet address ranges. To provide the best summarization of address ranges for routes, choose your
address ranges so that they can be expressed using a single prefix and subnet mask.
To ensure this, add static routes representing the off-subnet address ranges to the routers neighboring the
VPN servers, and then use the routing protocol of your intranet to propagate the off-subnet routes to other
routers. When you add the static routes to the neighboring routers, specify that the gateway or the next hop
address is the intranet interface of the VPN server.
For information about adding static routes, see “Configuring the branch office network” in Help and Support
Center for Windows Server 2003.
Configuring the Server as a Dynamic Router

If you are using RIP or OSPF, you can configure any VPN server that is using off-subnet address ranges as a
RIP or OSPF router.
For OSPF, you must also configure the VPN server as an autonomous system boundary router (ASBR). For
more information, see “OSPF design considerations” in Help and Support Center for Windows Server 2003.
If you use a routing protocol other than a RIP or OSPF, such as Interior Gateway Routing Protocol (IGRP),
on the VPN server’s neighboring intranet router, configure the interface connected to the subnet to which the
VPN server is assigned for RIP or OSPF and configure all other interfaces for IGRP.
To configure the VPN server with an on-subnet address range, configure the VPN server to obtain IP
addresses through DHCP or manually configure on-subnet address ranges.
For information about:
• Configuring the VPN server as a RIP router, see “Configure RIP for IP” in Help and Support
Center for Windows Server 2003.
• Configuring the VPN server as an OSPF router, see “OSPF design considerations” and
“Configure OSPF” in Help and Support Center for Windows Server 2003.
Configuring Routing on a VPN Client

By default, when a Windows-based VPN client makes a VPN connection, the VPN client automatically adds
a new default route for the VPN connection and sets a higher metric for the existing default route. Because a
new default route has been added, all Internet locations, except for the IP address of the tunnel server and
locations based on other routes, are not reachable for the duration of the VPN connection.
Whether the default route is acceptable for the VPN connection depends on your remote access clients’ needs
(whether they need simultaneous access to both the intranet and the Internet) and security issues. For a full
discussion of the routing options for VPN remote access clients, see “Determining Routing for VPN Remote
Access Clients” earlier in this chapter.
Based on your design, implement one of the following routing options on the VPN client:
• If the remote access user does not require concurrent access to intranet and Internet
resources, use the default gateway for the VPN connection.
• If the remote access user requires concurrent access to intranet and Internet resources over a
VPN connection, choose one of the following options:
• If you want to allow Internet access through the organization’s intranet, use the default
gateway for your VPN connection.
Internet traffic between the VPN client and Internet hosts passes though firewalls or
proxy servers as though the VPN client were physically connected to the organization’s
intranet. This method can affect performance, but it enables an organization to filter and
monitor Internet access according to its network policies while the VPN client is
connected to the organization network.
• If the addressing within your intranet is based on a single class-based network ID, and
the addresses assigned to VPN clients are from that single class-based network ID,
prevent the use of the default gateway for your VPN connection.
• If the addressing within your intranet is not based on a single class-based network ID,
prevent the use of the default gateway for your VPN connection. Then, use one of the
split tunneling methods described in “Determining Routing for VPN Remote Access
Clients” earlier in this chapter.
To prevent the VPN client from creating a new default route during a VPN
connection
1. In Control Panel, double-click Network Connections, and then double-click the name of the
VPN connection.
2. In the Connect dialog box, click Properties.
3. In the properties dialog box for the VPN connection, click the Networking tab.
5. On the General tab, click Advanced to display the Advanced TCP/IP Settings dialog box.
6. To prevent a default route from being created during a VPN connection, on the General tab,
clear the Use default gateway on remote network check box.
No default route will be created for the connection. However, a route corresponding to the
Internet address class of the assigned IP address will be created. For example, if the IP
address assigned during the connection process is 10.0.12.119, the Windows Server 2003–
based or Windows XP–based VPN client creates a route for the class-based network ID
10.0.0.0 with the subnet mask 255.0.0.0.
Implementing Security for a VPN Solution

After configuring the VPN server as a remote access server and configuring routing on both the server and
the remote access clients, implement security of a VPN solution by performing the following tasks:
• Install certificates for L2TP/IPSec VPN connections.
• Configure the appropriate level of data encryption.
• Optionally, configure remote access account lockout.
Installing Certificates for VPN Connections

A certificate infrastructure is a requirement for L2TP/IPSec-based VPN connections. Certificates provide
stronger authentication security than password-based authentication does.
To provide a certificate infrastructure for a VPN client that makes L2TP/IPSec connections:
1. Install a certificate in the Local Computer certificate store on the VPN server.
2. Install a user certificate in the Current User certificate store of each client.
The certificate provides authentication for establishing IPSec security associations (SAs).
To provide a certificate infrastructure for user-level authentication with EAP-TLS:
1. Install a certificate on the authenticating server for the VPN server.
2. If you are not using smart cards, install a registry-based user certificate on each client.
-Or-
If you are using smart cards, install a certificate on each smart card distributed to a VPN
client user.
Before you can install a certificate, a certification authority must be present and reachable. For a computer in
a Windows Server 2003 domain, you can use auto-enrollment or the Certificates snap-in to install a
certificate. Alternatively, you can install a certificate by using a Web browser to connect the VPN client to the
CA Web enrollment agent. To install a certificate by using a CA Web enrollment agent, perform the following
procedure:
To use the CA Web enrollment tool to install a certificate on a VPN client
1. Use a Web browser to connect the VPN client to the CA Web enrollment tool at
http://ServerName/certsrv, where ServerName is the name of the server hosting the CA.
2. Click Request a certificate, and then click Advanced Certificate Request.
3. Click Create and submit a request to this CA to display a Web form for entering
certificate information.
4. Enter the required information on the Web form, and then click Submit.
5. Click Install this certificate.
For information about:
• Using the Certificates snap-in to install a certificate, see “Using certificates” in Help and
• Using certificate autoenrollment to install a certificate, see “Certificate autoenrollment” in
Help and Support Center for Windows Server 2003.
• Deploying smart cards, see “Planning a Smart Card Deployment” in Designing and
Deploying Directory and Security Services of this kit.
Configuring Encryption for a VPN Solution

In the remote access policy that governs VPN connections on the server, set the appropriate encryption
strengths for PPTP and L2TP/IPSec connections. For a procedure for entering encryption settings in a remote
access policy, see “Remote access/VPN server role: Configuring a remote access/VPN server” in Help and
For PPTP-based VPN connections, specify one of the following encryption strengths:
• To support MPPE with a 40-bit key, select Basic.
• To support MPPE with a 56-bit key, select Strong.
• To support MPPE with a 128-bit key, select Strongest.
For L2TP/IPSec-based VPN connections, specify one of the following encryption strengths:
• To support 56-bit DES, select either Basic or Strong.
• To support 3DES encryption, select Strongest.
Note
The No Encryption level, which allows connections that do not use
data encryption, is not recommended.
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.
Configuring Remote Access Account Lockout for a VPN

Solution
If you will use remote access account lockout to prevent online dictionary attacks, enable remote access
account lockout by modifying the AccountLockout subkey in registry on the server that authenticates remote
access requests.
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.
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 Reference
on the Windows Server 2003 Deployment Kit companion CD or at
http://www.microsoft.com/reskit.
The AccountLockout subkey can be found in the following subkey:

HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters
The AccountLockout subkey does not exist in the registry until you enable the Routing and Remote Access
service or install the Internet Authentication Service.
To configure remote access account lockout, modify two entries in the AccountLockout subkey:
1. To enable account lockout, set MaxDenials to 1 or greater.
MaxDenials sets the maximum number of failed attempts that can occur within the
configured reset time before the account is locked out. By default, MaxDenials is set to
zero, which disables account lockout.
2. To change the interval at which the failed attempts counter is reset, set the number of
minutes in ResetTime (mins).
By default, the failed attempts counter is reset every 48 hours (a value of 0xb40, or 2,880
minutes). To modify this interval, enter the preferred number of minutes.
For more information about remote access account lockout, see “Remote Access Server” in the
Note
To manually reset a user account that has been locked out before the
failed attempts counter is automatically reset, delete the following
registry subkey, which corresponds to the user’s account name:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Remo
teAccess\Parameters\AccountLockout\domainname:username.
Deploying a Dial-up Remote

Access Server Solution
Deploying a dial-up remote access server involves three major tasks: configuring a Windows Server 2003–
based server as a dial-up remote access server, configuring the LAN adapter to provide the server with a
connection to the intranet, and configuring the appropriate level of encryption strangth in the dial-up remote
access policy. Figure 8.8 shows the process for deploying a dial-up remote access server solution.
Figure 8.8 Deploying a Dial-up Remote Access Server Solution
Configuring a Dial-up Remote Access

Server
To provide dial-up access to your organization’s intranet, configure a computer running Windows
Server 2003 as a dial-up remote access server.
Before configuring the server as a dial-up remote access server, you must enable the Routing and Remote
Access service, which is installed automatically with Windows Server 2003. Use the Routing and Remote
Access Server Setup Wizard. For instructions on using the wizard, see “Remote access/VPN server role:
Configuring a remote access/VPN server” in Help and Support Center for Windows Server 2003.
Note
You can optionally implement Network Access Quarantine Control to
quarantine each new remote access connection until the configuration
of the client computer can be verified against network policy
restrictions. For more information, see “Planning for Network Access
Quarantine Control” and “Configuring Network Access Quarantine
Control” earlier in this chapter.
With Routing and Remote Access enabled, configure the properties of a dial-up remote access server by
using the Routing and Remote Access snap-in.
To configure a server for dial-up remote access
1. Open the Routing and Remote Access snap-in.
2. In the console tree, right-click the server name, and then click Properties.
3. On the General tab of the Server Properties dialog box, verify that the Remote access
server check box is selected.
4. On the Security tab, set up authentication for dial-up remote access clients:
a. Click Authentication Methods, and in the dialog box select the authentication
methods that the server will accept for dial-up connections.
Note The server is configured by default to accept certain authentication

methods. You can use remote access policies to control which
authentication methods to accept. 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.
b. Under Authentication Provider on the Security tab, select the authentication provider
to use for dial-up networking clients.
c. Under Accounting Provider, select and configure the accounting provider to use for
recording dial-up connection accounting information.
5. On the IP tab, set up routing for remote access clients:

a. Verify that the Enable IP routing and Allow IP-based remote access and demand-
dial connections check boxes are selected.
b. If you are using DHCP to obtain IP addresses for remote access clients, select
Dynamic Host Configuration Protocol (DHCP).
-Or-
Select Static address pool, and then configure ranges of IP addresses that are
dynamically assigned to dial-up networking clients.
If the static IP address pool consists of ranges of IP addresses for a separate subnet,
either enable an IP routing protocol on the remote access server or add static IP routes
for each range to your IP routing infrastructure. If the routes are not added, remote
access clients cannot receive traffic from resources on the intranet.
Configuring a Dial-up Connection to the

Intranet
A LAN adapter provides the connection from a dial-up remote access server to the intranet. To enable this
connection, you must configure TCP/IP on the LAN adapter and, on the dial-up remote access server,
configure the modem ports for remote access.
Configuring TCP/IP on the LAN Adapter

Configure the following TCP/IP settings on the LAN adapter that provides the connection from the dial-up
remote access server to the intranet:
• The IP address and subnet mask assigned by a network administrator.
• The default gateway of a local router.
• The IP addresses of DNS and WINS servers.
Configuring a Connection to Dial-up Networking Clients

To enable multiple dial-up clients to connect to the intranet simultaneously, the dial-up solution must have a
modem bank connected to a telecommunications provider. The modem bank adapter includes drivers that you
install on the dial-up remote access server.
Configuring Dial-in Ports for Remote Access

With the modem bank adapter drivers installed, the modem bank appears as a device with multiple modem
ports. Use the Routing and Remote Access snap-in to configure all of the active modem bank ports on the
server for remote access.
To configure the ports of a device for remote access

1. Open the Routing and Remote Access snap-in.
2. In the console tree, right-click Ports, and then click Properties.
3. In the Ports Properties dialog box, select the device that you want to configure, and then
click Configure.
4. In the Configure Device dialog box, select the appropriate routing connection options.
Configuring Encryption for a Dial-up

Solution
In the remote access policy that governs connections for remote access on the dial-up remote access server,
use Routing and Remote Access to set the appropriate encryption level. For a procedure for entering
encryption settings in a remote access policy, see “Configuring authentication and data encryption” in Help
and Support Center for Windows Server 2003.
In the remote access policy for dial-up connections on the dial-up remote access server, choose one of the
following encryption levels:
• To use MPPE with a 40-bit key, select Basic.
• To use MPPE with a 56-bit key, select Strong.
• To use MPPE with a 128-bit key, select Strongest.
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.
Additional Resources
These resources contain additional information and tools related to this chapter.
Related Information
• “Designing a Public Key Infrastructure” in Designing and Deploying Directory and Security
Services of this kit.
• “Deploying Smart Cards” in Designing and Deploying Directory and Security Services of
this kit.
• “Deploying IAS” in this book.
• “Deploying Remote Access Clients Using Connection Manager” in this book.
• The Internetworking Guide of the Windows Server 2003 Resource Kit (or see the
Internetworking Guide on the Web at http://www.microsoft.com/reskit) for more information
about Routing and Remote Access.
Related Help Topics

For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click
Set search options. Under Help Topics, select the Search in title only checkbox.
• “Remote access/VPN server role: Configuring a remote access/VPN server” in Help and
• “Configure RIP for IP” in Help and Support Center for Windows Server 2003 for
information about configuring the VPN server as an RIP router.
• “OSPF design considerations” and “Configure OSPF” in Help and Support Center for
Windows Server 2003 for information about configuring a VPN server as an OSPF router.
• “OSPF design considerations” in Help and Support Center for Windows Server 2003 for
information about configuring a VPN server as an autonomous system boundary router
(ASBR).
• “Introduction to remote access policies” in Help and Support Center for Windows
Server 2003.
• “Configuring authentication and data encryption” in Help and Support Center for Windows
Server 2003 for a procedure for setting the encryption level in a remote access policy.
• “VPN servers and firewall configuration” in Help and Support Center for Windows
Server 2003 for procedures explaining how to configure packet filters on the firewall and the
VPN server.
• “Configuring the branch office network” in Help and Support Center for Windows
Server 2003.
• “Using certificates” in Help and Support Center for Windows Server 2003 for information
about using the Certificates snap-in to install a certificate.
• “Certificate autoenrollment” in Help and Support Center for Windows Server 2003 for
information about using certificate autoenrollment to install a certificate.

Deploying Dial-Up and VPN Remote Access Servers

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Deploying Dial-Up and VPN Remote Access Servers

Uploaded by

Copyright:

Available Formats

C H A P T E R 8

Deploying Dial-up and

Overview of Deploying Dial-up

Process for Deploying Dial-up

Choosing Dial-up or VPN

Using Dial-up Networking for Remote Access

Figure 8.3 Dial-up Remote Access Design

Providing Remote Access over a VPN

VPNs offer two primary benefits:

Designing a Remote Access

Determining Hardware Requirements

Determining Hardware Requirements for Dial-up Networking

Determining Hardware Requirements for VPN

Performing Capacity Planning

Considering Outsourcing Options

Placing Remote Access Servers

VPN Server Behind the Firewall

VPN Server in Front of the Firewall

Determining Routing for VPN Remote

Choosing Between Routing Approaches

Choosing Among Split Tunneling Options

Obtaining IP Addresses for Remote Access Clients

Planning Security for a VPN

Selecting a VPN Protocol

NAT Requirements for VPN Protocols

Selecting an Authentication Protocol

Authentication Protocols for PPTP VPN Connections

MS-CHAP and MS-CHAP MS-CHAP and MS-CHAP v2 are password-based authentication

Authentication Protocols for L2TP/IPSec Connections

Guidelines for Selecting Authentication Protocols

Selecting the Scope and Level of Encryption

Protection Provided by Link Encryption

Providing End-to-End Encryption

Planning a Certificate Infrastructure to Support Client

Planning for Network Access Quarantine Control

Processing a Connection Attempt Under Network Access

Components of Network Access Quarantine Control

This configuration consists of the following components:

Quarantine-compatible access server

Enhancing Security by Using Remote Access Account

Optimizing Your Remote Access Server

Increasing Availability by Using Redundant Servers

Increasing Performance by Using Network Load Balancing

Testing Your Remote Access Server Design

Tools for Testing a Remote Access Server Design

Deploying a VPN Remote Access

Configuring a VPN Remote Access Server

Configuring the Server as a VPN Remote Access Server

Configuring TCP/IP on the VPN Server

Configuring Name Resolution on a VPN Server

Configuring Packet Filters for a VPN Server

Configuring Filters for a VPN Server Behind a Firewall

Source IP address = Perimeter Allows PPTP tunnel maintenance

Source IP address = Perimeter Required only when the VPN

Source IP address = Perimeter Allows PPTP tunneled data from

Configuring Filters for a VPN Server in Front of a Firewall

Configuring Network Access Quarantine Control

Configuring Routing for a VPN Solution

Configuring Routing on a VPN Server

Configuring Static Routes on the Server

Configuring the Server as a Dynamic Router

Configuring Routing on a VPN Client

Implementing Security for a VPN Solution