[Contents] [Prev] [Next] [Index] [Report an Error]

# L2TP/IPSec Tunnels

L2TP/IPSec remote access allows clients to connect to a corporate VPN over the public Internet with a secure connection. The L2TP tunnel runs on top of an IPSec transport mode connection. The secure tunnel runs from the client PC to the E Series router that terminates the secure tunnel. For example, using L2TP with IPSec enables B-RAS clients to securely connect to a corporate or other VPN in addition to using another unsecured connection to the Internet, depending on the client software capabilities.

On the router side of the L2TP connection, the E Series router acts as the LNS. On the PC client side of the connection, the client acts as the LAC and runs the L2TP/IPSec client software on supported platforms. (For a list of the supported platforms, see Client Software Supported.) Both sides of the connection run IPSec in transport mode with Encapsulating Security Payload (ESP) encryption and authentication.

In the model shown in Figure 22, a client PC connects to its local provider, who gives the client a public IP address. Using the public IP address, the client PC initiates an IPSec connection toward the L2TP/IPSec gateway for the private network that it wants to connect to. After establishing the IPSec connection, the client establishes an L2TP tunnel to the same L2TP/IPSec gateway, which provides the client with another IP interface to access the private network it is connecting to. The L2TP tunnel is completely protected by the IPSec connection established earlier.

Figure 22: L2TP with IPSec Application

## Setting Up the Secure L2TP Connection

Figure 23 gives an overview of the process used to set up a secure connection between the client PC and an E Series router that is acting as a VPN provider.

Figure 23: L2TP/IPSec Connection

To set up the secure connection shown in Figure 23:

1. Obtain an IP address from your ISP, using a normal B-RAS termination.
2. IKE signals a security association (SA) between the client PC and the E Series router that is acting as a VPN provider.
   - SAs are established to secure data traffic.
   - The IPSec connection secures L2TP traffic.
3. Set up an L2TP tunnel and session between the client PC (the LAC) and the E Series router (the LNS).

   The tunnel runs over the SAs that IKE established.

## L2TP with IPSec Control and Data Frames

L2TP and IPSec define control and data messages used for L2TP/IPSec. Figure 24 shows an L2TP control frame encapsulated by IPSec. The shaded area shows the encrypted portion of the frame.

Figure 24: L2TP Control Frame Encapsulated by IPSec

Figure 25 is an L2TP data frame encapsulated by IPSec. The shaded area shows the encrypted portion of the frame.

Figure 25: L2TP Data Frame Encapsulated by IPSec

## Compatibility and Requirements

This section covers various compatibility issues and requirements for the L2TP/IPSec traffic.

### Client Software Supported

The L2TP/IPSec software supports the following client PC operating systems and L2TP and IPSec applications:

- Windows 2000 and Windows XP running built-in IPSec VPN software
- Microsoft L2TP/IPSec VPN client for Windows NT, Windows 98, and Windows Me
- SafeNet client software
- Mac OS X version 10.3 or higher

### Interactions with NAT

There are two ways that you can configure E Series routers to interact with Network Address Translation (NAT) devices in the network:

- Configure the router to run in NAT passthrough mode by using the application l2tp-nat-passthrough command. For information, see NAT Passthrough Mode .
- Configure the virtual router to enable NAT Traversal (NAT-T) by using the ipsec option nat-t command. For information, see NAT Traversal .

### Interaction Between IPSec and PPP

PPP defines the Compression Control Protocol (CCP) and the Encryption Control Protocol (ECP) modes. These modes are currently not supported in the E Series router. There is no interaction related to encryption directives between IPSec and PPP.

### LNS Change of Port

In the L2TP world, the LNS is allowed to change its port number; this functionality is currently not supported in ERX routers. IPSec allows only port 1701 to be used for L2TP/IPSec tunnels. However, the LAC is allowed to use any source port it desires.

### Group Preshared Key

