Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Layer 2 Tunneling Protocol (L2TP)

Layer 2 Tunneling Protocol (L2TP) is a protocol for tunneling Layer 2 traffic over a Layer 3 network. You can use L2TP to enable Point-to-Point Protocol (PPP) tunneling within your network.

L2TP requires an L2TP access concentrator (LAC) and an L2TP network server (LNS). The LNS is one endpoint of an L2TP tunnel. The LAC, configured on an access device, receives packets from a remote client and forwards them to the LNS on a remote network. The LAC and LNS are peers.

For information about how to configure L2TP for subscriber access , see L2TP for Subscriber Access Overview.

Minimum L2TP Configuration

To define the minimum configuration for L2TP, include at least the following statements at the [edit access] hierarchy level:

Note:

When the LNS is configured with RADIUS authentication, the default behavior is to accept the preferred RADIUS-assigned IP address. Previously, the default behavior was to accept and install the nonzero peer IP address received in the Internet Protocol Control Protocol (IPCP) configuration request packet.

L2TP Profiles

Configure profiles for L2TP.

When multiple types of profiles are configured, the operating system only implements one configuration. The operating system prioritizes them as follows, where [edit access profile profile-name] overrides all other profile configurations:

  1. [edit access profile profile-name]
  2. [edit access group-profile profile-name]
  3. [edit access profile profile-name user-group-profile profile-name]

Access Profiles

To validate L2TP connections and session requests, you set up access profiles by configuring the profile statement at the [edit access] hierarchy level. You can configure multiple profiles. You can also configure multiple clients for each profile.

Configure the L2TP Client

To configure the client, include the client statement at the [edit access profile profile-name] hierarchy level:

client-name is the peer identity.

For L2TP, you can optionally use the wildcard (*) to define a default tunnel client to authenticate multiple LACs with the same secret and L2TP attributes. If an LAC with a specific name is not defined in the configuration, the wildcard tunnel client authenticates it.

Note:

The * for the default client configuration applies only to M Series routers. On MX Series routers, use default instead. See L2TP LNS Inline Service Interfaces for more about MX Series routers.

Client-Specific Profile

To define L2TP properties for a client-specific profile, include one or more of the following statements at the [edit access profile profile-name client client-name l2tp] hierarchy level:

Note:

When you configure the profile, you can configure either L2TP or PPP parameters, but not both at the same time.

interface-id (in the interface-id statement) is the identifier for the interface representing an L2TP session configured at the [edit interfaces interface-name unit local-unit-number dial-options] hierarchy level.

number (in the maximum-sessions-per-tunnel statement) is the maximum number of sessions for an L2TP tunnel.

shared-secret (in the shared-secret statement) is the shared secret for authenticating the peer.

You can specify PPP authentication (in the ppp-authentication statement). By default, the PPP authentication uses CHAP. You can configure this to use Password Authentication Protocol (PAP).

You can configure LNS so it renegotiates LCP with the PPP client (in the lcp-negotiation statement). By default, the PPP client negotiates the LCP with the LAC. When you do this, the LNS discards the last sent LCP configuration request and last received LCP configuration request AVPs from the LAC; for example, the LCP negotiated between the PPP client and LAC.

You can configure the Junos OS so that the LNS ignores proxy authentication AVPs from the LAC and reauthenticates the PPP client using a CHAP challenge (in the local-chap statement). By default, the PPP client is not reauthenticated by the LNS. When you do this, the LNS directly authenticates the PPP client.

You can configure the PPP MP for L2TP if the PPP sessions that are coming into the LNS from the LAC have multilink PPP negotiated. When you do this, you join multilink bundles based on the endpoint discriminator (in the multilink statement).

  • milliseconds (in the drop-timeout statement) specifies the number of milliseconds for the timeout that associated with the first fragment on the reassembly queue. If the timeout expires before all the fragments have been collected, the fragments at the beginning of the reassembly queue are dropped. If the drop timeout is not specified, the Junos OS holds on to the fragments (fragments may still be dropped if the multilink reassembly algorithm determines that another fragment belonging to the packet on a reassembly queue has been lost).

    Note:

    The drop timeout and fragmentation threshold for a bundled multilink might belong to different tunnels. The different tunnels might have different drop timeout and fragmentation thresholds. We recommend configuring group profiles instead of profiles when you have L2TP tunnels.

  • bytes specifies the maximum size of a packet, in bytes (in the fragment-threshold statement). If a packet exceeds the fragmentation threshold, the Junos OS fragments it into two or more multilink fragments.

Example: Define the Default Tunnel Client

For any tunnel client, you can optionally use the user group profile to define default PPP attributes for all users coming in through a tunnel. The user group profile must define PPP attributes. If the user group profile is specified, all users (PPP sessions) use the PPP attributes specified in the user group profile. The PPP attributes specified in the local or RADIUS server take precedence over those specified in the user group profile.

