Generally three devices are involved in VPDN tunneling. Two of these devices function as tunnel endpoints--one device initiates the VPDN tunnel, and the other device terminates the VPDN tunnel. Depending on the tunneling architecture, different types of devices can act as the local tunnel endpoint.

As new tunneling protocols have been developed for VPDNs, protocol-specific terminology has been created to describe some of the devices that participate in VPDN tunneling. However, these devices perform the same basic functions no matter what tunneling protocol is being used. For the sake of clarity we will use this generic terminology to refer to VPDN devices throughout this documentation:

• NAS--The network access server (NAS) is typically a device maintained by an ISP that provides VPDN services for its customers. The NAS is the local point of contact for the client device. Establishing a connection between the NAS and the client will referred to as receiving a calll or placing a calll, depending on whether a dial-in or dial-out scenario is being discussed. Depending on the tunneling architecture, the NAS functions as follows:

  • For NAS-initiated VPDN tunneling scenarios and dial-out VPDN tunneling scenarios, the NAS functions as a tunnel endpoint. The NAS initiates dial-in VPDN tunnels and terminates dial-out VPDN tunnels. The Cisco ASR 1000 Series Aggregation Services Routers support dial-in only.
  • For client-initiated VPDN tunneling scenarios, the NAS does not function as a a tunnel endpoint; it simply provides Internet connectivity.

• Tunnel server--The tunnel server is typically maintained by the customer and is the contact point for the remote private network. The tunnel server terminates dial-in VPDN tunnels and initiates dial-out VPDN tunnels.

• Tunnel server--The tunnel server is typically maintained by the customer and is the contact point for the remote private network. The tunnel server terminates dial-in VPDN tunnels and initiates dial-out VPDN tunnels.

• Tunnel switch--A tunnel switch is a device configured to perform multihop VPDN tunneling. A tunnel switch acts as both a NAS and a tunnel server. The tunnel switch terminates incoming VPDN tunnels and initiates the outgoing VPDN tunnels that will carry data on to the next hop.

Although technically a tunnel switch is a tunnel endpoint for both the incoming tunnel and the outgoing tunnel, for the sake of simplicity the tunnel endpoints in a multihop deployment are considered to be the device that initiates the first tunnel and the device that terminates the final tunnel of the multihop path.

The table below lists the generic terms and the corresponding technology-specific terms that are sometimes used to describe the NAS and the tunnel server.

Note	The Cisco ASR 1000 Series Aggregation Services Routers support only L2TP.

A VPDN tunnel exists between the two tunnel endpoints. The tunnel consists of a control connection and zero or more Layer 2 sessions. The tunnel carries encapsulated PPP datagrams and control messages between the tunnel endpoints. Multiple VPDN sessions can use the same VPDN tunnel.

A VPDN session is created between the tunnel endpoints when an end-to-end PPP connection is established between a client and the tunnel server. Datagrams related to the PPP connection are sent over the tunnel. There is a one-to-one relationship between an established session and the associated call. Multiple VPDN sessions can use the same VPDN tunnel.

Client-initiated dial-in VPDN tunneling is also known as voluntary tunneling. In a client-initiated dial-in VPDN tunneling scenario, the client device initiates a Layer 2 tunnel to the tunnel server, and the NAS does not participate in tunnel negotiation or establishment. In this scenario, the NAS is not a tunnel endpoint; it simply provides Internet connectivity. The client device must be configured to initiate the tunnel.

The main advantage of client-initiated VPDN tunneling is that it secures the connection between the client and the ISP NAS. However, client-initiated VPDNs are not as scalable and are more complex than NAS-initiated VPDNs.

Client-initiated VPDN tunneling can use the L2TP protocol or the L2TPv3 protocol if the client device is a router. If the client device is a PC then PPTP termination and L2TP over IPSEC termination are not supported on Cisco IOS XE operating system.

The figure below shows a client-initiated VPDN tunneling scenario.

Before configuring a client-initiated dial-in VPDN tunneling deployment, you must complete the required tasks in the “Configuring AAA for VPDNs” module.

NAS-initiated dial-in VPDN tunneling is also known as compulsory tunneling. In a NAS-initiated dial-in VPDN tunneling scenario, the client dials in to the NAS through a medium that supports PPP. If the connection from the client to the ISP NAS is over a medium that is considered secure, such as digital subscriber line (DSL), ISDN, or the public switched telephone network (PSTN), the client can choose not to provide additional security. The PPP session is securely tunneled from the NAS to the tunnel server without any special knowledge or interaction required from the client.

NAS-initiated VPDN tunneling can be configured with the L2TP or L2F protocol.

Note	The Cisco ASR 1000 Series Aggregation Services Routers support only L2TP.

The figure below shows a NAS-initiated dial-in tunneling scenario.

