VPN Deployment

Q. How do I install a computer certificate on a VPN server?

A. If you are using the Windows Server 2003 or Windows 2000 Server Certificate Services, configure the Active Directory service system container that holds the computer account of the VPN server for automatic enrollment of computer certificates by using the Group Policy Editor snap-in. A computer certificate is automatically issued to the VPN server the next time computer Group Policy is updated. If autoenrollment is not appropriate or you are using a third-party certification authority (CA), create a certificate using the CA’s administration software and export it to a certificate file. Then, import the certificate file on the VPN server into the Local Computer store of the VPN server by using the Certificate Manager snap-in. For more information, see Chapter 6, “Deploying Remote Access VPNs,” or Chapter 9, “Deploying Site-to-Site VPNs.”

Q. Why do my VPN connections work from some locations and not from others?

A. The Internet service provider (ISP) you are using at the time of the connection might be blocking specific types of TCP/IP traffic that are preventing VPN connectivity. For example, PPTP traffic uses TCP port 1723 to create the connection and IP protocol 47 to send data. L2TP/IPSec traffic uses UDP ports 500 and 4500 to create the connection and IP protocol 50 to send data.

Your VPN traffic might also be blocked by a NAT. For PPTP connections, ensure that the NAT has a PPTP editor that can properly map PPTP data traffic. For L2TP/ IPSec connections, ensure that the NAT supports a single IPSec connection or that both the VPN client and server support IPSec NAT-T.

Q. How do I configure my firewalls to allow Microsoft VPN traffic?

A. PPTP traffic uses TCP port 1723 to create and maintain the connection and IP protocol 47 to send data. L2TP/IPSec traffic uses UDP ports 500 and, if using Windows Server 2003 with NAT-T, 4500 to create and maintain the connection, and it uses IP protocol 50 to send data. Configure your firewall to allow these types of traffic to and from your VPN server.

For detailed information, see Appendix A.

Q. How do I use RSA Security’s SecurID with Microsoft VPNs?

A. For information on how to use the RSA Security SecurID system to authenticate Microsoft VPN connections, see the RSA Security Web site (http://www.rsasecurity.com/products/securid/) to obtain the latest components for your operating system.

Q. Why are preshared keys nonsecure?

A. For IPSec (tunnel mode or transport mode) to negotiate encryption, the systems must first decide they are willing to trust each other. There are two methods defined in IPSec to accomplish this. One is with X.509 certificates and the other is with preshared keys.

The most secure way to do this is with X.509 certificates. In this case, the two systems first obtain an X.509 certificate from certificate authorities so that the certificates share a common root authority. Think of it as both sides getting the certificate from someone they mutually trust. In this case, the certificate for the gateway uniquely identifies the gateway, and the certificate for the client uniquely identifies the client. Using IKE, the certificates are securely exchanged and the gateway and the client computers can authenticate each other after they generate encryption keys and begin using the IPSec main mode security association (SA).

Because certificate deployment had not yet matured, preshared keys were primarily placed into the IPSec standard for the purpose of testing basic interoperability between vendor implementations. Some people continue to use preshared keys rather than deploy much more secure X.509 certificates. For preshared keys, each operating system is configured with a shared key (similar to a password).

When the operating systems start IPSec main mode negotiation using IKE, they indicate to each other that a preshared key is used as the authentication method. However, there is no way to uniquely identify the gateway or the client in advance (particularly in remote access). You might try using the IP addresses as a hint, but in remote access, there is no way to uniquely identify the gateway or client in advance because the computer is roaming between Internet access points and often gets a different IP address at each connection. For this to work, all computers involved must be configured with the same preshared key.

For example, if you have 1,500 VPN clients and four VPN servers, all the operating systems would have to use the same preshared key. If the preshared key is ever compromised, a malicious user can use it to attempt to connect to your server. If the malicious user has the correct preshared key, the server will negotiate the main mode IPSec SA.

If user authentication is also used, the remote access connection is rejected, unless the malicious user also has knowledge of a set of valid user credentials. Even without valid user credentials, computation time on the gateway is used to derive the encryption keys and authenticate the computer attempting the IPSec SA. By performing repeated connection attempts from multiple computers, the gateway processing power can be consumed and block all other communications to the server, resulting in a denial-of-service (DoS) attack.

The only way to fix the vulnerability of a compromised preshared key is to configure a new preshared key on the server, and then either manually reconfigure the preshared key on all other systems or distribute the new preshared key in secret. During the key change transition time, no one will have access to the server. This situation is equivalent to having to change the locks on the doors of your business when 1,500 employees share the same key required for accessing the building.

The issues with preshared keys are also discussed in the article “Authentication Vulnerabilities in IKE and XAUTH with Weak Pre-Shared Secrets.”

Q. Other VPN vendors say they solve preshared key issues with their implementations. How is that done?

A. This is accomplished by using the weakest form of IPSec trust, called IKE aggressive mode. In this case, the two systems pass a plain text name to each other as a hint for which preshared key to use. This lets customers create multiple IPSec preshared keys, and the server can then support multiple preshared keys. In practice, the customer divides the users into a small set of groups. Each group is assigned a group name and a single common shared key. The server is configured with all the group names and the shared keys used by each group.

This makes the size of the group sharing a specific preshared key smaller, but it does not actually solve the problem of a compromised preshared key. (See the article, “Authentication Vulnerabilities in IKE and XAUTH with Weak Pre-Shared Secrets.”) It takes only one stolen preshared key to do a DoS attack, and all the members of the group that share that secret are affected. You can take the solution to an extreme and give each user a unique name and preshared key, but on that scale, it is more secure and just as easy to use a certificate.

Q. Are there alternatives to group preshared keys that don’t require you to create an X.509 certificate for every remote access VPN user and that don’t expose names using aggressive mode?

A. Yes. X.509 certificates include a name. X.509 certificates can also be granted to more than one system. By using these two facts, you can deploy group shared certificates while retaining the much stronger IKE main mode negotiation. In this situation, a certificate is generated and packaged in a Public Key Cryptography Standards (PKCS)-12 format. This format requires a password to unlock the certificate for use. The resulting PKCS file can be copied to and unlocked on more than one computer.

When a computer using the shared certificate connects, IKE main mode negotiates a list of possible certificate authorities that can be used. Challenges are then exchanged, and the shared certificate is used to sign the challenge and to send the public certificate contents to the other system. In the end, a few X.509 certificates can be used (similar to group preshared keys) but with the security strength of certificates, the protection of a password, and the interoperability of a PKCS distribution mechanism.