Embed Size (px)
Citation preview
Overview of Deploying Dial-up and VPN Remote Access ServersUpdated: March 28, 2003
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.
Process for Deploying Dial-up and VPN Remote Access ServersUpdated: March 28, 2003
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 VPNUpdated: March 28, 2003
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 an attacker 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 Internet Authentication Service (IAS)" in this
book.
Designing a Remote Access Server SolutionUpdated: March 28, 2003
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
Considering Outsourcing OptionsUpdated: March 28, 2003
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 ServersUpdated: March 28, 2003
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
Updated: March 28, 2003
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 VPNUpdated: March 28, 2003
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
Internet Authentication Service (IAS)" in this book.
Optimizing Your Remote Access Server DesignUpdated: March 28, 2003
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 DesignUpdated: March 28, 2003
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 SolutionUpdated: March 28, 2003
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 Internet Authentication Service (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 ServerUpdated: March 28, 2003
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 ServerUpdated: March 28, 2003
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 ServerUpdated: March 28, 2003
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. SelectInternet 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.
3. Select Internet Protocol (TCP/IP), and then 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.
7. Configuring Name Resolution on a VPN Server8. Updated: March 28, 2003
9. 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.
10. 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
Updated: March 28, 2003
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 firewall On 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
Inbound Destination IP address = Perimeter network interface of VPN serverTCP destination port = 1723 (0x6BB)
Allows PPTP tunnel maintenance traffic from the PPTP client to the PPTP server.
Destination IP address = Perimeter network interface of VPN serverIP Protocol ID = 47 (0x2F)
Allows PPTP tunneled data from the PPTP client to the PPTP server.
Destination IP address = Perimeter network interface of VPN serverTCP source port = 1723 (0x6BB)
Required only when the VPN server is acting as a VPN client (a calling router) in a site-to-site (also known as router-to-router) 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.
Outbound Source IP address = Perimeter network interface of VPN serverTCP source port = 1723 (0x6BB)
Allows PPTP tunnel maintenance traffic from the PPTP server to the PPTP client.
Source IP address = Perimeter network interface of VPN serverIP Protocol ID = 47 (0x2F)
Allows PPTP tunneled data from the PPTP server to the PPTP client.
Source IP address = Perimeter network interface of VPN serverTCP destination port = 1723 (0x6BB)
Required only when the VPN server is acting as a VPN client (a calling router) in a site-to-site VPN connection. If you allow all traffic from the VPN server to TCP port 1723, network attacks can emanate from sources on the 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
Inbound Source IP address = Perimeter network interface of VPN serverTCP source port = 1723 (0x6BB)
Allows PPTP tunnel maintenance traffic from the VPN server to the VPN client.
Source IP address = Perimeter network interface of VPN serverIP Protocol ID = 47 (0x2F)
Allows PPTP tunneled data from the VPN server to the VPN client.
Source IP address = Perimeter network interface of VPN serverTCP destination port = 1723 (0x6BB)
Required only when the VPN server is acting as a VPN client (a calling router) in a site-to-site VPN connection. If you allow all traffic from the VPN server to TCP port 1723, network attacks can emanate from sources on the Internet using this port.
Outbound Destination IP address = Perimeter network interface of VPN serverTCP source port = 1723 (0x6BB)
Allows PPTP tunnel maintenance traffic from the PPTP client to the PPTP server.
Destination IP address = Perimeter
Allows PPTP tunneled data from the PPTP client to the
network interface of VPN serverIP Protocol ID = 47 (0x2F)
PPTP server.
Destination IP address = Perimeter network interface of VPN serverTCP source port = 1723 (0x6BB)
Required only when the VPN server is acting as a VPN client (a calling router) in a site-to-site VPN connection. If you allow all traffic to the VPN server from TCP port 1723, network attacks can emanate from sources on the 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 firewall On 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
Inbound Destination IP address = Perimeter network interface of VPN serverUDP destination port = 500 (0x1F4)
Allows IKE traffic to the VPN server.
Destination IP address = Perimeter network interface of VPN serverUDP destination port = 4500 (0x1194)
Allows IPSec NAT-T traffic to the VPN server.
Destination IP address = Perimeter network interface of VPN serverIP Protocol ID = 50 (0x32)
Allows IPSec ESP traffic to the VPN server.
Outbound Source IP address = Perimeter network interface of VPN serverUDP source port = 500 (0x1F4)
Allows IKE traffic from the VPN server.
Source IP address = Perimeter network interface of VPN serverUDP source port = 4500 (0x1194)
Allows IPSec NAT-T traffic from the VPN server.
Source IP address = Perimeter network interface of VPN serverIP Protocol ID = 50 (0x32)
Allows IPSec ESP traffic from the 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
Inbound Source IP address = Perimeter network interface of VPN serverUDP source port = 500 (0x1F4)
Allows IKE traffic from the VPN server.
Source IP address = Perimeter network interface of VPN serverUDP source port = 4500 (0x1194)
Allows IPSec NAT-T traffic from the VPN server.
Source IP address = Perimeter network interface of VPN serverIP Protocol ID = 50 (0x32)
Allows IPSec ESP traffic from the VPN server.
Outbound Destination IP address = Perimeter network interface of VPN serverUDP destination port = 500 (0x1F4)
Allows IKE traffic to the VPN server.
Destination IP address = Perimeter network interface of VPN serverUDP destination port = 4500 (0x1194)
Allows IPSec NAT-T traffic to the VPN server.
Destination IP address = Perimeter network interface of VPN serverIP Protocol ID = 50 (0x32)
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
Inbound Destination IP address = Internet interface of VPN serverSubnet mask = 255.255.255.255
TCP destination port = 1723
Allows PPTP tunnel maintenance to the VPN server.
Destination IP address = Internet interface of VPN serverSubnet mask = 255.255.255.255
IP Protocol ID = 47
Allows PPTP tunneled data to the VPN server.
Destination IP address = Internet interface of VPN serverSubnet mask = 255.255.255.255
TCP (established) source port = 1723
Required only when the VPN server is acting as a VPN client (a calling router) in a site-to-site VPN connection. Accepts TCP traffic only when a VPN server initiates the TCP connection.
Outbound Source IP address = Internet interface of VPN serverSubnet mask = 255.255.255.255
TCP source port = 1723
Allows PPTP tunnel maintenance traffic from the VPN server.
Source IP address = Internet interface of VPN serverSubnet mask = 255.255.255.255
IP Protocol ID = 47
Allows PPTP tunneled data from the VPN server.
Source IP address = Internet interface of VPN serverSubnet mask = 255.255.255.255
TCP (established) destination port = 1723
Required only when the VPN server is acting as a VPN client (a calling router) in a site-to-site VPN connection. Sends TCP traffic only when a VPN server 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
Inbound Destination IP address = Internet interface of VPN serverSubnet mask = 255.255.255.255
UDP destination port = 500
Allows IKE traffic to the VPN server.
Destination IP address = Internet interface of VPN serverSubnet mask = 255.255.255.255
UDP destination port = 1701
Allows L2TP traffic from the VPN client to the VPN server.
Destination IP address = Internet interface of VPN serverSubnet mask = 255.255.255.255
UDP destination port = 4500
Allows IPSec NAT-T traffic from the VPN client to the VPN server.
Outbound Source IP address = Internet interface of VPN serverSubnet mask = 255.255.255.255
UDP source port = 500
Allows IKE traffic from the VPN server.
Source IP address = Internet interface of VPN serverSubnet mask = 255.255.255.255
UDP source port = 1701
Allows L2TP traffic from the VPN server to the VPN client.
Source IP address = Internet interface of VPN serverSubnet mask = 255.255.255.255
Allows IPSec NAT-T traffic from the VPN server to the VPN client
UDP source port = 4500
Configuring Network Access Quarantine ControlUpdated: March 28, 2003
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 Tools.
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 Tools.
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 Updated: March 28, 2003
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 ServerUpdated: March 28, 2003
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 ClientUpdated: March 28, 2003
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.
4. SelectInternet Protocol (TCP/IP), and then click Properties.
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 SolutionUpdated: March 28, 2003
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 ConnectionsUpdated: March 28, 2003
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 Support
Center for Windows Server 2003.
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 SolutionUpdated: March 28, 2003
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 Support Center for Windows Server 2003.
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 SolutionUpdated: March 28, 2003
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 Windows Server 2003 Resource
Kit 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.
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\RemoteAccess\Parameters\
AccountLockout\domainname:username.
For more information about remote access account lockout, see "Remote Access Technologies" in the
Networking Collection of the Windows Server 2003 Technical Reference.
Deploying a Dial-up Remote Access Server SolutionUpdated: March 28, 2003
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 strength 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 ServerUpdated: March 28, 2003
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.
1. Under Authentication Provider on the Security tab, select the authentication provider to use
for dial-up networking clients.
2. Under Accounting Provider, select and configure the accounting provider to use for recording
dial-up connection accounting information.
1. 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 IntranetUpdated: March 28, 2003
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 SolutionUpdated: March 28, 2003
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.
