Implementing Secure Access Between Private Networks

Objective:

Implement secure access between private networks.

You have learned how to connect a remote user to a production Windows Server 2003 system by using RRAS. RRAS can also provide features that are used to securely connect networks together. Windows Server 2003 RRAS provides two mechanisms for securely connecting private networks: VPN and demand-dial routing.

Windows Server 2003 VPNs

A VPN creates a logical private network across an existing public network infrastructure such as the Internet. You've already seen this from a client-server perspective in Step by Step 6.11, but now we're going to examine this from a server-to-server or network-to-network point of view. This connection is called virtual because the logical connection is built independently of the underlying physical network. In other words, the VPN connection is not aware of the physical route the packets take across the networkit is aware only of the endpoints of the virtual connection.

The purpose of a VPN is to securely extend a private internal network to users and external networks. When a VPN is configured correctly, a user should be unable to differentiate a VPN connection from a LAN connection. More importantly, the user's applications should not be able to differentiate between the two types of connections either. Therefore, using a VPN is a seamless method for integrating remote users or locations into a private network.

There are two common types of VPNs that you are likely to encounter:

• Remote access VPN A remote access VPN is typically used to allow remote users to connect to a private corporate network securely. Remote access VPNs were one of the major drivers of the VPN technology because they allow users to connect to a corporate network without requiring the extensive modem cards and lines needed for large remote access server implementations.

• Site-to-site VPN Also known as a network-to-network VPN, a site-to-site VPN is typically used to replace expensive private WAN links with lower-cost VPN connections, utilizing the Internet as the underlying public network. When implemented correctly, site-to-site VPNs can provide a cost-effective, reliable option to replace the more traditional WAN connections. An additional use for site-to-site VPNs that is becoming more common has to do with the growing requirement for companies to interconnect with business partners, vendors, and customers. Not only do VPNs provide a secure mechanism for these interconnections, but they can be created much more quickly than installing a WAN connection, which typically takes from 45 to 60 days.

One other type of VPN connection that is less common but growing in popularity is a VPN connection across a private network. This is a variant of the site-to-site connection, but instead of replacing a private WAN connection, it is used to enhance the security of the WAN. This type of connection is typically used in environments where different sections of the internal network require different levels of security. For example, a VPN might be required to access the Research and Development network within a company to ensure secure connections between corporate offices that exchange sensitive data, or to secure top-secret data within government files traversing the internal network.

All three of these VPN types are easily supported with the Windows Server 2003 RRAS.

Supported VPN Protocols

Windows Server 2003 supports two VPN protocols: PPTP and L2TP.

PPTP

PPTP is a proprietary VPN protocol originally developed by the PPTP Forum, a group of vendors that included Ascend Communications, Microsoft Corporation, 3Com, ECI Telematics, and U.S. Robotics. PPTP was designed as an extension of PPP to allow PPP to be tunneled through an IP network. One of the main differentiators of PPTP versus IPSec is that PPTP supports the encapsulation of not only IP, but also IPX or NetBEUI. This is particularly useful in Windows and Novell environments that have not migrated to TCP/IP.

PPTP uses the proprietary MPPE protocol to encrypt the link between the VPN client and server, and it uses the Generic Routing Encapsulation (GRE) protocol for the encapsulation of the encrypted PPTP data in the PPP frame, which can be an IP datagram, an IPX datagram, or a NetBEUI frame.

One of the key benefits of PPTP is that because Microsoft helped develop it, it has been bundled with all current versions of Microsoft's operating systems. This caused some problems because some security experts felt that PPTP was not secure enough to be used for Internet-based VPN connections, but Windows Server 2003 contains an updated version of PPTP that is secure.

At one time, PPTP was the most widely used VPN protocol, but the release of IPSec has had a significant impact on PPTP's use. Although PPTP is still popular with Microsoft shops and when Windows Server 2003 is being used as the VPN server, IPSec is enjoying increasing popularity with companies that are using hardware-based VPN servers. PPTP is steadily being replaced by L2TP and will likely not be widely used for much longer or in future versions of Windows.

