About the L2TP VPN Gateway Application

The L2TP VPN Gateway test application provides comprehensive L2TP Network Server testing in a 3G environment using the L2TP protocol. The optional L2TP Network Server and L2TP Secure Network Server features provide a virtual LNS that can support test operations driven by another test system or tool.

When describing L2TP testing, the following definitions are used:

Mobile Node (MN) — The mobile subscriber unit.
L2TP Access Concentrator (LAC) — A device that terminates the MN side of the L2TP tunnel.
L2TP Network Server (LNS) Gateway — A gateway that controls access to a private network and terminates the private side of the L2TP tunnel.
Network Host — An application server with which the MN can exchange bearer plane traffic.

The L2TP Access Concentrator and the LNS exchange the messages necessary to negotiate an L2TP tunnel and establish individual MN PPP sessions within the tunnel, resulting in PPP connectivity between the MN and the LNS. IPSec may be used to encrypt L2TP control plane traffic between the LAC and the LNS. IPSec may also be used to encrypt the bearer plane traffic between the MN and the LNS or another IPSec peer on the private network side of the LNS.

A general L2TP VPN access model is shown in the diagram below. In this model, the LNS Gateway assigns the MN's IP address, allowing the MN to access a private network without the need for NAT traversal.

The LNS Nodal test case simulates one or more LACs, and simulates MNs from the standpoint of generating unique user credentials when authentication is used in establishing PPP sessions with the LNS.

Learn more about the LNS Nodal test case

Protocols

L2TP
PPP
IPSec

Emulators

Mobile Node (MN)
L2TP Access Concentrator (LAC)
Network Host

Testing with L2TP

Layer Two Tunneling Protocol (L2TP) can be used to tunnel PPP packets between two L2TP peers, in this case an LAC and an LNS, across the Internet or other IP network. When a VPN user establishes a PPP session with an LAC, the LAC establishes an L2TP tunnel with the designated LNS if a tunnel does not already exist, and then establishes an L2TP session with the LNS for the MN's PPP session. An L2TP tunnel can accommodate multiple L2TP sessions, and an LNS can maintain L2TP tunnels with multiple LACs. A two-way CHAP challenge-response may be used to authenticate the L2TP peers during tunnel establishment. The LNS may authenticate an MN using an external device such as a AAA server. The diagram below shows the process of establishing an L2TP tunnel and L2TP session, resulting in IP connectivity between an MN and an application server (Network Host).

With the L2TP VPN Gateway application, you can test the ability of an LNS to establish and maintain IPSec SAs, L2TP tunnels, and L2TP sessions, and its ability to handle bearer plane traffic when you add Data Traffic to the test. In a test scenario, the MN, LAC, and Network Host are emulated by the test system. When the test begins, the LAC node attempts to establish an L2TP tunnel with the LNS SUT and if the tunnel is established, it then attempts to establish L2TP sessions for each of the MNs as they are activated. As the MNs are deactivated, the LAC node terminates the L2TP sessions. When the last MN session is deactivated, the LAC node tears down the L2TP tunnel. Since the test system simulates both the MNs and the LAC, no actual messages are generated by the MN and the LAC node does not perform any type of user authentication. The exchanges between an MN and the LAC in the diagram below are shown for illustrative purposes only.

Message Types

The test application supports the L2TP control messages shown in the flow diagram above and defined below. Any other control messages received from an LNS will be discarded.

Zero-Length-Body Acknowledgement (ZLB ACK) — Either peer can send a ZLB ACK to acknowledge receipt of an L2TP control message when a specific control response is not required and when there are no other messages in a queue waiting to be sent.

L2TP Control

The following messages are used to establish, maintain, and tear down L2TP tunnels:

Start-Control-Connection-Request (SCCRQ) — An SCCRQ is sent from the LAC to the LNS to begin the tunnel establishment process.
Start-Control-Connection-Reply (SCCRP) — The LNS responds to an acceptable SCCRQ with an SCCRP, indicating that tunnel establishment should continue and identifying the Tunnel ID. If the SCCRQ is not acceptable, the LNS responds with a StopCCN.
Start-Control-Connection-Connected (SCCCN) — The LAC responds to an acceptable SCCRP with an SCCCN, completing the tunnel establishment. If the SCCRP is not acceptable, the LAC responds with a StopCCN.
Hello (HELLO) — HELLO is a keep-alive message that can be sent from either peer when it has not received any control or PPP messages for a period of time. If a response is not received, the tunnel is torn down. Control, PPP, or ZLB ACK messages are all acceptable responses to a HELLO.
Stop-Control-Connection-Notification (StopCCN) — A StopCCN can be sent by either peer to tear down a tunnel during normal operation or due to an error such as an unacceptable or out-of-sequence control message. Any L2TP sessions that are active when a StopCCN is received are deactivated.

When tunnel authentication is used, the SCCRQ contains a CHAP challenge to the LNS, the SCCRP contains the LNS's CHAP response and a CHAP challenge to the LAC, and the SCCCN contains the LAC's CHAP response to the LNS.

L2TP Session

The following messages are used to activate and deactivate L2TP sessions:

Incoming-Call-Request (ICRQ) — An ICRQ is sent from the LAC to the LNS to begin L2TP session establishment for an MN.
Incoming-Call-Reply (ICRP) — The LNS responds to an acceptable ICRQ with an ICRP, indicating that the session request was successful and identifying the Session ID. If the ICRQ is not acceptable, the LNS responds with a CDN.
Incoming-Call-Connected (ICCN) — The LAC responds to an acceptable ICRP with an ICCN, completing the session establishment. The ICCN contains PPP LCP parameters and may contain credentials used by the LNS to authenticate the MN. If the ICRP is not acceptable, the LAC responds with a CDN.
Set-Link-Info (SLI) — The LNS sends an SLI to the LAC to set the negotiated PPP options and can send an SLI at any time during the L2TP session to change the PPP options.
Call-Disconnect-Notify (CDN) — A CDN can be sent by either peer to deactivate an L2TP session during normal operation or due to an error such as an unacceptable or out-of-sequence control message. A cause code attribute indicates the reason for the deactivation.