Group preshared keys allow the provisioning of secure remote access by means of L2TP/IPSec to networks that do not use a certificate authority (CA) to issue certificates. A group preshared key is associated with a local IP address in the E Series router and is used to authenticate L2TP/IPSec clients that target this IP address as their VPN server address.

| Caution: Group preshared keys are not fully secure, and we recommend that you use digital certificates in place of group preshared keys. Group preshared keys are open to man-in-the-middle attacks. To reduce this risk, the ERX routers accept only IPSec connections that specify L2TP traffic selectors for security associations (SAs) that are negotiated over IKE connections authenticated with group preshared keys.

## NAT Passthrough Mode

NAT devices can change the IP address and port number of a traversing IP packet. Encrypted frames, in which an ESP header follows the IP header, may or may not get through the NAT device.

You can set up the router to run in NAT passthrough mode, which causes the router to not check UDP checksums. The reason is that a NAT device may change the IP address while the UDP header is encrypted. In this case, the UDP checksum cannot be recalculated. Not checking UDP checksums does not compromise security, because IPSec protects UDP with an authentication algorithm far stronger than UDP checksums. To set up the router to run in NAT passthrough mode, use the application l2tp-nat-passthrough command.

We recommend that you configure the router to use NAT passthrough mode when the NAT device provides a feature commonly known as IPSec passthrough.

For information about configuring NAT passthrough mode as part of an IPSec transport profile, see Configuring IPSec Transport Profiles .

## NAT Traversal

Using NAT passthrough mode is an adequate solution when a single remote user located behind a NAT device needs secure access to an E Series router. However, NAT passthrough mode does not support secure access to the router by multiple remote users at locations such as hotels or airports where a NAT device resides between the router and the remote users. In addition, NAT passthrough mode does not provide secure access for groups of remote users at corporate locations where a NAT device resides between the company's intranet and the public IP network.

To allow secure router access for multiple remote hosts located behind a NAT device, the router supports a set of IETF standards collectively known as NAT Traversal (NAT-T). For a list of the individual standards that NAT-T comprises, see References .

### How NAT-T Works

By default, NAT-T is enabled on every virtual router configured on the system. With NAT-T enabled, IPSec traffic flows transparently through a NAT device, thereby allowing one or more remote hosts located behind the NAT device to use secure L2TP/IPSec tunnel connections to access the router.

After NAT-T is enabled on a specific virtual router, either by default or by using the ipsec option nat-t command, the router performs the following actions, in this order:

1. The router monitors the exchange of private vendor ID (VID) payloads between the client PC and the E Series router during the IKE SA negotiation to determine whether both sides of the negotiation support NAT-T.
2. If both sides of the negotiation support NAT-T, the router detects whether a NAT device resides between the IPSec remote peers.
3. If a NAT device is detected between the remote peers, the router negotiates the appropriate type of UDP encapsulation as part of the IKE SA and uses this encapsulation method to process the IPSec traffic.

The ipsec option nat-t command affects only those IKE SAs negotiated on the virtual router after the command is issued. The command has no effect on IKE SAs that were previously negotiated.

### UDP Encapsulation

As part of the IKE SA negotiation process, the router automatically negotiates UDP encapsulation for L2TP/IPSec control and data frames.

When NAT-T is enabled, L2TP/IPSec control frames and data frames are wrapped in an additional NAT-T UDP header that enables data to flow transparently through the NAT device. The NAT device can translate the IP address of the source port associated with the NAT-T UDP header, whereas the IPSec ESP header does not have a source port that the NAT device can translate.

Figure 26 shows an L2TP control frame encapsulated with a NAT-T UDP header. The shaded area shows the portion of the frame that is encrypted by IPSec.

Figure 26: L2TP Control Frame with NAT-T UDP Encapsulation

Figure 27 shows an L2TP data frame encapsulated with a NAT-T UDP header. The shaded area shows the portion of the frame that is encrypted by IPSec.

Figure 27: L2TP Data Frame with NAT-T UDP Encapsulation

