Chapter 5: Migrating to Dial-up and VPN Remote Access Servers Running Windows Server 2003 | Migrating from Microsoft Windows NT Server 4.0 to Windows Server 2003

This chapter helps you evaluate your options for upgrading or migrating your remote access solution from servers that are running Microsoft Windows NT Server version 4.0 to servers that are running a product in the Microsoft Windows Server 2003 family. This chapter describes the differences between Remote Access Service (RAS) or Routing and Remote Access Service (RRAS) in Windows NT Server 4.0 and Routing and Remote Access in Windows Server 2003 and the benefits of upgrading or migrating. It also describes how to reuse your settings from RAS or RRAS and the requirements for upgrading a server that is running RRAS from Windows NT Server4.0 to Windows Server 2003.

Overview of Remote Access Migration

Although there are similarities between RAS or RRAS running on Windows NT Server 4.0 and Routing and Remote Access running on the Windows Server 2003 family, there have been major changes and improvements since Windows NT Server 4.0 was released. This section discusses some of those changes and improvements, and later sections explain how you can reuse settings from RAS or RRAS to facilitate your Routing and Remote Access deployment.

Before you begin to migrate from RAS or RRAS to Routing and Remote Access, or upgrade from RRAS to Routing and Remote Access, you should understand the functional differences between these components and the differences in how you perform tasks that involve these components. You should also consider in what ways your existing remote access solution does and does not meet your needs and which of your existing settings to migrate to your new remote access solution.

Feature Enhancements from RAS to RRAS

Both RAS and RRAS are available for WindowsNT Server4.0. RAS supports both dial-up connections and virtual private networks (VPNs) that use Point-to- Point Tunneling Protocol (PPTP). After the release of WindowsNT Server4.0, RRAS was made available as a free released-to-Web offering. RRAS enhances RAS by creating a unified routing and remote access service.

RRAS for Windows NT Server 4.0 improved upon RAS by supporting:

Routing Information Protocol (RIP) version 2 routing protocol for IP.
Open Shortest Path First (OSPF) routing protocol for IP.
Demand-dial routing, the routing over on-demand or persistent WAN links such as those over analog phone or ISDN connections that use PPTP.
Internet Control Message Protocol (ICMP) Router Discovery.
Remote Authentication Dial-In User Service (RADIUS) client.
IP and Internetwork Packet Exchange (IPX) packet filtering.
PPTP support for site-to-site (also known as router-to-router) VPN connections.
A graphical user interface administrative program called Routing and RAS Admin and a command-line utility called Routemon.

Changes in Features from RRAS to Routing and Remote Access

Routing and Remote Access for the Microsoft Windows 2000 Server family continued the evolution of multiprotocol routing and remote access services. The Routing and Remote Access features introduced in the Windows 2000 Server family include:

Internet Group Management Protocol (IGMP) and support for multicast boundaries.
Network address translation with addressing and name resolution components that simplify making the connection between a small office/home office (SOHO) network and the Internet.
Integrated AppleTalk routing.
Layer Two Tunneling Protocol with Internet Protocol Security (L2TP/IPSec) support for remote access and site-to-site VPN connections.
Improved administration and management tools. The graphical user interface program is Routing and Remote Access in MMC. The command-line utility is Netsh.

Additional enhancements to Routing and Remote Access have been made in the Windows Server 2003 family. Two of the enhancements are specifically designed for small businesses.

Enhancements for Small Businesses

The following enhancements are specifically designed for small businesses.

Broadcast Name Resolution

Broadcast name resolution is a NetBIOS over TCP/IP (NetBT) name resolution proxy that is built into Routing and Remote Access. This proxy allows remote access clients connecting to a network consisting of one or more subnets with a single router (the remote access server running a member of the Windows Server2003 family) to resolve names without having to query a Domain Name System (DNS) or Windows Internet Name Service (WINS) server.

This feature allows a small business to configure a remote access or VPN server so that employees can work offsite. With broadcast name resolution enabled, clients connecting remotely can resolve the names of computers on the small business network without requiring the deployment of a DNS or WINS server.

PPPoE for Demand-Dial Connections

With this feature, organizations can use Point-to-Point Protocol over Ethernet (PPPoE) for demand-dial connections (also known as dial-on-demand connections). Demand-dial connections are used by Routing and Remote Access to make point-to-point connections between LANs over which packets are routed. You can access this feature by clicking Connect using PPP over Ethernet (PPPoE) on the Connection Type page of the Demand-Dial Interface Wizard.

