VPN can be used with Windows 2000 between end points, such as server to server or client to server, or via DUN (Dial-Up Networking). DUN lets you create a remote-access connection, assign addresses dynamically on the IPsec gateway's network and, with the addition of L2TP, carry non-IP protocols. Otherwise, you will need routable addresses between end points.

Building the VPN

Windows 2000 offers robust tools for building VPNs. Fortunately, the same Microsoft Management Console (MMC) is used on Windows 2000 Professional and all versions of Windows 2000 Server. The heart of the configuration lies in the IPsec policies on the local machine. Several predefined security policies are available when Windows 2000 is installed, but none are activated. Security policies can be applied to all IP traffic or limited by a number of options. For example, you can have all traffic between the desktop and a specific Web server encrypted, while all other traffic passes in the clear. Likewise, you can have traffic encrypted at the peer's request. Although you can have multiple security policies defined, only one security policy can be active at any given time.

Configuring IPsec for each end point can be complex if you don't have a plan or much experience with VPN. As shown in "Flexible IPsec" (below), I configured policies on the end-user computer and the two servers. Obviously, you can't configure or dictate security on public Web servers. A simpler method is to configure the end-user computer to respond to IPsec if requested by the other end. When the end-user computer initiates a connection, the server requiring security responds with a security-negotiation request. If the negotiation is successful, the connections will complete successfully.

Although VPN policies can be configured on each machine, such policies don't scale well and require end users to make changes to the system manually; thus, doing so is often more trouble that it's worth. However, a security policy--including IPsec configuration--can be established within Active Directory (AD). AD policy configuration overwrites the local security policy.

IPsec was designed to be robust, which is evidenced by the ability of peers to send multiple IPsec proposals when negotiating the VPN. For example, if my policy says to attempt the strongest security possible and then step back if that fails, I would configure my IPsec peer to offer 3DES encryption and HMAC-SHA-1 for authentication first and then offer DES and HMAC-SHA-1 authentication. When the IPsec negotiation proceeds, 3DES should be chosen if the peer supports it. In Windows 2000, multiple proposals are supported and can be configured as the default or on a VPN basis.

One caveat: Because of a design decision by Microsoft, there's one instance in which your expected security policy won't be enforced. If 3DES is chosen as the encrypting algorithm, DES might be used instead. This occurs when two computers do not have the High Encryption Pack installed, but their IPsec policy specifies only 3DES. The Windows 2000 computers will negotiate down to DES. This event is entered into the application event log. If one of the computers has the High Encryption Pack and the other doesn't and 3DES is required, the negotiation will fail and the event will be logged.

The reason the computers will negotiate down to DES, representatives from Microsoft say, is to maintain communications with the remote machine. Computers configured with the High Encryption Pack will fail in their negotiation attempts and cause alerts in the application event log, notifying administrators. In our opinion, if it is not available, 3DES should not be selectable.

Authenticating End Points

Security is greatly enhanced when applied to individual desktops. Insiders have a greater opportunity to employ passive means to gather information off the wire using analyzers. Encryption obviously limits what can be gathered. If you run an all-Windows 2000 shop or are migrating to one, VPN is a no-brainer because VPNs can be created between Windows 2000 Pro workstations as well as between Pro and Server and Server to Server.

Three authentication methods are available when forming a VPN: Kerberos 5, certificates and preshared secrets. The two most scalable methods, Kerberos and certificates, require Active Directory. Certificate authentication also requires access to a CA (certificate authority). If the two computers are in the same domain or in a trusted domain, you can use Kerberos authentication. This is perhaps the easiest to implement and requires no management overhead, because authentication is based on existing user credentials.

Understanding how certificates are used with IPsec VPN is important. Traditionally, certificates have been associated with end users. For example, if you wanted to use S/MIME (Secure MIME), you could get from VeriSign a certificate that identifies you. Typically, certificates are issued to users and stored locally, but that means users can access their certificates only from one workstation--unless their certificates are stored on smart cards. In Windows 2000, certificates in IPsec VPN are issued to computers and are used to authenticate the computer and establish the VPN to the Domain independently of the end user.

If you are running your own self-signed CA (one not part of a larger hierarchy) and want to form a VPN with a computer outside your domain, when you build the policy, you have to select the CA that will be signing the peer certificate.

If you don't have Active Directory running, or you want to make VPN connections between third-party VPN devices, you may have to use a preshared secret. A preshared secret uses a string of characters for authentication. All the computers you wish to connect must have the same preshared secret to communicate. This method doesn't scale well, because the keys have to be securely distributed and managed. For basic IPsec, however, a preshared secret is the most common denominator. It may also be the only choice when forming IPsec VPNs between computers that don't share a common trusted domain or CA.