Additionally, IKE packets transmitted during the IKE SA negotiation process are encapsulated with a NAT-T UDP header, and include a non-ESP marker to distinguish them from standard ESP control and data frames. Figure 28 shows an IKE packet encapsulated with a NAT-T UDP header.

Figure 28: IKE Packet with NAT-T UDP Encapsulation

Only frames that use the ESP encryption and authentication protocol can be UDP-encapsulated. Frames that use authentication header (AH) cannot be UDP-encapsulated; therefore, NAT-T is not supported for L2TP/IPSec connections that use AH.

For more detailed information about encapsulation and other IPSec security parameters, see Configuring IPSec.

### UDP Statistics

When NAT-T is enabled, UDP-encapsulated IPSec packets arriving and leaving the router look like standard UDP packets. However, the router does not forward these packets to and from the SRP module, as it does for other UDP packets. As a result, the UDP statistics maintained by the SRP module do not reflect UDP-encapsulated IPSec packets.

### NAT Keepalive Messages

The router does not generate NAT keepalive messages. The following reasons explain why this behavior does not generally pose problems for remote users.

- The primary application for using NAT-T is enabling secure L2TP/IPSec access to an E Series router for remote hosts located behind a NAT device. The L2TP protocol has its own keepalive mechanism that is sufficient for keeping NAT entries alive.
- In most NAT configurations, an ERX router does not operate behind the NAT device, thereby making the generation of keepalive messages unnecessary.

If the router receives NAT keepalive messages as part of the L2TP/IPSec traffic flow, it discards these messages at the ingress line module on which the messages were received.

### Configuring and Monitoring NAT-T

For instructions on configuring and monitoring NAT-T, see the sections listed in Table 17.

Table 17: Configuration and Monitoring Tasks for NAT-T

Task | Command | See Section
--- | --- | ---
Enabling and disabling NAT-T on a virtual router | ipsec option nat-t | Configuring NAT-T
Displaying information about the current NAT-T setting on a virtual router | show ipsec option | Monitoring DVMRP/IPSec, GRE/IPSec, and L2TP/IPSec Tunnels
Displaying information about the IKE SA negotiation when NAT-T is enabled | show ipsec ike-sa | Monitoring DVMRP/IPSec, GRE/IPSec, and L2TP/IPSec Tunnels

## Single-Shot Tunnels

You can use the single-shot-tunnel command in L2TP Destination Profile Host Configuration mode to configure a single-shot L2TP tunnel. Although configuration of single-shot tunnels is more typically used with secure L2TP/IPSec tunnels, as described in this chapter, you can also configure single-shot tunnels for nonsecure L2TP tunnels that do not run over an IPSec connection.

A single-shot tunnel has the following characteristics:

- The L2TP tunnel can carry no more than a single L2TP session for the duration of its existence.
- The router ignores the idle timeout period for single-shot tunnels. This means that as soon a single-shot tunnel's session is removed, the single-shot tunnel proceeds to disconnect.
- The following characteristics apply only to secure L2TP/IPSec single-shot tunnels:
  - The underlying IPSec connection for a single-shot tunnel can carry no more than a single L2TP tunnel for the duration of its existence.
  - The router disconnects the underlying IPSec transport connection for a single-shot tunnel at the beginning of the destruct timeout period instead of waiting until the destruct timeout period expires.

For L2TP/IPSec single-shot tunnels, as soon as the tunnel or its single session fails negotiations or disconnects, the router prevents any further L2TP tunnels or L2TP sessions from connecting, and requires that a new IPSec connection be established for any subsequent connection attempts.

Table 18 describes the differences between how the router handles the idle timeout period (configured with the l2tp tunnel idle-timeout command) and the destruct timeout period (configured with the l2tp destruct-timeout command) for standard L2TP/IPSec tunnels and for single-shot L2TP/IPSec tunnels when the last remaining tunnel session has been disconnected.

Table 18: Differences in Handling Timeout Periods for L2TP/IPSec Tunnels