For more details on PPTP, see RFC 2637, "Point-to-Point Tunneling Protocol" (July 1999). It is important to note that this is an informational RFC and was never adopted as a standard. This is a key difference between PPTP and IPSec.

L2TP

L2TP is a combination of the best features of PPTP and the Layer 2 Forwarding (L2F) protocol. The L2F protocol was an early competing protocol for PPTP that was developed by Cisco Systems. Like PPTP, L2TP was designed as an extension of PPP to allow PPP to be tunneled through an IP network. However, L2TP defines its own tunneling protocol, based on L2F. L2TP support was first included in a Microsoft server product with the release of Windows 2000 Server, and it continues to be supported in Windows Server 2003. Prior to Windows 2000, PPTP was the only supported VPN protocol in the Windows operating system family.

L2TP uses one of the IPSec protocols, Encapsulating Security Payload (ESP), for encryption. For this reason, L2TP under Windows Server 2003 is also known as L2TP/IPSec. The use of IPSec as the encryption mechanism allows L2TP/IPSec to utilize third-party encryption hardware to offload the encryption functions of the VPN connections from the VPN server. Also, the standard implementation of L2TP/IPSec requires the use of machine Public Key Infrastructure (PKI) certificates. This ensures a more secure connection, but at the cost of a more complex implementationyou must have access to a Certificate Authority (CA) to implement an L2TP/IPSec VPN connection.

As mentioned in the previous paragraph, L2TP uses IPSec for encryption. We examine IPSec in more detail in the next section.

IPSec

IPSec is a set of protocols developed by the Internet Engineering Task Force (IETF) to allow for the secure exchange of data via the IP. As a result, IPSec is used by many vendors to deliver VPN services. One of the major limitations of IPSec is that the IETF guidelines do not allow IPSec to support the traversal of networks by using Network Address Translation (NAT). Microsoft has addressed this issue in the latest version of its IPSec VPN.

Two encryption modes are supported by standard IPSec: transport and tunnel. Transport-mode IPSec encrypts only the data portion of a packet. The packet's header information is left intact. For a more secure connection, tunnel-mode IPSec encrypts not only the data portion of a packet, but also the header.

The protocols used by IPSec include the following:

• Internet Security Association and Key Management Protocol/Oakley (ISAKMP/Oakley) The ISAKMP/Oakley protocol is used to share a public key between the sender and receiver of a secure connection. This protocol allows the receiving system to retrieve a public key and then authenticate the sender by using digital certificates.

• Internet Key Exchange (IKE) The IKE protocol is used to authenticate the endpoints of an IPSec connection, negotiate the exchange of IPSec keys, and negotiate IPSec security associations (SAs). An SA is used by the IPSec endpoints to define how data will be encrypted and decrypted. IKE also uses the Diffie-Hellman public-key cryptography protocol to exchange the session keys used to create the initial secure connection.

• Authentication Header (AH) The AH protocol authenticates the data packet and ensures the integrity of the data being sent. This protocol uses hashing algorithms to ensure packet and data integrity by signing the packets with a hash. The hash is then decoded at the other end of the connection to verify the data. The algorithms used by AH include MD5 and Secure Hash Algorithm (SHA).

• ESP The ESP protocol encrypts the data contents of a packet. In conjunction with ESP, IPSec can use a number of encryption algorithms, including DES and Triple DES (3DES).

Note: Network Interfaces and a Windows Server 2003 VPN

You need two NICs installed in a server to set up a Windows Server 2003 VPN (and to complete Step by Step 6.12 in the following section). With Windows Server 2003, you must have an external (Internet) interface and an internal (local LAN) interface to install a VPN connection. However, if you want the server to act as the endpoint of a VPN connection and do not need to route traffic to the internal network, you can use a single-interface server.

