< Home

Mechanism of L2TP VPN in the NAS-Initiated Scenario

This section describes the mechanism of L2TP VPN in the NAS-Initiated scenario in terms of tunnel negotiations, packet encapsulation

Tunnel Negotiation

Before a dialup user sends service data to the intranet, the information about the tunnel used to transmit the data needs to be negotiated. Figure 1 shows the process in which a dialup user initiates an access request, the NAS and LNS negotiates an L2TP VPN tunnel, and the user accesses intranet resources.
Figure 1 L2TP VPN tunnel establishment in the NAS-initiated scenario
  1. The dialup user and NAS establish a PPPoE connection.

    The dialup user broadcasts PPPoE messages to search for the NAS. The NAS is the tunnel ingress for the user to access the intranet resources of the headquarters.

    Packet Exchange Procedure Packet Content

    PPPoE client: sends PADI broadcast packets to search for a PPPoE server.

    PPPoE server: returns a PADO packet to inform that it can establish a PPPoE connection with the PPPoE client.

    PPPoE client: sends a PADR packet to request a session ID used to establish a PPPoE session from the PPPoE server.

    PPPoE server: returns a PADS packet to notify the PPPoE client of the session ID (1).

    PPPoE client: sends an LCP Request packet to negotiate link-layer parameters. For example, as shown in the figure at the right side, the negotiated MRU is 1480.

    The PPPoE server returns an LCP ACK packet to the PPPoE client.

    PPPoE client: sends a PAP packet to request the PPPoE server to perform identity authentication. As shown in the figure at the right side, the PAP packet carries user name hb@hb and password admin@123. After the authentication succeeds, the PPPoE client and server establish a connection.

    If the dialup user uses CHAP authentication, the authentication process is little different. For details, see section PPP CHAP.

    NOTE:
    An L2TP VPN tunnel does not have the data encapsulation function. To prevent user data theft, you are advised to use the IPSec technology to provide the data encryption function for L2TP VPN.
  2. The NAS and LNS establish an L2TP VPN tunnel.

    After the PPPoE connection is established, the NAS and LNS start to negotiate the L2TP VPN tunnel.

    Packet Exchange Procedure Packet Content

    NAS: sends an SCCRQ packet to notify the LNS of the tunnel ID (1). The NAS uses the initial tunnel ID (0) to send an SCCRQ packet.

    In L2TP VPN, a NAS or LNS can establish multiple tunnels simultaneously to transmit different user services. The NAS or LNS negotiates the tunnel IDs for tunnels to be established to distinguish between the tunnels.

    L2TP packets are transmitted using UDP. When sending an SCCRQ packet, the NAS selects an idle interface as the source interface to send the packet to interface 1701 of the LNS. After receiving the packet, the LNS uses interface 1701 to send a response packet to the specified interface of the NAS. The interfaces at both sides are fixed until the tunnel is disconnected.

    LNS: sends an SCCRP packet to notify the NAS of the tunnel ID (1).

    NAS: sends an SCCCN packet.

    So far, the two devices have negotiated the tunnel ID to establish an L2TP VPN tunnel.

  3. The NAS and LNS establish an L2TP session.

    In Step 4, the dialup user establishes a PPP connection with the LNS. The L2TP session is used to record and manage the status of the PPP connection. Therefore, before establishing a PPP connection, the NAS and LNS need to negotiate an L2TP session.

    Packet Exchange Procedure Packet Content

    NAS: sends an ICRQ packet to notify the LNS of the session ID (28). The NAS uses the initial session ID (0) to send an ICRQ packet.

    LNS: sends an ICRP packet to notify the NAS of the session ID (24).

    NAS: sends an ICCN packet.

    So far, the two devices have negotiated the session ID to establish an L2TP session.

  4. The dialup user and LNS establish a PPP connection.

    The dialup user establishes a PPP connection with the LNS to obtain an intranet IP address from the LNS.

    1. Optional: The LNS performs secondary identity authentication for the dialup user.

      In the NAS-initiated scenario, there are two user identity authentication solutions. In one solution, only the NAS performs user identity authentication. In the other solution, both the NAS and LNS perform user identify authentication (secondary authentication). The LNS determines the solution to be used.

      • Proxy authentication

        In proxy authentication, only the NAS authenticates users, and the LNS does not perform secondary user identity authentication. For example, in 1, when a dialup user establishes a PPPoE connection with the NAS, the NAS has used PAP/CHAP to authenticate the identity of the dialup user. Then the LNS does not perform secondary authentication.

      • CHAP mandatory authentication

        After the NAS completes user identify authentication, the LNS requires the user to experience identity authentication in CHAP mode. The authentication mode is secondary identity authentication.

      • LCP renegotiation

        The LNS does not trust the authentication results of the NAS. It requires the user to perform the LCP negotiation again with the LNS and requires the LNS to re-authenticate the user (secondary authentication).

      Proxy authentication is used on the LNS by default. Specifically, secondary authentication is not implemented for the user.

    2. After identity authentication succeeds, the dialup user sends an IPCP Request packet to request the LNS to assign an intranet IP address.
    3. The LNS sends an IPCP ACK packet to the dialup user. The packet carries the intranet IP address allocated to the dialup user. So far, the PPP connection has been established. As shown in the following figure, the intranet address assigned by the LNS to the dialup user is 172.16.1.51.

  5. The dialup user sends service packets to access the enterprise headquarters.

    As shown in the following figure, the dialup user uses intranet address 172.16.1.51 to access intranet server 192.168.1.1. The packet from the user is encapsulated by the NAS and decapsulated by the LNS and reaches the intranet server. For details on packet encapsulation, see Packet Encapsulation.

