Pre-shared Key Authentication for L2TP over IPSec Router-to-Router VPN Connections

By default, both the L2TP client and L2TP server for Windows 2000 are pre-configured for certificate-based IPSec authentication. When you make an L2TP over IPSec connection, an IPSec policy is automatically created to specify that the Internet Key Exchange (IKE) will use certificate-based authentication during the negotiation of security settings for L2TP. This means that both the L2TP client and L2TP server must have a computer certificate (also known as a machine certificate) installed before a successful L2TP over IPSec connection can be established. Both computer certificates must either be from the same certificate authority (CA), or the root certificate of each computer's CA must be installed as a trusted root certificate authority in each other's trusted root certificate store. For more information about IPSec, see "Internet Protocol Security" in the TCP/IP Core Networking Guide.

In some cases, a certificate-based IPSec authentication method is not desired for L2TP-based router-to-router VPN connections. For example, if you have a small organization and do not want to deploy a certificate infrastructure, or you are connecting to routers that do not support certificate-based IPSec authentication. In these cases, you can manually configure IPSec policy to use pre-shared keys when creating router-to-router VPN connections. This pre-shared authentication key acts like a simple password in the IKE negotiation, if both sides can prove they know the same password, then they trust each other and will continue to negotiate private, symmetric encryption keys, and specific security settings for L2TP traffic.

Using an IKE pre-shared key is generally considered not as secure as using certificates because the IKE authentication (and implicit trust) is dependent on the key value only, which is stored in plain text format in the IPSec policy. Anyone who views the policy can see the pre-shared key value. If a malicious user views the pre-shared key, then they could configure their system to successfully establish IPSec security with your system. However, the L2TP connection requires user level authentication using a PPP authentication protocol. Therefore, a malicious user would have to know both the pre-shared key and the proper user credentials to successfully establish the L2TP over IPSec connection.

To perform pre-shared key authentication for L2TP over IPSec router-to-router VPN connections, you must change a registry setting and then configure IPSec policy settings.

To prevent the Routing and Remote Access service from automatically creating an IPSec policy for L2TP traffic, set the value of ProhibitIpSec to 1 (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan \Parameters). By default, ProhibitIpSec is set to 0. When ProhibitIpSec is set to 1, the encryption settings on the demand-dial interface configured on the calling router are ignored in favor of the encryption settings of the manually configured IPSec policy. The computer must be restarted for the changes to this registry setting to take effect.

Where you configure the IPSec settings depends on the following:

• If the VPN server is a stand-alone server or a member of a Windows NT 4.0 domain, then you must configure local machine IPSec policy.
• If the VPN server is a member of Windows 2000 domain, local IPSec policies are overwritten by assigned domain IPSec policies. In order to create IPSec policy that is only applied to the VPN server, create an organizational unit (OU) in the Active Directory^™ directory service, place the VPN server computer account in the OU, and use the Group Policy to create and assign IPSec policies for the VPN server OU. The IPSec policies created for the VPN server OU will be propagated to the VPN server.

Before creating IPSec policy, you must decide whether all sites being connected will use the same pre-shared key or whether each connection will use a separate pre-shared key. This decision impacts how IPSec filter lists and policy are configured.

The same pre-shared key may be used when one administrator or company controls both L2TP tunnel endpoints.

Different pre-shared keys may be used when configuring L2TP tunnels between systems that are not under the same administrative or corporate security control. For example, one Windows 2000 VPN server may be configured to communicate to six different business partners, each of which need a different IKE pre-shared key for L2TP connections.

For example purposes, the following sections discuss the IPSec configuration required for a router that is using L2TP over IPSec pre-shared key authentication for router-to-router VPN connections between a corporate hub office in New York and two branch offices; one in Boston and one in London.

Note

If you have a Windows 2000 VPN server that is communicating to other L2TP clients or servers using the default certificate-based IPSec authentication, and you want to use IPSec pre-shared key authentication for one L2TP/IPSec tunnel, then you must include rules to use certificate authentication for those systems already using it, as well as a rule for pre-shared key authentication in the same IPSec policy.

Same Pre-shared Key for All Connections

To use the same pre-shared key for all L2TP over IPSec router-to-router VPN connections, configure the following:

1. Using the Routing and Remote Access snap-in, create the appropriate demand-dial interfaces. In our example, create a demand-dial interface for the connection to the Boston branch office and a demand-dial interface to the London branch office.
2. Using the IP Security Policies snap-in, create an IPSec filter action that does not allow unsecured L2TP communication.
3. Create one IPSec filter list that contains filters for all the L2TP over IPSec connections using the same IKE pre-shared authentication key value. Each filter within the filter list is for a specific location. Using our example, you would configure a filter list with two filters, one filter defining the L2TP traffic to the Boston router and one filter defining the L2TP traffic to the London router.
4. Create a new IPSec policy that uses a single active rule; a rule that uses the filter action that does not allow unsecured L2TP communication, the filter list for all the L2TP over IPSec connections, and a pre-shared key as the authentication method.