Configuring a VPN Connection

Now that you are familiar with some of the underlying protocols involved in creating a VPN connection, Step by Step 6.12 demonstrates the creation of a VPN demand-dial connection.

Step By Step

6.12. Enabling VPN Demand-Dial Routing on a Windows Server 2003 Server

1.	Log on to Windows Server 2003 by using the Administrator account or another account that has administrator privileges.
2.	Open the Routing and Remote Access console by selecting Start, Administrative Tools, Routing and Remote Access.
3.	In the left pane, right-click the server and select Properties from the context menu. The server (local) Properties dialog box, as seen in Figure 6.70, appears. Figure 6.70. Before you can configure demand dial routing, it must be enabled on the server.
4.	On the General tab, select LAN and demand-dial routing. Click OK to return to the Routing and Remote Access console.
5.	Right-click Network Interfaces within the console tree and select New Demand-Dial Interface from the context menu. The Demand-Dial Interface Wizard appears.
6.	Click Next to proceed. The Interface Name dialog box appears.
7.	In the Interface Name field, type a name for this connection interface. Click Next to continue. The Connection Type dialog box of the wizard, as seen in Figure 6.71, appears. Note that if your server does not have a modem installed, the first option displayed in Figure 6.71 will be unavailable to you. Figure 6.71. The Connection Type dialog box offers three alternatives for a demand-dial connection.
8.	In the Connection Type dialog box, select Connect Using Virtual Private Networking (VPN) and click Next to continue. The VPN Type dialog box of the wizard, as seen in Figure 6.72, appears. Figure 6.72. If you aren't sure which VPN type to use, the server automatically selects a VPN type when it tries to connect.
9.	Select Automatic Selection and click Next. The Destination Address dialog box of the wizard, as seen in Figure 6.73, appears. Figure 6.73. You can use an IP address or a DNS name to identify the remote router.
10.	Enter the IP address or DNS name of the answering router in the space provided. Click Next to continue. The Protocols and Security dialog box, as seen in Figure 6.74, appears. Figure 6.74. Because you are creating a VPN connection, you will be able to select only the first two options.
11.	On the Protocols and Security dialog box, select the protocols you want to route over the connection. Select Route IP Packets on This Interface and Add a User Account So a Remote Router Can Dial In. You cannot select the option of sending a plaintext password due to the security ramifications associated with unencrypted passwords. Click Next to continue. The Static Routes for Remote Networks dialog box, as seen in Figure 6.75, appears. Figure 6.75. You will need to define at least one static route.
12.	Click Add to open the Static Route dialog box, as seen in Figure 6.76. Figure 6.76. Enter your static route configuration information.
13.	Enter the network and the subnet mask and click OK to add the new route. You can see the new route in the Static Routes for Remote Networks dialog box, as seen in Figure 6.77. Click Next to continue. The Dial In Credentials dialog box, as seen in Figure 6.78, appears. Figure 6.77. The static route has been added. Figure 6.78. You need to supply the credentials the remote router will be using to connect to this server.
14.	As a result of selecting the Add a User Account So a Remote Router Can Dial In option in Step 9, you need to create a user ID and password for the remote router to authenticate with when it dials in. Enter a username and password and then click Next to continue. The Dial Out Credentials dialog box, as seen in Figure 6.79, appears. Figure 6.79. You need to supply the credentials that this router will be using to connect to the remote server.
15.	In the Dial Out Credentials dialog box, enter the security credential information that will allow you to connect to the answering router, including the username, domain, and password. Click Next to continue. The Completing the Demand-Dial Interface Wizard dialog box appears.
16.	Click Finish to return to the Routing and Remote Access console. You should see your new demand-dial interface in the right pane of the Routing and Remote Access console when Network Interfaces is selected in the left pane.

Exam Alert: Using VPNs with Network Address Translation

