Section 8.3. Planning, Implementing, and Maintaining Routing and Remote Access


8.3. Planning, Implementing, and Maintaining Routing and Remote Access

In Windows Server 2003, the Routing And Remote Access service (RRAS) allows a server to be configured as a multipurpose remote access server and as an IP router. As a remote access server, a Windows server can connect clients to the internal network whether they use broadband, dial-up, or VPN. As an IP router, use a Windows server to connect LANs, wide area networks (WANs), and VPNs.

8.3.1. Planning a Routing Strategy

Both hardware and software routers can be used to connect your organization's LANs and WANs. There are advantages and disadvantages to both hardware and software routers. Hardware routers tend to be more expensive than software routers and more complex to configure. Software routers typically are easier to configure and less expensive than hardware routers, but may not be as reliable as hardware routers. Beyond issues of cost, configurability, and reliability, the RRAS provides the same routing services as most hardware routers.

8.3.1.1.
8.3.1.1.1. Connecting LANs and WANs

When planning a routing strategy, the difference between a LAN connection and a WAN connection is important. Most local area networks have multiple subnets over which local hosts communicate. To allow hosts to communicate across network segments, you'll need some type of routing technology. RRAS includes:


DHCP Relay Agent routing protocol

This protocol allows the server to route DHCP broadcast messages between subnets. The maximum number of DHCP relays agents that can handle DHCP relayed traffic is 4, by default. The maximum allowed value is 16.


RIP version 2 for Internet Protocol

This protocol allows dynamic routing between subnets. RIP is an easily managed routing protocol, but limited to a maximum hop count of 15. For successful communications, source and destination computers can have no more than 15 routing devices between them.


OSPF

This protocol allows extended dynamic routing between subnets. With OSPF, source and destination computers can have more than 15 routing devices between them. For successful implementation, both transit areas and neighbors should be configured.

RIP is a distance vector routing protocol and uses only the number of hops for its metrics. RIP can only use broadcast or multicast transmissions for communication with other routers, both of which generate more traffic than unicast transmissions. RIP requires little planning or configuration.

OSPF is a link state routing protocol and computes its metrics based on many conditions, including network speed and congestion. OSPF can only use unicast transmissions to communicate with other routers. OSPF requires significant planning and configuration.


Tip: Neither RIP nor OSPF facilitates multicasting. Internet Group Management Protocol (IGMP) is the routing protocol that makes multicasting possible.

When these routing technologies are implemented on a LAN, you'll typically use a single LAN router to connect two subnets. This router connects the subnets by having a configured routing interface for each subnet being connected.

In contrast to tightly connected local area networks, wide area networks typically are connected over long distances. WAN connections are used to connect multiple networks at separate physical locations into a single large internetwork. With WAN connections, install a WAN router at each site and connect the routers using a WAN link. You can build in redundancy and fault tolerance using additional, redundant WAN connections.

The same routing technologies that are used on LANs can be used on WANs. It is important, however, to keep in mind the relay/routing limitations that are applicable. Common WAN configurations for multiple connections are:

  • Ring topology where all sites are connected one to another in a ring and each site has two possible routes to another site. For example, if Sites 1, 2, 3, 4, 5, and 6 are in a ring, Site 1 could reach Site 3 through Site 2 or through Sites 4 and 5.

  • Mesh topology where every site is connected to every other site. For example, if Sites 1, 2, 3, 4, 5, and 6 are in a mesh, each site has a direct connection to each other site and has alternate routes to a site through any of the other sites.

  • Star topology where a central site is connected to remote sites. For example, the main site, Site 1, has separate connections to Sites 2, 3, 4, 5, and 6. Because the remote sites are not connected to each other, failure of the direct connection to the main site means the remote site cannot reach any other site.

When WAN connections are provided over leased lines, the connections are private and VPN technology is not need. On the other hand, if WANs are connected over the public Internet, VPN technology must be used to secure the connections.

8.3.1.2. Identifying routing protocols to use in a specified environment

To route traffic between subnets or over WAN connections, routers must be configured with the appropriate routing entries. Routers can use static or dynamic routing. With static routing, administrators must manually create routing entries and maintain those entries if the network topology changes. With dynamic routing, the router itself creates entries automatically and updates the entries as appropriate.

