Routing and Remote AccessConcepts | Windows Server 2003 in a Nutshell

Routing and Remote AccessConcepts

Remote access enables remote clients such as mobile users with laptops to connect to the corporate network and access shared resources. Routing enables traffic on one network to pass to another. In WS2003, both of these functions are configured using a single tool: the Routing and Remote Access Server (RRAS) console. This section covers the different types of remote access supported by RRAS, including dedicated versus dial-up remote access, Internet access, and virtual private networking (VPN). It also includes using RRAS for direct computer connection using a null-modem cable. For an explanation of client-side remote access, see Connections earlier in this chapter.

How Remote Access Works

Apart from LAN connections, which are created automatically by WS2003, and direct computer connections, which are temporary connections used to transfer files between two machines, all other forms of connections establish or provide remote access to computers, networks, or the Internet. Remote access typically works as follows :

A remote access client attempts to connect to a remote access server (or remote access device) using a WAN connection such as a dial-up connection over a phone line using a modem.
The remote access server responds to the connection attempt from the client and negotiates a suitable WAN protocol, such as PPP, that both the client and server can understand. WAN protocols are discussed later in this section.
The client uses the WAN protocol to encapsulate the network-level data packets (usually IP packets). Typically, both client and server need to use the same LAN protocol, unless the server is performing LAN protocol conversion in addition to providing remote access to the client.
The server provides the client with access to its own resources only, or it acts as a gateway to allow the client to access resources on the server's connected network, depending on how remote access is configured on the server.

Implementing Remote Access

To implement remote access, you basically need to do two things:

Configure a server to receive inbound connections from remote clients.
Configure client computers with outbound connections for connecting to the server.

In addition, you need to:

Grant the users of your client computers suitable permission to connect to your remote access server. This can be allowed or denied on a per-user basis by configuring each user 's account, but it can also be managed by creating and implementing a remote access policy (see Remote Access Policies later in this section).
Specify whether the clients can access only resources on the remote access server or also resources on the LAN connected to the server (gateway function of remote access server).

You can implement the server side of a remote access solution using a WS2003 computer in two primary ways: standalone and domain-based. Both types of remote access servers can accept dial-up, demand-dial , direct cable, or VPN connections from remote clients. You create and configure connections on WS2003 computers using Network Connections in the Control Panel; see Connections earlier in this chapter for more information.

Remote Access Terminology

Various kinds of protocols are associated with remote access; they include LAN, WAN, multilink, authentication, and encryption protocols. The following is a brief summary of the different types and functions of these protocols.

LAN Protocols

TCP/IP is the default LAN protocol on WS2003, and RRAS supports remote access to corporate IP networks and the Internet using TCP/IP over PPP or SLIP. The phrase TCP/IP over PPP means TCP/IP is the LAN protocol, PPP is the WAN protocol, and IP packets are encapsulated into PPP frames in order to send them over the WAN link between the client and server.

WS2003 also supports remote access connectivity for additional LAN protocols:

AppleTalk: Supports remote access connections to Macintosh file and print servers using the AppleTalk Control Protocol (ATCP) over dial-up PPP connections.
IPX/SPX: Supports remote access connections to legacy NetWare file and print servers using the IPX Control Protocol (IPXCP) over PPP.
NetBEUI: Supports remote access connections to NT RAS and legacy LAN Manager servers configured as NetBIOS gateways. Note that NetBEUI is not available on WS2003 by default, but a workaround allows it to be installed by extracting appropriate files from the product CD.

For more information on LAN protocols, see TCP/IP later in this chapter.

WAN Protocols

Also called remote access protocols, the following WAN protocols are supported by WS2003:

PPP (Point-to-Point Protocol): The most common WAN protocol in use today. PPP is suitable for establishing WAN connectivity between different platforms such as Microsoft Windows, Unix, or Macintosh. PPP supports several methods for authenticating clients (discussed later) and supports data encryption and compression. WS2003 supports PPP for both inbound and outbound connections and for any LAN protocol, and PPP is the standard WAN protocol used in most RRAS implementations .
SLIP (Serial Line Internet Protocol): A legacy WAN protocol that is not used much anymore. WS2003 can function as a SLIP client but not as a SLIP server. WS2003 SLIP clients must use TCP/IP and communicate with SLIP servers via a serial COM port on the client machine.
Microsoft RAS (Microsoft Remote Access Service): A legacy WAN protocol used on NT 3.1, Windows for Workgroups 3.11, MS-DOS, and Microsoft LAN Manager. Microsoft RAS protocol requires that these clients use NetBEUI. WS2003 supports both client and server implementation of Microsoft RAS.
ARAP (AppleTalk Remote Access Protocol): ARAP can be used by Macintosh clients to connect to WS2003 remote access servers. WS2003 doesn't include an ARAP client.

Multilink Protocols

A multilink connection consists of multiple physical connections combined into a single logical connection. For example, you could use multilink to combine two 56 kbps dial-up modem connections into a single 112 kbps connection to provide increased bandwidth for remote access. WS2003 supports two protocols for multilink connections:

