Skip to main content

Virtual Private Networking: Frequently Asked Questions

This FAQ answers commonly asked questions about virtual private networking (VPN) in the Microsoft Windows family of operating systems. Click a question to view its answer. To view all the answers at one time, select the View all answerscheck box.

On This Page
 VPNs Defined
 Microsoft Support for VPNs
 VPN Standards and Interoperability
 VPN Deployment

VPNs Defined

A. Microsoft defines a virtual private network as the extension of a private network that encompasses links across shared or public networks like the Internet. With a VPN, you can send data between two computers across a shared or public network in a manner that emulates a point-to-point private link (such as a dial-up or long haul T-Carrier-based WAN link). Virtual private networking is the act of creating and configuring a virtual private network.

To emulate a point-to-point link, data is encapsulated, or wrapped, with a header that provides routing information, which allows the data to traverse the shared or public network to reach its endpoint. To emulate a private link, the data is encrypted for confidentiality. Packets that are intercepted on the shared or public network are indecipherable without the encryption keys. The link in which the private data is encapsulated and encrypted is a VPN connection.

There are two key VPN scenarios—remote access and site-to-site. In remote access, the communications are encrypted between a remote computer (the VPN client) and the remote access VPN gateway (the VPN server) to which it connects. In site-to-site (also known as router-to-router), the communications are encrypted between two routers (VPN gateways) that link two sites.

A. For remote access connections, an organization can use VPN connections to leverage the worldwide connectivity of the Internet and trade their direct-dial remote access solutions (and their corresponding equipment and maintenance costs) for a single connection to an Internet service provider (ISP) without sacrificing the privacy of a dedicated dial-up connection.

For routed connections, an organization can use VPN connections to leverage the worldwide connectivity of the Internet and trade long-distance dial-up or leased lines for simple connections to an Internet service provider (ISP) without sacrificing the privacy of a dial-up or dedicated site-to-site link.

Microsoft Support for VPNs

A. Microsoft provides Point-to-Point Tunneling Protocol (PPTP)-based remote access clients with Windows 2000, Windows XP (both Windows XP Home Edition and Windows XP Professional), Windows Server 2003, Windows Vista, and Windows Server 2008. Microsoft provides Layer Two Tunneling Protocol with Internet Protocol security (L2TP/IPSec)-based remote access clients with Windows 2000, Windows XP (both Windows XP Home Edition and Windows XP Professional), Windows Server 2003, Windows Vista, and Windows Server 2008.

Microsoft provides a Secure Socket Tunneling Protocol (SSTP)-based remote access client in Windows Server 2008 and Windows Vista Service Pack 1. For more information about SSTP, see The Secure Socket Tunneling Protocol and the Routing and Remote Access Blog.

A. Microsoft supports a fully-featured PPTP-based remote access server in Windows NT Server 4.0, Windows 2000 Server, and Windows Server 2003. Microsoft supports a fully-featured L2TP/IPSec-based remote access server in Windows 2000 Server and Windows Server 2003.

Microsoft also supports a single-connection PPTP and L2TP/IPsec-based remote access server in Windows 2000 Professional, Windows 2000 Server (standalone), Windows XP Professional, and Windows Vista (all versions) through the Incoming Connections feature of the Network Connections folder. For information about Incoming Connections for Windows XP, see Incoming connections. For information about Incoming Connections for Windows Vista, see Set up an incoming VPN or dial-up connection.

Microsoft supports a Secure Socket Tunneling Protocol (SSTP) remote access server in Windows Server 2008. For more information about SSTP, see The Secure Socket Tunneling Protocol and the Routing and Remote Access Blog.

A. Microsoft supports PPTP-based site-to-site VPN connections in Windows Server 2003 and Windows Server 2008. Microsoft supports L2TP/IPSec-based and IPSec tunnel mode site-to-site VPN connections in Windows 2000 Server and Windows Server 2003.