Whether you use static or dynamic routing will depend on your routing strategy. You must consider the number of networks, routers, and sites that are in the enterprise and determine how best to configure routing. Dynamic routing eliminates the need for administrators to create and maintain routing entries, providing an efficient and automated solution. Static routing requires administrators to create and maintain routing entries.

Static routing entries can be created and managed using either the Routing And Remote Access console or the route commands. Before you work with static routes at a command prompt, you should print the currently configured static routes by entering route print. The output of route print shows current interfaces, static routes, and persistent routes.

You can create static routes using the route add command. The syntax of the route add command follows:

 route add DestinationNetworkID mask NetworkMask Gateway metric MetricCost if     Interface 

such as:

 route add 192.168.11.0 mask 255.255.255.0 192.168.10.1 metric 1 if 0x10003 

The metric and interface are optional. If you do not specify them, they are selected automatically. To make a static route persistent, you can use route add -p. Persistent static routes are not deleted even if the router is stopped and restarted.

To change a static route, you can use the route change command. The syntax of the route change command follows:

 route change DestinationNetworkID mask NetworkMask Gateway metric MetricCost if Interface 

such as:

 route change 192.16.15.0 mask 255.255.255.0 192.168.42.1 metric 1 if      0x10003 

At a command prompt can delete a static route using route delete. The syntax is:

 route delete DestinationNetworkID 

For example:

 route delete 192.168.11.0 

The RIP and OSPF routing protocols use dynamic routing. When an RIP router is initially configured, the only entries in its routing tables are for the networks to which it is physically connected. The router then starts sending announcements of its availability to other routers of the networks it services. Responses from announcements allow the router to update its routing tables.

RIP announcements can be made depends using one of two operating modes:


Periodic update mode

RIP announcements are sent periodically to learn of available routes and routes are deleted automatically when the router is stopped and restarted


Auto-static update mode

RIP announcements are sent when other routers request updates, learned routes are added as static, and routes remain until they are manually deleted.

When changes occur to the network topology, RIP version 2 uses triggered updates to communicate the changes to other routers. To configure the version of RIP to use, you can set the Outgoing Packet Protocol and Incoming Packet Protocol on the General tab of the RIP connection's properties dialog box (see Figure 8-13).

Figure 8-13. Set the RIP version for outgoing and incoming packets.


When using RIP version 2, you can improve security by enabling authentication for your routers. On the General tab, select the Activate Authentication checkbox and enter a password in the password field. Once you enable authentication, all routers using RIP version 2 must be configured in this same way with the same password so that the routers can update each other. Otherwise, route updates fail.

On the Security tab of the RIP connection's properties dialog box (see Figure 8-14), you can configure filters to add additional security. You can set separate filter actions for incoming routes and outgoing routers. For incoming routes, you can configure filters to accept all routes, accept all routes in the ranges listed, or ignore all routes in the ranges listed. For outgoing routes, you can configure filters to announce all routes, announce all routes in the ranges listed, or not announce all routes in the ranges listed.

Figure 8-14. Configure filters to improve RIP security.


OSPF is a link-state protocol that uses the Shortest Path First (SPF) algorithm to calculate routes. The route with the lowest route cost is the shortest path, and the shortest path is always used first when routing. An OSPF router maintains a link-state database that it uses to track the network topology. The database is synchronized with adjacent routers or specifically defined nonbroadcast multiple access (NBMA) neighbors.

When a change is made to the network topology, the first OSPF router to identify the change sends out a change notification. This change notification is used to update the link-state database so that the routing tables can be recalculated automatically. OSPF routers divide the network into areas of responsibility called transit areas , and maintain link-state information only for those transit areas for which they've been configured.

Dynamic routers, such as RIP and OSPF routers, exchange information about their networks with other routers using the same dynamic routing protocols. Typically, you'll want to use RIP version 2 over RIP version 1. RIP version 1 uses broadcasts for announcements and doesn't allow for authentication. RIP version 2 uses multicast for its announcements and does allow authentication to be used. RIP version 2 is best used on medium-sized networks with 50 or less routers, and the maximum number of hops that any IP packet must be transferred over is less than 16.

On larger networks or networks with redundant paths, OSPF is a better choice than RIP. OSPF is ideally suited to networks with 50 or more routers. Where RIP may generate significant amounts of announcement traffic on large networks, OSPF reduces traffic by synchronizing updates to its database and routing tables.

