No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE40E-M2 V800R010C10SPC500 Feature Description - User Access 01

This is NE40E-M2 V800R010C10SPC500 Feature Description - User Access
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
L2TP Session Establishment Process

L2TP Session Establishment Process

The establishment of an L2TP session involves the following messages:

  • Incoming-Call-Request (ICRQ) message: is sent only by the LAC. Each time detecting a call request sent by a user, the LAC sends an ICRQ message to the LNS to request the establishment of a session connection. The ICRQ message carries session parameters.

  • Incoming-Call-Reply (ICRP) message: is sent only by the LNS to reply to the ICRQ message sent by the LAC, indicating that a session connection can be established.

  • Incoming-Call-Connected (ICCN) message: is sent only by the LAC to reply to the ICRP message sent by the LNS, indicating that a reply to the call request is sent and the session connection needs to be established on the LNS.

  • Call-Disconnect-Notify (CDN) message: is sent to the peer to notify the disconnection of the session and the reason for the disconnection.

  • Zero-Length Body (ZLB) message: is sent to the remote end when no messages in the queue of the local end are to be sent. In addition, during the teardown of the session connection and the control connection, sending a ZLB message indicates that a StopCCN or CDN message is received. The ZLB message only contains an L2TP header and has no payload.

Establishing a session connection

After a control connection is successfully established, a request for the establishment of a session connection is sent when a user call is detected. Different from a control connection, a session connection is unidirectional. The request for the establishment of a session connection is initiated by the LAC. Figure 8-7 shows the process of establishing a session connection.

Figure 8-7 Diagram of the process of establishing a session connection

The establishment of an L2TP session connection is triggered through PPP.

On the device, you can run the command to view the session connections that are successfully established.

Tearing down a session connection

Either the LAC or the LNS can initiate a session disconnection. The initiator sends a CDN message to the peer end to instruct the peer end to disconnect the session. After receiving the message, the peer end responds with a ZLB ACK message. Figure 8-8 shows the LAC-initiated session disconnection process.

Figure 8-8 Teardown of an L2TP session connection

P2P Login Process of L2TP Users

Figure 8-9 shows the typical networking diagram of an L2TP tunnel.

Figure 8-9 Networking diagram of an L2TP tunnel

Figure 8-10 shows the flowchart of establishing an L2TP call for tunnel authentication.

Figure 8-10 Flowchart of establishing an L2TP tunnel call

  1. The PC initiates a request for establishing a call.

  2. The PPP LCP negotiation is performed between the PC and the LAC.

  3. The LAC authenticates the user information sent by the PC through PAP or CHAP.

  4. The LAC sends the user information (including the user name and password) to a RADIUS server for authentication.

  5. The RADIUS server authenticates the user information. If authentication succeeds, the LNS address corresponding to the user is sent and the LAC is to initiate a request for establishing a tunnel connection.

  6. The LAC sends a request for establishing a tunnel connection to the specified LNS.

  7. The LAC sends a CHAP Challenge message to the specified LNS. The LNS replies to the CHAP Challenge message with a CHAP Response message and sends a CHAP Challenge message to the LAC. Then, the LAC replies to the CHAP Challenge message with a CHAP Response message.

  8. Tunnel authentication succeeds.

  9. The LAC sends the user CHAP Response message, identifier of the Response message, and negotiated PPP parameters to the LNS.

  10. The LNS sends the request for access to the RADIUS server for authentication.

  11. The RADIUS server authenticates the request. If authentication succeeds, the RADIUS server sends a response message.

  12. If the user configures forcible CHAP authentication on the LNS, the LNS authenticates the user information and sends a CHAP Challenge message to the user. The user then replies the LNS with a CHAP Response message.

  13. The LNS sends the request for access again to the RADIUS server for authentication.

  14. The RADIUS server authenticates the request. If authentication succeeds, the RADIUS server sends a response message.

  15. After authentication succeeds, the user can access resources of the Intranet.

User Authentication Modes on the LNS

The LNS can authenticate a user twice. The first authentication is performed on the LAC and the second authentication is performed on the LNS. Note that "none" is also an authentication mode.

On the LNS, the user can be authenticated in proxy mode, forcible CHAP mode, or forcible LCP renegotiation mode.

  • LCP renegotiation

    If authentication required on the LNS is more strictly than that on the LAC, or if the LNS needs to obtain information directly from a user (in the scenario where the LNS and the LAC are of different vendors), the LCP renegotiation between the LNS and the user can be configured. During the renegotiation, the authentication mode configured on the corresponding VT is adopted. In this case, information for proxy authentication on the NAS is ignored.

  • Forcible CHAP authentication

    If only forcible CHAP authentication is configured, the LNS authenticates the user information through CHAP. If authentication fails, no session can be established.

  • Proxy authentication

    If the LCP renegotiation and forcible CHAP authentication are not configured, the LNS authenticates the user information through proxy.

    Proxy authentication refers to that the LAC sends all information about a user and the locally-configured authentication mode to the LNS, and then the LNS authenticates a user based on received information.

    When an NAS initiates a request for NAS-initiated VPN services, a user needs to negotiate parameters of a PPP session with the NAS. If the negotiation is successful, the NAS initiates an L2TP tunnel connection and sends the user information to the LNS. The LNS then authenticates the user information.

    In the case that the LNS adopts proxy authentication, if the VT is configured with CHAP authentication and the LAC is configured with PAP authentication, authentication on the LNS fails and the session cannot be established, because the priority of CHAP authentication on the LNS is higher that the priority of PAP authentication on the LAC.

    If the LAC is configured with AAA authentication in none mode, AAA authentication is not performed no matter whether the LAC is configured with PAP or CHAP authentication. After the authentication mode is sent to the LNS, the LNS authenticates the user information through AAA (in local, RADIUS or none mode).

    The relationships between proxy authentication and the authentication mode configured in a VT are as follows:

    • The authentication mode configured in the VT cannot be more complicated than the authentication mode configured on the LAC. If PAP authentication is configured on the LAC, whereas CHAP authentication is configured on a VT of the LNS, authentication on the LNS fails.

    • In other situations, the LNS adopts the authentication mode sent by the LAC rather than the authentication mode on a VT.

Download
Updated: 2019-01-02

Document ID: EDOC1100058415

Views: 12218

Downloads: 8

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next