Creating the Filter Action

To create a filter action that does not permit unsecured L2TP communication, create a filter action with the following properties:

• On the General tab:
  • Name: Secure L2TP (example)
  • Description: Requires inbound negotiation. Discards clear text inbound. Forces negotiation outbound. (example)
• On the Security Methods tab:
  • Select Negotiate security and add at least the High type to the list. Add additional types as needed.
  • Clear the Accept unsecured communication, but always respond using IPSec and Allow unsecured with non IPSec-aware computer check boxes. Select the Session key Perfect Forward Secrecy check box if needed.

The example discussed here use the same encryption strength for all destinations. However, you may need to create filter actions specific to a destination, depending on the IPSec security capabilities of the remote system. For example, a filter action for Boston may require only 3DES encryption, whereas a filter action for London may require only DES due to cryptography export restrictions. To handle both 3DES and DES in the same filter action, include them both in the filter action security method list, putting 3DES first to make sure it is selected first when possible.

Creating the Filter List for the Same Pre-shared Key for all Connections

To configure a filter list that contains all L2TP-based router-to-router VPN connections, create a filter list with the following properties:

• Name: L2TP connections (example)
• Description: Destinations for L2TP pre-shared key connections. (example)

Then, for each destination, create a filter within the filter list with the following configuration:

• On the Addressing tab:
  • Under Source Address, select A specific IP Address and type the IP address of an Internet interface of the local router. In our example, type the IP address of the New York router's Internet interface.
  • Under Destination Address, select A specific IP Address and type the IP address of an Internet interface of the router on the other end of this router-to-router VPN connection. In our example, for the Boston connection, type the IP address of the Boston router's Internet interface.
  • Select Mirrored.
• On the Protocol tab:
  • Under Select a protocol type, select UDP.
  • Under Set the IP protocol port, select From this port and type 1701, and then select To this port.
• On the Description tab:
  • Under Description, type a description of this filter that describes its connection endpoint. For example, for the demand-dial connection to Boston, type the description: L2TP to Boston. This description appears in the IPSec monitor utility.

Configuring an IPSec Policy for the Same Pre-shared Key

To configure an IPSec policy that uses the same pre-shared key for all L2TP-based router-to-router VPN connections, create an IPSec policy with the following properties:

• On the General tab:
  • Name: Pre-shared key L2TP Connections (example)
  • Description: IPSec pre-shared key authentication for L2TP over IPSec router-to-router VPN connections. (example)
  • Change Check for policy changes every and Advanced settings as needed.
• On the Rules tab:
  • Clear the Default Response rule.

Add a rule with the following properties:

• On the IP Filter List tab:
  • Select the IP filter list that corresponds to all L2TP connections to all branch offices. Using our example, select the IP filter list called L2TP connections.
• On the Filter Action tab:
  • Select the filter action that does not allow unsecured L2TP communication. Using our example, select the filter action called Secure L2TP.
• On the Authentication Methods tab:
  • Under Authentication Method preference order, configure a single method that uses the pre-shared key. Type the pre-shared key that is common between all routers to which this router is making a pre-shared key L2TP over IPSec connection. When configuring a pre-shared key, choose a key that is at least 20 characters long and is a random mixture of upper and lower case letters, numbers and punctuation characters.
• On the Tunnel Setting tab:
  • Select This rule does not specify an IPSec tunnel.
• On the Connection Type tab:
  • Select All network connections.

Because the filter list contains all of the destinations for L2TP-based router-to-router VPN connections, only a single rule within the IPSec policy is required.

Different Pre-shared Keys for Different Connections

To use different pre-shared keys for all L2TP over IPSec router-to-router VPN connections, configure the following:

1. Create the appropriate demand-dial interfaces. In our example, create a demand-dial interface for the connection to the Boston branch office and a demand-dial interface to the London branch office.
2. Create a filter action that does not allow unsecured L2TP communication.
3. Create an IPSec filter list that contains a single filter for the L2TP over IPSec connection to a specific location. Using our example, configure a filter list with one filter defining the L2TP traffic to the Boston router. Then, configure another filter list with one filter defining the L2TP traffic to the London router.
4. Create a new IPSec policy that uses a series of rules; each rule uses the filter action that does not allow unsecured L2TP communication, the filter list for a specific L2TP over IPSec connection, and the pre-shared key for the specific connection as the authentication method.