The Secure Socket Tunneling Protocol (SSTP) for Windows Server 2008 does not support site-to-site VPN connections. For more information about SSTP, see The Secure Socket Tunneling Protocol and the Routing and Remote Access Blog.

A. Windows CE 3.0 includes PPTP support, including MS-CHAP v2 for authentication. Pocket PC 2002 is based upon Windows CE 3.0 and also includes PPTP support. In a future release of Windows CE, VPN support will expand to include use of Extensible Authentication Protocol (EAP) for authentication with PPTP and L2TP/IPSec support to follow. In the near term, Microsoft recommends that customers look to third-party VPN clients to support L2TP/IPSec and EAP if strong authentication is needed.

A. For detailed information, see the “Remote access and VPN connection enhancements” section of New Networking Features in Windows Server 2008 and Windows Vista.

A. Secure Socket Tunneling Protocol (SSTP) is a new tunneling protocol that uses HyperText Transfer Protocol (HTTP) encapsulation over a Secure Sockets Layer (SSL) channel. Because SSTP uses SSL traffic (TCP port 443), SSTP can be used in many different network configurations, for example, when VPN clients or servers are behind network address translators (NATs), firewalls, or proxy servers. SSTP is only supported by Windows Server 2008 and Windows Vista Service Pack 1. For additional information, see The Secure Socket Tunneling Protocol and the Routing and Remote Access Blog.

A. PPTP provides a good level of security that is suitable for most companies, and it has benefits compared to L2TP/IPSec and other IPSec-based VPN solutions because of the security model it uses. While IPSec has powerful security, the deployments are usually more costly and have limitations.

One of the benefits of PPTP is that it does not require a certificate infrastructure, which many organizations are not yet ready to deploy. Rather, it relies on a user's logon credentials to establish trust to connect the tunnel and to create the encryption keys for the session. Additionally, the management of user names and passwords is well known.

For customers who want stronger security than user passwords, PPTP can be used with EAP so that smart cards or token cards can be used for authentication. This increases the strength of the encryption key generation and reduces the risk of dictionary attacks. In addition, PPTP can be used through most Network Address Translators (NATs) today with no modifications required for either the client or server. IPSec traffic, on the other hand, cannot traverse a NAT unless both the client and server support IPSec NAT traversal (IPSec NAT-T).

Until certificate infrastructure becomes ubiquitous, PPTP will remain an important protocol choice for many customers.

A. In order for a NAT to function, it must translate either IP addresses or port numbers in the packets that it is forwarding. If a NAT translates IP addresses or port numbers for either Internet Key Exchange (IKE) traffic (which is used to negotiate IPSec security associations) or IPSec-protected traffic, the integrity of the packet is invalidated.

To prevent a NAT from translating IPSec traffic, some NATs support IPSec traffic for a single connection through the NAT. Another solution is IPSec NAT traversal (NAT-T), a new standard for allowing Encapsulating Security Payload (ESP)-encapsulated traffic across one or more NATs. IPSec NAT-T is described in the Internet drafts titled UDP Encapsulation of IPSec Packets (draft-ietf-ipsec-udp-encaps-02.txt) and Negotiation of NAT-Traversal in the IKE (draft-ietf-ipsec-nat-t-ike-02.txt). IPSec NAT-T defines changes to IPSec protocols and new Internet Key Exchange messages and payloads that are exchanged between two IPSec NAT-T-capable peers. IPSec NAT-T must be supported by both the client and server.

Windows Vista, Windows Server 2008, Windows Server 2003, Windows XP with Service Pack 2, and Microsoft L2TP/IPSec VPN Client support IPSec NAT-T. The L2TP/IPSec NAT-T Update for Windows XP with Service Pack 1 and Windows 2000 provides VPN client IPSec NAT-T support for Windows 2000 and Windows XP. For details about this update, see the Knowledge Base article "L2TP/IPSec NAT-T Update for Windows XP and Windows 2000".