PPP Multilink (MP): Allows one or more dial-up PPP connections to be combined into a single logical connection. PPP Multilink can be used with modems, ISDN adapters, or X.25 cards to provide additional bandwidth for these connections.
BAP (Bandwidth Allocation Protocol): BAP is a dynamic multilink protocol that allows physical links to be added or dropped as needed. This is particularly useful if service-carrier charges depend on bandwidth utilization by clients.

WAN Authentication Protocols

WAN connections can use any of several authentication protocols to authenticate remote access clients that are attempting to connect to a remote access server. The authentication protocols supported by outbound dial-up connections on WS2003 are (in order of increasing security):

PAP (Password Authentication Protocol): An older scheme that transmits passwords as clear text.
SPAP (Shiva Password Authentication Protocol): A variant of PAP developed by the Shiva Corporation that uses two-way (reversible) encryption for securely transmitting passwords. However, SPAP doesn't support data encryption, only password encryption.
CHAP (Challenge Handshake Authentication Protocol): Uses the secure one-way hashing scheme, Message Digest 5. CHAP lets the client prove its identity to the server without actually transmitting the password over the WAN link, so it is more secure than the reversible scheme used in SPAP.
MS-CHAP (Microsoft Challenge Handshake Authentication Protocol): A version of CHAP specifically tailored for Microsoft Windows remote access clients and servers. A newer version, MS-CHAP v2, requires both the client and the server to prove their identities to each other before allowing a connection. MS-CHAP v2 is supported only by WS2003, W2K, NT 4.0, and Windows 98 clients and servers.

In addition to these authentication protocols, WS2003 also supports Extensible Authentication Protocol (EAP), an extension to PPP that supports a wide range of additional security mechanisms including token cards, smart cards, MD5-CHAP, and TLS/SSL.

WS2003 also supports Remote Authentication Dial-in User Service (RADIUS), a client/server authentication protocol widely used by ISPs. RADIUS is implemented on WS2003 using the Internet Authentication Service (IAS) and provides a way of centrally managing user authentication, authorization, and accounting functions.

Table 4-48 summarizes which multilink and authentication protocols are supported by different Microsoft Windows dial-up clients.

Table 4-48. Microsoft Windows client support for PPP authentication protocols

Client	Authentication protocols
	PAP	SPAP	CHAP	MS-CHAP	MS-CHAPv2	EAP	PPMP	BAP
WS2003	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Windows 2000	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Windows XP	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
NT 4.0	Yes	Yes	Yes	Yes	Yes		Yes
NT 3.51	Yes	Yes	Yes	Yes
Windows 98	Yes	Yes	Yes	Yes	Yes		Yes
Windows 95	Yes	Yes	Yes	Yes	Yes

Encryption Protocols

In addition to the encrypted authentication protocols described earlier, WS2003 supports several protocols for encrypting data transmitted over remote access connections, including:

MPPE (Microsoft Point-to-Point Encryption): A data encryption scheme that uses a 40-, 56-, or 128-bit RSA RC4 encryption algorithm (depending on export requirements for your country)
IPSec (Internet Protocol Security): A scheme that uses a 56 bit DES or 168 bit Triple DES encryption algorithm

Be aware that data encryption is not supported for the following authentication protocols: PAP, SPAP, and CHAP.

Virtual Private Network (VPN)

WS2003 RRAS allows you to set up a VPN that provides secure remote access services to clients without the need to purchase additional hardware such as modems or multiport adapters. Instead, a VPN utilizes an Internet connection such as a DSL connection or T1 line to provide secure remote access services to clients. VPNs work by encapsulating LAN protocol packets, such as TCP/IP packets, into PPP frames. These PPP frames are then transported using a secure VPN protocol, such as PPTP or L2TP, over the WAN link. A common scenario for implementing a VPN is as follows:

Mobile users with laptops running XP Professional have an outbound dial-up VPN connection configured on their machines. These users want to securely access their company's intranet using an insecure Internet connection. From a remote location, a user dials up a regional ISP to gain access to the Internet to establish a VPN with their corporate intranet.
On the company side, a WS2003 system with a dedicated T1 connection to the Internet has an inbound VPN connection configured on it. This remote access server will use the insecure Internet for servicing remote clients, rather than using the traditional remote access solutiona modem bank (which typically adds the additional expense of leasing a number of additional phone lines for remote access purposes, and since our company already has a T1 line anyway to provide LAN users with Internet access, then why not make use of it for remote access as well?).
The client dials up his ISP and connects to the Internet. Once connected, the client uses PPTP or L2TP to establish a secure, encrypted communications session with the VPN server at corporate headquarters. In effect, the client securely becomes part of the corporate LAN by tunneling through the insecure Internet between them.

VPN connections can even be used within a LAN to provide secure network communications between a VPN client and a VPN server.

Here are the two WAN protocols supported by WS2003 for creating VPNs:

