L2TP Session Establishment Process
L2TP session establishment involves the following messages:
Incoming-Call-Request (ICRQ): is sent by the LAC to the LNS when an incoming call is detected, requesting session establishment. An ICRQ message carries session parameters.
Incoming-Call-Reply (ICRP): is sent by the LNS to the LAC in response to a received ICRQ message, indicating that session establishment is allowed.
Incoming-Call-Connected (ICCN): is sent by the LAC to the LNS in response to a received ICRP message, indicating that the ICRP message was accepted, the call has been answered, and the L2TP session should move to the established state.
Call-Disconnect-Notify (CDN): is sent to inform the peer of session teardown and the reason why the session teardown occurred.
Zero-Length Body (ZLB): is sent to the peer if there are no further messages waiting in queue for the peer. During session teardown, the receiver of a CDN message must send a ZLB message to acknowledge receipt of the CDN message. A ZLB message gets its name because it has only an L2TP header but no payload.
Session Establishment
After a control connection is established, the LAC requests the LNS to establish a session when an incoming call is detected. Different from a control connection, a session is established in a directional manner. On the NetEngine 8000 F, a session request is initiated by the LAC. Figure 1 shows the process of session establishment.
The establishment of an L2TP session is triggered through PPP.
You can run the display command on the LAC or LNS to view the sessions that have been successfully established.
Session Teardown
Either the LAC or LNS can initiate a request for session teardown. The initiator sends a CDN message, requesting the peer to tear down the session. The peer sends the initiator a ZLB ACK message in response to the received CDN message. Figure 2 shows the process of session teardown initiated by the LAC.
Process of an L2TP user going online
Figure 3 shows the typical L2TP networking.
Figure 2 shows the process of establishing an L2TP tunnel session.
A PC initiates a request for establishing a call connection and implements PPPoE negotiation with the LAC.
The PC and LAC perform PPP LCP negotiation.
The LAC authenticates the user information provided by the PC through PAP or CHAP.
The LAC sends the user information (including the username and password) to a RADIUS server for authentication.
The RADIUS server authenticates the user. If the authentication succeeds, the RADIUS server sends the LAC the LNS address corresponding to the user as well as other information, and the LAC prepares for initiating a tunnel connection request.
The LAC sends a tunnel connection request to the LNS.
The LAC sends a CHAP Challenge message to the LNS, and the LNS replies with a CHAP Response message. Then, the LNS then sends a CHAP Challenge message to the LAC, and the LAC replies with a CHAP Response message.
Tunnel authentication between the LAC and LNS is authenticated.
After tunnel authentication succeeds, the LAC sends the CHAP response, response identifier, and PPP negotiation parameters to the LNS.
The LNS sends the access request information to the RADIUS server for authentication.
The RADIUS server authenticates the access request. If the authentication succeeds, the RADIUS server returns with a response message.
If mandatory CHAP authentication is configured on the LNS, the LNS authenticates the user and sends a CHAP Challenge message to the PC. The PC then returns a CHAP Response message.
The LNS sends the access request information to the RADIUS server again for authentication.
The RADIUS server authenticates the access request. If the authentication succeeds, the RADIUS server returns with a response message.
After the authentication succeeds, the user can access internal resources of an enterprise.
Modes of User Authentication
User authentication is performed twice. The first round of authentication is performed on the LAC, and the second round of authentication on the LNS.
There are three modes of user authentication: LCP renegotiation, mandatory CHAP authentication, and proxy authentication.
LCP renegotiation
You can configure LCP renegotiation between the LNS and PC if the user authentication on the LNS needs to be stricter than that on the LAC or the LNS needs to directly obtain certain information from the user. The latter situation may occur when the LNS and LAC are from different vendors. LCP renegotiation uses the authentication mode configured on the corresponding VT. In this case, the proxy authentication information on the NAS side is ignored.
Mandatory CHAP authentication
If only mandatory CHAP authentication is configured, the LNS performs CHAP authentication on the user. If the authentication fails, no session can be established.
Proxy authentication
If neither LCP renegotiation nor mandatory CHAP authentication is configured, the LNS performs proxy authentication on the user.
In proxy authentication, the LAC encapsulates PAP and CHAP authentication information into an ICCN message and sends the message to the LNS. The LNS then uses the PAP and CHAP authentication information to authenticate the user.
For the VPN service request initiated by the NAS, when the PPP session starts, the client performs PPP negotiation with the NAS first. If the negotiation succeeds, the NAS initializes the L2TP tunnel connection and sends the user information to the LNS. The LNS then determines whether the user is authorized based on the received proxy authentication information.
If the LAC uses the MSCHAP V1 or MSCHAP V2 authentication mode when the LNS attempts to authenticate the user, the ICCN message sent by the LAC to the LNS does not carry authentication information. In this case, the LNS renegotiates the authentication mode with the client and reauthenticates the user based on the renegotiation result. If the renegotiation fails, the user fails to go online.
The relationships between proxy authentication and the authentication mode configured on a VT are as follows:The authentication mode on the VT cannot be more complex than that on the LAC. If the authentication mode on the LAC is PAP but that on the VT of the LNS is CHAP, the authentication fails.
In other situations, the LNS adopts the authentication mode carried in the messages sent by the LAC rather than the authentication mode configured on the VT.