Timeout Period | Standard L2TP/IPSec Tunnels (Not Single-Shot) | Single-Shot L2TP/IPSec Tunnels
--- | --- | ---
Idle timeout period | The tunnel persists until the idle timeout period expires. If a new L2TP session is created before the idle timeout period expires, the tunnel persists to carry the new session and any subsequent sessions that are established. When the idle timeout period expires, the router disconnects the tunnel. | The router ignores the idle timeout period. This behavior prevents a single-shot tunnel from passing traffic after its single L2TP session is disconnected.
Destruct timeout period | The router signals the underlying IPSec transport connection to disconnect when the destruct timeout period expires. | The router signals the underlying IPSec transport connection to disconnect at the beginning of the destruct timeout period.

For information about configuring L2TP/IPSec single-shot tunnels on the router, see Configuring Single-Shot Tunnels .

## Configuration Tasks for Client PC

To set up client PCs, you need to:

1. Create an IPSec security policy to secure L2TP traffic to the E Series router.
2. Get a certificate for the client or set up preshared keys.
3. Create a VPN connection to the router.
4. Log the client in to the E Series router.

## Configuration Tasks for E Series Routers

The main configuration tasks for setting up L2TP/IPSec are:

1. Set up IP connectivity to L2TP clients; for example, PPPoE, DHCP, or static IP.
2. Set up digital certificates on the router, or configure preshared keys for IKE authentication.
   - To set up digital certificates, see Configuring Digital Certificates.
   - To set up preshared keys, see Configuring IPSec Parameters in Configuring IPSec.
3. Create IPSec policies. See Defining an IKE Policy in Configuring IPSec.
4. Configure RADIUS authentication and accounting. See JUNOSe Broadband Access Configuration Guide.
5. Configure L2TP destination profiles. See the next section, Enabling IPSec Support for L2TP.
6. Configure NAT-T on the virtual router. See Configuring NAT-T.
7. Configure single-shot L2TP/IPSec tunnels. See Configuring Single-Shot Tunnels.
8. Configure IPSec transport profiles. See Configuring IPSec Transport Profiles .

## Enabling IPSec Support for L2TP

To configure an L2TP destination profile:

1. Create a destination profile that defines the location of the LAC, and access L2TP Destination Profile Configuration mode.
   `
   host1(config)#l2tp destination profile boston4 ip address 0.0.0.0
   host1(config-l2tp-dest-profile)#
   `
2. Define the L2TP host profile, and enter L2TP Destination Profile Host Configuration mode.
   `
   host1(config-l2tp-dest-profile)#remote host default
   host1(config-l2tp-dest-profile-host)#
   `
3. Specify that for L2TP tunnels associated with this destination profile, the router accept only tunnels protected by IPSec.
   `
   host1(config-l2tp-dest-profile-host)#enable ipsec-transport
   `
4. (Optional) Assign a profile name for a remote host.
   `
   host1(config-l2tp-dest-profile-host)#profile georgeProfile1
   `
5. Specify the local IP address to be used in any packets sent to the LAC.
   `
   host1(config-l2tp-dest-profile-host)#local ip address 10.0.0.1
   `

For information about other L2TP destination profile commands, see LNS Configuration Prerequisites.

enable ipsec-transport

- Use to specify that the router accept only L2TP tunnels protected by an IPSec transport connection.
- Example
  `
  host1(config-l2tp-dest-profile-host)#enable ipsec-transport
  `
- Use the no version to disable IPSec transport mode.
- See enable ipsec-transport.

l2tp destination profile

- Use to create the destination profile that defines the location of the LAC and to access L2TP Destination Profile Configuration mode.
- If no virtual router is specified, the current virtual router context is used.
- If the destination address is 0.0.0.0, then any LAC that can be reached via the specified virtual router is allowed to access the LNS. If the destination address is nonzero, then it must be a host-specific IP address.
- The router supports up to 4,000 L2TP destination profiles.
- Example
  `
  host1:boston(config)#l2tp destination profile boston ip address 10.10.76.12
  host1:boston(config-l2tp-dest-profile)#
  `
- Use the no version to remove the L2TP destination profile and all of its host profiles.

  | Note: If you remove a destination profile, all tunnels and sessions using that profile will be dropped.

- See l2tp destination profile.

## Configuring NAT-T

To configure NAT-T on the current virtual router:

1. Select the name of the virtual router you want to configure.
   `
   host1(config)#virtual-router westford
   host1:westford(config)#
   `
2. Enable NAT-T for the current virtual router.
   `
   host1:westford(config)#ipsec option nat-t
   `

ipsec option nat-t

- Use to enable NAT-T for the current virtual router.
- With NAT-T enabled, IPSec traffic flows transparently through a NAT device, thereby allowing one or more remote hosts located behind the NAT device to use secure L2TP/IPSec tunnel connections to access the router.
- The ipsec option nat-t command affects only those IKE SAs negotiated on this virtual router after the command is issued; it has no effect on previously negotiated IKE SAs.
- Example
  `
  host1:sunnyvale(config)#ipsec option nat-t
  `
- Use the no version to disable NAT-T for the current virtual router.
- Use the default version to restore the default NAT-T setting on the virtual router, enabled.
- See ipsec option nat-t.

## Configuring Single-Shot Tunnels

To configure a single-shot L2TP/IPSec tunnel:

1. Create an L2TP destination profile, which defines the location of the LAC. The l2tp destination profile command accesses L2TP Destination Profile Configuration mode.
   `
   host1(config)#l2tp destination profile boston4 ip address 0.0.0.0
   host1(config-l2tp-dest-profile)#
   `
2. Create an L2TP host profile, which defines the attributes that the router, acting as the LNS, uses when communicating with the LAC. The remote host command accesses L2TP Destination Profile Host Configuration mode.
   `
   host1(config-l2tp-dest-profile)#remote host default
   host1(config-l2tp-dest-profile-host)#
   `
3. Specify that, for L2TP tunnels associated with this host profile, the router accept only tunnels protected by IPSec.
   `
   host1(config-l2tp-dest-profile-host)#enable ipsec-transport
   `
4. Specify that the L2TP tunnels associated with this host profile are single-shot tunnels.
   `
   host1(config-l2tp-dest-profile-host)#single-shot-tunnel
   `
5. (Optional) Configure other attributes for the L2TP host profile.
6. (Optional) Use the show l2tp destination profile command to verify configuration of the single-shot tunnel for a particular L2TP host profile.

   For information about how to use this command, see show l2tp destination profile .

For information about the other commands you can use to configure L2TP destination profiles and L2TP host profiles, see LNS Configuration Prerequisites.

single-shot-tunnel

- Use to configure the L2TP/IPSec tunnels associated with a particular L2TP host profile as single-shot tunnels.
- A single-shot tunnel can carry no more than a single L2TP session for the duration of its existence.
- The router ignores the idle timeout period for single-shot tunnels.
- The following characteristics apply only to secure L2TP/IPSec single-shot tunnels:
  - The underlying IPSec connection for a single-shot tunnel can carry no more than a single L2TP tunnel for the duration of its existence.
  - The router disconnects the underlying IPSec transport connection for a single-shot tunnel at the beginning of the destruct timeout period instead of waiting until the destruct timeout period expires.
- A single-shot tunnel does not persist beyond its last connected L2TP session. As a result, using single-shot L2TP/IPSec tunnels instead of the default (standard) tunnel behavior provides better protection against a brute force attack that makes multiple, simultaneous authentication attempts.
- Example
  `
  host1(config-l2tp-dest-profile-host)#single-shot-tunnel
  `
- Use the no version to restore the default behavior for L2TP/IPSec tunnels, which disables the single-shot attribute.
- See single-shot-tunnel.

[Contents] [Prev] [Next] [Index] [Report an Error]