A. Negative analyses of PPTP were published over three years ago. Security analysts identified three problems that were immediately corrected. Since then, there have been no new issues cited. Their most serious complaint was not concerning the implementation but rather that the use of a user name and password for VPN connections is not as secure as certificate-based authentication. Microsoft agrees with this conclusion which is one of the reasons why Windows Server 2008 and Windows Server 2003 support public key infrastructure (PKI) and include a certification authority service. If you must use user names and passwords, enforce the use of strong passwords. Strong passwords are long (more than eight characters) and contain a random mixture of upper and lower case letters, numbers, and punctuation. An example of a strong password is f*3L~qO2>xR3w#4o.

VPN Standards and Interoperability

A. Microsoft supports only standard protocols that have been proven to interoperate. Windows Vista, Windows XP (both Windows XP Home Edition and Windows XP Professional), and Windows 2000 Professional include an integrated VPN client. Windows Server 2003 and Windows Server 2008 include an integrated VPN server (also known as a VPN gateway).

For remote access VPNs, Windows includes support for the Point-to-Point Tunneling Protocol (PPTP) (RFC 2637) and the Layer Two Tunneling Protocol (L2TP) (RFC 2661, a Proposed Standard) that are secured using Internet Protocol Security (IPSec) (RFCs 4301-4303, Proposed Standards) using IPSec Encapsulating Security Payload (ESP) in transport mode. The integration between L2TP and IPSec is described in RFC 3193 (Proposed Standard). Both the client and server implementations use industry standard methods for IPSec trust (X.509 certificates) and industry standard user authentication including the Challenge-Handshake Authentication Protocol (CHAP) (RFC 1994, Proposed Standard), the Microsoft Challenge-Handshake Authentication Protocol version 2 (MS-CHAP v2) (RFC 2759), and the Extensible Authentication Protocol (EAP) (RFC 2284).

For site-to-site VPN connections, Windows Server 2003 and Windows Server 2008 support PPTP, L2TP/IPSec, and IPSec tunnel mode.

All of the protocols supported have been demonstrated to provide good multi-vendor interoperability.

A. Most vendors making this claim are using IPSec tunnel mode for remote access. Unfortunately, the IPSec RFCs do not describe the use of IPSec tunnel mode for remote client access. In particular, the RFCs provide no mechanisms for user authentication, IP address assignment, and name server address assignment.

As a result, vendors implementing a remote access solution based on IPSec tunnel mode have been forced to extend the protocol. These extensions are not standard, and drafts that were introduced to the IETF to define a standard have been withdrawn. As a result, there is no standard for remote client access using IPSec tunnel mode. Consequently, many vendor implementations are not interoperable.

In contrast, Microsoft has followed several standards precisely using L2TP (RFC 2662, a Proposed Standard) as the remote access protocol and IPSec (RFCs 4301-4303, Proposed Standards) as the encryption protocol, combined in a manner described in the L2TP/IPSec RFC 3193.

A. The following VPN protocols are IETF standards:

  • L2TP over IPSec using ESP transport mode (L2TP/IPSec). L2TP, defined in RFC 2661, is an IETF Proposed Standard, and the integration of L2TP with IPSec is defined in RFC 3193. There are implementations from Microsoft, Cisco, and Nortel Networks that have been demonstrated to interoperate. L2TP/IPsec tunnels traffic, preserving the full end-to-end semantics of communications conducted inside the tunnel. It fully supports legacy address and host configuration technologies (IPCP). It is commonly used by customers in multi-vendor environments. It supports password authentication using PAP, CHAP, MS-CHAP, and MS-CHAP v2, and it supports strong authentication using EAP.

  • IPSec Tunnel Mode. The use of IPSec tunnel mode for VPNs, described in the Internet draft draft-ietf-ipsec-dhcp-13.txt, has been approved as an IETF Proposed Standard. It tunnels traffic, preserving the end-to-end semantics of the communications it is carrying. The trust model is defined as part of the IETF standard using either standard X.509 certificates or pre-shared keys. The standard supports both dynamic and static addressing. IPSec tunnel mode is appropriate for site-to-site VPN connections and has been demonstrated to be interoperable by Microsoft, Cisco, Nortel, and others. There is no standard for legacy user authentication within IPSec tunnel mode, which makes it unsuitable for use in remote access. It is implemented by most VPN gateways. There have been many public interoperability demonstrations and customer deployments using real products.