For the exam, be sure you know that unlike in previous versions of Windows, the IPSec VPN client included with Windows Server 2003 can traverse a firewall or network by using NAT. In previous versions of Windows, PPTP was needed if NAT was used in any portion of the connection, due to the limitations of the existing IPSec protocol suite specifications.

In previous versions of the Windows Server operating system, access across a network using NAT with an IPSec tunnel wasn't possible. NAT can still present some problems, so we need to talk about what exactly NAT is. As you are undoubtedly aware, the Internet relies on TCP/IP for communications. In addition, for two systems to communicate by using TCP/IP, each system must have a unique IP address. Without a unique address, the network cannot deliver the packet to a system. This sounds like a straightforward process until you consider the size of the Internet.

In the early days of the Internet, when IP addressing was being developed, the 32-bit addressing scheme (known as IP version 4 [IPv4]) was considered more than adequate for any potential network growth. Theoretically, there were 4,294,967,296 unique addresses available by using 32-bit addressing, and even discounting the reserved ranges, there are still more than 3 billion possible addresses. At the time, that was enough addresses to provide an address for every person on the planet, including children.

Unfortunately, the designers of the IPv4 addressing scheme dramatically underestimated the explosive growth of the Internet and the popularity of TCP/IP in business and home networks. There are no longer enough addresses to go around. As a result, a new addressing scheme is being developed. IPv6 is an addressing scheme that allows for a dramatically larger pool of addresses, but it is enjoying very limited deployment on the Internet today. This is in large part due to the use of NAT. (For more information on NAT, see RFC 3022, "Traditional IP Network Address Translator [Traditional NAT].")

NAT is a standard that allows you to use one set of IP addresses on your internal LAN and a second set of IP addresses for the Internet connection. There is a device (usually a router or firewall) between the two connections, and it provides NAT services and manages the translation of internal addresses to external addresses. This allows companies to use large numbers of unregistered internal addresses while only needing a fraction of that number of addresses on the Internet, thus conserving the addresses.

There are two main types of NAT:

• Static NAT Static NAT maps an unregistered IP address on a private network to a registered IP address on a public network, on a one-to-one basis. Static NAT is typically used when the translated device needs to be accessible from the public network. For example, a Web server on your private network might have the unregistered address 10.100.100.100 but be using the NAT address 12.2.2.123. A user trying to connect to that Web site can enter 12.2.2.123, and the router or firewall at the other end translates that address to 10.10.10.10 when the packet reaches it, allowing the remote user to access the Web site.

• Dynamic NAT Dynamic NAT maps an unregistered IP address to a registered IP address from a group of registered IP addresses. Dynamic NAT is most commonly used when large pools of systems on the internal network need to access the Internet and don't have a requirement for a static address. When a workstation initiates a connection to the public network, its unregistered address is translated to the next available registered address. You commonly see this used in corporate networks and in some ISP networks (with DSL and cable modem connections, for example).

Note: Which NAT Will You Encounter?

What sort of NAT might you run into in the corporate world? The answer is both. Dynamic NAT is most common, as it allows for better utilization of registered addresses, but static NAT is used in circumstances in which the translated address must remain the sameas in for a Web server, for example.

The most critical thing to remember about NAT is that due to limitations in the first version of the IPSec standard, IPSec cannot traverse a translated network. IPSec requires that both the VPN client and the VPN server have static, untranslated addresses on the public network for connection to occur. What this means from a practical perspective is that if you are trying to connect and there is NAT in the network architecture anywhere, you need the latest Microsoft IPSec client to connect successfully.

Demand-Dial Routing

In this chapter, we have already discussed in detail the most common method for connecting two private networks: VPN. Now we need to discuss the use of demand-dial routing connection for connecting private networks.

A demand-dial network consists of a calling router and an answering router. When you're using Windows Server 2003, both the calling and answering routers must have RRAS installed. You typically see demand-dial routing used in two instances:

• Redundant network links Demand-dial routing is a good solution for providing redundant network links. In the event that a primary, always-connected network connection is unavailable, a Windows Server 2003 server with demand-dial routing can initiate a backup dial connection until the primary connection is available again.