8.3.1.3. Planning routing for IP multicast traffic

With TCP/IP, host computers can be configured to use broadcast, unicast, and multicast message transmission. Broadcast messages are used by all computers configured to use TCP/IP. A broadcast message, as the name implies, is broadcast to every host on the network. Because broadcasts are indiscriminant and reach every system whether it is the intended recipient or not, broadcasts are limited by default to the local subnet on which the source computer is located.

With TCP version 4, Class A, B, and C IP addresses use unicast transmissions in which each computer has a separate IP address. Unicast transmissions involve only two systems: a source and a destination. To use unicast to send the same message to multiple systems, the source computer must send the message multiple timesonce to each recipient.

With TCP version 4, Class D IP addresses use multicast transmissions in which a group of computers known as the host group have a single destination IP address. Because multicast transmissions identify an entire group of systems, a single source computer can send a single message to multiple recipients.

Members of the host group can be located on any LAN on the network. They can even be located in different remote locations connected via the organization's WAN. However, for the message to be transmitted across LAN and WAN connections, the routers on the network must know which hosts are members of the group. This allows the messages to be forwarded.

Computers that are members of a multicast host group must register themselves with the network routers using the Internet Group Management Protocol (IGMP). All members of the group and all routers providing access to the members of the group must support IGMP.


Tip: All Windows computers that use TCP/IP support IGMP. RRAS servers can be configured with the IGMP routing protocol.

Routers support IGMP in several ways. First, you must be able to configure the router to use the IGMP routing protocol, and then specify the routing interfaces on which IGMP traffic can be received. The interface used must support a special mode called multicast promiscuous mode. While most network interface adapters support this mode, you should verify that a hardware router's network interface adapters do.


Tip: To support large-scale multicasting, the router must also be able to share host group membership information with other routers. This means the router must implement a distributed multicast routing protocol, such as Distance Vector Multicast Routing Protocol (DVMRP). The RRAS does not support distributed multicast routing protocols, but can use a third-party version of one of these protocols.

8.3.2. Planning Security for Remote Access Users

Using RRAS, you can configure remote access so that individual users at remote locations can access the organization's network. Remote access can be used in this way for dial-up, broadband, and wireless connections from remote clients. All three types of remote access connections can use VPN as well to enhance security.

8.3.2.1. Analyzing protocol security requirements

Before you configure remote access for remote clients, you should determine how remote access security should be configured to best safeguard the internal network from attack and ensure that organizational security policies and requirements are met. You should start by determining:

  • Who needs remote access

  • What level of access each user requires

  • What applications, if any, users need to run

One of the ways you can secure remote access is to configure the dial-in properties of the user's account. In Active Directory Users And Computers, you can configure dial-in properties for individual users. To set these for an individual user, right-click the account name, select Properties, and then click the Dial-in tab. As Figure 8-15 shows, you can set the dial-in properties thar are described next.

Figure 8-15. Configuring dial-in properties.



Remote Access Permission (Dial-in or VPN)

Using the related options, you can allow or deny remote access to the selected user. You can also elect to control access through Remote Access Policy.


Verify Caller ID

Using this option, you can set the user's telephone number, which can be verified prior to allowing remote access using Caller ID.


Callback Options

Using the related options, you can configure whether callback is required to a specific number or can be set by the caller.

8.3.2.2. Planning authentication methods for remote access clients

RRAS enables administrators to configure Virtual Private Network (VPN) access for remote clients. With VPN connections, both Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP) are supported. By default, the appropriate protocol can be automatically selected when a connection is made. Because L2TP uses IPSec for advanced encryption, L2TP is more secure than PPTP.

RRAS supports Windows authentication and RADIUS authentication. Windows authentication is the default authentication method, and it allows you to use standard Windows security for authentication. RADIUS authentication can be used if your organization has Remote Authentication Dial-in User Service (RADIUS) servers. To configure authentication, right-click a server entry in the Routing And Remote Access console, select Properties, and then use the Authentication Provider selection list on the Security tab to configure the desired authentication method (see Figure 8-16).

Figure 8-16. Set the desired authentication provider.