By allowing PPPoE as a connection type for demand-dial connections, a small business can use the NAT/Basic Firewall component of Routing and Remote Access and its broadband Internet connection to connect an office network to the Internet.

Other Enhancements

The following enhancements are not specifically designed for small businesses; however, some of them (such as network address translation and Basic Firewall) can be used in a small business environment.

NAT and Basic Firewall

The network address translation and Basic Firewall components of Routing and Remote Access have been enhanced to support a basic firewall. These components allow you to protect a computer that is running a product in the Windows Server2003 family and to enable your server to act as a network address translator (NAT) to allow access to the Internet. The computers on the private network are protected because the NAT does not forward traffic from the Internet unless a private network client requests it. However, the NAT itself can be vulnerable to attack. If Basic Firewall is enabled on the public interface of the NAT, all packets that are received on that interface and that do not correspond to traffic requested by the NAT (either for itself or for private intranet clients) are discarded.

You can enable this functionality from the NAT/Basic Firewall tab in the Properties dialog box of an interface that is configured to use the NAT/Basic Firewall IP routing protocol component of Routing and Remote Access.

Snap-in and Setup Wizard Enhancements

The Routing and Remote Access Server Setup Wizard has been modified to make it easier to initially configure Routing and Remote Access. Routing and Remote Access has been modified to make it easier to configure server settings after the initial configuration has been completed.

Improved Configuration for EAP-TLS Properties

The Smart Card or other Certificate Properties dialog box has been improved to allow the configuration of multiple RADIUS servers and multiple root certification authorities for local and remote connections. You can access the Smart Card or other Certificate Properties dialog box from the Properties dialog box of each connection in the Network Connections folder.

Network Access Quarantine Control

Network Access Quarantine Control is a feature of both Routing and Remote Access and Internet Authentication Service. It delays normal remote access to a private network until the configuration of the remote access computer has been examined and validated by an administrator-provided script. Network Access Quarantine Control is designed to prevent computers with unsupported configurations from accessing resources on a private network.

When a remote access computer initiates a connection to a remote access server, the user is authenticated and the remote access computer is assigned an IP address. However, the connection is placed in quarantine mode, in which network access is limited. The administrator-provided script is run on the remote access computer. If the script notifies the remote access server that it has successfully run and that the remote access computer complies with current network policies, quarantine mode is removed, and the remote access computer is granted normal remote access.

Network Access Quarantine Control in Routing and Remote Access supports new RADIUS vendor-specific attributes for quarantine restrictions and a new MprAdminConnectionRemoveQuarantine() application programming interface (API) to remove the quarantine restrictions from the remote access connection.

For more information, see the Network Access Quarantine Control link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Manage Your Server and Routing and Remote Access Integration

This feature provides an integrated method for configuring the initial setup of Routing and Remote Access. With this feature, an IT administrator can configure multiple features in the Windows Server2003 family from the same initial interface.

Ability to Enable the Routing and Remote Access Internal Interface as a Network Address Translation Private Interface

On a computer that is running Windows2000 Server, providing remote access to a private intranet, and acting as a NAT to provide access from the intranet to the Internet, there is no way to provide Internet access to connected remote access clients. On computers that are running Windows Server2003, you can add the Internal interface as a private interface to the NAT/Basic Firewall component of Routing and Remote Access. This allows connected remote access clients to access the Internet.

Improvements in Default Behavior for Internal and Internet Interfaces

To prevent potential problems with resolving the name of the VPN server and accessing services that are running on the VPN server, Routing and Remote Access by default disables DNS dynamic update registration for the Internal interface and disables both dynamic DNS and broadcast name resolution for the interface identified in the Routing and Remote Access Server Setup Wizard as the Internet interface.

L2TP/IPSec Connections and IPSec NAT Traversal

In Windows2000, Internet Key Exchange (IKE) and Encapsulating Security Payload (ESP) traffic cannot traverse a NAT because if the NAT translates the IP addresses or ports of the packet, it invalidates the security of the packets. This means that you cannot create an L2TP/IPSec connection from behind a NAT and that you must use PPTP for VPN connections.

The Windows Server2003 family supports User Datagram Protocol (UDP) encapsulation of IPSec packets to allow IKE and ESP traffic to pass through a NAT. This feature allows L2TP/IPSec connections to be created between client computers and servers that are running products in the Windows Server2003 family and that are located behind one or more NATs.

To create such connections from client computers that are running Microsoft Windows 98, Windows Millennium Edition, or WindowsNT Workstation4.0, users must install the Microsoft L2TP/IPSec VPN Client. For more information, see the Microsoft L2TP/IPSec VPN Client link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