Packet Encapsulation

Figure 2 shows the packet encapsulation and decapsulation processes.
Figure 2 Packet encapsulation in the NAS-initiated scenario
  1. The original data packet sent by the dialup user is encapsulated with a PPP header and a PPPoE header and then is sent to the NAS.

    A PPPoE connection is point-to-point. Therefore, after a PPPoE connection is established, the PC of the dialup user does not need to select a route. The PC sends the encapsulated packet to the NAS.

  2. The VT interface of the NAS removes the PPPoE header from the packet, adds an L2TP header to the packet, and sends the packet based on the route to the Internet.

  3. After receiving the packet, the LNS removes the L2TP and PPP headers from the packet and forwards the packet based on the intranet route.
  4. After the receiving the packet, the server on the enterprise headquarters returns a response packet to the dialup user.

Security Policy

  • Figure 3 shows the security zones that packets pass through on the NAS.
    When a dialup user accesses the enterprise intranet, the packets that pass through the NAS are classified into two types, and the security policy processes the two types of packets as follows:
    • PPPoE packets received by the NAS from the dialup user

      The PPPoE packets include the negotiation packets exchanged by the dialup user and NAS to establish a PPPoE connection and PPPoE-encapsulated data packets sent by the dialup user to access the intranet of the enterprise headquarters. Because the PPPoE packets are not subject to any security policy, it is unnecessary to configure a security policy for the PPPoE packets on the NAS.

    • L2TP packets sent by the NAS

      The L2TP packets include the L2TP packets exchanged between the NAS and LNS to establish a tunnel and the L2TP packets sent by the dialup user to access the intranet of the enterprise headquarters. The L2TP packets are transmitted from the Local zone to the Untrust zone.

    Figure 3 Packet direction on the NAS
  • Figure 4 shows the security zones that packets pass through on the LNS.
    When a dialup user accesses the enterprise intranet, the packets that pass through the LNS are classified into two types, and the security policy the two types of packets as follows:
    • L2TP packets exchanged between the NAS and LNS

      The L2TP packets include the L2TP negotiation packets exchanged by the NAS and LNS to establish a tunnel and the pre-decapsulated L2TP packets sent by the dialup user to access the intranet of the enterprise headquarters. The L2TP packets are transmitted from the Untrust zone to the Local zone.

    • Service packets sent by the dialup user to access the intranet of the enterprise headquarters

      The VT interface of the LNS decapsulates the service packets sent by the dialup user to access the intranet of the enterprise headquarters. The packets are transmitted from the DMZ to the Trust zone. The VT interface on the LNS resides in the DMZ, and the interface connecting the LNS to the intranet of the enterprise headquarters resides in the Trust zone.

    Figure 4 Packet direction on the LNS
Table 1 describes the matching conditions of the security policies on the NAS and LNS.
Table 1 Matching conditions of the security policies on the NAS and LNS
Traffic Direction Device Source Zone Destination Zone Source Address Destination Address Application
Traffic sent by a dialup user to access the enterprise intranet NAS Local Untrust 1.1.1.1/24 1.1.1.2/24 L2TP
LNS Untrust Local 1.1.1.1/24 1.1.1.2/24 L2TP
DMZ Trust 172.16.1.2 to 172.16.1.100 (addresses in the address pool) 192.168.1.0/24 *
Traffic sent by a server on the intranet of the enterprise headquarters to the dialup user LNS Trust DMZ 192.168.1.0/24 172.16.1.2 to 172.16.1.100 (addresses in the address pool) *
*: indicates that the application depends on the service type, which can be TCP, UDP, ICMP and any other service packet type.
Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
Next topic >