Creating the Filter Action

The configuration of the filter action for the different pre-shared key for different connections is the same as the filter action for the same pre-shared key for all connections.

Creating the Filter List for a Different Pre-shared Key for all Connections

To configure a filter list for a specific router-to-router VPN connection, create a filter list with the following properties (using the connection to Boston as an example):

• Name: L2TP pre-shared key connection to Boston (example)
• Description: Boston destination for L2TP pre-shared key connection. (example)

Then, create a single filter with the following configuration:

• On the Addressing tab:
  • Under Source Address, select A specific IP Address and type the IP address of an Internet interface of the router. In our example, type the IP address of the New York router's Internet interface.
  • Under Destination Address, select A specific IP Address and type the IP address of an Internet interface of the router on the other end of this router-to-router VPN connection. For example, type the IP address of the Boston router's Internet interface.
  • Select Mirrored.
• On the Protocol tab:
  • Select a protocol type: Select UDP.
  • Set the IP protocol port: Select From this port and type 1701, and then select To this port.
• On the Description tab:
  • Under Description, type a description of this filter that describes the connection endpoint. For example, for the demand-dial connection to Boston, type the description: L2TP to Boston. This description appears in the IPSec monitor utility.

Repeat this procedure for each L2TP over IPSec router-to-router VPN connection. Using our example, configure another IPSec filter list for the connection to the London router.

Configuring an IPSec Policy for a Different Pre-shared Key for Each Connection

To configure an IPSec policy that uses a different pre-shared key for each L2TP router-to-router VPN connection, create an IPSec policy with the following properties:

• On the General tab:
  • Name: Pre-shared key L2TP Connections (example)
  • Description: IPSec pre-shared key authentication for L2TP over IPSec router-to-router VPN connections. (example)
  • Change Check for policy changes every and Advanced settings as needed.
• On the Rules tab:
  • Clear the Default Response rule.

For each L2TP router-to-router VPN connection, add a rule with the following properties (using the connection to Boston as an example):

• On the IP Filter List tab:
  • Select the IP filter list that corresponds to an L2TP over IPSec connection. In our example, you would select the IP filter list called L2TP pre-shared key connection to Boston.
• On the Filter Action tab:
  • Select the filter action that does not allow unsecured L2TP communication. In our example, you would select the filter action called Secure L2TP.
• On the Authentication Methods tab:
  • Under Authentication Method preference order, configure a single method that uses pre-shared key. Type the pre-shared key that is common between the two routers on this router-to-router VPN connection. Using our example, type the pre-shared key used by the New York and Boston routers for the New York to Boston VPN connection. When configuring a pre-shared key, choose a key that is at least 20 characters long and is a random mixture of upper and lower case letters, numbers and punctuation characters.
• On the Tunnel Setting tab:
  • Select This rule does not specify an IPSec tunnel.
• On the Connection Type tab:
  • Select All network connections.

Add a separate rule for each L2TP over IPSec router-to-router VPN connection. Using our example, add another rule for the connection to the London router.

Note

For an incoming L2TP over IPSec connection, the Routing and Remote Access service queries IPSec to discover the type of encryption that was negotiated. The query is for the encryption used for an IPSec security association (SA) for IP traffic to UDP port 1701. If an IPSec SA exists for IP traffic to UDP port 1701, the type of encryption used for the IPSec SA is returned. When ProhibitIpSec is set to 0, an IPSec SA is always found for this type of traffic because L2TP traffic filters are automatically created by the Routing and Remote Access service. The encryption type is then compared to the types of encryption allowed by the profile settings of the matching remote access policy for the L2TP connection. If the encryption type returned from the IPSec query does not match the allowed encryption strengths in the remote access policy profile, the connection attempt is rejected. If ProhibitIpSec is set to 1 and a specific filter for UDP port 1701 is not configured, the query fails to find an SA for IP traffic to UDP port 1701 and no encryption is assumed. This can cause the connection attempt to be rejected if the encryption setting on the matching remote access policy profile has the No encryption setting disabled. Therefore, the disconnection of encrypted L2TP over IPSec connections can occur when an IPSec filter exists that uses pre-shared key for all IP traffic and a specific filter for UDP port 1701 is not configured.

Using IPSecPol to Create the IPSec Policy

IPSec policy for pre-shared key L2TP over IPSec connections can also be configured using the IPSecPol Resource Kit tool. For more information, see the Windows 2000 Resource Kit Tools Help.

© 1985-2000 Microsoft Corporation. All rights reserved.