The Accounting Provider list lets you specify whether and how connection requests and sessions are logged. Windows Accounting logs connection requests and sessions in logfiles stored in the Remote Access Logging folder. RADIUS Accounting sends details about connection requests and sessions to the RADIUS server. The RADIUS server in turn logs this information.


Tip: RADIUS proxy and server support is a new feature in Windows Server 2003. You can install and use Microsoft Internet Authentication Service (IAS) to provide RADIUS proxy and server services. If you have multiple remote access servers, you can use RADIUS authentication and accounting to centralize the authentication and accounting. Do this by configuring the remote access servers to use RADIUS authentication and accounting, and then configuring a RADIUS server, such as an IAS server, to handle authentication and accounting. This allows remote access users to access any remote access server, and means you only have to maintain a single set of user accounts on the RADIUS server. When planning a remote access server deployment in a large network environment, keep these advantages in mind.

The method a RRAS server uses to authenticate remote access clients is determined by the Authentication Methods settings. You can view and manage the configured authentication methods using the dialog box shown in Figure 8-17. To configure authentication methods, right-click a server entry in the Routing And Remote Access console, select Properties, and then click the Authentication Methods button on the Security tab.

Figure 8-17. Managing RRAS authentication methods.


Table 8-15 summarizes the available user authentication methods. Before changing the settings, keep the following in mind:

  • The authentication methods are used in the order shown and are essentially organized from the most secure to the least secure.

  • To protect the network, remote users should be authenticated using the most secure method possible.

  • To successfully establish a connection and authenticate a user, the RRAS server and the remote access client must have at least one common authentication method and one common encryption method configured.

Table 8-15. User authentication methods for RRAS

Authentication method

Authentication details

Authentication security

Extensible Authentication Protocol (EAP)

Extends the authentication methods for PPP connections to include the EAP methods configured through remote access policies. In a standard configuration, these policies allow MD5-Challenge, Protected EAP (PEAP), Smart card, or other PKI certificate to be used.

Allows use of nonpassword-based authentication. Required if you want to use smart cards with remote access clients or PKI certificates. No other authentication method used by RRAS supports smart cards or PKI certificates.

Microsoft Encrypted Authentication Version 2 (MS-CHAP v2)

Uses Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 2 to authenticate remote access and demand-dial connections using mutual authentication and strong encryption. MS-CHAP v2 is required for encrypted PPP and PPTP connections.

Secure, encrypted, password-based authentication. Most secure encrypted password option for clients running Windows 98 or later.

Microsoft Encrypted Authentication (MS-CHAP)

Uses Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) to authenticate remote access and demand-dial connections using encryption. MS-CHAP is required for encrypted PPP and PPTP connections.

Secure, encrypted, password-based authentication. Less secure than MS-CHAP v2. Supports Windows 95 and Windows NT 3.51 clients that can't use MS-CHAP v2.

Encrypted Authentication (CHAP)

Uses MD-5 Challenge Handshake Authentication Protocol (CHAP) to authenticate remote access and demand-dial connections using encryption.

Secure, reversible-encryption, password-based authentication. Supports non-Microsoft remote access clients. If required, you must specifically enable Store Passwords Using Reversible Encryption in Group Policy or user properties settings.

Shiva Password Authentication Protocol (SPAP)

Uses authentication with reversible encryption and is compatible with Shiva LAN Rover and Shiva clients.

Reversible-encryption password-based authentication. Designed for use with Shiva products. SPAP is not secure.

Unencrypted Password (PAP)

Uses Password Authentication Protocol (PAP) and sends passwords in plain-text during authentication.

Unsecured, unencrypted, password-based authentication. For clients that support no other authentication method. PAP is the most unsecure authentication method.

Allow Remote Systems To Connect Without Authentication

Allows unauthenticated remote access to the network.

Unsecured, unauthenticated access. Removes security requirements and not recommended.


When you've configured VPN and set L2TP as the protocol type, you can use IPSec with L2TP to enhance security. To do this, you must define a custom IPSec policy, and then configure L2TP security options. To configure L2TP security options, right-click a server entry in the Routing And Remote Access console, select Properties, and then click the Security tab. Select the Allow Custom IPSec Policy For L2TP Connection checkbox. In the Pre-Shared Key text box, type a preshared key to use with the custom IPSec policy. Each client computer that will remotely access the network over VPN and be subject to the IPSec policy must be configured with the same preshared key.

8.3.2.3. Planning remote access policies