• Small office connections Demand-dial routing is also used in small office environments or remote offices where the expense of maintaining a constant connection is too high. A demand-dial connection can be established when access to external network resources is needed, and then the connection can be terminated when the connection is no longer needed.

Note: Demand-Dial Routing Is Not Just for Modems Anymore

Although this service is still called demand-dial, it can also refer to connections made by using a VPN connection across a public network. This is becoming more common as Internet access becomes more ubiquitous. Windows Server 2003 also introduced support for PPP over Ethernet (PPPoE) connections. PPPoE is based on PPP and Ethernet and provides a specification for connecting hosts on an Ethernet network to the Internet through a broadband medium (DSL, cable modem, or wireless). PPPoE combines Ethernet's ability to support multiple hosts on a LAN with PPP's serial connection capabilities.

To enable demand-dial routing on an existing Windows Server 2003 server, complete Step by Step 6.13.

Note: Modem Required

You will need to have a modem installed in your server to complete Step by Step 6.13.

Step By Step

6.13. Enabling Demand-Dial Routing on a Windows Server 2003 Server

1.	Log on to Windows Server 2003 by using the Administrator account or another account that has administrator privileges.
2.	Open the Routing and Remote Access console by selecting Start, Administrative Tools, Routing and Remote Access.
3.	Right-click Network Interfaces within the console tree and select New Demand-Dial Interface from the context menu. The Demand-Dial Interface Wizard appears.
4.	Click Next to proceed. The Interface Name dialog box of the wizard appears.
5.	In the Interface Name field, type a name for the connection interface. Click Next to continue. The Connection Type dialog box of the wizard appears.
6.	In the Connection Type dialog box, select Connect Using a Modem, ISDN Adapter, or Other Physical Device and then click Next to continue. The Select a Device dialog box of the wizard appears.
7.	Select the physical device you want to use and click Next. The Phone Number dialog box of the wizard appears.
8.	Enter the phone number of the answering router in the space provided. Click Next to continue. The Protocols and Security dialog box of the wizard appears.
9.	In the Protocols and Security dialog box, you can select the protocols you want to route over this connection. Select Route IP Packets on This Interface and Add a User Account So a Remote Router Can Dial In. You should avoid enabling the sending of a plaintext password whenever possible, due to the security ramifications associated with unencrypted passwords. Click Next to continue. The Static Routes for Remote Networks dialog box of the wizard appears.
10.	Click Add to open the Static Route dialog box. Enter the destination, the network mask, and the metric and then click OK to add the new route. Click Next to continue. The Dial In Credentials dialog box of the wizard appears.
11.	As a result of selecting the Add a User Account So a Remote Router Can Dial In option in step 9, you need to create a user ID and password for the remote router to authenticate with when it dials in. In the Dial In Credentials dialog box, enter a username and password and then click Next to continue. The Dial Out Credentials dialog box of the wizard appears.
12.	Enter the security credential information that will allow you to connect to the answering router, including the username, domain, and password. Click Next to continue. The Completing the Demand-Dial Interface Wizard dialog box appears.
13.	Click Finish to return to the Routing and Remote Access console. You should see the new demand-dial interface in the right pane of the Routing and Remote Access console when Network Interfaces is selected in the left pane.

When a calling router receives a packet over the network, the router determines the best route to use to forward the packet. If the route chosen is a demand-dial route, a connection is initiated with the other side. A connection can be initiated over either a physical connection such as an analog or ISDN line or over a logical connection known as a tunnel. Such tunnels are established by using either PPTP or L2TP.

After the demand-dial router determines that a connection needs to be established, the demand-dial router determines whether a connection currently exists. If the status is connected, the packet is forwarded to the destination host. If no connection is in place, the calling router must establish a connection.