A. The following VPN protocols are non-standard:

  • IPSec tunnel mode with XAUTH (extended authentication), mode config, hybrid-auth, or CRACK. After considering alternatives such as mode config, the IETF adopted the Internet draft draft-ietf-ipsec-dhcp-13.txt as an IETF Proposed Standard for configuration of IPSec tunnel mode. Similarly, the IETF considered, and rejected, standardization of XAUTH, Hybrid, and CRACK authentication methods. Mode config was rejected for IETF standardization because it lacks the flexibility and generality of DHCP, complicates IPSec failover scenarios, and requires modifications to IKE that are considered inadvisable. Similarly, XAUTH was rejected because it is incompatible with existing IETF authentication frameworks such as EAP, SASL, and GSS-API, requires IKE modification, and contains major security flaws. The IETF rejected standardization of Hybrid and CRACK due to concerns about increasing the complexity and security vulnerabilities with IKE. While the IPSRA WG is working on standardization of legacy authentication methods via PIC, work is not yet completed, and interoperable implementations are not available. So far, there is no IETF standard providing accurate accounting in IPSec tunnel mode. Given the current state of IPSec tunnel mode standardization for remote access, Microsoft believes that L2TP/IPsec represents more mature technology.

  • IPSec tunnel mode using IP Security Remote Access (IPSRA) definitions for remote access. The IPSRA WG has been chartered with standardizing the use of IPSec tunnel mode in remote access scenarios. So far, the group has standardized use of DHCP with IPSec tunnel mode for configuration (Internet draft draft-ietf-ipsec-dhcp-13.txt, now a Proposed Standard) and is working on legacy user authentication via PIC. Microsoft is a coauthor of the IPSRA documents and believes that they show promise. Use of DHCP for address assignment is a significant improvement compared to mode config. PIC supports the use of EAP for user authentication without modifying IKE. However, while several vendors have implemented IPSec/DHCP, there are no known PIC implementations.

A. Since the second quarter of 1999, Microsoft has been publicly demonstrating its implementations of L2TP/IPSec VPN clients and Cisco's IOS implementation for remote access. Since then, implementations have shipped on Cisco's VPN 3000, 5000, and IOS gateways; Nortel Networks Contivity gateways; and gateway products from Intel, Ericsson, Nokia, 3COM, and NetScreen (all of which work with X.509 certificates for computer trust and with password-based authentication). In addition, there have been a number of successful interoperability tests between the Windows client and other third-party VPN gateways at IPSec industry interoperability meetings known as "bakeoffs."

A. The IPSec protocol includes two modes of operation: transport mode and tunnel mode. Transport mode defines a protocol for encrypting communications between two end-systems such that no other computer or device is involved in the dialog—ensuring end-to-end privacy and integrity of the data. The IPSec standards define a second mode of operation called tunnel mode. Tunnel mode was defined to enable routed connections between two networks--encrypting the traffic on behalf of all computers on the two networks. The best way to think of this is two routers that encrypt traffic before passing it over the Internet.

Neither IPSec transport mode nor IPSec tunnel mode provides all the functionality necessary for remote access. Remote access is a hybrid model where one computer is an end-system (the client), and the second system is an intermediate system (the server). In order to use either IPSec transport mode or tunnel mode, additional protocols are required to manage the semantics of remote access. Specifically, there needs to be an interoperable protocol used for automatic address assignment; a method for accounting by tracking session state; and an interoperable mechanism for legacy user authentication