PPTP (Point-to-Point Tunneling Protocol): Derived from PPP. It uses PPP encryption for data and works only with TCP/IP as the underlying network protocol. PPTP is generally viewed as less secure than L2TP but is easier to implement.
L2TP (Layer 2 Tunneling Protocol): Derived from the Layer 2 Forwarding (L2F) protocol. L2TP supports data encryption and tunneled authentication using IPSec and works with TCP/IP, X.25, Frame Relay, ATM, and other point-to-point, packet-oriented WAN links (but the WS2003 version supports only TCP/IP natively). L2TP also supports header compression for more efficient transfer of data.

Remote Access Policies

A remote access policy is a collection of conditions and connection settings. Remote access policies simplify the administrative task of managing remote access for users and groups in your enterprise. Using remote access policies, you can:

Allow or deny remote access depending on the time or day of the week, the group membership of the remote user, the type of connection (VPN or dial-up), and so on
Configure remote access settings to specify authentication protocols and encryption schemes used by clients, maximum duration of a remote access session, etc.

Remote access policies consist of three parts :

Conditions: These are attributes that are compared to the settings of the remote connection to determine whether the connection attempt should be allowed or denied. If multiple conditions are specified in the policy, they must all match the settings of the client or the connection attempt will be refused . Examples of conditions include the phone number of the remote access server, date and time restrictions, domain-based groups the user belongs to, etc.
Remote access permission: If the specified conditions are met, then remote access permission is either granted or denied, depending on how you configure this setting in the policy. (By default, this is set to Deny when a new policy is created.)
Profile: These are settings applied to the connection once it has been authorized (in other words, once remote access permission has been verified note that authorization is different from authentication , which has to do with the user's credentials being accepted at the server end). Profile settings can include maximum session time allowed, whether Multilink is enabled, types of authentication protocols and encryption schemes allowed, and so on. These policy settings must also match the settings of the client, or the connection attempt will be finally denied.

Remote access policies are configured using the RRAS console. They are contained within the Remote Access Policies container under the server node in the console tree. There is a default remote access policy created when the RRAS is installed on a computer. This policy is called "Allow access if dial-in permission is enabled" and specifies that users will be denied remote access permission by the policy if:

Their user account has its remote access controlled by remote access policies (the default on a native mode, domain-based, or standalone WS2003 remote access server).
Their account logon restrictions allow them to log on anytime (also the default).

In other words, the default remote access policy denies remote access to all users unless a user account explicitly has remote access allowed for it.

Remote access policies are stored on their associated remote access servers in WS2003 rather than in Active Directory to facilitate application of these policies to client connections without generating additional network traffic.

How Remote Access Policies Work

Let's start by considering how remote access by users to a remote access server can be explicitly controlled without using remote access policies. You explicitly allow or deny a user remote access permission by using the Dial-in tab of the properties sheet for the user account, using:

Local Users and Groups in the Computer Management console on a standalone WS2003 computer
Active Directory Users and Groups on a WS2003 domain controller or a member server that belongs to a domain

However, if you want to control remote access for users using remote access policies, then instead of selecting Allow or Deny on the Dial-in tab for a user, specify that WS2003 should "Control access through Remote Access Policy." (This setting is configured by default for built-in and new users in WS2003 domains configured to run in native mode and on standalone WS2003 remote access servers.) In this case, the permissions setting of the policy will determine whether the user will be allowed to establish a connection with the remote access server.

If your WS2003 domain is running in mixed mode, you don't have the option of selecting "Control access through Remote Access Policy"this option is grayed out on the user account's properties sheet. The reason is that mixed-mode domains may contain both WS2003 and NT domain controllers, and NT RAS servers don't support remote access policies. You should convert your domain from mixed mode to native mode if you want to use remote access policies on domain-based remote access servers (standalone WS2003 systems do support remote access policies, however). If you have a domain-based remote access server running in a mixed-mode domain, you should delete the default remote access policy if it is present.

By default, all built-in and new user accounts on native-mode, domain-based, and standalone remote access servers have "Control access through Remote Access Policy" selected in their properties (unless their setting was previously changed from Deny to Allow, in which case it becomes Deny). On mixed-mode domain-based servers, all built-in and new user accounts have Deny as their remote access permission.

Remote access policies are used to control connection attempts in the following way:

The remote client (with the user account set to "Control access through Remote Access Policy") tries to connect to a remote access server (here, a domain-based server where the domain is running in native mode).
The server checks its list of policies:
- If there is no remote access policy configured, the connection is refused.
- If there is only one policy, all conditions in the policy must match the user's connection settings in order to move on to Step 3.
- If there are multiple policies, these are tested in order, one at a time, until one matches and you move on to Step 3, or all fail and the connection is refused.
If a policy whose conditions match the user is found, the server checks the remote access permission of the policy. If this is set to Deny, then connection is refused; otherwise , move on to Step 4.
If remote access permission has been allowed to the user through a policy, the server checks the profiles associated with the policy. If these profile settings match the user, the connection is established and the user connects to the server; otherwise, no other untried policies are tried, and the connection is finally refused.