To establish a connection from the calling router to the answering router, the calling router checks the dial-out hours and demand-dial filters configured on the interface. If dial-out hours or demand-dial filters prohibit establishing a connection, the connection attempt fails, and the host that originated the packets is notified that the destination host is unreachable. If, after the router checks, the connection is able to proceed, the router retrieves the configuration of the demand-dial interface and then, based on the configuration, a connection is established with the answering router. The Windows Server 2003 demand-dial router supports several types of connections, including the following:

• Modem or ISDN With this type of configuration, the configured phone number is dialed.

• VPN With this type of configuration, the configured host or IP address is used to establish either a PPTP or IP Security (IPSec) connection.

• Direct serial or direct parallel port With this type of configuration, a direct connection is made between the calling router and the answering router over the serial port or parallel port. (This is almost never used outside a lab/test environment.)

After a connection has been made, it is necessary for the calling router to negotiate a PPP connection with the answering router. Part of the negotiation is to send the credentials of the calling router. The answering router then checks the credentials against a local accounts database and/or remote policies or forwards the connection attributes to a RADIUS server, where the credentials are checked.

In addition to authenticating the users' credentials, PPP negotiates parameters for the connection, such as the IP addresses of both routers, the name servers to be used, and any static routes that may have been put in place by the user.

Finally, the answering router looks up the user initiating the connection to find a matching interface. If a matching demand-dial interface is located, the connection state is changed to a connected state, and the routing connection is established. If a matching interface is not found, the calling entity is identified as a remote access client computer, and a routing connection is not established.

Types of Demand-Dial Connections

Two types of connections are available with demand-dial routing: on-demand connections and persistent connections.

An on-demand connection is initiated when a packet is received by the calling router. When the calling router receives information for the answering router, it initiates the connection. After the information has been transmitted to the answering router and the connection has remained idle for a period of time, the connection is dropped. You can configure the demand-dial timeout on the Options tab of the demand-dial interface Properties dialog box.

In a demand-dial environment, one router can be configured to initiate the connection, or both routers can be configured to initiate connections. Having only one router configured to initiate the connection is known as a one-way connection. Having both routers configured to initiate connections is known as a two-way connection.

In a one-way initiated connection, the calling router is configured with a username that is used to connect to the answering router. Associated with this user account are static routes that define which packets are to be routed to the other side. When the connection is initiated and the username is authenticated by the answering router, the static routes associated with the username are added to the routing table of the answering router.

A two-way initiated connection is very similar to a one-way initiated connection, except that both routers must be configured with the necessary information to allow each to establish the connection. In addition, the calling and answering routers must both be configured.

In both a one-way initiated connection and a two-way initiated connection, the router initiating the call must be configured with a username that matches the username on a demand-dial interface on the answering router.

An on-demand connection can introduce problems for time-sensitive applications because the application must be able to tolerate a delay while the calling router initiates the connection with the answering router and the static routes configured on both routers are propagated throughout the internetworks on both sides. The length of this delay varies, depending on the type of physical or logical connection being established.

With a persistent connection, there is no delay while the calling router initiates a connection with the answering router. The connection is available on a permanent basis. This type of connection is generally found in WAN environments where the connection is over a leased line, X.25 connection, or ISDN connection. With a persistent connection, the calling router can be configured to reestablish the connection automatically if the connection is lost.

The choice of connection provides insight into the type of routing that should be configured over the connection. If the connection is persistent, one of the dynamic routing protocols, such as RIP or OSPF, may be used with special configuration to take into consideration the use of a demand-dial connection.

In an on-demand connection scenario, the use of a dynamic routing protocol might not be the most appropriate choice. Dynamic protocols need to periodically exchange information between routers to keep their routing tables up-to-date. This is a function of how dynamic routing protocols work. The requirement to periodically exchange information with other routers in the environment can cause a connection to be made each time the update process takes place, or in some cases, it can keep the connection up permanently, depending on how often the update process takes place. This may not be what is desired in an environment where you are trying to minimize costs.