To meet these requirements using IPSec transport mode, two IETF standards are combined (L2TP and IPSec transport mode). This is the solution supported by Microsoft in Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, and with the Microsoft L2TP/IPSec VPN Client.

To meet these requirements using IPSec tunnel mode, vendors developed proprietary technologies such as mode config and XAUTH. These technologies were developed quickly and were not subjected to rigorous analysis within the IETF before deployment. Once that analysis was conducted, serious flaws were found, and the technologies were rejected for standardization. The IETF chose to advance alternative approaches to IPSec tunnel mode for remote access, such as IPSec/DHCP and PIC. Microsoft endorses the IETF's analysis and recommends that customers reject flawed proprietary extensions to IPSec, such as mode config and XAUTH.

A. Another vendor who supports IPSec tunnel mode claims they are standard because they use XAUTH and mode config. They say this addresses remote access for IPSec tunnel mode. Isn't an IPSec implementation that includes these protocols considered a standard?

XAUTH and/or mode config are not IETF standards. They have been extensively analyzed and have been rejected because of major flaws. Therefore IPSec tunnel mode implementations including these protocols cannot claim standards status and have known defects for which no fix is available.

XAUTH changes a core IPSec protocol named Internet Key Exchange (IKE). The IKE protocol is critical to IPSec as it is used to negotiate the security parameters of the IPSec security association including computer trust, encryption keys, and security methods. The IKE protocol took approximately nine years to develop within the IETF. Every proposal was carefully scrutinized for security weaknesses and was rejected if it did not meet the rigorous requirements for strong security. In contrast, XAUTH was developed in a short period of time and without the same scrutiny as IKE. XAUTH fundamentally changes the IKE protocol. The original authors of the IKE protocol reviewed XAUTH and discovered serious security issues that adversely affect the important benefits of IPSec. Under criticism from IETF members, XAUTH was removed from the IETF standards track.

In a related activity, the IETF Security Area Directors issued an e-mail on August 2, 2001, declaring a moratorium on changes to the IKE protocol. In this mail they indicated that IPSec security could be adversely affected by the complexity of IKE and that IKE changes should not be made until IKE was simplified. The mail went on to list various technologies (including XAUTH, hybrid auth, and others) as not helping to simplify IKE. As a result, L2TP/IPSec remains the only IETF standard method for remote access VPN with IPSec encryption.

A. There are several key reasons for this.

  • XAUTH contains serious security flaws for which no known fix is available and has been rejected for IETF standardization. Given this, Microsoft believes that it would be irresponsible for us to endorse this technology, especially when IETF standards-based technology is under development.

  • XAUTH is incompatible with existing IETF authentication frameworks such as EAP and GSS-API. This means that developers who want to develop authentication techniques for the Windows platform would need to develop their methods using multiple, incompatible APIs. This prevents customers from using existing authentication methods within remote access scenarios. For developers, it increases the complexity and cost of developing a new authentication method. Rather than introducing another authentication framework to the detriment of customers and developers, Microsoft endorses efforts within IETF and IEEE to extend the applicability of EAP. This allows customers and developers to leverage their efforts, developing authentication methods with universal applicability, such as in wireless scenarios (via 802.1X).
  • Because of the poor interoperability of XAUTH and mode config, Microsoft could not implement the technology and have it work with more than one vendor.
  • L2TP/IPSec is already an interoperable standard that is supported in commercial products from leading networking companies and can be implemented in models similar to XAUTH with IPSec but with much stronger security, reliable accounting, and standards-based configuration.
  • The IETF rejected XAUTH and mode config and has a more appropriate IPSec tunnel mode-based remote access solution in development through the IPSRA working group.