After the RRAS server authenticates a remote user and verifies his identity, the server next attempts to authorize the user. Authorization determines whether the server should permit the user to connect, based on any conditions that may apply to when and how the user can remotely access the server.

Remote access policies are used to define specific conditions that users must meet before RRAS authorizes them to access the server or the network. You can:

  • Create policies that limit access based on group membership, time of day, day of the week, and more.

  • Specify through policies what authentication and encryption protocols must be used.

  • Define different policies for different types of connections, such as dial-up, wireless, and VPN.

To view and manage remote access policies, select the Remote Access Policies node in the Routing And Remote Access console. Policies are reviewed in priority order, with the highest priority being 1. To create a policy, right-click the Remote Access Policies node, and then select New Remote Access Policy. The New Remote Access Policy Wizard, shown in Figure 8-18, walks you through the steps of creating the remote access policy and setting conditions.

Figure 8-18. Use the New Remote Access Policy Wizard to define a remote access policy.


When multiple policies are listed in the Remote Access Policies node as shown in Figure 8-19, you can control the order in which policies are reviewed for applicability by right-clicking a policy and using the Move Up or Move Down options as appropriate. The order of policies is important to determine how conditions are applied to a connection that has been authenticated but is not yet authorized.


Tip: Before RRAS can use remote access policies, the Control Access Through Remote Access Policy option must be set in the Dial-in tab of the user's properties dialog box. Use Active Directory Users And Computers to set this option. This option is not available in Windows 2000 Mixed Mode domains, in which the Allow Access setting is equivalent to the Control Access Through Remote Access Policy setting, when operating at the Windows Server 2003 domain functional level.

Figure 8-19. Listing remote access policies.


If a connection matches the conditions specified in a policy, the profile associated with the policy is applied to the connection. You can view and edit policy profiles by right-clicking the policy, and then clicking the Edit Profile button on the Settings tab. Using the Edit Dial-in Profile properties dialog box, shown in Figure 8-20, you can then set dial-in contracts, IP address assignment, authentication, encryption, and other options for the connection.

Figure 8-20. Setting options for the policy profile.


When remote access is controlled through policy, RRAS reviews policies using the following rules:

  1. RRAS checks the connection against the highest priority remote access policy. If there are no policies listed, RRAS rejects the connection.

  2. If the connection doesn't satisfy all the conditions in the highest priority remote access policy, RAS checks the connection against the next highest priority remote access policy. It continues through all the policies until it finds a match for all conditions. If the connection doesn't satisfy all the conditions in any one of the policies, RRAS rejects the connection.

  3. When the connection satisfies all the conditions of one of the policies, RRAS next checks whether the user's dial-in properties should be ignored. This option is set using the advanced attribute Ignore-User-Dialin-Properties.

  4. If Ignore-User-Dialin-Properties is set to True, RRAS checks the remote access permission setting of the policy to determine whether to grant or deny access. If Deny Access is selected, RRAS rejects the connection. If Allow Access is selected, RRAS matches the connection against the profile properties, accepting the connection if there is a match and rejecting the connection if there isn't.

  5. If Ignore-User-Dialin-Properties is set to False, RRAS checks the user's dial-in properties to determine whether to grant or deny access. If Deny Access is selected, RRAS rejects the connection. If Allow Access is selected, RRAS matches the connection against the profile properties, accepting the connection if there is a match and rejecting the connection if there isn't.

8.3.3. Troubleshooting TCP/IP Routing

Exam 70-293 tests your ability to troubleshoot TCP/IP routing in the following areas:

  • Diagnosing and resolving issues related to establishing a remote access dial-up connection, diagnosing and resolving issues related to remote access VPNs, and diagnosing and resolving issues related to resources beyond the remote access server, which were previously covered in Chapter 5 under "Troubleshooting User Access to Remote Access Services."

  • Troubleshooting router-to-router VPNs and troubleshooting demand-dial routing, which were previously covered in Chapter 5 under "Troubleshooting Routing And Remote Access Routing."




MCSE Core Required Exams in a Nutshell
MCSE Core Required Exams in a Nutshell: The required 70: 290, 291, 293 and 294 Exams (In a Nutshell (OReilly))
ISBN: 0596102283
EAN: 2147483647
Year: 2006
Pages: 95

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