In an on-demand connection, the preferred way of enabling routing is to use either static routes or autostatic updates. Step by Step 6.12 looked at using the static routes method, and the following section describes autostatic updates. When you're configuring static routes, you need to consider using a default route (0.0.0.0). The default route is used to specify what should be done with network traffic when none of the existing routes provide a path for it. If no route exists, the router forwards the traffic through the default route. If all the IP traffic needs to traverse the demand-dial connection, a default route should be the only route that needs to be configured. For more information on static routes, see Chapter 7, "Implementing, Managing, and Troubleshooting Routing."

Autostatic Updates

An autostatic update is a request from a router for all known routes or services from the router on the other side of the connection. After the request is received, the router adds the requested routes to its routing table. An autostatic update is a one-time, one-way exchange of routing information. Autostatic updates do not occur automatically on initiation of a demand-dial connection. Rather, the autostatic update must be manually initiated, or a schedule must be put in place to update routes. After the routes have been sent, the two routers do not exchange updates of routing information unless a manual request to update is made or a scheduled request occurs, depending on how autostatic updates are configured within the environment. Autostatic updates are useful for environments where there are too many routes for static routing to be manageable.

Challenge

You are the network administrator for NR Widgets, Inc., a multinational conglomerate, and you are based in the conglomerate's corporate headquarters. NR Widgets has a mobile population of about 200 people who need access to the network for submitting expense reports.

About 100 of the users live and work within your local area code, and the rest are scattered throughout the country. Your management does not want to pay for long-distance calls for remote access.

Your mobile users consist of three groups. The first group is the highly technical telecommuters, who need access to everything. They are also very security conscious and want to make sure their information is as secure as possible. The second group is the local users who need access but are not too concerned about the security of the connection. The third group consists of about 35 users who work from home and have high-speed Internet connections.

Your manager has tasked you to accomplish the following goals:

• You must ensure that each group has access to the network.

• You must ensure that each group of users has the information security it needs.

• You must ensure that long-distance or toll-free numbers are not used.

Through your discussions with the key stakeholders in this project, you've determined the following additional information:

• The management of your company is reluctant to make a major investment in toll charges for a dial-based remote access solution.

• Your company has three main populations of users, each with different remote access requirements.

• Each team needs to have a particular level of security.

Your task is to implement the required remote access solution for NR Widgets, Inc.

Try to complete this exercise on your own, listing your conclusions on a sheet of paper. After you have completed the exercise, compare your results to those given here.

Answers

As you have discovered in this chapter, you can meet the requirements of this case by configuring Windows Server 2003 RRAS. However, by now, you probably realize that it is a bit more complicated than just running the Routing and Remote Access Server Setup Wizard. First, you need to take a close look at each population of users. The technical telecommuters, who have access to confidential information, need to have a configuration that leverages the robust security and encryption mechanisms of Windows Server 2003 RRAS. You might need their profile configured for dial-back, and you might also need to use smart cards for authentication.

You probably need to limit the access of the second group of users so that these users can't get sensitive information on the network because these users are using a less secure, more user-friendly authentication policy.

Finally, although it is easy to configure a networkfor example, an Internet-based VPNyou still need to make decisions. You need to examine the amount of bandwidth you have to the Internet to support these users. You need to consider where the server is placed. Should it be behind a firewall or directly on the Internet? You need to consider which VPN protocol is best suited for the environment. You might even find that your remote users who are not in the local area code want to utilize a local ISP in conjunction with the VPN solution, allowing you to further save on toll charges. All this is very dependent on the environment and the circumstances and requires effective planning. Here's what you need:

• You need to have one server that is running Windows Server 2003 server and RRAS.

• The server needs to have modems installed and configured for dial-in users.

• Users who do not have the ability to dial locally to the server need to leverage the Windows Server 2003 VPN service; therefore, the server needs an Internet connection.

• The server needs remote access profiles to control the session security for each group.