The Internet Drafts titled UDP Encapsulation of IPSec Packets (draft-ietf- ipsec-udp-encaps-02.txt) and Negotiation of NAT-Traversal in the IKE (draft- ietf-ipsec-nat-t-ike-02.txt) describe support in the Windows Server2003 family for IPSec traffic traversing NATs.

NLB Support for L2TP/IPSec Traffic

In Windows2000, Network Load Balancing (NLB) could not manage IPSec security associations (SAs) among multiple servers. If a server in the cluster became unavailable, the SAs managed by that cluster were orphaned and eventually timed out. This meant that you could not cluster L2TP/IPSec VPN servers. You could use DNS round- robin for load distribution across multiple L2TP/IPSec VPN servers, but there was no fault tolerance.

In the Windows Server2003 family, NLB has been enhanced to provide clustering support for IPSec SAs. You can create a cluster of L2TP/IPSec VPN servers, and NLB will provide both load balancing and fault tolerance for L2TP/IPSec traffic.

This feature is provided only with Windows Server2003, Enterprise Edition, and Windows Server2003, Datacenter Edition.

Preshared Key Configuration for L2TP/IPSec Connections

Windows Server2003 supports both computer certificates and a preshared key as authentication methods to establish IPSec SAs for L2TP connections. A preshared key is a string of text that is configured on both the VPN client and the VPN server. Preshared key authentication is a relatively weak authentication method; therefore, it is recommended that you use preshared key authentication only while your public key infrastructure (PKI) is being deployed or when VPN clients require the use of preshared key authentication. You can enable the use of preshared key authentication and specify a preshared key for L2TP connections from Routing and Remote Access by opening the Properties dialog box of a remote access server and clicking the Security tab.

VPN clients in Microsoft Windows XP and the Windows Server2003 family also support preshared key authentication. You can enable preshared key authentication and specify a preshared key for L2TP connections from Network Connections by opening the Properties dialog box of a VPN connection, clicking the Security tab, and changing the IPSec settings or by configuring a Connection Manager Administration Kit (CMAK) profile for your users. For more information about configuring a CMAK profile, see Deploying Remote Access Clients Using Connection Manager in Deploying Network Services of the Microsoft WindowsServer 2003 Deployment Kit (or see Deploying Remote Access Clients Using Connection Manager on the Web at http://www.microsoft.com/reskit).

Preshared key authentication is also supported for site-to-site VPN connections between computers that are running products in the Windows Server2003 family. You can enable preshared key authentication and configure a preshared key for demand-dial interfaces from Routing and Remote Access by opening the Properties dialog box of a demand-dial interface, clicking the Security tab, and changing the IPSec settings .

Feature Limitations

VPN Connection Limit for Windows Server2003, Web Edition

Windows Server 2003, Web Edition, supports only one VPN connection at a time, whether the connection is based on PPTP or L2TP. This limitation also exists for WindowsXP. To support more than one VPN connection, you must use Windows Server2003, Standard Edition; Windows Server2003, Enterprise Edition; or Windows Server2003, Datacenter Edition.

IPX Routing Support Removed

Routing and Remote Access in the Windows Server2003 family does not support IPX routing, which includes the following:

The forwarding of IPX traffic
The use of Routing Information Protocol (RIP) for IPX
The use of Service Advertising Protocol (SAP) as a router
The forwarding of NetBIOS over IPX broadcasts

Accessing RAS, RRAS, and Routing and Remote Access

Understanding how you access Routing and Remote Access in the Windows Server2003 family compared to how you access RAS and RRAS in WindowsNT Server4.0 will assist you during the migration or upgrade process. Table 5.1 shows how to perform common tasks using RAS or RRAS in WindowsNT Server4.0 and Routing and Remote Access in Windows Server2003.

Table 5.1: Performing Common Tasks with RAS or RRAS (Windows NT Server 4.0) and in Routing and Remote Access (Windows Server 2003)
To:	In Windows NT Server 4.0, use:	In Windows Server 2003, use:
Enable and configure remote access	In Control Panel, in Network, the Services tab	Routing and Remote Access found in the Administrative Tools folder
Configure authentication and encryption options	In Control Panel, in Network, the Services tab	Routing and Remote Access
Manage remote access servers and clients	Remote Access Admin or Routing and RAS Admin	Routing and Remote Access
Grant remote access permission to user accounts	Remote Access Admin or User Manager for Domains	Active Directory Users and Computers or Computer Management, Local Users and Groups (if the remote access server is not part of a domain)