For further information about NAS-initiated tunneling deployments, see the Configuring NAS-Initiated Dial-In VPDN Tunneling module.

Before configuring a NAS-initiated dial-in VPDN tunneling deployment, you must complete the required tasks in the Configuring AAA for VPDNs module.

Multihop VPDN is a specialized VPDN configuration that allows packets to pass through multiple tunnels. Ordinarily, packets are not allowed to pass through more than one tunnel. In a multihop tunneling deployment, the VPDN tunnel is terminated after each hop and a new tunnel is initiated to the next hop destination. A maximum of four hops is supported.

Multihop VPDN is required for the scenarios described in these sections:

L2TP is an Internet Engineering Task Force (IETF) standard that combines the best features of the two older tunneling protocols: Cisco L2F and Microsoft PPTP.

L2TP offers the same full-range spectrum of features as L2F, but offers additional functionality. An L2TP-capable tunnel server will work with an existing L2F NAS and will concurrently support upgraded components running L2TP. Tunnel servers do not require reconfiguration each time an individual NAS is upgraded from L2F to L2TP. The table below compares L2F and L2TP feature components.

Traditional dialup networking services support only registered IP addresses, which limits the types of applications that are implemented over VPDNs. L2TP supports multiple protocols and unregistered and privately administered IP addresses. This allows the existing access infrastructure--such as the Internet, modems, access servers, and ISDN terminal adapters (TAs)--to be used. It also allows customers to outsource dial-out support, thus reducing overhead for hardware maintenance costs and 800 number fees, and allows them to concentrate corporate gateway resources.

The figure below shows the basic L2TP architecture in a typical dial-in environment.

Using L2TP tunneling, an ISP or other access service can create a virtual tunnel to link remote sites or remote users with corporate home networks. The NAS located at the POP of the ISP exchanges PPP messages with remote users and communicates by way of L2TP requests and responses with the private network tunnel server to set up tunnels. L2TP passes protocol-level packets through the virtual tunnel between endpoints of a point-to-point connection. Frames from remote users are accepted by the ISP NAS, stripped of any linked framing or transparency bytes, encapsulated in L2TP, and forwarded over the appropriate tunnel. The private network tunnel server accepts these L2TP frames, strips the L2TP encapsulation, and processes the incoming frames for the appropriate interface.

The figure below depicts the events that occur during establishment of a NAS-initiated dial-in L2TP connection.

The following describes the sequence of events shown in the figure above and is keyed to the figure:

1. The remote user initiates a PPP connection to the ISP NAS using a medium that supports PPP such as the analog telephone system. The NAS accepts the connection, the PPP link is established, and Link Control Protocol (LCP) is negotiated.

2. After the end user and NAS negotiate LCP, the NAS partially authenticates the end user with CHAP or PAP. The username, domain name, or Dialed Number Information Service (DNIS) is used to determine whether the user is a VPDN client. If the user is not a VPDN client, authentication continues, and the client will access the Internet or other contacted service. If the username is a VPDN client, the mapping will name a specific endpoint (the tunnel server).

3. The tunnel endpoints, the NAS and the tunnel server, authenticate each other before any tunnel or session establishment is attempted. Alternatively, the tunnel server can accept tunnel creation without any tunnel authentication of the NAS. The NAS and the tunnel server exchange control messages to negotiate tunnel establishment.

4. Once the tunnel exists, an L2TP session is created for the end user. The NAS and the tunnel server exchange call messages to negotiate session establishment.

5. The NAS will propagate the negotiated LCP options and the partially authenticated CHAP or PAP information to the tunnel server. The tunnel server will funnel the negotiated options and authentication information directly to the virtual access interface, allowing authentication to be completed. If the options configured in the virtual template interface do not match the options negotiated with the NAS, the connection will fail and a disconnect notification will be sent to the NAS.

6. PPP packets are exchanged between the dial-in client and the remote tunnel server as if no intermediary device (the NAS) is involved.

Subsequent PPP incoming sessions (designated for the same tunnel server) do not repeat the L2TP tunnel negotiation because the L2TP tunnel is already open.

L2TPv3 is an enhanced version of L2TP with the capability to tunnel any Layer 2 payload. L2TPv3 defines the L2TP protocol for tunneling Layer 2 payloads over an IP core network using Layer 2 Virtual Private Networks (VPNs).

In VPDN deployments, L2TPv3 can be used to establish a client-initiated tunnel from a local router to the remote customer network over an emulated circuit known as a pseudowire. There is one pseudowire associated with each L2TPv3 session.

Rather than using a VPDN group configuration, L2TPv3 uses an L2TP class configuration that is associated with the pseudowire. L2TPv3 pseudowires can also be used to establish L2TP tunnels by configuring an L2TP class on the local device and an accept-dialin VPDN group on the customer network.

For detailed information about the L2TPv3 protocol, see the Additional References section.