A. There are several reasons why interoperability is important.

  • You may need to support gateways from different vendors within your company. Maybe you have decentralized purchasing, or maybe you will be involved in a merger or acquisition with someone who chose a different vendor. By using interoperable standards, you can reduce the time it takes to integrate your business infrastructures and benefit from the business change.

  • Many companies are looking for ways to streamline supply chain management and other types of inter-business transactions. VPNs make it possible to create secured "extranet" zones where companies can do more than share web applications. By giving your business partner remote access to the extranet zone, you can support a broad range of protocols and support a much richer set of scenarios than using HTTP alone. Interoperability lets you build such an extranet without having to dictate vendors or products to your business partner; something that can create serious deployment barriers due to conflicts in hosting multiple VPN clients in end-user computers.
  • Interoperability allows customers the freedom to choose a client that is easy to use and deploy, while independently selecting a server based on its characteristics as a server. Rather than compromising on your server or client, you can choose the best server for the situation. Using interoperable standards also helps reduce deployment cost and helps avoid client deployment issues.

A.Customers have told Microsoft they prefer that Windows come with the networking technologies required to support core connectivity scenarios. The adoption of VPN for remote access is growing rapidly and is being used by most companies. For economic reasons, Microsoft sees remote access VPN replacing dial-up remote access to the company network because it allows companies to use a single Internet link to support all their remote access users, thus reducing modem pool management costs, multiple telephone line costs, etc. This trend makes VPN a core connectivity scenario.

Any type of authenticated network access (dial-up, VPN, or 802.1X) requires integration with the operating system (OS) at many levels, including several layers within the IP stack, OS credential management, and user OS login. This is necessary to make the solution easily deployable, to ensure application compatibility, to ensure clean OS upgrade capability, and to provide a single sign-on experience for network access, OS access, file sharing, printing, and other network applications.

Improper integration can compromise system security, disrupt applications, and prevent customers from carrying out even basic service pack upgrades to the operating system. It can also result in having to maintain separate logon systems for network access, applications, and the network operating system. Because of this, Microsoft considers it a responsibility to deliver well-integrated, interoperable VPN clients. The best way to achieve this is through interoperable industry standards.

VPN Deployment

A. If you are using the Windows Server 2003 or Windows Server 2008 Certificate Services, configure the Active Directory™ service system container that holds the computer account of the VPN server for automatic enrollment of computer certificates 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 auto-enrollment 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 using the Certificate Manager snap-in. For more information, see Deploying Dial-up and VPN Remote Access Servers and Windows Server 2008 Networking and Network Access Protection (NAP).

A. The Internet service provider (ISP) that you are using at the time of the connection may 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 may 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.

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 4500 to create and maintain the connection and IP protocol 50 to send data. Configure your firewall to allow these types of traffic to and from your VPN server.

A. For information on how to use RSA Security's SecurID system to authenticate Microsoft VPN connections, see the RSA Web site to obtain the latest components for your operating system.

A. In order 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 pre-shared 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).

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

When the systems start IPSec main mode negotiation using IKE, they indicate to each other that a pre-shared 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 know this 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 pre-shared key.

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

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 attack.

The only way to fix the vulnerability of a compromised pre-shared key is to configure a new pre-shared key on the server and either manually reconfigure the pre-shared key on all other systems or distribute the new pre-shared key in secret. During the key change transition time, no one will have access to the server. This 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.

A. This is accomplished 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 pre-shared key to use. This lets customers create multiple IPSec pre-shared keys, and the server can then support multiple pre-shared 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 key used by each group.

This makes the size of the group sharing a specific pre-shared key smaller, but it does not actually solve the problem of a compromised pre-shared key. It takes only one stolen pre-shared key to do a denial of service attack and all the members of the group that share that secret are affected. It is possible to take this to an extreme and give each user a unique name and pre-shared key, but on that scale, it is more secure and just as easy to use a certificate.

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, it is possible to 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 in order 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 pre-shared keys) but with the security strength of certificates, the protection of a password, and the interoperability of a PKCS distribution mechanism.

Today, many VPN gateways have the ability to support a broad range of certificate authorities as do Windows Vista, Windows Server 2003, Windows XP, and Windows Server 2008 VPN clients. Customers are better served by utilizing this method rather than using pre-shared keys.

 Top of page