Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Dynamic Host Configuration Protocol wikipedia , lookup
Server Message Block wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Extensible Authentication Protocol wikipedia , lookup
TV Everywhere wikipedia , lookup
Distributed firewall wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Wireless security wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Module 9: Remote User Connectivity Overview Introducing Routing and Remote Access Designing a Functional Remote Access Solution Securing a Remote Access Solution Enhancing a Remote Access Design for Availability Optimizing a Remote Access Design for Performance An organization might allow dial-up clients and remote office locations to access its private network resources. The remote access features of Routing and Remote Access in Microsoft® Windows® 2000 provide secure, dial-up access to a network for remote access clients. The remote access clients connect remotely by using various protocols and connection types. At the end of this module, you will be able to: Recognize Routing and Remote Access as a solution for remote access. Identify the design decisions that influence a functional remote access solution. Select appropriate strategies to secure remote access connections. Select appropriate strategies to enhance remote access availability. Select appropriate strategies to improve remote access performance. Introducing Routing and Remote Access Design Decisions for a Remote Access Solution VPN with Remote Access Solutions Routing and Remote Access Features Integration Benefits Routing and Remote Access enables remote access clients to access corporate networks as if they were directly connected to the corporate network. The remote access clients connect to the network by using dial-up communication links. To design a remote access solution, you need to: Identify the decisions influencing a remote access solution. Describe the architectural elements of a virtual private network (VPN) in a remote access networking strategy. Identify the features offered by Routing and Remote Access so that you can apply them successfully in the network design. Identify the benefits of integrating Routing and Remote Access with other Windows 2000 services. Design Decisions for a Remote Access Solution Adapter or Modem Remote Access Client Public Network Adapter or Modem Remote Access Server Provider Network PSTN X.25 ISDN Intranet Number of Dial-Up Clients? Local or Network-Wide Resources? Connection Technologies? Client Authentication, Security, and Encryption? Client Connection Protocols? Routing and Remote Access supports dial-up connections for remote users connecting to a private network. Users can access resources on the remote access server or on attached networks, provided they meet the network security requirements defined for the network design. Providing a Routing and Remote Access solution can reduce the dependence on service infrastructures (such as Internet service providers (ISPs)), and the performance variability of the Internet. In designing a Routing and Remote Access solution, you need to consider the: Maximum number of simultaneous user connections required. Types of resources that the clients would require to access (local, remote, or both). Connection technologies and throughput requirements. For example, connections that use modems over Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), or X.25. Client authentication, security, and encryption requirements. Client connection protocols. VPN with Remote Access Solutions Dial-Up VPN Client Voluntary Tunnel Compulsory Tunnel VPN Server Point of Presence (POP) PSTN ISDN POP/Network Access Server (NAS) VPN Server Internet VPN Server RADIUS Server POP/NAS Compulsory Tunnel with RADIUS VPN Connection Types Account-based Authentication and Encryption Compatibility with Other Operating Systems Many organizations are transitioning from a centralized in-house dial-up remote access infrastructure to an Internet-based infrastructure for clients accessing a corporate intranet. Organizations requiring support for dial-up clients can reduce costs by outsourcing the remote access dial-up points to an ISP. In addition, VPN maintains a high level of security for client connections to the private network. A VPN supports secure point-to-point communications over a private or public IP-based network. VPN connections are Transmission Control Protocol (TCP)based and require no intermediate router support. VPN Connection Types VPN supports Internet Protocol (IP) layer tunneling that creates a secure connection between a VPN-based remote access client and a remote access server on the private network. The computers participating in a VPN connection authenticate one another and encrypt the data flowing through the VPN. Note: It is possible to create a tunnel and send the data through the tunnel without encryption. However, it will not be a VPN connection because the private data is sent across a shared or public network in an unencrypted form. VPN connections can be designed as compulsory or voluntary tunnels. Compulsory tunnels are preconfigured device-initiated connections for which: The remote access server initiates tunnel connections. The remote access server supports the tunnel protocol. Client authentication is per user based and optionally uses Remote Authentication Dial-In User Service (RADIUS). Client support for tunneling is not required Voluntary tunnels are ad-hoc connections for which: The dial-up user initiates tunnel connections. Client support for tunneling protocols is required. No intermediate remote access server support for tunneling is required. Account-based Authentication and Encryption VPN enhances data security for a connection by: Authenticating remote users prior to data exchange. Encrypting authentication credentials. Encrypting exchanged data. Both Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP) support encrypted and plain text authentication. When using L2TP and Internet Protocol Security (IPSec) transport mode, VPN authentication is based on an exchange of certificates that prevents unauthorized access to resources and data. Authentication certificates also provide a means of sharing data encryption keys. Compatibility with Other Operating Systems The VPN technology is supported by a number of vendors and operating systems, and is supported on a number of remote access servers. Although only Windows 2000 supports a VPN configured for L2TP, any Windows 32-bit operating system supports a VPN configured for PPTP. Routing and Remote Access Features NetBEUI TCP/IP NWLink PPP Internet Remote Access Server NetBEUI NWLink TCP/IP SLIP PPP Non-Microsoft Communications Server Provides Dial-Up Access Supports various transport protocols Supports various WAN technologies Supports standard security protocols Provides Server Interoperability Dial-Up Client A Routing and Remote Access-based server supports dial-up connectivity to a network. In addition to providing access to directories and files, a remote access server also handles authentication and encryption for remote access clients. Provides Dial-Up Access Routing and Remote Access provides dial-up access for remote user connections by using Point-to-Point Protocol (PPP) or the Microsoft RAS protocol. Supports various transport protocols Over the communication channel, PPP allows negotiation of the following protocols: Transmission Control Protocol/Internet Protocol (TCP/IP). NetWare IPX/SPX/NetBIOS Compatible Transport Protocol (NWLink). NetBIOS Enhanced User Interface (NetBEUI). AppleTalk protocol. The Microsoft RAS protocol is a proprietary protocol supporting dial-up clients by using the NetBEUI local area network (LAN) protocol. The Microsoft RAS protocol is supported in all previous versions of Microsoft remote access and is used on Microsoft Windows NT® version 3.1, Windows for Workgroups, MS-DOS®, and LAN Manager clients. The remote access server acts as a network basic input/output system (NetBIOS) gateway for these remote clients. Routing and Remote Access Features … The NetBIOS gateway provides client access to resources over: NetBEUI. NetBIOS over TCP/IP (NetBT) protocol. NetBIOS over Internetwork Packet Exchange (IPX) protocol. Note: Routing and Remote Access does not support Serial Line Internet Protocol (SLIP) clients, whereas the Microsoft remote access client software does supports SLIP connections. Supports various WAN technologies Dial-up remote access clients can connect to wide area networks (WANs) by using the following methods: Standard telephone lines with a modem (PSTN) ISDN X.25 direct connection or X.25 packet assembler/disassembler (PAD) Supports standard security protocols Routing and Remote Access supports secured authentication and data encryption. The remote access server automatically negotiates authentication and encryption levels with PPP-based remote access clients. For authentication, Routing and Remote Access supports: Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) Microsoft Challenge Handshake Authentication Protocol, version 2 (MS-CHAP v2). Challenge Handshake Authentication Protocol (CHAP). Extensible Authentication Protocol-Transport Level Security (EAPTLS). Shiva Password Authentication Protocol (SPAP). Password Authentication Protocol (PAP). Provides Server Interoperability Remote access clients can access any PPP-based remote access servers. These servers include: Shiva LAN Rover. NetWare Connect. UNIX-based SLIP or PPP. Other PPP-based communications servers. Integration Benefits DHCP Server DNS Server WINS Server RADIUS Server Active Directory IP Address Name Resolution Name Resolution Authentication and Accounting Remote Access Policies Remote Access Server Routing and Remote Access integrates with other Windows 2000 networking services to extend these services to remote access clients and reduce network management. DHCP Integration Integration with DHCP allows dynamic allocation of IP address and configuration information to remote access clients. This reduces configuration errors by eliminating manual client configuration. Routing and Remote Access leases blocks of 10 IP addresses from DHCP for remote access clients. When clients disconnect, the IP address is returned to the pool. If the remote access server is configured to use the DHCP Relay Agent, all DHCP configuration information is provided to the remote access clients through the DHCP Relay Agent. If the DHCP Relay Agent is not configured on the server, clients only receive the IP address and subnet mask provided by the remote access server. Note: The TCP/IP options in DHCP can include specific configuration information for remote access clients by using the predefined user class RRAS.Microsoft to define the required client options. DNS Integration DNS integration allows clients with dynamically allocated IP addresses and configuration information to update their name records in a Windows 2000-based DNS server. This integration allows dial-up client DNS names to be resolved in the same manner as clients directly connected to the network. WINS Integration WINS integration allows dial-up clients with dynamically allocated IP addresses and configuration information to update their NetBIOS names in WINS. This integration allows the NetBIOS resource names that are registered by the dial-up client to be resolved in the same manner as clients directly connected to the network. RADIUS Integration RADIUS integration centralizes the management of multiple remote access servers. This integration allows: Centralized administration of remote access policies. Logging of client authentication success or failure from multiple remote access servers. Distributed authentication for clients in a heterogeneous network. Active Directory Integration Integration of Routing and Remote Access with a Windows 2000 native-mode domain allows the remote access policies to be administered through the Active Directory™ directory service. This integration provides: Unified administration by using the Active Directory management consoles. Mapping of Windows 2000 users and groups to remote access policies, which control dial-up connection permissions. Note: On a Windows 2000 remote access server, which is a member of a Windows 2000 mixed mode, or Microsoft Windows NT version 4.0 domain, a remote access policy cannot be specified for a user account. Designing a Functional Remote Access Solution Integrating Remote Access Solutions into a LAN Environment Integrating Remote Access Solutions into a Routed Environment Integrating VPN into a Routed Environment Selecting a Tunneling Protocol Integrating VPN Servers with the Internet Placing Remote Access Servers Within a Private Network Discussion: Evaluating Routing and Remote Access Functional Requirements The components of a Windows 2000-based dial-up solution include Routing and Remote Access-based servers, dial-up clients, LAN and remote access protocols, WAN options, and security options. Routing and Remote Access in Windows 2000 provides the server-side components to support a dial-up solution. To design a remote access solution based on Routing and Remote Access, you must consider the network access requirements, the protocols required, and the server placement issues. In this lesson you will learn about the following topics: Integrating remote access solutions into a LAN environment Integrating remote access solutions into a routed environment Integrating VPN into a routed environment Selecting a tunneling protocol Integrating VPN servers with the Internet Placing remote access servers within a private network Integrating Remote Access Solutions into a LAN Environment Dial-Up Clients Remote Access Server NetBEUI TCP/IP NWLink PPP Security Policies for Dial-Up Clients Concurrent Sessions and Multilink Aggregate Throughput for Clients Client Configuration Policies, Groups and Users LAN A remote access solution for a nonrouted LAN can provide a centralized dial-up facility for remote access clients. Clients connecting to the remote access server can be authenticated, provided with TCP/IP configuration information, and allowed access to resources on the network by using the permitted protocols. While designing a remote access solution for a nonrouted LAN, you need to identify solutions for the following: The security model for administering remote access permissions and connection settings in the remote access server. You can control access by individual user names, or by Windows 2000 native-mode or mixed-mode Remote Access Policies. The number of concurrent sessions required to service the dial-up clients. This allows definition of the number of inbound ports required. If PPP (Point-to-Point Protocol) Multilink Protocol and Bandwidth Allocation Protocol (BAP) are enabled, it may be necessary to provide more than one connection point per client. The aggregate throughput requirements for the clients. The peak aggregate bandwidth required by the clients must be equal to or less than the bandwidth available to the LAN interface in the remote access server. The TCP/IP configuration for the dial-up clients. The allocation of IP addresses and a subnet mask can be configured by the remote access server through preallocation to the client (allowing a fixed IP address), from a fixed pool of addresses, from DHCP, and from the Automatic Private IP Addressing (APIPA) addresses (169.254.0.1 through 169.254.255.254). The TCP/IP configuration for the dial-up clients with fixed IP addresses. The remote access server can configure the allocation of IP addresses and a subnet mask through pre-allocation to the client, thereby allowing a fixed IP address. Note: Remote access policies must be defined to permit users to request a fixed IP address, and you must configure the dial-up properties of the user account with a static IP address. The TCP/IP configuration for the dial-up clients with dynamic IP addresses. The allocation of IP addresses and a subnet mask can be configured by the remote access server from a fixed pool of addresses, from DHCP, and from APIPA addresses. Note: If a DHCP Relay Agent is configured on the remote access server, the client can request TCP/IP options that are defined in the DHCP scope for the subnet. If the DHCP Relay Agent is not configured, the clients only receive the IP address and subnet mask provided by the DHCP server. Integrating Remote Access Solutions into a Routed Environment Selecting Dial-Up Solutions Enabling Supported Protocols Providing Client-to-Server Connections Providing Demand-Dial Router-to-Router Connections Before integrating a remote access solution into a routed environment, you must consider the access connection speed and connection type of the dial-up users. You can constrain the functionality of any dial-up remote access design by the access connection speed and connection type. Bandwidth limitations of LANs and WAN links, and the dial-up connection speed, can place practical constraints on the remote access implementation design. Selecting Dial-Up Solutions Remote access servers can provide access to intranetbased resources by using dial-up connections. Dial-up connections are used when the remote access clients dial directly into modems attached to the organization's remote access servers. Consider implementing Routing and Remote Access dial-up solutions if the: Use of the Internet as a mechanism for accessing intranet-based resources is considered an unacceptable risk. Variability of the data throughput rate for an Internet connection is insufficient to support client needs. Logical connections consist of multiple physical connections, or the connections are increased in response to client bandwidth requirements. Security aspects of the network design require additional security features such as caller Identification (ID) verification or callback support. Cost of providing phone lines, modems, and multiport communication adapters is not prohibitive. Enabling Supported Protocols Remote access servers support connectivity to remote access clients by using multiple protocols. Certain protocols may be required to access particular intranetbased resources or applications. The following table lists the Routing and Remote Accessbased protocols and their features. Choose To provide TCP/IP Access to Web-based applications, File Transfer Protocol (FTP) servers, or other applications that are based on the TCP/IP protocol. NWLink Access to NetWare-based file and print servers by using Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX). AppleTalk Access to Apple Macintosh remote access clients by using the AppleTalk Remote Access Protocol. NetBEUI Access to file and print resources in a small, nonrouted LAN by using NetBIOS naming conventions. Providing Client-to-Server Connections Dial-up remote access solutions provide access to intranet-based resources for remote access clients. A dial-up remote access design must specify the: Number of telephone lines, modems, adapters, or asynchronous ports required to support the maximum number of simultaneous client connections. User accounts that will be granted remote access. Remote access policy restrictions that apply to a user or a group of users. Providing Demand-Dial Router-to-Router Connections To support connectivity between remote locations, a multiple remote access design must specify the: Telephone lines, modems, and asynchronous ports required for connecting the remote locations. Routing capabilities found in the Routing and Remote Access-based servers. Demand-dial interfaces found in Routing and Remote Access-based servers used to automate the initiation of the connection between the locations. User accounts used by the Routing and Remote Accessbased servers to authenticate each other. Remote access policy restrictions. Integrating VPN into a Routed Environment Selecting Dial-Up or VPN-based Servers Providing Remote Access Client Connections A VPN implementation can support hundreds of VPN remote access clients. However, the local network and WAN links can place practical constraints on the VPN design. Before selecting a VPN protocol and connection type, evaluate your organizational needs and environmental constraints. The VPN protocols provided by Windows 2000 support a variety of operating systems, security needs, and network designs. Selecting Dial-Up or VPN-based Servers Routing and Remote Access-based servers provide access to intranet-based resources by using VPN or dial-up connections. VPN connections are used when remote access clients dial into an ISP and then establish a virtual connection to the remote access servers of an organization. Dial-up connections are used when the remote access clients dial directly in to modems attached to the remote access servers of the organization. Consider implementing VPN remote access servers if: Using the Internet to access intranet-based resources is an acceptable risk. The organization's connection to the Internet supports the aggregate throughput required for the maximum number of concurrent remote access clients. The variability of Internet bandwidth does not adversely impact client response times. Providing Remote Access Client Connections Implementation designs that incorporate VPN servers provide access to intranet-based resources by using remote access clients. A VPN server design must specify: The number of PPTP or L2TP ports necessary to support the maximum number of simultaneous clients. The user accounts that are granted remote access. Remote access policy restrictions. Selecting a Tunneling Protocol PPP Frame PPTP IP GRE PPP Header Header Header Encrypted PPP Payload (IP Datagram, IPX Datagram) Remote Resource Server Client Remote Access Server Secure Tunnel over Existing Network L2TP/IPSec IP Header Private Network PPP Frame IPSec UDP L2TP PPP ESP Header Header Header Header PPP Payload (IP Datagram, IPX Datagram) Encrypted by IPSec Signed IPSec ESP Trailer IPSec Auth Trailer Dial-up clients may require secure connections to a remote location, or to resources on a private network. Routing and Remote Access in Windows 2000 supports two tunneling protocols that provide authentication and data encryption for creating VPN connections: PPTP L2TP PPTP PPTP is a de facto industry standard tunneling protocol that was first supported in Windows NT 4.0. PPTP is an extension of PPP and improves upon the authentication, compression, and encryption mechanisms of PPP. Microsoft Point-to-Point Encryption (MPPE) is used to encrypt PPP frames. A PPTP frame consists of a PPP frame carrying the encrypted payload with a Generic Routing Encapsulation (GRE) header. The encrypted payload can be an IP datagram, an IPX datagram or a NetBEUI frame. By default, Routing and Remote Access is configured for 128 PPTP ports. If your design requires more ports, then you must plan for the creation of these ports. If the Routing and Remote Access server is configured as a Virtual private network (VPN) server using the Routing and Remote Access Server setup wizard, then it is configured for 128 PPTP ports. L2TP L2TP-based virtual private networking connections are a combination of L2TP and IPSec. L2TP uses the authentication and compression methods of PPP, but relies on IPSec transport mode for encryption services. In an L2TP-based virtual private networking connection, the sender and receiver must support both L2TP and IPSec. The routers between the peer endpoints are required to support only IP. L2TP encapsulates the original payload inside a PPP frame and performs compression whenever possible. This compressed frame is then transported inside a User Datagram Protocol (UDP) packet that is encrypted by IPSec using an ESP header. By default, Routing and Remote Access is configured for 128 L2TP ports. If your design requires more ports, then you must plan for the creation of these ports. Note: IPSec can be used in tunnel mode without L2TP. IPSec tunnel mode is not supported for clients in remote access VPN scenarios. In this mode, IPSec is used for interoperability with other routers, gateways, or end systems. Select compulsory VPN tunnels if the client cannot support tunnel protocols directly. If clients can support the VPN protocols, select voluntary end-to-end VPN tunnels to provide the highest level of data protection. Integrating VPN Servers with the Internet Routing and Remote Access-based Router VPN Server Internet Firewall or NAT Device VPN Server Internet Integrating VPN Servers and Firewalls Integrating VPN Servers and NAT Devices The placement of a VPN server can significantly affect network security for a network that contains a firewall or a network address translation (NAT) device. A correctly placed VPN server must be accessible without compromising network security. Integrating VPN Servers and Firewalls Firewalls filter IP traffic based on the IP address and port number of the packet. Proper placement of the VPN server relative to the firewall will achieve the functionality, availability, and performance goals of the design without compromising the security aspects of the design. Outside the firewall Place the VPN server outside the firewall if: Exposing the Routing and Remote Access-based VPN server directly to the Internet does not compromise the security aspects of the design. The security risks associated with allowing access to the entire VPN IP address range through the firewall are unacceptable. All sensitive data is placed behind the firewall, and all remote access through the firewall is limited to the VPN server. If the VPN server resides outside the firewall, consider: Providing an IPSec tunnel between the unprotected VPN server and the Routing and Remote Access-based router that is placed inside the firewall, to reduce the number and complexity of the firewall filters. Configuring the firewall to allow communication between the unprotected VPN server and the Routing and Remote Access-based router inside the firewall. Encrypting all data between the unprotected VPN server and the internal Routing and Remote Access-based router by using the strongest encryption possible. Inside the firewall Place the VPN server inside the firewall if: The added security risk of exposing the Routing and Remote Access-based VPN server directly to the Internet compromises the security aspects of the design. The potential security problems associated with allowing access to the entire VPN IP address range through the firewall are acceptable. If the VPN server resides inside the firewall, you must configure the firewall filters to allow all PPTP-based and L2TP-based traffic across the entire VPN IP address range. Integrating VPN Servers and NAT Devices NAT devices, such as a proxy server, translate private IP addresses into public IP addresses and vice-versa. Some application servers directly record the IP address and port number of the remote access client. These applications require a translation table on the NAT device to operate correctly. The NAT device modifies the header of the IP packet in both directions to allow the application to perform normally. Using PPTP tunnels with a NAT device When configuring NAT devices for PPTP tunnels, remember that: PPTP does not encrypt IP header, and it operates with any NAT device. The NAT device requires the appropriate application translation tables. Using L2TP tunnels with a NAT device When configuring NAT devices for L2TP tunnels, remember that: When using IPSec with Encapsulating Security Payload (ESP) to encrypt data, the IP headers are encrypted. The NAT device cannot perform the modifications to the IP header. L2TP and IPSec with ESP encryption does not work with applications that require NAT translation tables. Placing Remote Access Servers Within a Private Network Firewall Internet Screened Subnet Remote Access Server Router Multimedia Server Router Router Placing in a Subnet Placing in a Screened Subnet Placing in a Single Segment LAN Resource Server WAN Link In designing a remote access solution, you must consider the position of the remote access server. The placement of a remote access server in a network can affect the delivery of data to remote access clients. It can also affect the data traffic flowing to other users on the network. Placing the Remote Access Server in a Subnet The server must be positioned in a subnet or on the segment with the most client-accessible resources if: There is a switched nonrouted LAN with multiple physical segments. This position minimizes unicast traffic flowing across segments, as the switch does not reflect traffic onto all segments. There is a routed network with multiple routers. Position the remote access server to minimize cross-subnet traffic. This position minimizes the effect of client data on the bandwidth available to other network users. Aggregate bandwidth considerations The data for all dial-up clients passes through the remote access server interface to the private network. Even when the client data speeds are moderate, the aggregate throughput required because of this concentration can be significant. In any design, wherever possible, you must minimize the routed path to resources that are used by the dial-up clients. Minimizing the routed path reduces both the client traffic delays, and the interaction of dial-up client traffic and normal network user traffic. For example, consider a remote access server with 128*56 kilobits per second (Kbps) V.90 modems. If you assume the following conditions: 1. 2. At peak times all lines will be used. A multimedia training application is running on the remote access clients, requiring sustained throughput of 38 Kbps from server to client. The aggregate bandwidth required will be: 38Kbps * 128 = 4.864 megabits per second (Mbps) The simplified throughput calculation shows that the remote access server would use 49 percent of the available bandwidth on a 10 Mbps Ethernet segment. The LAN traffic of other network users would increase this usage further and might make it impossible to service the dial-up clients' multimedia needs. A possible solution in this example is to move the multimedia files onto the remote access server so that network access is not required. Placing the Remote Access Server in a Screened Subnet The server should be positioned in a screened subnet if: Corporate policies exist with a mandate that client access be processed by a firewall or filter. Clients use a VPN tunnel to connect to the private network. The remote access server contains other data made available to the public networks. The majority of client resources exist in the screened subnet. Placing the Server in a Single Segment LAN The remote access server can be positioned solely based on physical network requirements if: There is a single segment, non-switched LAN. Clients are allowed to access only the remote access server resources. Discussion: Evaluating Routing and Remote Access Functional Requirements Remote Access Server WINS Clients Subnet 1 Subnet 2 WINS Clients Router A1 Router A2 Non-WINS Clients Router Subnet 5 Windows 2000–based Router File and Print Server Subnet 3 Subnet 4 WINS Clients Windows Multimedia Server To provide a functional remote access solution for an organization, you must decide on the number and placement of servers based on the throughput and access requirements of dial-up clients. The following scenario describes an organization's current network configuration. Read through the scenario, and then answer the questions. Scenario An organization has decided to restructure an existing remote access solution to give access to a larger number of employees. You are assigned the task of evaluating the currently available configuration and providing a viable solution for the new requirements. The current network configuration provides: Intranet access to all shared folders and Web-based applications. Access for 16 concurrent clients by using 56 Kbps modems. Network architecture as shown in the preceding diagram, with the routed network based on 10 Mbps Ethernet. Support for a mission-critical Web-based application that requires 24hours-a-day, 7-days-a-week operation. The organization requires the following new facilities: Intranet access to all shared folders and Web-based applications for remote access clients. Access for a total of 160 concurrent clients by using 56 Kbps modems. This requires average throughput of 7.5 Kbps per client. A solution that allows 36 of the concurrent clients to access training video presentations on the Windows Media™ Server. This requires sustained 28 Kbps throughput per client. Your are required to adhere to the following limitations: The flow of data for remote access clients across multiple subnets must be minimized wherever possible. Remote access servers will be based on a corporate standard computer purchase. The computer has a 10 Mbps network card and three 56 Kbps V.90 digital interface cards, each supporting eight 56 Kbps V.90 client connections. Securing a Remote Access Solution Selecting the Appropriate Authentication Protocols Selecting the Appropriate Encryption Methods Ensuring Security with Remote Access Policies Restricting Access to Private Network Resources Distributing Authentication and Accounting Using RADIUS The security of a network can be compromised if remote users are provided access to intranet-based resources. An effective security configuration confirms the identity of the clients attempting to access the resources on the network, protects specific resources from inappropriate access by users, and provides a simple, efficient way to set up and maintain security on the network. To help accomplish these goals, Routing and Remote Access offers the following security features: Prevents unauthorized remote access by using appropriate authentication protocols. Prevents unauthorized remote access by using appropriate encryption methods. Restricts access to the remote access server by using remote access policies. Restricts access to private network resources. Authenticates user accounts by using RADIUS. Selecting the Appropriate Authentication Protocols Remote Access Server Private Network Router Dial-Up Client Authentication To reduce the potential for unauthorized access, Routing and Remote Access supports various authentication protocols and encryptions methods. Some of the protocols supported by Routing and Remote Access provide enhanced authentication, whereas other protocols that provide less security give other benefits such as support for a wide diversity of remote access clients. The following table lists the authentication protocols supported by Routing and Remote Access and describes when to choose each protocol. Choose When MS-CHAP Providing encrypted authentication support for Microsoft Windows 95, Microsoft Windows 98, Windows NT 4.0, or Windows 2000. MS-CHAP v2 Providing encrypted authentication support for Windows 2000. EAP-TLS Providing encrypted authentication support for a smart card.The Routing and Remote Access-based remote access server is a member of a mixed-mode or native-mode domain in Windows 2000.The cost of adding a smart card reader to each remote access client is not prohibitive. CHAP Providing encrypted authentication support for remote access clients that use a diversity of operating systems.The client requires encrypted authentication. SPAP Providing encrypted authentication support for remote access clients by using Shiva LAN Rover software. PAP Providing unencrypted authentication, and when the remote access clients support no other protocol. Selecting the Appropriate Encryption Methods Remote Access Server Dial-Up Client Private Network Router Encryption MPPE L2TP over IPSec The encryption methods supported by Routing and Remote Access provide varying levels of encryption. MPPE MPPE uses RSA (public-key cipher for encryption/decryption) RC4 stream cipher to encrypt data for PPP or PPTP connections. MPPE can be configured by using a remote access policy to use 40bit, 56-bit, or 128-bit encryption keys. The 40-bit and 56bit keys are designed for international use. The 128-bit encryption keys are designed for North American use and are available in only North American versions of Windows 2000. MPPE … The following table shows the validation and encryption options available for MPPE. Validate by using Require data encryption Authentication methods Encryption enforcement negotiated Allow unsecured No password PAP, CHAP, SPAP, MSCHAP, MS-CHAP v2 Optional encryption (connect even if no encryption) Require secured password No CHAP, MS-CHAP, MSCHAP v2 Optional encryption (connect even if no encryption) Require secured password Yes MS-CHAP, MS-CHAP v2 MS-CHAP, MS-CHAP v2 Smart card No EAP/TLS Optional encryption (connect even if no encryption) Smart card Yes EAP/TLS Require encryption (disconnect if server declines) Note: To enable MPPE-based data encryption for dial-up or VPN connections, you must select the MS-CHAP, MSCHAP v2, or EAP-TLS authentication methods. These authentication methods generate the required keys used in the encryption process. Choose MPPE as the remote access data encryption method if: Using the MS-CHAP, MS-CHAP v2, or EAP-TLS authentication protocols. User authentication is used and no machine certificate infrastructure exists. L2TP over IPSec IPSec encrypts data within an L2TP-based connection. IPSec uses machine-based certificates for authentication, thereby reducing the ability of an unauthorized computer to impersonate an authorized computer. Validate by using The following table describes the validation and encryption options, and the authentication methods that are used within an L2TP-based connection Require Authentication methods data negotiated encryption Encryption enforcement Require secured No password CHAP, MS-CHAP, MSCHAP v2 Optional encryption (connect even if no encryption) Require Yes secured password CHAP, MS-CHAP, MSCHAP v2 Require encryption (disconnect if server declines) Smart card No EAP/TLS Optional encryption (connect even if no encryption) Smart card Yes EAP/TLS Require encryption (disconnect if server declines) The United States government eliminated export controls for most computer hardware and software products that incorporate "strong encryption" (symmetric key encryption with key lengths over 64 bits). Microsoft ships strong encryption capability in all products where previous export limitations resulted in only 40-bit and 56-bit Data Encryption Standard (DES) being available. In Windows 2000, the conversion to 128-bit encryption affects encryption of files on the disk, Internet Protocol (IP) Security, network driver interface specification (NDIS) wide area network connections, Secure Sockets Layer (SSL), and Terminal Services. Microsoft products may not be exported to Afghanistan, Cuba, Iran, Iraq, Libya, North Korea, Sudan, or Syria where export embargos are still enforced. Choose IPSec as the remote access data encryption method if: Using L2TP tunneling. A public certificate infrastructure exists. Ensuring Security with Remote Access Policies User Connection Request N Y Have a Policy? Reject Connection N Y Next Policy Policy Match? Y Accept Connection User Deny? Y Remote Deny? N Y User Allow? Y User Profile OK? N Remote access policies are a set of conditions and connection settings that define remote access permissions and usage. If the settings used for a dial-up client do not match at least one of the remote access policies that apply to the connection, the connection attempt fails, regardless of the client dial-up settings. Three models exist for defining remote access permissions and connection settings: Access restricted by user. Permits implicit and explicit Allow access or Deny access decisions on a user-by-user basis. Access restricted by a policy in a Windows 2000 native-mode domain. Permits implicit and explicit Grant remote access or Deny remote access decisions on a user or group basis. Access restricted by a policy in a Windows 2000 mixed-mode domain. Permits implicit and explicit Allow access or Deny access decisions on a user or group basis; it is implemented in the same manner as it is implemented in Windows NT 4.0 Customizing the remote access policies can restrict access to the remote access server by the: Time of the day and day of the week. Windows 2000 group to which the remote access user belongs. Type of connection being requested (Dial-up or VPN connection). Authentication and encryption types requested. Restricting Access to Private Network Resources Dial-Up Client Remote Access Server IP Network Network Server Properties of a Remote Access Server Allow access to IP network by dial-up clients You can secure the network resources by limiting access to the remote access or VPN server. The resources made available to clients can be different from the resources accessible to other users in the network. For example, if remote access permissions are given to employees and to a partner organization's staff, the dial-up resources made available may be restricted for the partner organization staff. Access to resources can be restricted for dial-up clients by: Allowing access to only those resources that are on the remote access server. This restriction is set on each individual remote access server, and applies to all clients who connect to the server. Allowing access to resources on the routed network to which the remote access server is attached. This restriction is set on each individual remote access server, and applies to all clients who connect to the server. Distributing Authentication and Accounting Using RADIUS Policy and Authentication Requests RADIUS Client Remote Access Server and RADIUS Client Router RADIUS Server (Internet Authentication Service) Dial-Up Remote Access Clients UNIX Server and RADIUS Server Authentication Requests Windows 2000 Domain Controller RADIUS is a security authentication protocol based on clients and servers, and is commonly used by ISPs on non-Microsoft remote access servers. Features of RADIUS RADIUS provides the ability to authenticate remote user accounts by using methods other than Windows 2000based authentication. For example, a remote access server that uses RADIUS can authenticate remote users by accessing a user account database located on a UNIX system. RADIUS centralizes the management of client authentication and accounting for remote access servers. The integration of Routing and Remote Access with RADIUS allows centralized: Remote access policies to be defined for all remote access servers, replacing individual server policies. Logging of client success, failure, and connection status events for multiple servers. The events to be logged include: Authentication requests for the connecting user. Authentication accepts and rejects for the connecting user. Accounting-interim requests, sent periodically by the remote access server during a user session. Enhancing a Remote Access Design for Availability Adding Redundant Remote Access Servers Centralizing the Management of Remote Access Servers Using RADIUS Discussion: Evaluating Routing and Remote Access Security and Availability Requirements The availability of a remote access implementation design is measured by the percentage of time users are able to obtain remote access to intranet-based resources. Windows 2000 enhances remote access availability by adding redundant remote access servers, and by centralizing the management of remote access servers. In this lesson you will learn about the following topics: Adding redundant remote access servers Centralizing the management of remote access servers using RADIUS Evaluating routing and remote access security and availability requirements Adding Redundant Remote Access Servers Using Connection Manager to Distribute Clients Adding Remote Access Servers at Remote Locations Using Multiple VPN Servers with Round Robin DNS Entries Using Windows Clustering with VPN Servers Any design that requires high availability must include more than one Routing and Remote Access-based server or VPN server. The level of availability for Routing and Remote Access is determined by the requirements of the organization. Remote access solutions with redundant servers can provide higher availability for both dial-up and VPN clients. Using Connection Manager to Distribute Clients Dial-up remote access clients connect to the private network by using a modem connected to a specific phone number. In the event of a single point connection failure involving the phone line, the modem, or the remote access server, connection to the private network is lost. To provide remote access availability in the event of a single point connection failure, consider: Assigning each remote access client a primary phone number connected to a designated remote access server. Assigning each remote access client a backup phone number connected to a redundant remote access server. Using Connection Manager to call the primary phone number first, and in the event of a failure, calling the backup phone number. Using Connection Manager to distribute and update changes to the access numbers for the intranet. Adding Remote Access Servers at Remote Locations In a design in which the remote access servers are centralized, a connection failure between remote locations affects access to the remote resources.To avoid this, consider distributing the remote access servers to the remote locations if: Connections between remote locations are unreliable. Connections between remote locations are experiencing heavy traffic. Remote access clients tend to connect to resources in a single location. A reduction of phone charges results from calling local numbers. Any design that requires high availability must include more than one VPN server. Using Multiple VPN Servers with Round Robin DNS Entries The round robin DNS entries must be with the same fully qualified domain name (FQDN), while also using the IP address of the respective VPN servers. Multiple round robin DNS entries are processed in the sequence found in the DNS database. When a server has more than one round robin entry in the DNS database, the server is accessed a corresponding number of times in sequence. When using multiple VPN servers and round robin DNS to provide high availability: Ensure that a round robin DNS entry exists for each VPN server. Add additional round robin DNS entries when specific VPN servers support a greater number of remote access clients than other VPN servers. Know that the design consumes fewer system resources than a design that uses Windows Clustering. Be aware that the VPN server failover is not automatic, and remote access clients receive time-out messages when attempting to connect to inactive VPN servers. Using Windows Clustering with VPN Servers You can use Network Load Balancing, one of the Windows 2000 Advanced Server features that make up Windows Clustering, to improve the availability of Internet Information Server (IIS), proxy, DNS, FTP, VPN, and streaming media servers. Network Load Balancing clusters provide high scalability and availability by combining up to 32 servers running Windows 2000 Advanced Server into a single cluster. Windows Clustering provides complete VPN server redundancy and centralized administration of the cluster. When using multiple VPN servers and Windows Clustering to provide high availability: Ensure that all servers in the same cluster have a highspeed, persistent connection. Be aware that VPN server failover is automatic and remote access clients do not receive time-out messages when attempting to connect to inactive VPN servers. Centralizing the Management of Remote Access Servers Using RADIUS Distributing Remote Access Policies to All Servers Providing Redundant Authentication and Accounting RADIUS centralizes the administration of remote access policies by configuring all remote access and VPN servers to share a common policy. Also, RADIUS inherently provides for centralized accounting of logon status. In organizations in which RADIUS is not used, remote access policies are configured on each remote access and VPN server. In addition, the log files that track user authentication success or failure are located on each remote access server. This complicates the management process because the system administrator has to manage multiple servers. Multiple remote access servers use RADIUS to centralize the: Administration of remote access policies. Logging of authentication success or failure. Discussion: Evaluating Routing and Remote Access Security and Availability Requirements ISP/Internet Connection WINS Clients Subnet 1 7 Remote Access Servers and 1 VPN/Proxy Server WINS Clients Subnet 2 Router A2 Non-WINS Clients Router A1 Subnet 5 Windows 2000–based Router File and Print Server Subnet 3 Subnet 4 WINS Clients Windows Multimedia Server To provide a highly available and secure remote access solution for an organization, you must decide on the number and placement of servers, and the security requirements of the organization and clients. The following scenario describes an organization's current network configuration. Read through the scenario, and then answer the questions. Scenario An organization has decided to restructure an existing remote access solution to improve security and availability. You are assigned the task of evaluating the currently available configuration and providing a viable solution for the new requirements. The current network configuration provides: Intranet access to all shared folders and Web-based applications. Internet connectivity by using a single computer VPN/proxy/firewall connection to an ISP. Access for 160 concurrent clients by using 56 Kbps modems. Access for 10 clients who use VPN access to the network. Network architecture as shown in the preceding diagram with the routed network based on 10 Mbps Ethernet. Support for a mission-critical Web-based application that requires 24-hours-a-day, 7-days-a-week operation. Remote access servers that are based on a corporate standard computer purchase. The computer has a 10 Mbps network card and three 56 Kbps V.90 digital interface cards, each supporting eight 56 Kbps V.90 client connections. Optimizing the Remote Access Design for Performance Distributing Remote Access Across Multiple Servers Improving Remote Access Performance on a Server In a remote access or VPN solution, the increase in the number of client connections can affect the performance of the solution. You must improve the performance of individual servers, or share the load of servers by including additional servers in the network design as the number of remote access clients increases. In this lesson you will learn about the following topics: Distributing remote access across multiple servers Improving remote access performance on a server Distributing Remote Access Across Multiple Servers Using Connection Manager to Distribute Clients Evaluate and then redistribute remote access clients across remote access servers Provide a new phone book that reflects the redistribution Adding Remote Access Servers at Remote Locations Distributes network load to the location where the resource resides Improves remote access performance Adding VPN Servers Factors such as changes in client application usage, WAN usage, and number of clients can affect the performance of a remote access server. A possible solution for the performance degradation is to use multiple remote access servers and distribute the client load across the servers. Using Connection Manager to Distribute Clients In a multiple-server remote access solution, the clients must be distributed evenly across the servers. Connection Manager allows the distribution of a phone book with multiple access numbers to clients. The clients connect to the dial-up numbers in the order specified in their phone book. The order of the phone book entries can be set for individual users or groups, allowing the client load to be evenly distributed between servers. Adding Remote Access Servers at Remote Locations Adding remote access servers at remote locations may improve performance where clients access local resources. At each remote location, install the appropriate number of remote access servers to support the clients that dial-up to access resources. Install remote access servers at remote locations if: The cost of the additional remote access servers is acceptable. The dial-up clients mostly access local resources. A significant reduction of phone charges results from calling local numbers. Adding VPN Servers Create VPN server designs by adding multiple VPN servers in a load-balancing configuration. These redundant servers distribute the remote access clients in a manner that divides total resource usage across all of the servers. Improving Remote Access Performance on a Server Improving Single Server Performance Dedicating a Server to Remote Access and VPN Servers Upgrading Existing Remote Access and VPN Servers Improving WAN and LAN Connection Performance Routing and Remote Access enhances server performance by supporting multiple CPUs that can be used by the multithreaded service. You can select a solution to enhance the performance of the server, depending on the components limiting the performance of the server. Improving Single Server Performance The following table lists the performance-limiting factors with the possible solutions. If the performance-limiting factor is Consider Client connection speed Upgrading to modems that support a higher transmission rate. Upgrading to intelligent communications adapters to offload processing from the remote access server. Using multiple or higher bandwidth network cards for the private and public network connection. Remote access server connection Individual computer Minimizing or offloading other services running on the computer. Adding multiple CPUs. Providing ample memory to support the service. Note: If the remote access server is also providing resources for remote access clients, the performance of the disk subsystems might become a limiting factor. Under these circumstances, the disk subsystem performance may be improved by using redundant array of independent disks (RAID) arrays. Dedicating a Server As a Remote Access and VPN Server In some designs, remote access and VPN servers share resources with other services and applications on the same physical computer. If performance is not achieving the design specifications, move all other functions to a separate computer. Consider dedicating a server to remote access or VPN if: Other functions running on the same computer can be transferred to another system. The cost of adding the additional server is acceptable. The existing server hardware cannot be upgraded further. Upgrading Existing Remote Access and VPN Servers When the resources of the VPN server are exhausted, the performance degrades relative to the degree to which the resources are used. After enough resources are depleted, the performance of the VPN server does not achieve the design specifications. Consider upgrading the existing VPN servers if: Other functions must run on the same computer. The cost of adding the additional server is unacceptable. The existing VPN server hardware supports future upgrades. Improving WAN and LAN Connection Performance In a proper design of remote access and VPN servers, the maximum data rate of the Internet or intranet connection must be the limiting factor in accessing resources. For example, if the design specifies the use of 256 Kbps asymmetric digital subscriber line (ADSL) connections for remote access clients, clients must expect data transmission rates near 256 Kbps. To improve the data throughput rates, consider: Upgrading to an ISP that provides improved data rates. Upgrading to intelligent communications adapters to offload processing from the server. Lab: Designing a Remote Access Solution Objectives After completing this lab, you will be able to: Evaluate a scenario to determine the requirements for a Routing and Remote Access design. Design a Routing and Remote Access solution for the given scenario. Prerequisites Before working on this lab, you must have: Knowledge of Routing and Remote Access features and functionality. Knowledge of Routing and Remote Access strategies for security, availability, and performance. Exercise 1: Making Remote Access Implementation Decisions In this exercise, you will design a remote access solution for the given scenario. Review the diagrams and the scenario. Answer the questions provided to complete your solution to the scenario. Scenario An organization has decided to restructure an existing remote access-based solution to its private network. You are assigned the task of evaluating how dial-up remote access is used in the existing physical network design. The current network configuration provides: Intranet access to all shared folders and Web-based applications at all locations. Access to the Internet from all locations. Remote access to corporate resources, regardless of a single server failure, for 60 remote staff members. Support for all of the hosts, as shown in the diagram. Support for dial-up clients with a mixture of 33.6 and 56 Kbps modems. Support for a mission-critical Web-based application that requires 24hours-a-day, 7-days-a-week availability. Remote access to shared folder resources on Windows 2000 and Novell NetWare 3.x-based servers, and to Web-based applications and files, including a sales multimedia presentation requiring sustained 28 Kbps throughput. Isolation of the organization's network from the Internet by using a proxy server and a firewall, both situated at LocationA. Encryption for all remote communications authentication and data. In the current scenario: Each remote user consumes an average of two percent of the remote access server's resources with an inactive baseline of four percent. Corporate guidelines for resource computers and servers require that average usage not be above 70 percent. Average data rates for remote clients do not fall below 30 Kbps. High Level Network Design The following diagram shows an overview of the existing network configuration. Each location is shown in detail in subsequent diagrams. LocationA Network Design The following diagram shows the existing network configuration at LocationA. LocationB Network Design The following diagram shows the existing network configuration at LocationB. LocationC Network Design The following diagram shows the existing network configuration at LocationC. Review Introducing Routing and Remote Access Designing a Functional Remote Access Solution Securing a Remote Access Solution Enhancing a Remote Access Design for Availability Optimizing a Remote Access Design for Performance