Configuring Remote Access/Virtual Private Networking

This module is called "Configuring Remote Access/Virtual Private Networking" because it covers not only virtual private networking (VPN), but also the Remote Access Service (RAS) built in to Windows® 2000 Server, and other areas beyond VPN.

The new protocols that are available in the Microsoft® Windows 2000 Server operating system will be discussed, as well as how you can configure outbound and inbound connections. The discussion of remote access policies will explain how you get a lot more control over who can get in, when they can get in, and where they can go. Also covered are the evaluation and creation of remote access policies.

These are all the new protocols for network access in Windows 2000 Server. You may already be familiar with many of them, especially RADIUS, which is a way to do security separately in the access business.

The Extensible Authentication Protocol is the source of Windows 2000's support for token cards and biometrics. EAP is an open standard that allows additional authentication methods to be written for token cards, biometrics, or whatever the next new instrument will be.

For example, if a company develops a retinal scan system, it can use EAP as a method of providing RAS authentication that can be stored in the Active Directory™ service and that works with Windows 2000.

RADIUS, which stands for Remote Authentication Dial-in User Service, is essentially a way to break access out from the "triple-A" functions of authentication, accounting, and audit.

In the Windows NT® 4.0 stand-alone server model, the server authenticates users and does any necessary logging for the users' connections. It also provides access, the actual connection.

With RADIUS, those pieces are separated out, so an IAS (Internet Authentication Server) server provides the authentication. The IAS server also handles the audit—which is a log of unauthorized attempts, authorized attempts, and that kind of thing—as well as the accounting of the call statistics.

Because the network access server only provides access, it doesn't know whether a user is allowed on or not; it's relying on RADIUS in the form of the IAS server.

RADIUS can be used in different scenarios. In one scenario, Internet service provider users are authenticated using their company authentication credentials:

1. The ISP hosts a RADIUS client inside the POP.

2. The client authenticates using PAP, CHAP, or MS-CHAP.

3. The ISP's RADIUS client forwards the authentication to a subscribing company's RADIUS server. The company's RADIUS server authenticates the request and stores accounting information.

This approach lets companies easily add and delete users and grant and deny access to the ISP without the ISP having to manage the administration. It also lets companies centrally track ISP expenses. Users benefit by getting an easier logon experience because they need to remember only their company logon credentials.

Also, Windows 2000 now supports IPSec.

In its simplest form, IPSec, or Internet Protocol Security, allows the encryption of IP packets to protect the data in those packets. IPSec has two modes of operation:

• Host mode, in which two hosts communicate with each other directly.

  For example, Microsoft ran a pilot of IPSec. At the server on which the Human Resources department keeps all the data it wants to keep secure, the pilot-test group set a policy on that server that said "only speak IPSec." Then, for efficiency's sake, the group set a policy on all the Human Resources workstations and users that said, "request IPSec first." This wasn't necessary because the workstations would have requested IPSec anyway, but this policy enabled quicker connections. When all the workstations talk to that one server, they all speak IPSec. And Kerberos is used for their encryption material because they're all members of the same domain. Because the connection is encrypted, the security of the server is well protected.

• Tunnel mode allows IP packets to be placed inside of an encrypted IPSec packet to carry a private, addressed packet over a public network to another private network. Anytime you're going host to gateway, or gateway to gateway, if you want to go to a private network behind a gateway, you've got to tunnel because those addresses are not out there on the public network.

  An example of tunnel mode IPSec is a Lucent hardware product called Xedia. A VPN using pure IPSec, Xedia uses either certificates or shared secrets (shared passwords) to set up those tunnels.

  The other special case for tunnel mode is when IPSec is used as the encryption method for the Layer 2 Tunneling Protocol (L2TP).

If you want to set up a secure tunnel over the Internet in a remote access mode, you can't use IPSec directly unless your client has an IP address. Because you've got to get an IP address as part of the transaction, you need some kind of Layer 2 protocol. And Microsoft's attempt at this was Point-to-Point Tunneling Protocol (PPTP), which was essentially Microsoft's proprietary solution to tunneling over the Internet, á la L2TP. PPTP combined the encryption and the tunneling together. Because the protocol defines all of that as one, you have to use Microsoft's point-to-point encryption.

What happened in the interim is the IUTF defined a standard for L2TP, which is just the tunneling protocol—you can use any kind of encryption you want. Of course, the encryption everyone is going to use is IPSec because that's also an open standard and it's available.

You'll be seeing a lot more products that support L2TP, but there hasn't been a lot of testing yet. Therefore, you'll be on the bleeding edge if you try to get L2TP devices to interoperate at this point. They will get there, but they're not there yet.

Today there are three important VPN solutions to choose from: PPTP, L2TP, and IPSec Tunnel Mode by itself.

• Because PPTP does not require Public Key Infrastructure (PKI), it is simpler to deploy and costs less to manage, compared to L2TP with IPSec encryption and IPSec Tunnel Mode.

• Because of IPSec packet authenticity, L2TP/IPSec and IPSec Tunnel Mode cannot pass through a NAT (network address translation) without doing multiple, nested tunnels. If you are using a NAT between your POP entry point and the Internet, this could be problematic. Because PPTP is an encrypted IP packet placed inside of a non-encrypted IP packet, it can pass through a NAT.

• IPSec Tunnel Mode does not define how non-IP traffic is carried. It supports IP-only and Unicast-only traffic. L2TP and PPTP both define how non-IP and Multicast traffic can pass through the tunnel in a multivendor, interoperable way.