Optionally, you can use a wildcard client to define a user group profile. When you do this, any client entering this tunnel uses the PPP attributes (defined user group profile attributes) as its default PPP attributes.

Configure the Access Profile

Note:

When you configure a profile, you can only configure either L2TP or PPP parameters. You cannot configure both at the same time.

  1. To configure the access profile, include the profile statement at the [edit access] hierarchy level and assign a name to the profile:
  2. To configure the L2TP properties for a profile, include the following statements at the [edit access profile profile-name] hierarchy level:
  3. You can configure the order in which the operating system tries different methods to authenticate peers. For each access attempt, the software tries the first configured authentication method. Configure the authentication order using the authentication-order statement. If you do not include the authentication-order statement, the operating system verifies clients using password authentication.

    In authentication-methods, specify one or more of the following in the preferred order. When you configure the authentication methods for L2TP, only the first configured authentication method is used.

    • radius—Verify the client using RADIUS authentication services.

    • password—Verify the client using the information configured at the [edit access profile profile-name client client-name] hierarchy level.

    For L2TP, RADIUS authentication servers are configured at the [edit access radius-server] hierarchy level. For more information about configuring RADIUS authentication servers, see Configuring RADIUS Authentication for L2TP.

Example: Access Profile Configuration

The following example shows a configuration of an access profile:

Group Profile

You can optionally configure a group profile. Any client referencing the configured group profile inherits all the group profile attributes. This makes it easier to apply L2TP on a larger scale.

To configure the L2TP for the group profile, include the following statements at the [edit access group-profile profile-name l2tp] hierarchy level:

interface-id is the identifier for the interface representing an L2TP session configured at the [edit interfaces interface-name unit local-unit-number dial-options] hierarchy level.

You can configure the LNS so that it renegotiates the link control protocol (LCP) with the PPP client (in the renegotiation statement). By default, the PPP client negotiates the LCP with the L2TP access concentrator (LAC). When you do this, the LNS discards the last sent and the last received LCP configuration request attribute value pairs (AVPs) from the LAC; for example, the LCP negotiated between the PPP client and the LAC.

You can configure Junos OS so that the LNS ignores proxy authentication AVPs from the LAC and reauthenticates the PPP client using a CHAP challenge (in the local-chap statement). When you do this, the LNS directly authenticates the PPP client. By default, the PPP client is not reauthenticated by the LNS.

number is the maximum number of sessions per L2TP tunnel.

Reference the Group Profile from the L2TP Profile

You can reference a configured group profile from the L2TP tunnel profile.

To reference the group profile configured at the [edit access group-profile profile-name] hierarchy level, include the group-profile statement at the [edit access profile profile-name client client-name] hierarchy level:

profile-name references a configured group profile from a PPP user profile.

Example: PPP MP for L2TP

Configure L2TP Authentication

L2TP does not include any authentication methods, so it is flexible and can be used with your preferred security features. When you configure PPP properties for an L2TP profile, you typically configure the chap-secret statement or pap-password statement.

Configure the CHAP Secret for an L2TP Profile

CHAP allows each end of a PPP link to authenticate its peer, as defined in RFC 1994. The authenticator sends its peer a randomly generated challenge that the peer must encrypt using a one-way hash; the peer must then respond with that encrypted result. The key to the hash is a secret known only to the authenticator and authenticated. When the response is received, the authenticator compares its calculated result with the peer’s response. If they match, the peer is authenticated.

Each end of the link identifies itself to its peer by including its name in the CHAP challenge and response packets it sends to the peer. This name defaults to the local hostname, or you can explicitly set it using the local-name option. When a host receives a CHAP challenge or CHAP response packet on a particular interface, it uses the peer identity to look up the CHAP secret key to use.

Note:

When you configure PPP properties for a Layer 2 Tunneling Protocol (L2TP) profile, you typically configure the chap-secret statement or pap-password statement.

To configure CHAP, include the profile statement and specify a profile name at the [edit access] hierarchy level:

Then reference the CHAP profile name at the [edit interfaces interface-name ppp-options chap] hierarchy level.

You can configure multiple profiles. You can also configure multiple clients for each profile.

profile is the mapping between peer identifiers and CHAP secret keys. The identity of the peer contained in the CHAP challenge or response queries the profile for the secret key to use.

client is the peer identity.

chap-secret secret is the secret key associated with that peer.

Example: Configuring L2TP PPP CHAP

Configure the PAP Password for an L2TP Profile

To configure the Password Authentication Protocol (PAP) password, include the pap-password statement at the [edit access profile profile-name client client-name] hierarchy level:

pap-password is the password for PAP.

Example: Configure PAP for an L2TP Profile

Example: Configure L2TP

Configure L2TP for M7i and M10i Routers

For M7i and M10i routers, you can configure Layer 2 Tunneling Protocol (L2TP) tunneling security services on an Adaptive Services Physical Interface Card (PIC) or a MultiServices PIC.

To configure L2TP, include the following statements at the [edit access] hierarchy level: