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

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:
The tunnel runs over the SAs that IKE established.
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

This section covers various compatibility issues and requirements for the L2TP/IPSec traffic.
The L2TP/IPSec software supports the following client PC operating systems and L2TP and IPSec applications:
There are two ways that you can configure E-series routers to interact with Network Address Translation (NAT) devices in the network:
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.
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 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 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 .
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 .
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:
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.
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.
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.
The router does not generate NAT keepalive messages. The following reasons explain why this behavior does not generally pose problems for remote users.
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.
For instructions on configuring and monitoring NAT-T, see the sections listed in Table 18.
Table 18: Configuration and Monitoring Tasks for NAT-T
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:
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 19 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 19: Differences in Handling Timeout Periods for L2TP/IPSec Tunnels
For information about configuring L2TP/IPSec single-shot tunnels on the router, see Configuring Single-Shot Tunnels .
To set up client PCs, you need to:
The main configuration tasks for setting up L2TP/IPSec are:
To configure an L2TP destination profile:
- host1(config)#l2tp destination profile boston4
ip address 0.0.0.0
- host1(config-l2tp-dest-profile)#
- host1(config-l2tp-dest-profile)#remote host
default
- host1(config-l2tp-dest-profile-host)#
- host1(config-l2tp-dest-profile-host)#enable
ipsec-transport
- host1(config-l2tp-dest-profile-host)#profile
georgeProfile1
- 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
- host1(config-l2tp-dest-profile-host)#enable
ipsec-transport
l2tp destination profile
- host1:boston(config)#l2tp destination profile
boston ip address 10.10.76.12
- host1:boston(config-l2tp-dest-profile)#
![]() |
Note: If you remove a destination profile, all tunnels and sessions using that profile will be dropped. |
To configure NAT-T on the current virtual router:
- host1(config)#virtual-router westford
- host1:westford(config)#
- host1:westford(config)#ipsec option nat-t
ipsec option nat-t
- host1:sunnyvale(config)#ipsec option nat-t
To configure a single-shot L2TP/IPSec tunnel:
- host1(config)#l2tp destination profile boston4
ip address 0.0.0.0
- host1(config-l2tp-dest-profile)#
- host1(config-l2tp-dest-profile)#remote host
default
- host1(config-l2tp-dest-profile-host)#
- host1(config-l2tp-dest-profile-host)#enable
ipsec-transport
- host1(config-l2tp-dest-profile-host)#single-shot-tunnel
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
- host1(config-l2tp-dest-profile-host)#single-shot-tunnel