• PPTP and L2TP can work with legacy, password-based user authentication systems, and they can support advanced user authentication with smart cards, token cards, biometrics, and similar devices. This is done by negotiating authentication through the PPP layer with PAP, CHAP, or MS-CHAP (password authentication), or through Extensible Authentication Protocol (EAP) for card-based and biometric authentication systems. IPSec Tunnel Mode has no IETF specification for user authentication, so there is no interoperable way to do user authentication for remote access VPN.

As a result:

• PPTP is best for when customers want a secure solution without the cost and complexity of IPSec. It is also useful when traffic must pass through a NAT. Customers that want additional security and a NAT can configure Windows 2000 IPSec policies so that the PPTP packet is carrying IPSec-encrypted traffic. This can provide extremely powerful security while passing through a NAT.

• L2TP is best where security is important and customers are committed to PKI deployment. If a NAT is required in the VPN path, this solution may not work.

• IPSec Tunnel Mode is useful only for site-to-site links where IP-only and Unicast-only traffic is involved. Generally, routers do not do user-level authentication, so they do not have the same deployment issues. In addition, routers can more easily be configured for static IP addresses to overcome the lack of address assignment in IPSec Tunnel Mode.

  While IPSec Tunnel Mode remote access solutions are available today, these are proprietary implementations that do not interoperate. Vendors were forced to implement noninteroperable user authentication and address assignment to use IPSec by itself. Many vendors have plans to adopt L2TP/IPSec for remote access. It is better to push these vendors to move faster than to deploy a solution that will need to be replaced in the not-too-distant future—especially because this solution would also require the installation of a nonstandard client on all systems.

Essentially, the Bandwidth and Allocation Protocol (BAP) is relevant to the old ISDN model. In that model, you would just bring up an extra B-channel as they were needed, and let them go down when they weren't needed, so that you didn't have to pay for bandwidth you weren't using.

With DSL becoming common, BAP is probably not going to be as widely implemented as expected. But it's still useful in situations in which your only means of access involves a long-distance toll charge, for example, because BAP allows you to get additional bandwidth on demand.

This graphic illustrates the wizard used to create a dial-up connection.

Note: This graphic was created using Windows 2000 Server Beta 3. The actual wizard in the final product may vary from how it is pictured here.

In Microsoft's remote access model, users gain access in three ways.

Windows NT 4.0

In the old model, the user would dial in on a phone line to a Windows NT 4.0–based server that has a digiboard with modems, or some other kind of remote access hardware. The server would go to its domain controller with an NTLM protocol request to authorize the user. The domain controller would reply yes, and then the Windows NT–based server would let the user in.

This model doesn't separate the triple-A functionality from the access; it's all happening in one box. And it's not happening in a particularly efficient manner.

Windows 2000

The new model uses three servers running Windows 2000. When the user dials in and provides her credentials, the Windows 2000–based server is pointed to an Internet Authentication Server using RADIUS. Through the IAS server, the Windows 2000–based server asks RADIUS whether that user can get in.

The IAS server then queries the domain controller for the user's credentials, and it applies any policies that the RADIUS server has been configured to verify. The IAS checks the credentials and policies, then passes a response back to the Windows 2000–based server. And Windows 2000 goes ahead and provides or denies access based on this reply.

This method enables centralized logging. Even if you have several remote access servers, you still only have to go to one RADIUS server to get the logs.

Windows 2000 with Third-Party Tunneling

The final model uses third-party tunneling—that is, providing access through the Internet. To illustrate, imagine that a Microsoft employee is dialing in from Columbus, Ohio. Microsoft doesn't have a POP there, but one of its carriers does.

The user dials into a network access provider (NAP) in Columbus. That carrier knows that requests from users logging on with a microsoft.com identifier need to go to Microsoft's RADIUS server. The RADIUS server again checks with the domain controller, applies its policy, and responds back to this third-party NAP, indicating whether access is permitted.

Now the dial-in user has an IP connection to the Internet, but he needs a PPTP connection. So he goes to the PPTP server (which could be an L2TP server in the future). The PPTP server gets the user's credentials, goes to the RADIUS server, checks again to verify the ability to establish a PPTP connection, which again the RADIUS server will verify by checking the domain controller against Active Directory. Then the PPTP provides the tunnel and the access through the gateway.

This diagram shows Microsoft's extranet, used to serve business associates who need access to certain business information.

And it's classic VPN, in that a VPN router is on the client side. There may or may not be a screening router on the client side, so the Microsoft side has a screening router that accepts connections only from the right IP addresses. And then the client can speak to the VPN router.

The next step is to configure your server to accept in-bound VPN sessions. You can do this using Routing and Remote Access Service, a component built into Windows 2000 Server and accessed through Control Panel.

Your remote access policy should meet each of these criteria:

• Responsibility for granting remote access should be shared between IAS and the Windows 2000 Routing and Remote Access Service.

• Because remote access policies are not stored in Active Directory, they're not replicated out. Therefore, if you want to maintain a consistent policy set throughout all your RADIUS servers, every RADIUS server will need some kind of mechanism for distributing policies.

• The remote access policy you choose should include conditions, permissions, and user profiles.

This diagram illustrates the process of determining whether a user is authorized to get access and then what network resources the user is authorized to access.

To create a remote access policy, you:

1. Configure the user dial-in settings.

2. Configure the remote access policy conditions.

3. Configure the remote access profile settings, which are the policies that apply to the kinds of remote access you have.

This is an example of a remote access policy condition. In this example, any user in the Sales group who tries to connect between 8:00 A.M. and 5:00 P.M., Monday through Friday, and who has a specified IP address …

… will be allowed 90 minutes of connect time and four multilink lines, but IPSec encryption is required.