|
|
This chapter describes how to configure, verify, maintain, and troubleshoot a Virtual Private Network (VPN). It includes the following main sections:
For a complete description of the commands mentioned in this chapter, see the Cisco IOS Dial Services Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
A VPN carries private data over a public network. It extends remote access to users over a shared infrastructure. VPNs maintain the same security and management policies as a private network. They are the most cost-effective method of establishing a point-to-point connection between remote users and a central network.
A benefit of access VPNs is the way they delegate responsibilities for the network. The customer outsources the responsibility for the information technology (IT) infrastructure to an Internet service provider (ISP) that maintains the modems that the remote users dial in to (called modem pools), access servers, and internetworking expertise. The customer is then only responsible for authenticating its users and maintaining its network.
Instead of connecting directly to the network by using the expensive Public Switched Telephone Network (PSTN), access VPN users only need to use the PSTN to connect to the ISP local point of presence (POP). The ISP then uses the Internet to forward users from the POP to the customer network. Forwarding a user call over the Internet provides dramatic cost saving for the customer. Access VPNs use Layer 2 tunneling technologies to create a virtual point-to-point connection between users and the customer network. These tunneling technologies provide the same direct connectivity as the expensive PSTN by using the Internet. This means that users anywhere in the world have the same connectivity as they would at the customer headquarters.
VPNs allow separate and autonomous protocol domains to share common access infrastructure including modems, access servers, and ISDN routers. VPNs use the following tunneling protocols to tunnel link level frames:
L2F or L2TP passes protocol-level packets through the virtual tunnel between endpoints of a point-to-point connection.
Cisco routers fast switch VPN traffic. In stack group environments in which some VPN traffic is offloaded to a powerful router, fast switching provides improved scalability.
For a complete description of the commands mentioned in this chapter, refer to the Cisco IOS Dial Solutions Command Reference publication. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
The VPDN MIB offers a mechanism to track failures of user calls in a VPN system allowing SNMP retrieval of user call failure information, on a per-user basis.
Refer to the Cisco VPDN Management MIB for a list of supported objects for the VPDN MIB.
In dial-in scenarios, users dial in to the NAS, and the NAS forwards the call to the tunnel server using a VPN tunnel.
In dial-out scenarios, the tunnel server initiates a VPN tunnel to the NAS, and the NAS dials out to the clients.
For the sake of clarity, we will use these generic terms, and not the technology-specific terms. Table 10 lists the technology-specific terms that are often used for these devices.
| Generic Term | L2F Term | L2TP Term |
|---|---|---|
Tunnel Server | Home Gateway | L2TP Network Server (LNS) |
Network Access Server (NAS) | NAS | L2TP Access Concentrator (LAC) |
VPNs are designed based on one of two architectural options: client-initiated or NAS-initiated VPNs.
VPNs use L2F or L2TP tunnels to tunnel the link layer of high-level protocols (for example, PPP frames or asynchronous High-Level Data Link Control (HDLC)). ISPs configure their NASs to receive calls from users and forward the calls to the customer tunnel server. Usually, the ISP only maintains information about the tunnel server—the tunnel endpoint. The customer maintains the tunnel server users' IP addresses, routing, and other user database functions. Administration between the ISP and tunnel server is reduced to IP connectivity.
Figure 13 shows the PPP link running between a client (the user hardware and software) and the tunnel server. The NAS and tunnel server establish an L2F tunnel that the NAS uses to forward the PPP link to the tunnel server. The VPN then extends from the client to the tunnel server. The L2F tunnel creates a virtual point-to-point connection between the client and the tunnel server.
The following sections give a functional description of the sequence of events that establish a VPN using L2F as the tunneling protocol:
The "Protocol Negotiation Sequence" section is an overview of the negotiation events that take place as the VPN is established. The "L2F Tunnel Authentication Process" section gives a detailed description of how the NAS and tunnel server establish the L2F tunnel.
A user who wants to connect to the customer tunnel server, first establishes a PPP connection to the ISP NAS. The NAS then establishes an L2F tunnel with the tunnel server. Finally, the tunnel server authenticates the client username and password, and establishes the PPP connection with the client.
Figure 14 shows the sequence of protocol negotiation events between the ISP NAS and the customer tunnel server.
Table 11 explains the sequence of events shown in Figure 14.
When the NAS receives a call from a client that is to be tunneled to a tunnel server, it first sends a challenge to the tunnel server. The tunnel server then sends a combined challenge and response to the NAS. Finally, the NAS responds to the tunnel server challenge, and the two devices open the L2F tunnel.
Before the NAS and tunnel server can authenticate the tunnel, they must have a common "tunnel secret." A tunnel secret is a common shared secret that is configured on both the NAS and the tunnel server. For more information on tunnel secrets, see the "Configuring VPN Tunnel Authentication" section later in this chapter. By combining the tunnel secret with random value algorithms, which are used to encrypt the tunnel secret, the NAS and tunnel server authenticate each other and establish the L2F tunnel.
Figure 15 shows the tunnel authentication process.
Table 12 explains the sequence of events shown in Figure 15.
Once the tunnel server authenticates the client, the access VPN is established. The L2F tunnel creates a virtual point-to-point connection between the client and the tunnel server. The NAS acts as a transparent packet forwarder.
When subsequent clients dial in to the NAS to be forwarded to the tunnel server, the NAS and tunnel server need not repeat the L2F tunnel negotiation because the L2F tunnel is already open.
L2TP is an emerging Internet Engineering Task Force (IETF) standard that combines the best features of two existing tunneling protocols: Cisco L2F (L2F) and Microsoft Point-to-Point Tunneling Protocol (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 network access server 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. Table 13 offers a comparison of L2F and L2TP feature components.
| Function | L2F | L2TP |
|---|---|---|
Flow Control | No | Yes |
AVP hiding | No | Yes |
Tunnel server load sharing | Yes | Yes |
Tunnel server stacking/multihop support | Yes | Yes |
Tunnel server primary and secondary backup | Yes | Yes |
DNS name support | Yes | Yes |
Domain name flexibility | Yes | Yes |
Idle and absolute timeout | Yes | Yes |
Multilink PPP support | Yes | Yes |
Multichassis Multilink PPP support | Yes | Yes |
Security |
|
|
Traditional dialup networking services only support registered IP addresses, which limits the types of applications that are implemented over VPNs. L2TP supports multiple protocols and unregistered and privately administered IP addresses over the Internet. 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. Figure 16 shows the L2TP architecture in a typical dialup environment.
The following sections supply additional detail about the interworkings and Cisco implementation of L2TP. Using L2TP tunneling, an Internet service provider (ISP), or other access service, can create a virtual tunnel to link customer's remote sites or remote users with corporate home networks. The NAS located at the ISP's POP exchanges PPP messages with remote users and communicates by way of L2TP requests and responses with the customer 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's POP, stripped of any linked framing or transparency bytes, encapsulated in L2TP and forwarded over the appropriate tunnel. The customer's tunnel server accepts these L2TP frames, strips the L2TP encapsulation, and processes the incoming frames for the appropriate interface. Figure 17 shows the L2TP tunnel detail and how user "lsmith" connects to the tunnel server to access the designated corporate intranet.
A VPN connection between a remote user, a NAS at the ISP POP, and the tunnel server at the home LAN using an L2TP tunnel is accomplished as follows:
Event | Description |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
The result is that the exchange process appears to be between the dialup client and the remote tunnel server exclusively, as if no intermediary device (the NAS) is involved. Figure 18 offers a pictorial account of the L2TP incoming call sequence with its own corresponding sequence numbers. Note that the sequence numbers in Figure 18 are not related to the sequence numbers described in the previous table.
When a user dials in to an NAS to be tunneled to a tunnel server, the NAS must identify the tunnel server to which the user's call is to be forwarded. You can configure the router to authenticate users and also to select the outgoing tunnel based on the following criteria:
When an NAS is configured to forward VPN calls based on the user domain name, the user must use a username of the form username@domain. The NAS then compares the user domain name to the domain names it is configured to search for. When the NAS finds a match, it forwards the user call to the proper tunnel server.
With this feature, a corporation—which might have only one domain name—can provide multiple specific phone numbers for users to dial in to the network access server at the service provider POP. The service provider can select the tunnel to the appropriate services or portion of the corporate network based on the dialed number.
When a service provider has multiple AAA servers configured, VPN tunnel authorization searches based on domain name can be time consuming and might cause the client session to time out.
To provide more flexibility, service providers can now configure the NAS to perform tunnel authorization searches by domain name only, by DNIS only, or by both in a specified order.
AAA tunnel definition lookup allows the NAS to look up tunnel definitions using keywords. Two new Cisco AV pairs are added to support NAS tunnel definition lookup: tunnel type and l2tp-tunnel-password. These AV pairs are configured on the RADIUS server. Descriptions of the values are as follows:
request dialin l2tp ip 172.21.9.13 domain cisco.com l2tp local name dustie l2tp local secret partner
is equivalent to the following RADIUS server configuration:
cisco.com Password = "cisco" cisco-avpair = "vpdn: tunnel-id=dustie", cisco-avpair = "vpdn: tunnel-type=l2tp", cisco-avpair = "vpdn: l2tp-tunnel-password=partner', cisco-avpair = "vpdn: ip-addresses=172.21.9.13"
The L2TP dial-out feature enables tunnel servers to tunnel dial-out VPN calls using L2TP as the tunneling protocol. This feature enables a centralized network to efficiently and inexpensively establish a virtual point-to-point connection with any number of remote offices.
 |
Note Cisco routers can carry both dial-in and dial-out calls in the same L2TP tunnels. |
L2TP dial-out involves two devices: a tunnel server and an NAS. When the tunnel server wants to perform L2TP dial-out, it negotiates an L2TP tunnel with the NAS. The NAS then places a PPP call to the client(s) the tunnel server wants to dial out to.
Figure 19 shows a typical L2TP dial-out scenario.
Table 14 explains the sequence of events described in Figure 19.
| Event | Description |
|---|---|
1. | The tunnel server receives Layer 3 packets, which are to be dialed out, and forwards them to its dialer interface (either a dialer profile or DDR). The dialer issues a dial call request to the VPN group, and the tunnel server creates a virtual access interface. If the dialer is a dialer profile, this interface becomes a member of the dial pool. If the dialer is DDR, the interface becomes a member of the rotary group. The VPN group creates a VPN session for this connection and sets it in the pending state. |
2. | The tunnel server and NAS establish an L2TP tunnel (unless a tunnel is already open). |
3. | The tunnel server sends an Outgoing Call ReQuest (OCRQ) packet to the NAS, which checks if it has a dial resource available. If the resource is available, the NAS responds to the tunnel server with an Outgoing Call RePly (OCRP) packet. If the resource is not available, the NAS responds with a Call Disconnect Notification (CDN) packet, and the session is terminated. |
4. | If the NAS has an available resource, it creates a VPN session and sets it in the pending state. |
5. | The NAS then initiates a call to the PPP client. When the NAS call connects to the PPP client, the NAS binds the call interface to the appropriate VPN session. |
6. | The NAS sends an Outgoing Call CoNnected (OCCN) packet to the tunnel server. The tunnel server binds the call to the appropriate VPN session and then brings the virtual access interface up. |
7. | The dialer on the tunnel server and the PPP client can now exchange PPP packets. The NAS acts as a transparent packet forwarder. If the dialer interface is a DDR and a virtual profile is configured, the PPP endpoint is the tunnel server virtual-access interface, not the dialer. All Layer 3 routes point to this interface instead of the dialer. |
|
Note Large scale dial-out, BAP, and Dialer Watch are not supported. All configuration must be local on the router. |
Cisco VPN is configured using the VPN group configuration mode. VPN groups can now support the following:
A VPN group can act as either a tunnel server or an NAS, but not both. But individual routers can have both tunnel server VPN groups and NAS VPN groups.
The VPN group contains the four corresponding command modes listed in Table 15. These command modes are accessed from VPN group mode; therefore, they are generically referred to as VPN subgroups.
| Command Mode | Router Prompt | Type of Service |
|---|---|---|
accept-dialin | | tunnel server |
request-dialout | | tunnel server |
request-dialin | | NAS |
accept-dialout | | NAS |
The keywords and arguments for the previous accept-dialin and request-dialin commands are now independent accept-dialin mode and request-dialin mode commands.
The previous syntax is still supported, but when you display the configuration, the commands will be converted to appear in the new format.
For example, to configure a NAS to request dial-in, you could use the old command:
request dialin l2tp ip 10.1.2.3 domain jgb.com
When you view the configuration, the keywords and arguments are displayed in the new format as individual commands:
request-dialin protocol l2tp domain jgb.com initiate-to ip 10.1.2.3
Similarly, the accept-dialout and request-dialout commands have subgroup commands that are used to specify such information as the tunneling protocol and dialer resource.
Table 16 lists the new VPN subgroup commands and which command modes they apply to:
| Command | VPN Subgroups |
|---|---|
default | all subgroups |
dialer | accept-dialout |
dnis | request-dialin |
domain | request-dialin |
pool-member | request-dialout |
protocol | all subgroups |
rotary-group | request-dialout |
virtual-template | accept-dialin |
The other VPN group commands are dependent on which VPN subgroups exist on the VPN group.
Table 17 lists the VPN group commands and which subgroups you need to enable for them to be configurable.
| Command | VPN Subgroups |
|---|---|
accept-dialin | tunnel server VPN group1 |
accept-dialout | NAS VPN group2 |
authen before-forward | request-dialin |
default | any subgroup |
force-local-chap | accept-dialin |
initiate-to | request-dialin or request-dialout |
lcp renegotiation | accept-dialin |
local name | any subgroup |
multilink | request-dialin |
request-dialin | NAS VPN Group2 |
request-dialout | tunnel server VPN Group1 |
source-ip | any subgroup |
terminate-from | accept-dialin or accept-dialout |
| 1Tunnel server VPN groups can be configured for accept dialin and/or request dialout. 2NAS VPN groups can be configured for accept dialout and/or request dialin. |
Before configuring a VPN, you must complete the prerequisites described in the following sections:
The following sections describe the prerequisites that must be configured on all VPNs on both the NAS and the tunnel server.
To assign an IP address to the interface that will be carrying the VPN traffic and brings up the interface, use the following commands on both the NAS and the tunnel server beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)#interface interface-type number | Enters interface configuration mode. |
Step 2 | Router | Configures the IP address and subnet mask on the interface. |
Step 3 | Router(config-if)#no shutdown | Changes the state of the interface from administratively down to up. |
To enable AAA use the following commands on both the NAS and the tunnel server in global configuration mode. If you use RADIUS or TACACS for AAA, you also need to point the router to the AAA server using either the radius-server host or tacacs-server host command.
|
Note Refer to the Cisco IOS Security Configuration Guide for a complete list of commands and configurable options for security and AAA implementation. |
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)#aaa new-model | Enables the AAA access control system. |
Step 2 | Router(config)#aaa authentication login default
{local | radius | tacacs}
| Enables AAA authentication at login and uses the local username database for authentication.1 |
Step 3 | Router(config)#aaa authentication ppp default
{local | radius | tacacs}
| Configures the AAA authentication method that is used for PPP and VPN connections.1 |
Step 4 | Router(config)#aaa authorization network default
{local | radius | tacacs}
| Configures the AAA authorization method that is used for network-related service requests.1 |
Step 5 | Router(config)#aaa accounting network default
start-stop {radius | tacacs}
| (Optional) Enables AAA accounting that sends a stop accounting notice at the end of the requested user process.1 |
Step 6 | Router(config)#radius-server host ip-address [auth-port number] [acct-port number] Router(config)#radius-server key cisco or Router(config)#tacacs-server host ip-address [port integer] [key string] | Specifies the RADIUS server IP address and optionally the ports to be used for authentication and accounting requests. Sets the authentication key and encryption key to "cisco" for all RADIUS communication. |
| 1If you specify more than one method, AAA will query the servers or databases in the order they are entered. |
The following sections describe the prerequisites that must be configured on dial-in VPNs.
To specify the IP addresses and the BOOTP servers that will be assigned to VPN clients, use the following commands on the tunnel server in global configuration mode.
The IP address pool is the addresses that the tunnel server assigns to clients. You must configure an IP address pool. You can also provide BOOTP servers. Domain Name Servers (DNS) servers translate host names to IP addresses. WINS servers, which are specified using the async-bootp nbns-server command, provide dynamic NetBIOS names that Windows devices use to communicate without IP addresses.
| Command | Purpose | |
|---|---|---|
Step 1 | HGW(config)#ip local pool default first-ip-address last-ip-address | Configures the default local pool of IP address that will be used by clients. |
Step 2 | HGW(config)#async-bootp dns-server ip-address1 [additional-ip-address] | (Optional) Returns the configured addresses of DNS in response to BOOTP requests. |
Step 3 | HGW(config)#async-bootp nbns-server ip-address1 [additional-ip-address] | (Optional) Returns the configured addresses of Windows NT servers in response to BOOTP requests. |
To define the ISDN switch type and commission the T1 controllers to allow modem calls to come into the NAS, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | | Enters the telco switch type. An ISDN switch type that is specified in global configuration mode is automatically propagated into the individual serial interfaces (for example, interface serial 0:23, 1:23, 2:23, and 3:23). |
Step 2 | NAS(config)# controller t1 0 | Accesses controller configuration mode for the first T1 controller, which is number 0. The controller ports are numbered 0 through 3 on the quad T1/PRI card. |
Step 3 | NAS(config-controller)#framing framing-type | Enters the T1 framing type. |
Step 4 | NAS(config-controller)#linecode linecode | Enters the T1 line-code type. |
Step 5 | NAS(config-controller)#clock source line primary | Configures the access server to get its primary clocking from the T1 line assigned to controller 0. Line clocking comes from the remote switch. |
Step 6 | NAS(config-controller)#pri-group timeslots range | Assigns the T1 time slots as ISDNPRI channels. After you enter this command, a D-channel serial interface is instantly created (for example, S0:23) along with individual B-channel serial interfaces (for example, S0:0, S0:1, and so on.). The D-channel interface functions like a dialer for the B channels using the controller. If this was an E1 interface, the PRI group range would be 1 to 31. The D-channel serial interfaces would be S0:15, S1:15, S2:15, and S3:15. |
To configure the D channels (the signalling channels) to allow incoming voice calls to be routed to the integrated MICA technologies modems and to control the behavior of the individual B channels, use the following commands on the NAS beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | NAS(config)#interface serial 0:23 | Accesses configuration mode for the D-channel serial interface that corresponds to controller T1 0. The behavior of serial 0:0 through serial 0:22 is controlled by the configuration instructions provided for serial 0:23. This concept is also true for the other remaining D-channel configurations. |
Step 2 | NAS(config-if)# isdn incoming-voice modem | Enables analog modem voice calls coming in through the Bchannels to be connected to the integrated modems. |
Step 3 | NAS(config-if)#exit | Exits back to global configuration mode. |
Step 4 | NAS(config)#interface serial 1:23 NAS(config-if)#isdn incoming-voice modem NAS(config-if)#exit NAS(config)#interface serial 2:23 NAS(config-if)#isdn incoming-voice modem NAS(config-if)#exit NAS(config)#interface serial 3:23 NAS(config-if)#isdn incoming-voice modem NAS(config-if)#exit | Configures the three remaining Dchannels with the same ISDN incoming-voice modem setting. |
To define a range of modem lines and to enable PPP clients to dial in, bypass the EXEC facility, and automatically start PPP, use the following commands on the NAS beginning in global configuration mode.
Configure the modems and lines after the ISDN channels are operational. Each modem corresponds with a dedicated asynchronous line inside the NAS. The modem speed 115200 BPS and hardware flow control are default values for integrated modems.
| Command | Purpose | |||
|---|---|---|---|---|
Step 1 | | Enters the modem line or range of modem lines (by entering an ending-line-number) that you want to configure. | ||
Step 2 | | Enables PPP clients to dial in, bypass the EXEC facility, and automatically start PPP on the lines. | ||
Step 3 | | Displays the username:password prompt as the modems connect.
| ||
Step 4 | | Supports incoming and outgoing modem calls. |
To create a group-asynchronous interface and project protocol characteristics to the asynchronous interfaces, use the following commands on the NAS beginning in global configuration mode.
The group-async interface is a template that controls the configuration of the specified asynchronous interfaces inside the NAS. Asynchronous interfaces are lines running in PPP mode. An asynchronous interface uses the same number as its corresponding line. Configuring all the asynchronous interfaces as an asynchronous group saves you time by reducing the number of configuration steps.
| Command | Purpose | |
|---|---|---|
Step 1 | | Creates the group-asynchronous interface. |
Step 2 | | Uses the IP address defined on the specified interface. |
Step 3 | | Enables PPP. |
Step 4 | | Configures interactive mode on the asynchronous interfaces. Interactive mode means that clients can dial in to the NAS and get a router prompt or PPP session. Dedicated mode means that only PPP sessions can be established on the NAS. Clients cannot dial in and get an EXEC (shell) session. |
Step 5 | | Configures the authentication to be used on the interface during LCP negotiation. When both authentication methods are specified, the NAS first authenticates with the first method entered. If the first method is rejected by the client, the second authentication method is used. |
Step 6 | | Specifies the range of asynchronous interfaces to include in the group, which is usually equal to the number of modems in the access server. |
The following sections describe the prerequisites that must be configured on dial-out VPNs.
To configure the dialer on an NAS for L2TP dial-out, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | NAS(config)#interface dialer number | Defines a dialer rotary group. |
Step 2 | NAS(config-if)#ip unnumbered interface-type number | Configures the dialer to use the interface IP address. |
Step 3 | NAS(config-if)#encapsulation ppp | Enables PPP encapsulation |
Step 4 | NAS(config-if)#dialer in-band | Enables DDR on the dialer. |
Step 5 | NAS(config-if)#dialer aaa | Enables the dialer to use the AAA server to locate profiles for dialing information. |
Step 6 | NAS(config-if)#dialer-group group-number | Assigns the dialer to the specified dialer group. |
Step 7 | NAS(config-if)#ppp authentication chap | Specifies that CHAP authentication will be used. |
To configure the dialer on an a tunnel server for L2TP dial-out, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | LNS(config)#interface dialer number | Defines a dialer rotary group. |
Step 2 | LNS(config-if)#ip address ip-address subnet-mask | Specifies an IP address for the group. |
Step 3 | LNS(config-if)#encapsulation ppp | Enables PPP encapsulation. |
Step 4 | LNS(config-if)#dialer remote-name peer-name | Specifies the name used to authenticate the remote router that is being dialed. |
Step 5 | LNS(config-if)#dialer string dialer-number | Specifies the number that is dialed. |
Step 6 | LNS(config-if)#dialer vpdn | Enables dial-out. |
Step 7 | LNS(config-if)#dialer pool pool-number | Specifies the dialer pool. |
Step 8 | LNS(config-if)#dialer-group group-number | Assigns the dialer to the specified dialer group. |
Step 9 | LNS(config-if)#ppp authentication chap | Specifies that CHAP authentication will be used. |
Configuration for both dial-in and dial-out VPNs is described in the following sections:
See the section "VPN Configuration Examples" later in this chapter for examples of how you can implement VPN in your network.
To enable a VPN tunnel, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
Router(config)#vpdn1 enable | Enables VPN. |
| 1The Cisco IOS command syntax uses the more specific term virtual private dialup network (VPDN) instead of VPN. |
To disable a VPN tunnel, use the clear vpdn tunnel command in EXEC mode. The no vpdn enable command does not automatically disable a VPN tunnel.
VPN tunnel authentication enables routers to authenticate the other tunnel endpoint before establishing a VPN tunnel. It is required for L2F tunnels and optional for L2TP tunnels.
To disable VPN tunnel authentication for L2TP tunnels, use the following command beginning in global configuration mode:
| Command | Purpose |
|---|---|
ISP_NAS(config)#vpdn-group group ISP_NAS(config-vpdn)#no l2tp tunnel authentication | Disables VPN tunnel authentication for the specified VPN group. The VPN group will not challenge any router that attempts to open an L2TP tunnel. |
|
Note Before you can configure any l2tp VPN group commands, you must specify L2TP as the protocol for a VPN subgroup within the VPN group. For more information, see the "Dial-In VPN Configuration Task List" and "Dial-Out VPN Configuration Task List" sections later in this chapter. |
VPN tunnel authentication can be performed in the following ways:
This section discusses local tunnel authentication. For information on RADIUS and TACACS, refer to the "NAS AAA Tunnel Definition Lookup" section earlier in this chapter and the Cisco IOS Security Configuration Guide.
VPN tunnel authentication requires that a single shared secret—called the tunnel secret—be configured on both the NAS and tunnel server. There are two methods for configuring the tunnel secret:
To configure VPN tunnel authentication using the hostname or local name commands, use the following commands beginning in global configuration mode:
| Command | Purpose | |||
|---|---|---|---|---|
Step 1 | ISP_NAS(config)#hostname hostname or ISP_NAS(config)#vpdn-group group ISP_NAS(config-vpdn)#local name tunnel-name | Configures the router host name. By default, the router uses the host name as the tunnel name in VPN tunnel authentication. | ||
Step 2 | ISP_NAS(config)#username tunnel-name password tunnel-secret | Configures the other router's tunnel name and the tunnel secret as a user name and password combination.
|
To configure VPN tunnel authentication using the l2tp tunnel password command, use the following commands beginning in global configuration:
| Command | Purpose | |||
|---|---|---|---|---|
Step 1 | ISP_NAS(config)#vpdn-group group ISP_NAS(config-vpdn)#l2tp tunnel password tunnel-secret | Configures the tunnel secret that will be used for VPN tunnel authentication for this VPN group. | ||
Step 2 | ISP_NAS(config-vpdn)#local name tunnel-name ISP_NAS(config)#username tunnel-name password tunnel-secret | (Optional) Configures the tunnel name of the router. If the other router uses the l2tp tunnel password command to configure the tunnel secret, these commands are not necessary.
|
For sample VPN tunnel authentication configurations, see the "VPN Tunnel Authentication Examples" section later in this chapter.
The following tasks must be completed for dial-in VPNs:
The NAS is a device that is typically (although not always) located at a service provider POP; initial configuration and ongoing management is done by the service provider.
To configure an NAS to accept PPP calls and tunnel them to a tunnel server, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | NAS(config)#vpdn-group 1 | Creates VPN group 1. |
Step 2 | NAS(config-vpdn)#request-dia lin | Enables the NAS to request L2F or L2TP dial-in requests. |
Step 3 | NAS(config-vpdn-req-in)#protocol [l2f | l2tp | any] | Specifies which tunneling protocol is to be used. |
Step 4 | NAS(config-vpdn-req-in)#or NAS(config-vpdn-req-in)#dnis dnis-number | Specifies the domain name of the users that are to be tunneled.
Specifies the DNIS number of users that are to be tunneled. You can configure multiple domain names and/or DNIS numbers for an individual request-dialin subgroup. |
Step 5 | NAS(config-vpdn-req-in)# | Specifies the IP address that the NAS will establish the tunnel with. This is the IP address of the tunnel server. Optionally, you can configure a maximum number of connections that this VPN group will support and the priority of this VPN group. |
Step 6 | NAS(config-vpdn)#vpdn search-order {domain | dnis | domain dnis | dnis domain } | (Optional) Specifies the method that is used to determine if a dial-in call should be tunneled. If both keywords are entered, the NAS will search the criteria in the order they are entered. |
To configure a tunnel server to accept tunneled PPP connections from an NAS, use the following commands beginning in global configuration mode.
The tunnel server is the termination point for a VPN tunnel. The tunnel server initiates outgoing calls to and receives incoming calls from the NAS.
| Command | Purpose | |
|---|---|---|
Step 1 | LNS(config)#vpdn-group 1 | Creates VPN group 1. |
Step 2 | LNS(config-vpdn)#accept-dialin | Enables the tunnel server to accept dial-in requests. |
Step 3 | LNS(config-vpdn-acc-in)# | Specifies which tunneling protocol is to be used. |
Step 4 | LNS(config-vpdn-acc-in)# | Specifies the number of the virtual template that will be used to clone the virtual access interface. |
Step 5 | LNS(config-vpdn-acc-in)#exit LNS(config-vpdn)#terminate-fro m hostname hostname | Accepts tunnels that have this host name configured as a local name. |
See the section "Tunnel Server Comprehensive Dial-in Configuration" later in this chapter for a configuration example.
At this point, you can configure the virtual template interface with configuration parameters you want applied to virtual access interfaces. A virtual template interface is a logical entity configured for a serial interface. The virtual template interface is not tied to any physical interface and is applied dynamically, as needed. Virtual access interfaces are cloned from a virtual template interface, used on demand, and then freed when no longer needed.
To create and configure a virtual template interface beginning in global configuration mode, use the following commands:
| Command | Purpose | |
|---|---|---|
Step 1 | HGW(config)#interface virtual-template number | Create the virtual template that is used to clone virtual access interfaces. |
Step 2 | HGW(config-if)#ip unnumbered interface-type number | Specifies that the virtual access interfaces use the specified interface IP address. |
Step 3 | HGW(config-if)#ppp authentication {chap | pap |
chap pap | pap chap}
| Enables CHAP authentication using the local username database. |
Step 4 | HGW(config-if)#peer default ip address pool pool | Returns an IP address from the default pool to the client. |
Step 5 | HGW(config-if)#encapsulation ppp | Enables PPP encapsulation. |
Optionally, you can configure other commands for the virtual template interface. For more information about configuring virtual template interfaces, refer to the "Configuring Virtual Template Interfaces" chapter in the Dial Solutions Configuration Guide.
The following tasks must be configured for dial-out VPNs:
To configure a tunnel server to request dial-out tunneled PPP connections to an NAS, use the following commands beginning in global configuration mode:
| Command | Purpose | |||
|---|---|---|---|---|
Step 1 | LNS(config)#vpdn-group 1 | Creates VPN group 1. | ||
Step 2 | LNS(config-vpdn)#request-d ialout | Enables the tunnel server to send L2TP dial-out requests. | ||
Step 3 | LNS(config-vpdn-req-ou)#protocol l2tp | Specifies L2TP as the tunneling protocol.
| ||
Step 4 | LNS(config-vpdn-req-ou)#po ol-member pool-number or LNS(config-vpdn-req-ou)#ro tary-group group-number | Specifies the dialer profile pool that will be used to dial out. Specifies the dialer rotary group that will be used to dial out. You can only configure one dialer profile pool or dialer rotary group. Attempting to configure a second dialer resource will remove the first from the configuration. | ||
Step 5 | LNS(config-vpdn-req-ou)#exit LNS(config-vpdn)#initiate- to ip ip-address [limit limit-number] [priority priority-number] | Specifies the IP address that will be dialed out. This is the IP address of the NAS. Optionally, you can configure a maximum number of connections that this VPN group will support and the priority of this VPN group. | ||
Step 6 | LNS(config-vpdn)#local name hostname | Specifies that the L2TP tunnel will identify itself with this host name. |
To configure an NAS to accept tunneled dial-out connections from a tunnel server, use the following commands beginning in global configuration mode:
| Command | Purpose | |||
|---|---|---|---|---|
Step 1 | NAS(config)#vpdn-group 1 | Creates VPN group 1. | ||
Step 2 | NAS(config-vpdn)#accept-di alout | Enables the NAS to accept L2TP dial-out requests. | ||
Step 3 | NAS(config-vpdn-acc-ou)#protocol l2tp | Specifies L2TP as the tunneling protocol.
| ||
Step 4 | NAS(config-vpdn-acc-ou)#di aler dialer-interface | Specifies the dialer that is used to dial out to the client. | ||
Step 5 | NAS(config-vpdn-acc-ou)#exit NAS(config-vpdn)#terminate-from hostname hostname | Accepts L2TP tunnels that have this host name configured as a local name. |
The following optional tasks provide advanced VPN features:
In a VPN that uses remote AAA, when a user dials in, the access server that receives the call forwards information about the user to its remote AAA server. With basic VPN, the access server only sends the user domain name (when performing domain name-based authentication) or the telephone number the user dialed in from (when performing DNIS-based authentication).
Per-user VPN configuration sends the entire structured username to the AAA server the first time the router contacts the AAA server. This enables the Cisco IOS software to customize tunnel attributes for individual users who use a common domain name or DNIS.
Without VPN per-user configuration, Cisco IOS sends only the domain name or DNIS to determine VPN tunnel attribute information. Then, if no VPN tunnel attributes are returned, Cisco IOS sends the entire username string.
|
Note Per-user VPN configuration only supports RADIUS as the AAA protocol. |
To configure per-user VPN, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)#vpdn-group group-number | Enters VPN group configuration mode. |
Step 2 | Router(config-vpdn)#aut hen before-forward | Specifies that the entire structured username be sent to the AAA server the first time the router contacts the AAA server. |
When L2TP data packets are created, they have a type of service (ToS) field of zero, which indicates normal service. This ignores the ToS field of the encapsulated IP packets that are being tunneled.
To preserve quality of service (QoS) for tunneled packets by copying the IP packets' ToS field onto the L2TP data packets when they are created at the tunnel server virtual access interface, use the following commands beginning on global configuration mode:
| Command | Purpose | |||
|---|---|---|---|---|
Step 1 | LNS(config)#vpdn-group 1 | Creates VPN group 1. | ||
Step 2 | LNS(config-vpdn)#accept-dialin or LNS(config-vpdn)#request-dialout | Enables the tunnel server to accept dial-in requests. | ||
Step 3 | LNS(config-acc-in)# | Specifies L2TP as the tunneling protocol.
| ||
Step 4 | LNS(config-acc-in)# | Preserves the ToS field of the encapsulated IP packets. |
|
Note L2TP is the only tunneling protocol that supports preservation of IP ToS. The tunneled link must carry IP for the ToS field to be preserved. Proxy PPP dial-in is not supported. Only tunnel servers can be configured to preserve IP ToS. |
To shutdown a VPN tunnel, use the following command in privileged EXEC mode:
| Command | Purpose |
Router#clear vpdn tunnel {l2f nas-name hgw-name | l2tp [remote-name] [local-name]} | Shuts down a specific tunnel and all the sessions within the tunnel. |
To set a limit for the maximum number of allowed simultaneous VPN sessions, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
Router(config)#vpdn session-limit sessions | Limits the number of simultaneous VPN sessions on the router to the number specified with the sessions argument. |
To verify that the vpdn session-limit command is working properly, perform the following steps:
|
Note If you use a Telnet session to connect to the NAS, enable the terminal monitor command, which ensures that your EXEC session is receiving the logging and debug output from the NAS. |
Step 2 Establish a VPN session by dialing in to the NAS using an allowed username and password.
Step 3 Attempt to establish another VPN session by dialing in to the NAS using another allowed username and password.
Step 4 A Syslog message similar to the following should appear on the console of the router:
00:11:17:%VPDN-6-MAX_SESS_EXCD:L2F HGW great_went has exceeded configured local session-limit and rejected user wilson@soam.com
Step 5 Enter the show vpdn history failure command on the router. If you see output similar to the following, the session limit was successful:
User:wilson@soam.com NAS:cliford_ball, IP address = 172.25.52.8, CLID = 2 Gateway:great_went, IP address = 172.25.52.7, CLID = 13 Log time:00:04:21, Error repeat count:1 Failure type:Exceeded configured VPDN maximum session limit. Failure reason:
To prevent new sessions from being established on a VPN tunnel without disturbing the service of existing sessions, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
Router(config)#vpdn softshut1 | Prevents new sessions from being established on a VPN tunnel without disturbing existing sessions. |
| 1When the vpdn softshut command is enabled, Multichassis Multilink PPP (MMP) L2F tunnels can still be created and established. |
When the vpdn softshut command is enabled on an NAS, the potential session will be authorized before it is refused. This authorization ensures that accurate accounting records can be kept.
When the vpdn softshut command is enabled on a tunnel server, the reason for the session refusal will be returned to the NAS. This information is recorded in the VPN history failure table.
To verify that the vpdn softshut command is working properly, perform the following steps:
Step 2 Enter the vpdn softshut global configuration command on either the NAS or tunnel server.
Step 3 Verify that the original session is still active by entering the show vpdn command:
ENT_HGW# show vpdn
% No active L2TP tunnels
L2F Tunnel and Session
NAS CLID HGW CLID NAS Name HGW Name State
36 1 cliford_ball great_went open
172.25.52.8 172.25.52.7
CLID MID Username Intf State
36 1 mockingbird@gamehendge.com Vi1 open
Step 4 Attempt to establish another VPN session by dialing in to the NAS using another allowed username and password.
Step 5 A Syslog message similar to the following should appear on the console of the soft shutdown router:
00:11:17:%VPDN-6-SOFTSHUT:L2F HGW great_went has turned on softshut and rejected user wilson@soam.com
Step 6 Enter the show vpdn history failure command on the soft shutdown router. If you see output similar to the following, the soft shutdown was successful:
User:wilson@soam.com NAS:cliford_ball, IP address = 172.25.52.8, CLID = 2 Gateway:great_went, IP address = 172.25.52.7, CLID = 13 Log time:00:04:21, Error repeat count:1 Failure type:VPDN softshut has been activated. Failure reason:
The Syslog mechanism provides generic and failure event logging. Generic logging is a mixture of type error, warning, notification, and information logging for VPN. Logging can be done locally or at a remote tunnel destination. Both generic and failure event logging is enabled by default; therefore, if you wish to disable VPN failure events you must specifically configure the router or access server to do so. In order to disable the router to log VPN generic or history events, use the following commands in global configuration mode:
| Command | Purpose | ||
|---|---|---|---|
Router(config)#vpdn logging [local | remote] | Enables generic event logging, locally or at a remote endpoint. | ||
Router(config)#vpdn logging history failure | Enables the logging of failure events to the failure history table.
|
You may set the failure history table to a specific number of entries based on the amount of data you wish to track. To set the failure history table, use the following commands in global configuration mode:
| Command | Purpose |
|---|---|
Router(config)#vpdn history failure table-size entries | (Optional) Set the failure history table depth. |
This section describes how to verify that an L2F dial-in scenario functions as show in Figure 20. To verify connectivity, complete the following verification tasks:
From the client, dial in to the NAS by using the PRI telephone number assigned to the NAS T1 trunks. Sometimes this telephone number is called the hunt group number.
As the call comes into the NAS, a LINK-3-UPDOWN message automatically appears on the NAS terminal screen. In the following example, the call comes in to the NAS on asynchronous interface 14. The asynchronous interface is up.
*Jan 1 21:22:18.410: %LINK-3-UPDOWN: Interface Async14, changed state to up
|
Note No debug commands are turned on to display this log message. Start troubleshooting the NAS if you do not see this message after 30 seconds of when the client first sends the call. |
From the client, ping the tunnel server. From the client Windows 95 desktop perform the following steps:
Step 2 Select Run.
Step 3 Enter the ping ip-address command, where the IP address is the tunnel server address.
Step 4 Click OK.
Step 5 Look at the terminal screen and verify that the tunnel server is sending ping reply packets to the client.
From the tunnel server, enter the show caller command and show caller user name command to verify that the client received an IP address. The following example shows that Jeremy is using interface virtual-access 1 and IP address 172.30.2.1. The network administrator jane-admin is using console 0.
ENT_HGW# show caller
Line User Service Active
con 0 jane-admin TTY 00:00:25
Vi1 jeremy@hgw.com PPP L2F 00:01:28
ENT_HGW# show caller user jeremy@hgw.com
User: jeremy@hgw.com, line Vi1, service PPP L2F, active 00:01:35
PPP: LCP Open, CHAP (<- AAA), IPCP
IP: Local 172.22.66.25, remote 172.30.2.1
VPDN: NAS ISP_NAS, MID 1, MID open
HGW ENT_HGW, NAS CLID 36, HGW CLID 1, tunnel open
Counts: 105 packets input, 8979 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
18 packets output, 295 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
From the tunnel server, ping Jeremy PC at IP address 172.30.2.1:
ENT_HGW# ping 172.30.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.30.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 128/132/152 ms
From the tunnel server, enter the show interface virtual-access 1 command to verify that the interface is up, LCP is open, and no errors are reported:
ENT_HGW# show interface virtual-access 1
Virtual-Access1 is up, line protocol is up
Hardware is Virtual Access interface
Interface is unnumbered. Using address of FastEthernet0/0 (172.22.66.25)
MTU 1500 bytes, BW 115 Kbit, DLY 100000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, loopback not set, keepalive set (10 sec)
DTR is pulsed for 5 seconds on reset
LCP Open
Open: IPCP
Last input 00:00:02, output never, output hang never
Last clearing of "show interface" counters 3d00h
Queueing strategy: fifo
Output queue 1/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
114 packets input, 9563 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
27 packets output, 864 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
From the tunnel server, display active tunnel statistics by entering the show vpdn command and show vpdn tunnel all command:
ENT_HGW# show vpdn
% No active L2TP tunnels
L2F Tunnel and Session
NAS CLID HGW CLID NAS Name HGW Name State
36 1 ISP_NAS ENT_HGW open
172.22.66.23 172.22.66.25
CLID MID Username Intf State
36 1 jeremy@hgw.com Vi1 open
ENT_HGW# show vpdn tunnel all
% No active L2TP tunnels
L2F Tunnel
NAS name: ISP_NAS
NAS CLID: 36
NAS IP address 172.22.66.23
Gateway name: ENT_HGW
Gateway CLID: 1
Gateway IP address 172.22.66.25
State: open
Packets out: 52
Bytes out: 1799
Packets in: 100
Bytes in: 7143
To display useful information for monitoring and maintaining VPN sessions, use the following commands in privileged EXEC mode:
| Command | Purpose |
|---|---|
Router#show interface virtual access number | Displays information about the virtual access interface, LCP, protocol states, and interface statistics. The status of the virtual access interface should be: " |
Router#show vpdn | Displays a summary of all active VPN tunnels. |
Router#show vpdn domain | Displays all VPN domains and DNIS groups configured on the NAS. |
Router#show vpdn group [name | name domain | name endpoint] | Displays a summary of the relationships among VPDN groups and customer/VPDN profiles. When you include the name of the VPDN group, the output displays information on domain/DNIS, tunnel endpoint, session limits, group priority, active sessions, group status, and reserved sessions. |
Router#show vpdn history failure | Displays information about VPN user failures. |
Router#show vpdn multilink | Displays VPN multilink information. |
Router#show vpdn session [all | packets | sequence | state | timers | window] [interface | tunnel | username] | Displays VPN session information including interface, tunnel, username, packets, status, and window statistics. |
Router#show vpdn tunnel [all | packets | state | summary | transport] [id | local-name | remote-name] | Displays VPN tunnel information including tunnel protocol, ID, local and remote tunnel names, packets sent and received, tunnel, and transport status. |
Troubleshooting components in VPN is not always straightforward because there are multiple technologies and OSI layers involved. To display detailed messages about VPN and VPN-related events, use the following commands in EXEC mode:
| Command | Purpose |
|---|---|
Router#debug ppp negotiation | Displays information about packets sent during PPP startup, and detailed PPP negotiation options. |
Router#debug ppp chap | Displays CHAP packet exchanges. |
Router#debug vpdn error | Displays errors that prevent a tunnel from being established or errors that cause an established tunnel to be closed. |
Router#debug vpdn event | Displays messages about events that are part of normal tunnel establishment or shutdown. |
Router#debug vpdn l2tp-sequencing | Displays message about L2TP tunnel sequencing. |
Router#debug vpdn l2x-data | Display messages about L2F and L2TP data information. |
Router#debug vpdn l2x-errors | Displays L2F and L2TP protocol errors that prevent L2F and L2TP establishment or prevent normal operation. |
Router#debug vpdn l2x-events | Displays messages about events that are part of normal tunnel establishment or shutdown for L2F and L2TP. |
Router#debug vpdn l2x-packets or Router#debug vpdn packet | Displays each protocol packet exchanged. This option may result in a large number of debug messages and should generally only be used on a debug chassis with a single active session. |
This section provides examples of debug output from successful VPN sessions:
Figure 21 shows the topology used for the L2TP dial-in debug example.
The following is debug output from a successful L2TP dial-in session on an NAS for the topology shown in Figure 21:
DJ# debug vpdn event VPDN events debugging is on DJ# debug vpdn l2x-events L2X protocol events debugging is on DJ# show debugging VPN: L2X protocol events debugging is on VPDN events debugging is on DJ# 20:47:33: %LINK-3-UPDOWN: Interface Async7, changed state to up 20:47:35: As7 VPDN: Looking for tunnel -- cisco.com -- 20:47:35: As7 VPDN: Get tunnel info for cisco.com with NAS DJ, IP 172.21.9.13 20:47:35: As7 VPDN: Forward to address 172.21.9.13 20:47:35: As7 VPDN: Forwarding... 20:47:35: As7 VPDN: Bind interface direction=1 20:47:35: Tnl/Cl 8/1 L2TP: Session FS enabled 20:47:35: Tnl/Cl 8/1 L2TP: Session state change from idle to wait-for-tunnel 20:47:35: As7 8/1 L2TP: Create session 20:47:35: Tnl 8 L2TP: SM State idle 20:47:35: Tnl 8 L2TP: Tunnel state change from idle to wait-ctl-reply 20:47:35: Tnl 8 L2TP: SM State wait-ctl-reply 20:47:35: As7 VPDN: kath@cisco.com is forwarded 20:47:35: Tnl 8 L2TP: Got a challenge from remote peer, DJ 20:47:35: Tnl 8 L2TP: Got a response from remote peer, DJ 20:47:35: Tnl 8 L2TP: Tunnel Authentication success 20:47:35: Tnl 8 L2TP: Tunnel state change from wait-ctl-reply to established 20:47:35: Tnl 8 L2TP: SM State established 20:47:35: As7 8/1 L2TP: Session state change from wait-for-tunnel to wait-reply 20:47:35: As7 8/1 L2TP: Session state change from wait-reply to established 20:47:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async7, changed state to up
The following is debug output from a successful L2TP dial-in session on a tunnel server for the topology shown in Figure 21:
tunnel# debug vpdn l2x-events L2X protocol events debugging is on 20:19:17: L2TP: I SCCRQ from DJ tnl 8 20:19:17: L2X: Never heard of DJ 20:19:17: Tnl 7 L2TP: New tunnel created for remote DJ, address 172.21.9.4 20:19:17: Tnl 7 L2TP: Got a challenge in SCCRQ, DJ 20:19:17: Tnl 7 L2TP: Tunnel state change from idle to wait-ctl-reply 20:19:17: Tnl 7 L2TP: Got a Challenge Response in SCCCN from DJ 20:19:17: Tnl 7 L2TP: Tunnel Authentication success 20:19:17: Tnl 7 L2TP: Tunnel state change from wait-ctl-reply to established 20:19:17: Tnl 7 L2TP: SM State established 20:19:17: Tnl/Cl 7/1 L2TP: Session FS enabled 20:19:17: Tnl/Cl 7/1 L2TP: Session state change from idle to wait-for-tunnel 20:19:17: Tnl/Cl 7/1 L2TP: New session created 20:19:17: Tnl/Cl 7/1 L2TP: O ICRP to DJ 8/1 20:19:17: Tnl/Cl 7/1 L2TP: Session state change from wait-for-tunnel to wait-connect 20:19:17: Tnl/Cl 7/1 L2TP: Session state change from wait-connect to established 20:19:17: Vi1 VPDN: Virtual interface created for kath@cisco.com 20:19:17: Vi1 VPDN: Set to Async interface 20:19:17: Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking 20:19:18: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up 20:19:18: Vi1 VPDN: Bind interface direction=2 20:19:18: Vi1 VPDN: PPP LCP accepting rcv CONFACK 20:19:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
The following is an example of debug output from the debug vpdn event, debug vpdn error, and debug dialer events commands for a successful dial-out session on an NAS:
NAS# debug dialer events Dial on demand events debugging is on NAS# show debugging Dial on demand: Dial on demand events debugging is on VPN: L2X protocol events debugging is on VPDN events debugging is on NAS# *Mar 1 00:05:26.155:%SYS-5-CONFIG_I:Configured from console by console *Mar 1 00:05:26.899:%SYS-5-CONFIG_I:Configured from console by console *Mar 1 00:05:36.195:L2TP:I SCCRQ from lns_l2x0 tnl 1 *Mar 1 00:05:36.199:Tnl 1 L2TP:New tunnel created for remote lns_l2x0, address 10.40.1.150 *Mar 1 00:05:36.203:Tnl 1 L2TP:Got a challenge in SCCRQ, lns_l2x0 *Mar 1 00:05:36.207:Tnl 1 L2TP:O SCCRP to lns_l2x0 tnlid 1 *Mar 1 00:05:36.215:Tnl 1 L2TP:Tunnel state change from idle to wait-ctl-reply *Mar 1 00:05:36.231:Tnl 1 L2TP:I SCCCN from lns_l2x0 tnl 1 *Mar 1 00:05:36.235:Tnl 1 L2TP:Got a Challenge Response in SCCCN from lns_l2x0 *Mar 1 00:05:36.239:Tnl 1 L2TP:Tunnel Authentication success *Mar 1 00:05:36.239:Tnl 1 L2TP:Tunnel state change from wait-ctl-reply to established *Mar 1 00:05:36.243:Tnl 1 L2TP:SM State established *Mar 1 00:05:36.251:Tnl 1 L2TP:I OCRQ from lns_l2x0 tnl 1 *Mar 1 00:05:36.255:Tnl/Cl 1/1 L2TP:Session sequencing disabled *Mar 1 00:05:36.259:Tnl/Cl 1/1 L2TP:Session FS enabled *Mar 1 00:05:36.259:Tnl/Cl 1/1 L2TP:New session created *Mar 1 00:05:36.263:12C:Same state, 0 *Mar 1 00:05:36.267:DSES 12C:Session create *Mar 1 00:05:36.271:L2TP:Send OCRP *Mar 1 00:05:36.275:Tnl/Cl 1/1 L2TP:Session state change from idle to wait-cs-answer *Mar 1 00:05:36.279:DSES 0x12C:Building dialer map *Mar 1 00:05:36.283:Dialout 0x12C:Next hop name is 71014 *Mar 1 00:05:36.287:Serial0:23 DDR:rotor dialout [priority] *Mar 1 00:05:36.291:Serial0:23 DDR:Dialing cause dialer session 0x12C *Mar 1 00:05:36.291:Serial0:23 DDR:Attempting to dial 71014 *Mar 1 00:05:36.479:%LINK-3-UPDOWN:Interface Serial0:22, changed state to up *Mar 1 00:05:36.519:isdn_call_connect:Calling lineaction of Serial0:22 *Mar 1 00:05:36.519:Dialer0:Session free, 12C *Mar 1 00:05:36.523::0 packets unqueued and discarded *Mar 1 00:05:36.527:Se0:22 VPDN:Bind interface direction=1 *Mar 1 00:05:36.531:Se0:22 1/1 L2TP:Session state change from wait-cs-answer to established *Mar 1 00:05:36.531:L2TP:Send OCCN *Mar 1 00:05:36.539:Se0:22 VPDN:bound to vpdn session *Mar 1 00:05:36.555:Se0:22 1/1 L2TP:O FS failed *Mar 1 00:05:36.555:Se0:22 1/1 L2TP:O FS failed *Mar 1 00:05:42.515:%ISDN-6-CONNECT:Interface Serial0:22 is now connected to 71014
The following is an example of debug output from the debug vpdn event, debug vpdn error, debug ppp chap, debug ppp negotiation, and debug dialer events commands for a successful dial-out session on a tunnel server:
LNS# debug dialer events Dial on demand events debugging is on LNS# debug ppp negotiation PPP protocol negotiation debugging is on LNS# debug ppp chap PPP authentication debugging is on LNS# show debugging Dial on demand: Dial on demand events debugging is on PPP: PPP authentication debugging is on PPP protocol negotiation debugging is on VPN: VPDN events debugging is on VPDN errors debugging is on LNS# *Apr 22 19:48:32.419:%SYS-5-CONFIG_I:Configured from console by console *Apr 22 19:48:32.743:%SYS-5-CONFIG_I:Configured from console by console *Apr 22 19:48:33.243:Di0 DDR:dialer_fsm_idle() *Apr 22 19:48:33.271:Vi1 PPP:Phase is DOWN, Setup *Apr 22 19:48:33.279:Vi1 PPP:Phase is DOWN, Setup *Apr 22 19:48:33.279:Virtual-Access1 DDR:Dialing cause ip (s=10.60.1.160, d=10.10.1.110) *Apr 22 19:48:33.279:Virtual-Access1 DDR:Attempting to dial 71014 *Apr 22 19:48:33.279:Tnl/Cl 1/1 L2TP:Session sequencing disabled *Apr 22 19:48:33.279:Tnl/Cl 1/1 L2TP:Session FS enabled *Apr 22 19:48:33.283:Tnl/Cl 1/1 L2TP:Session state change from idle to wait-for-tunnel *Apr 22 19:48:33.283:Tnl/Cl 1/1 L2TP:Create dialout session *Apr 22 19:48:33.283:Tnl 1 L2TP:SM State idle *Apr 22 19:48:33.283:Tnl 1 L2TP:O SCCRQ *Apr 22 19:48:33.283:Tnl 1 L2TP:Tunnel state change from idle to wait-ctl-reply *Apr 22 19:48:33.283:Tnl 1 L2TP:SM State wait-ctl-reply *Apr 22 19:48:33.283:Vi1 VPDN:Bind interface direction=2 *Apr 22 19:48:33.307:Tnl 1 L2TP:I SCCRP from lac_l2x0 *Apr 22 19:48:33.307:Tnl 1 L2TP:Got a challenge from remote peer, lac_l2x0 *Apr 22 19:48:33.307:Tnl 1 L2TP:Got a response from remote peer, lac_l2x0 *Apr 22 19:48:33.311:Tnl 1 L2TP:Tunnel Authentication success *Apr 22 19:48:33.311:Tnl 1 L2TP:Tunnel state change from wait-ctl-reply to established *Apr 22 19:48:33.311:Tnl 1 L2TP:O SCCCN to lac_l2x0 tnlid 1 *Apr 22 19:48:33.311:Tnl 1 L2TP:SM State established *Apr 22 19:48:33.311:L2TP:O OCRQ *Apr 22 19:48:33.311:Vi1 1/1 L2TP:Session state change from wait-for-tunnel to wait-reply *Apr 22 19:48:33.367:Vi1 1/1 L2TP:I OCRP from lac_l2x0 tnl 1, cl 0 *Apr 22 19:48:33.367:Vi1 1/1 L2TP:Session state change from wait-reply to wait-connect *Apr 22 19:48:33.631:Vi1 1/1 L2TP:I OCCN from lac_l2x0 tnl 1, cl 1 *Apr 22 19:48:33.631:Vi1 1/1 L2TP:Session state change from wait-connect to established *Apr 22 19:48:33.631:Vi1 VPDN:Connection is up, start LCP negotiation now *Apr 22 19:48:33.631:%LINK-3-UPDOWN:Interface Virtual-Access1, changed state to up *Apr 22 19:48:33.631:Vi1 DDR:dialer_statechange(), state=4Dialer statechange to up Virtual-Access1 *Apr 22 19:48:33.631:Vi1 DDR:dialer_out_call_connected() *Apr 22 19:48:33.631:Vi1 DDR:dialer_bind_profile() to Di0 *Apr 22 19:48:33.631:%DIALER-6-BIND:Interface Virtual-Access1 bound to profile Dialer0Dialer call has been placed Virtual-Access1 *Apr 22 19:48:33.635:Vi1 PPP:Treating connection as a callout *Apr 22 19:48:33.635:Vi1 PPP:Phase is ESTABLISHING, Active Open *Apr 22 19:48:33.635:Vi1 LCP:O CONFREQ [Closed] id 1 len 15 *Apr 22 19:48:33.635:Vi1 LCP: AuthProto CHAP (0x0305C22305) *Apr 22 19:48:33.635:Vi1 LCP: MagicNumber 0x50E7EC2A (0x050650E7EC2A) *Apr 22 19:48:33.663:Vi1 LCP:I CONFREQ [REQsent] id 1 len 15 *Apr 22 19:48:33.663:Vi1 LCP: AuthProto CHAP (0x0305C22305) *Apr 22 19:48:33.663:Vi1 LCP: MagicNumber 0x10820474 (0x050610820474) *Apr 22 19:48:33.663:Vi1 LCP:O CONFACK [REQsent] id 1 len 15 *Apr 22 19:48:33.663:Vi1 LCP: AuthProto CHAP (0x0305C22305) *Apr 22 19:48:33.663:Vi1 LCP: MagicNumber 0x10820474 (0x050610820474) *Apr 22 19:48:33.663:Vi1 LCP:I CONFACK [ACKsent] id 1 len 15 *Apr 22 19:48:33.663:Vi1 LCP: AuthProto CHAP (0x0305C22305) *Apr 22 19:48:33.663:Vi1 LCP: MagicNumber 0x50E7EC2A (0x050650E7EC2A) *Apr 22 19:48:33.663:Vi1 LCP:State is Open *Apr 22 19:48:33.663:Vi1 PPP:Phase is AUTHENTICATING, by both *Apr 22 19:48:33.663:Vi1 CHAP:Using alternate hostname lns0 *Apr 22 19:48:33.663:Vi1 CHAP:O CHALLENGE id 1 len 25 from "lns0" *Apr 22 19:48:33.679:Vi1 CHAP:I CHALLENGE id 1 len 35 from "user0@foo.com0" *Apr 22 19:48:33.679:Vi1 AUTH:Started process 0 pid 92 *Apr 22 19:48:33.679:Vi1 CHAP:Using alternate hostname lns0 *Apr 22 19:48:33.683:Vi1 CHAP:O RESPONSE id 1 len 25 from "lns0" *Apr 22 19:48:33.695:Vi1 CHAP:I SUCCESS id 1 len 4 *Apr 22 19:48:33.699:Vi1 CHAP:I RESPONSE id 1 len 35 from "user0@foo.com0" *Apr 22 19:48:33.699:Vi1 CHAP:O SUCCESS id 1 len 4 *Apr 22 19:48:33.699:Vi1 DDR:dialer_remote_name() for user0@foo.com0 *Apr 22 19:48:33.699:Vi1 PPP:Phase is UP *Apr 22 19:48:33.703:Vi1 IPCP:O CONFREQ [Closed] id 1 len 10 *Apr 22 19:48:33.703:Vi1 IPCP: Address 10.20.1.150 (0x030614140196) *Apr 22 19:48:33.703:Vi1 CCP:O CONFREQ [Closed] id 1 len 10 *Apr 22 19:48:33.703:Vi1 CCP: LZSDCP history 1 check mode SEQ process UNCOMPRESSSED (0x170600010201) *Apr 22 19:48:33.711:Vi1 IPCP:I CONFREQ [REQsent] id 1 len 10 *Apr 22 19:48:33.715:Vi1 IPCP: Address 10.20.1.120 (0x030614140178) *Apr 22 19:48:33.715:Vi1 IPCP:O CONFACK [REQsent] id 1 len 10 *Apr 22 19:48:33.715:Vi1 IPCP: Address 10.20.1.120 (0x030614140178) *Apr 22 19:48:33.715:Vi1 CCP:I CONFREQ [REQsent] id 1 len 10 *Apr 22 19:48:33.715:Vi1 CCP: LZSDCP history 1 check mode SEQ process UNCOMPRESSSED (0x170600010201) *Apr 22 19:48:33.715:Vi1 CCP:O CONFACK [REQsent] id 1 len 10 *Apr 22 19:48:33.715:Vi1 CCP: LZSDCP history 1 check mode SEQ process UNCOMPRESSSED (0x170600010201) *Apr 22 19:48:33.719:Vi1 IPCP:I CONFACK [ACKsent] id 1 len 10 *Apr 22 19:48:33.719:Vi1 IPCP: Address 10.20.1.150 (0x030614140196) *Apr 22 19:48:33.719:Vi1 IPCP:State is Open *Apr 22 19:48:33.719:Vi1 DDR:Dialer protocol up *Apr 22 19:48:33.719:Dialer0:dialer_ckt_swt_client_connect:incoming circuit switched call *Apr 22 19:48:33.719:Di0 IPCP:Install route to 10.20.1.120 *Apr 22 19:48:33.719:Vi1 CCP:I CONFACK [ACKsent] id 1 len 10 *Apr 22 19:48:33.719:Vi1 CCP: LZSDCP history 1 check mode SEQ process UNCOMPRESSSED (0x170600010201) *Apr 22 19:48:33.719:Vi1 CCP:State is Open *Apr 22 19:48:34.699:%LINEPROTO-5-UPDOWN:Line protocol on Interface Virtual-Access1, changed state to up
This section describes a methodology for troubleshooting the VPN shown in Figure 22. First, view the debug output from a successful call. If your debug output does not match the successful output, follow the remaining steps to begin troubleshooting the network. The bolded lines of debug output indicate important information.
If you are accessing the NAS and tunnel server through a Telnet connection, you need to enable the terminal monitor command. This command ensures that your EXEC session is receiving the logging and debug output from the devices.
When you finish troubleshooting, use the undebug all command to turn off all debug commands. Isolating debug output helps you efficiently build a network.
Enable the debug vpdn-event command on both the NAS and the tunnel server and dial in to the NAS. The following debug output shows successful VPN negotiation on the NAS and tunnel server:
ISP_NAS# Jan 7 00:19:35.900: %LINK-3-UPDOWN: Interface Async9, changed state to up Jan 7 00:19:39.532: sVPDN: Got DNIS string As9 Jan 7 00:19:39.532: As9 VPDN: Looking for tunnel -- hgw.com -- Jan 7 00:19:39.540: As9 VPDN: Get tunnel info for hgw.com with NAS ISP_NAS, IP172.22.66.25 Jan 7 00:19:39.540: As9 VPDN: Forward to address 172.22.66.25 Jan 7 00:19:39.540: As9 VPDN: Forwarding... Jan 7 00:19:39.540: As9 VPDN: Bind interface direction=1 Jan 7 00:19:39.540: As9 VPDN: jeremy@hgw.com is forwarded Jan 7 00:19:40.540: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async9, changed state to up ENT_HGW# Jan 7 00:19:39.967: VPDN: Chap authentication succeeded for ISP_NAS Jan 7 00:19:39.967: Vi1 VPDN: Virtual interface created for jeremy@hgw.com Jan 7 00:19:39.967: Vi1 VPDN: Set to Async interface Jan 7 00:19:39.971: Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking 6w5d: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up Jan 7 00:19:40.051: Vi1 VPDN: Bind interface direction=2 Jan 7 00:19:40.051: Vi1 VPDN: PPP LCP accepted rcv CONFACK Jan 7 00:19:40.051: Vi1 VPDN: PPP LCP accepted sent CONFACK 6w5d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
If you see the debug output shown but cannot ping the tunnel server, go to the next section, "Troubleshooting PPP Negotiation."
If you do not see the above debug output, go to the section "Troubleshooting VPN Negotiation" later in this chapter.
The following sections describe several common misconfigurations that prevent successful VPN (either L2F or L2TP) negotiation:
The NAS and the tunnel server must both have the same usernames with the same password to authenticate the L2F tunnel. These usernames are called the tunnel secret. In this scenario, these usernames are ISP_NAS and ENT_HGW. The password is cisco for both usernames on both systems.
If one of the tunnel secrets on the NAS is incorrect, you will see the following debug output when you dial in to the NAS and the debug vpdn l2x-errors command is enabled on the NAS and tunnel server:
ISP_NAS# Jan 1 00:26:49.899: %LINK-3-UPDOWN: Interface Async3, changed state to up Jan 1 00:26:54.643: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async3, cha nged state to up Jan 1 00:27:00.559: L2F: Resending L2F_OPEN, time #1 Jan 1 00:27:05.559: L2F: Resending L2F_ECHO, time #1 Jan 1 00:27:05.559: L2F: Resending L2F_OPEN, time #2 Jan 1 00:27:10.559: L2F: Resending L2F_ECHO, time #2 Jan 1 00:27:10.559: L2F: Resending L2F_OPEN, time #3 Jan 1 00:27:15.559: L2F: Resending L2F_ECHO, time #3 Jan 1 00:27:15.559: L2F: Resending L2F_OPEN, time #4 Jan 1 00:27:20.559: L2F: Resending L2F_ECHO, time #4 Jan 1 00:27:20.559: L2F: Resending L2F_OPEN, time #5 Jan 1 00:27:25.559: L2F: Resending L2F_ECHO, time #5 Jan 1 00:27:25.559: L2F: Resend packet (type 2) around too long, time to kill off the tunnel ISP_NAS# ENT_HGW# Jan 1 00:26:53.645: L2F: Packet has bogus2 key C8353FAB B6369121 5w6d: %VPDN-6-AUTHENFAIL: L2F HGW , authentication failure for tunnel ISP_NAS; Invalid key 5w6d: %VPDN-5-UNREACH: L2F NAS 172.22.66.23 is unreachable Jan 1 00:27:00.557: L2F: Gateway received tunnel OPEN while in state closed ENT_HGW#
The phrase "time to kill off the tunnel" in the NAS debug output indicates that the tunnel was not opened. The phrase "Packet has bogus2 key" in the tunnel server debug output indicates that the NAS has an incorrect tunnel secret.
To avoid this problem, make sure that you configure both the NAS and tunnel server for the same two tunnel secret usernames with the same password.
If one of the tunnel secret usernames on the tunnel server is incorrect, the following debug output appears when you dial in to the NAS and the debug vpdn l2x-errors command is enabled on the NAS and tunnel server:
ISP_NAS# Jan 1 00:45:27.123: %LINK-3-UPDOWN: Interface Async7, changed state to up Jan 1 00:45:30.939: L2F: Packet has bogus1 key B6C656EE 5FAC6B3 Jan 1 00:45:30.939: %VPDN-6-AUTHENFAIL: L2F NAS ISP_NAS, authentication failure for tunnel ENT_HGW; Invalid key Jan 1 00:45:31.935: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async7, cha nged state to up Jan 1 00:45:35.559: L2F: Resending L2F_OPEN, time #1 Jan 1 00:45:35.559: L2F: Packet has bogus1 key B6C656EE 5FAC6B3 ENT_HGW# Jan 1 00:45:30.939: L2F: Tunnel authentication succeeded for ISP_NAS Jan 1 00:45:35.559: L2F: Gateway received tunnel OPEN while in state open Jan 1 00:45:40.559: L2F: Gateway received tunnel OPEN while in state open Jan 1 00:45:45.559: L2F: Gateway received tunnel OPEN while in state open Jan 1 00:45:50.559: L2F: Gateway received tunnel OPEN while in state open
Notice how this output is similar to the debug output you see when the NAS has a misconfigured tunnel secret username. This time you see the phrase "Packet has bogus1 key" on the NAS instead of the tunnel server. This tells you that the tunnel server has an incorrect tunnel secret username.
To avoid this problem, make sure that you configure both the NAS and tunnel server for the same two tunnel secret usernames with the same password.
If the NAS and tunnel server do not have matching tunnel names, they cannot establish an L2F tunnel. On the tunnel server, these tunnel names are configured under the vpdn-group 1 command by using the local name command. On the NAS, these names are configured on the RADIUS server.
The tunnel server must be configured to accept tunnels from the name the NAS sends it. This is done using the accept dialin l2f virtual-template 1 remote ISP_NAS command, where ISP_NAS is the name. The name it returns to the NAS is configured using the local name ENT_HGW command, where ENT_HGW is the name. These commands appear in the following running configuration:
vpdn-group 1 accept dialin l2f virtual-template 1 remote ISP_NAS local name ENT_HGW
On the RADIUS server, the tunnel names are configured by adding profiles to the NAS_Group group with the names ISP_NAS and ENT_HGW.
In the following debug output, the NAS attempted to open a tunnel using the name isp. Because the tunnel server did not know this name, it did not open the tunnel. To see the following debug output, enable the debug vpdn l2x-events and debug vpdn l2x-errors commands on the tunnel server:
ENT_HGW# Jan 1 01:28:54.207: L2F: L2F_CONF received Jan 1 01:28:54.207: L2X: Never heard of isp Jan 1 01:28:54.207: L2F: Couldn't find tunnel named isp
To avoid the problem described, make sure that the tunnel names match on the tunnel server and on the RADIUS server.
The following example assumes that you suspect an error in parsing control packets. You can use the debug vpdn packet using the control keyword to verify control packet information.
debug vpdn packet control
20:50:27: %LINK-3-UPDOWN: Interface Async7, changed state to up
20:50:29: Tnl 9 L2TP: O SCCRQ
20:50:29: Tnl 9 L2TP: O SCCRQ, flg TLF, ver 2, len 131, tnl 0, cl 0, ns 0, nr 0
20:50:29: contiguous buffer, size 131
C8 02 00 83 00 00 00 00 00 00 00 00 80 08 00 00
00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00
00 03 00 00 00 03 80 0A 00 00 00 04 00 00 00 ...
20:50:29: Tnl 9 L2TP: Parse AVP 0, len 8, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Parse SCCRP
20:50:29: Tnl 9 L2TP: Parse AVP 2, len 8, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Protocol Ver 256
20:50:29: Tnl 9 L2TP: Parse AVP 3, len 10, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Framing Cap 0x0x3
20:50:29: Tnl 9 L2TP: Parse AVP 4, len 10, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Bearer Cap 0x0x3
20:50:29: Tnl 9 L2TP: Parse AVP 6, len 8, flag 0x0x0
20:50:29: Tnl 9 L2TP: Firmware Ver 0x0x1120
20:50:29: Tnl 9 L2TP: Parse AVP 7, len 12, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Hostname DJ
20:50:29: Tnl 9 L2TP: Parse AVP 8, len 25, flag 0x0x0
20:50:29: Tnl 9 L2TP: Vendor Name Cisco Systems, Inc.
20:50:29: Tnl 9 L2TP: Parse AVP 9, len 8, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Assigned Tunnel ID 8
20:50:29: Tnl 9 L2TP: Parse AVP 10, len 8, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Rx Window Size 4
20:50:29: Tnl 9 L2TP: Parse AVP 11, len 22, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Chlng D807308D106259C5933C6162ED3A1689
20:50:29: Tnl 9 L2TP: Parse AVP 13, len 22, flag 0x0x8000 (M)
20:50:29: Tnl 9 L2TP: Chlng Resp 9F6A3C70512BD3E2D44DF183C3FFF2D1
20:50:29: Tnl 9 L2TP: No missing AVPs in SCCRP
20:50:29: Tnl 9 L2TP: Clean Queue packet 0
20:50:29: Tnl 9 L2TP: I SCCRP, flg TLF, ver 2, len 153, tnl 9, cl 0, ns 0, nr 1
contiguous pak, size 153
C8 02 00 99 00 09 00 00 00 00 00 01 80 08 00 00
00 00 00 02 80 08 00 00 00 02 01 00 80 0A 00 00
00 03 00 00 00 03 80 0A 00 00 00 04 00 00 00 ...
20:50:29: Tnl 9 L2TP: I SCCRP from DJ
20:50:29: Tnl 9 L2TP: O SCCCN to DJ tnlid 8
20:50:29: Tnl 9 L2TP: O SCCCN, flg TLF, ver 2, len 42, tnl 8, cl 0, ns 1, nr 1
20:50:29: contiguous buffer, size 42
C8 02 00 2A 00 08 00 00 00 01 00 01 80 08 00 00
00 00 00 03 80 16 00 00 00 0D 4B 2F A2 50 30 13
E3 46 58 D5 35 8B 56 7A E9 85
20:50:29: As7 9/1 L2TP: O ICRQ to DJ 8/0
20:50:29: As7 9/1 L2TP: O ICRQ, flg TLF, ver 2, len 48, tnl 8, cl 0, ns 2, nr 1
20:50:29: contiguous buffer, size 48
C8 02 00 30 00 08 00 00 00 02 00 01 80 08 00 00
00 00 00 0A 80 08 00 00 00 0E 00 01 80 0A 00 00
00 0F 00 00 00 04 80 0A 00 00 00 12 00 00 00 ...
20:50:29: Tnl 9 L2TP: Clean Queue packet 1
20:50:29: Tnl 9 L2TP: Clean Queue packet 2
20:50:29: Tnl 9 L2TP: I ZLB ctrl ack, flg TLF, ver 2, len 12, tnl 9, cl 0, ns 1, nr 2
contiguous pak, size 12
C8 02 00 0C 00 09 00 00 00 01 00 02
20:50:30: As7 9/1 L2TP: Parse AVP 0, len 8, flag 0x0x8000 (M)
20:50:30: As7 9/1 L2TP: Parse ICRP
20:50:30: As7 9/1 L2TP: Parse AVP 14, len 8, flag 0x0x8000 (M)
20:50:30: As7 9/1 L2TP: Assigned Call ID 1
20:50:30: As7 9/1 L2TP: No missing AVPs in ICRP
20:50:30: Tnl 9 L2TP: Clean Queue packet 2
20:50:30: As7 9/1 L2TP: I ICRP, flg TLF, ver 2, len 28, tnl 9, cl 1, ns 1, nr 3
contiguous pak, size 28
C8 02 00 1C 00 09 00 01 00 01 00 03 80 08 00 00
00 00 00 0B 80 08 00 00 00 0E 00 01
20:50:30: As7 9/1 L2TP: O ICCN to DJ 8/1
20:50:30: As7 9/1 L2TP: O ICCN, flg TLF, ver 2, len 203, tnl 8, cl 1, ns 3, nr 2
20:50:30: contiguous buffer, size 203
C8 02 00 CB 00 08 00 01 00 03 00 02 80 08 00 00
00 00 00 0C 80 0A 00 00 00 18 00 00 DA C0 80 0A
00 00 00 13 00 00 00 02 00 28 00 00 00 1B 02 ...
20:50:30: Tnl 9 L2TP: Clean Queue packet 3
20:50:30: As7 9/1 L2TP: I ZLB ctrl ack, flg TLF, ver 2, len 12, tnl 9, cl 1, ns 2, nr 4
contiguous pak, size 12
C8 02 00 0C 00 09 00 01 00 02 00 04
20:50:30: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async7, changed state to up
If you fixed the problem in your configuration, return to the section "Verifying VPN Sessions" earlier in this chapter.
If your call still cannot successfully complete L2F negotiation, contact your support personnel.
This section first shows debug output of successful PPP negotiation. The following section explain several common problems that prevent successful PPP negotiation:
Enable the debug ppp negotiation command on the tunnel server and dial in to the NAS.
The following debug output shows successful PPP negotiation on the tunnel server:
1d02h: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up *Feb 4 14:14:40.505: Vi1 PPP: Treating connection as a dedicated line *Feb 4 14:14:40.505: Vi1 PPP: Phase is ESTABLISHING, Active Open *Feb 4 14:14:40.505: Vi1 PPP: Treating connection as a dedicated line *Feb 4 14:14:40.505: Vi1 PPP: Phase is AUTHENTICATING, by this end *Feb 4 14:14:40.509: Vi1 PPP: Phase is UP
If your call successfully completed PPP negotiation, but you still cannot ping the tunnel server, go to the section "Troubleshooting AAA Negotiation" later in this chapter.
The debug ppp negotiation and debug ppp authentication commands are enabled to decipher a CHAP negotiation problem. This is due to a connectivity problem between a Cisco and non-Cisco device. Also note that the service-timestamps command is enabled on the router. The service-timestamps command is helpful to decipher timing and keepalive issues, and we recommend that you always enable this command.
Router# debug ppp authentication PPP authentication debugging is on Router# debug ppp negotiation PPP protocol negotiation debugging is on 3:22:53: ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/5 3:22:53: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = C6091F. 3:22:55: ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/5 3:22:55: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = C6091F 3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x0 (??) 3:22:55: PPP BRI0: B-Channel 1: rcvd unknown option 0x0 rejected 3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x1 (MRU) value = 0x5 F4 rejected 3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x3 (AUTHTYPE) value = 0xC223 value = 0x5 acked 3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x11 (MULTILINK_MRRU) rejected 3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x13 (UNKNOWN) 3:22:55: PPP BRI0: B-Channel 1: rcvd unknown option 0x13 rejected 3:22:55: ppp: config REJ received, type = 3 (CI_AUTHTYPE), value = C223/5 3:22:55: ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/5 3:22:55: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = C6091F 3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x3 (AUTHTYPE) value= 0xC2. Success rate is 0 percent (0/5) moog#23 value = 0x5 acked 3:22:55: ppp: config REJ received, type = 3 (CI_AUTHTYPE), value = C223/5 3:22:55: ppp: BRI0: B-Channel 1 closing connection because remote won't authenticate 3:22:55: ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/5 3:22:55: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = C6091F 3:22:55: %ISDN-6-DISCONNECT: Interface BRI0: B-Channel 1 disconnected from 0123 5820040 , call lasted 2 seconds 3:22:56: %LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to down Indication:
The following debug ppp chap sample output excerpt shows a CHAP authentication failure because of a configuration mismatch between devices. Verifying and correcting any username and password mismatch should remedy this problem.
Router# debug ppp chap ppp: received conf.ig for type = 5 (MAGICNUMBER) value = 1E24718 acked PPP BRI0: B-Channel 1: state = ACKSENT fsm_rconfack(C021): rcvd id E6 ppp: config ACK received, type = 3 (CI_AUTHTYPE), value = C223 ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 28CEF76C BRI0: B-Channel 1: PPP AUTH CHAP input code = 1 id = 83 len = 16 BRI0: B-Channel 1: PPP AUTH CHAP input code = 2 id = 96 len = 28 BRI0: B-Channel 1: PPP AUTH CHAP input code = 4 id = 83 len = 21 BRI0: B-Channel 1: Failed CHAP authentication with remote. Remote message is: MD compare failed
If your call cannot successfully complete PPP negotiation, contact your support personnel.
This section first shows debug output of successful AAA negotiation. The following sections then explain several common misconfigurations that prevent successful AAA negotiation:
Enable the debug aaa authentication and debug aaa authorization commands on the tunnel server and dial in to the NAS.
The following debug output shows successful AAA negotiation on the tunnel server. This output has been edited to exclude repetitive lines.
ENT_HGW# Jan 7 19:29:44.132: AAA/AUTHEN: create_user (0x612D550C) user='ENT_HGW' ruser=' ' port='' rem_addr='' authen_type=CHAP service=PPP priv=1 Jan 7 19:29:44.132: AAA/AUTHEN/START (384300079): port='' list='default' action =SENDAUTH service=PPP Jan 7 19:29:44.132: AAA/AUTHEN/START (384300079): found list default Jan 7 19:29:44.132: AAA/AUTHEN/START (384300079): Method=LOCAL Jan 7 19:29:44.132: AAA/AUTHEN (384300079): status = PASS Jan 7 19:29:44.132: AAA/AUTHEN: create_user (0x612D550C) user='ISP_NAS' ruser=' ' port='' rem_addr='' authen_type=CHAP service=PPP priv=1 Jan 7 19:29:44.132: AAA/AUTHEN/START (2545876944): port='' list='default' actio n=SENDAUTH service=PPP Jan 7 19:29:44.132: AAA/AUTHEN/START (2545876944): found list default Jan 7 19:29:44.132: AAA/AUTHEN/START (2545876944): Method=LOCAL Jan 7 19:29:44.132: AAA/AUTHEN (2545876944): status = PASS Jan 7 19:29:44.228: AAA/AUTHEN: create_user (0x612F1F78) user='jeremy@hgw.com' ruser='' port='Virtual-Access1' rem_addr='408/5550945' authen_type=CHAP service= PPP priv=1 Jan 7 19:29:44.228: AAA/AUTHEN/START (101773535): port='Virtual-Access1' list='' action=LOGIN service=PPP Jan 7 19:29:44.228: AAA/AUTHEN/START (101773535): using "default" list Jan 7 19:29:44.228: AAA/AUTHEN/START (101773535): Method=LOCAL Jan 7 19:29:44.228: AAA/AUTHEN (101773535): status = ERROR Jan 7 19:29:44.228: AAA/AUTHEN/START (101773535): Method=RADIUS Jan 7 19:29:44.692: AAA/AUTHEN (101773535): status = PASS Jan 7 19:29:44.692: Vi1 AAA/AUTHOR/LCP: Authorize LCP Jan 7 19:29:44.692: AAA/AUTHOR/LCP Vi1 (3630870259): Port='Virtual-Access1' list='' service=NET Jan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) user='jeremy@hgw.com' Jan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) send AV service=ppp Jan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) send AV protocol=lcp Jan 7 19:29:44.692: AAA/AUTHOR/LCP (3630870259) found list "default" Jan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) Method=RADIUS Jan 7 19:29:44.692: AAA/AUTHOR (3630870259): Post authorization status = PASS_REPL Jan 7 19:29:44.696: Vi1 AAA/AUTHOR/FSM: We can start IPCP 6w5d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up Jan 7 19:29:47.792: Vi1 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want 172.30.2.1
If the above debug output appears, but you still cannot ping the tunnel server, contact your support personnel and troubleshoot your network backbone.
If you did not see the debug output above, you need to troubleshoot AAA negotiation.
If the user password is incorrect (or it is incorrectly configured), the tunnel will be established, but the tunnel server will not authenticate the user. If the user password is incorrect, the following debug output appears on the NAS and tunnel server when you dial in to the NAS and the debug vpdn l2x-errors and debug vpdn l2x-events commands are enabled:
ISP_NAS# Jan 1 01:00:01.555: %LINK-3-UPDOWN: Interface Async12, changed state to up Jan 1 01:00:05.299: L2F: Tunnel state closed Jan 1 01:00:05.299: L2F: MID state closed Jan 1 01:00:05.299: L2F: Open UDP socket to 172.22.66.25 Jan 1 01:00:05.299: L2F: Tunnel state opening Jan 1 01:00:05.299: As12 L2F: MID jeremy@hgw.com state waiting_for_tunnel Jan 1 01:00:05.303: L2F: L2F_CONF received Jan 1 01:00:05.303: L2F: Removing resend packet (L2F_CONF) Jan 1 01:00:05.303: ENT_HGW L2F: Tunnel state open Jan 1 01:00:05.307: L2F: L2F_OPEN received Jan 1 01:00:05.307: L2F: Removing resend packet (L2F_OPEN) Jan 1 01:00:05.307: L2F: Building nas2gw_mid0 Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: CLID/DNIS 4089548021/5550945 Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: NAS-Port Async12 Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: Client-Bandwidth-Kbps 115 Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: NAS-Rate L2F/26400/28800 Jan 1 01:00:05.307: As12 L2F: MID jeremy@hgw.com state opening Jan 1 01:00:05.307: L2F: Tunnel authentication succeeded for ENT_HGW Jan 1 01:00:05.391: L2F: L2F_OPEN received Jan 1 01:00:05.391: L2F: Got a MID management packet Jan 1 01:00:05.391: L2F: Removing resend packet (L2F_OPEN) Jan 1 01:00:05.391: As12 L2F: MID jeremy@hgw.com state open Jan 1 01:00:05.391: As12 L2F: MID synced NAS/HG Clid=47/12 Mid=1 Jan 1 01:00:05.523: L2F: L2F_CLOSE received Jan 1 01:00:05.523: %VPDN-6-AUTHENERR: L2F HGW ENT_HGW cannot locate a AAA server for As12 user jeremy@hgw.com; Authentication failure ENT_HGW# Jan 1 01:00:05.302: L2F: L2F_CONF received Jan 1 01:00:05.302: L2F: Creating new tunnel for ISP_NAS Jan 1 01:00:05.302: L2F: Tunnel state closed Jan 1 01:00:05.302: L2F: Got a tunnel named ISP_NAS, responding Jan 1 01:00:05.302: L2F: Open UDP socket to 172.22.66.23 Jan 1 01:00:05.302: ISP_NAS L2F: Tunnel state opening Jan 1 01:00:05.306: L2F: L2F_OPEN received Jan 1 01:00:05.306: L2F: Removing resend packet (L2F_CONF) Jan 1 01:00:05.306: ISP_NAS L2F: Tunnel state open Jan 1 01:00:05.306: L2F: Tunnel authentication succeeded for ISP_NAS Jan 1 01:00:05.310: L2F: L2F_OPEN received Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: CLID/DNIS 4089548021/5550945 Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: NAS-Port Async12 Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: Client-Bandwidth-Kbps 115 Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: NAS-Rate L2F/26400/28800 Jan 1 01:00:05.310: L2F: Got a MID management packet Jan 1 01:00:05.310: L2F: MID state closed Jan 1 01:00:05.310: L2F: Start create mid intf process for jeremy@hgw.com 5w6d: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up Jan 1 01:00:05.390: Vi1 L2X: Discarding packet because of no mid/session Jan 1 01:00:05.390: Vi1 L2F: Transfer NAS-Rate L2F/26400/28800 to LCP Jan 1 01:00:05.390: Vi1 L2F: Finish create mid intf for jeremy@hgw.com Jan 1 01:00:05.390: Vi1 L2F: MID jeremy@hgw.com state open 5w6d: %VPDN-6-AUTHENERR: L2F HGW ENT_HGW cannot locate a AAA server for Vi1 user jeremy@hgw.com; Authentication failure
If the aaa authorization command on the tunnel server is configured with the default radius none keywords, the tunnel server may allow unauthorized access to your network.
This command is an instruction to first use RADIUS for authorization. The tunnel server first contacts the RADIUS server (because of the radius keyword). If an error occurs when the tunnel server contacts the RADIUS server, the tunnel server does not authorize the user (because of the none keyword).
To see the following debug output, enable the debug aaa authorization command on the tunnel server and dial in to the NAS:
ENT_HGW# *Feb 5 17:27:36.166: Vi1 AAA/AUTHOR/LCP: Authorize LCP *Feb 5 17:27:36.166: AAA/AUTHOR/LCP Vi1 (3192359105): Port='Virtual-Access1' list='' service=NET *Feb 5 17:27:36.166: AAA/AUTHOR/LCP: Vi1 (3192359105) user='jeremy@hgw.com' *Feb 5 17:27:36.166: AAA/AUTHOR/LCP: Vi1 (3192359105) send AV service=ppp *Feb 5 17:27:36.166: AAA/AUTHOR/LCP: Vi1 (3192359105) send AV protocol=lcp *Feb 5 17:27:36.166: AAA/AUTHOR/LCP (3192359105) found list "default" *Feb 5 17:27:36.166: AAA/AUTHOR/LCP: Vi1 (3192359105) Method=RADIUS *Feb 5 17:27:36.166: AAA/AUTHOR (3192359105): Post authorization status = ERROR *Feb 5 17:27:36.166: AAA/AUTHOR/LCP: Vi1 (3192359105) Method=NONE *Feb 5 17:27:36.166: AAA/AUTHOR (3192359105): Post authorization status = PASS_ADD *Feb 5 17:27:36.166: Vi1 CHAP: O SUCCESS id 1 len 4
 |
Caution Using the none keyword can allow unauthorized access to your network. Because of the risk of such errors occurring, we strongly recommend that you do not use the none keyword in your aaa commands. |
If you reverse the order of the local and radius keywords in the aaa authentication ppp command on the tunnel server, the L2F tunnel cannot be established. The command should be configured as aaa authentication ppp default local radius.
If you configure the command as aaa authentication ppp default radius local, the tunnel server first tries to authenticate the L2F tunnel using RADIUS. The RADIUS server sends the following message to the tunnel server. To see this message, enable the debug radius command.
ENT_HGW# Jan 1 01:34:47.827: RADIUS: SENDPASS not supported (action=4)
The RADIUS protocol does not support inbound challenges. This means that RADIUS is designed to authenticate user information, but it is not designed to be authenticated by others. When the tunnel server requests the tunnel secret from the RADIUS server, it responds with the "SENDPASS not supported" message.
To avoid this problem, use the aaa authentication ppp default local radius command on the tunnel server.
If your call still cannot successfully complete AAA negotiation, contact your support personnel.
This section provides the following configuration examples:
The following examples shows several possibilities for performing local tunnel authentication. These examples only show the information relevant to tunnel authentication.
The following example is for a NAS and tunnel server that configure the tunnel names by using local name VPN group commands. The NAS tunnel name is ISP_NAS, the tunnel server tunnel name is ENT_HGW, and the tunnel secret is tunnelme.
The NAS tunnel name is specified by the local name command. The tunnel server tunnel name and the tunnel secret are specified by the username command.
username ENT_HGW password 7 tunnelme . . . vpdn-group 1 local name ISP_NAS
The tunnel server tunnel name is specified by the local name command. The NAS tunnel name and the tunnel secret are specified by the username command.
username ISP_NAS password 7 tunnelme . . . vpdn-group 1 local name ENT_HGW
The following example is for a NAS and tunnel server that both configure the tunnel secret using the l2tp tunnel password command. Because both routers use this command, they do not need to use either username or local name commands for tunnel authentication. The tunnel secret is tunnelme.
NAS Configuration
vpdn-group 1 request-dialin protocol l2tp l2tp tunnel password tunnelme
Tunnel Server Configuration
vpdn-group 1 accept-dialin protocol l2tp l2tp tunnel password tunnelme
The follow example is for a NAS that uses the username command to specify the tunnel secret and a tunnel server that uses the l2tp tunnel password command to specify the tunnel secret.
NAS Configuration
username adrian password garf1eld . . . vpdn-group 1 local name stella
Tunnel Server Configuration
vpdn-group 1 accept--dialin protocol l2tp local name adrian l2tp tunnel password garf1eld
! Enable AAA authentication and authorization with RADIUS as the default method aaa new-model aaa authentication ppp default radius aaa authorization network default radius ! username ISP_NAS password 7 tunnelme username ENT_HGW password 7 tunnelme ! vpdn enable ! ! Configure VPN to first search on the client domain name and then on the DNIS vpdn search-order domain dnis ! Allow a maximum of 10 simultaneous VPN sessions vpdn session-limit 10 ! ! Configure VPN to initiate VPN dial-in sessions vpdn-group 1 request-dialin ! Specify L2TP as the tunneling protocol protocol l2TP ! Tunnel clients with the domain name "hgw.com" domain hgw.com ! Establish a tunnel with IP address 172.22.66.25 initiate-to ip 172.22.66.25 ! Identify the tunnel using the name "ISP_NAS" local name ISP_NAS ! ! Defines the ISDN switch type as primary-5ess isdn switch-type primary-5ess ! ! Commissions the T1 controller to allow modem calls in to the NAS controller T1 0 framing esf clock source line primary linecode b8zs pri-group timeslots 1-24 ! interface Ethernet0 ip address 172.22.66.23 255.255.255.192 ! ! Configure the Serial channel to allow modem calls in to the NAS interface Serial0:23 no ip address isdn switch-type primary-5ess isdn incoming-voice modem no cdp enable ! ! interface Group-Async1 ip unnumbered Ethernet0 encapsulation ppp async mode interactive no peer default ip address ppp authentication chap pap group-range 1 96 ! ip classless ip route 0.0.0.0 0.0.0.0 172.22.66.1 ! ! Specifies the RADIUS server IP address, authorization port, and accounting port radius-server host 172.22.66.16 auth-port 1645 acct-port 1646 ! Specifies the authentication key to be used with the RADIUS server radius-server key cisco ! line con 0 transport input none ! Configures the modems line 1 96 autoselect during-login autoselect ppp modem InOut line aux 0 line vty 0 4 ! end
The following example show a tunnel server configured to accept L2TP tunnels from an NAS using local authentication and authorization:
aaa new-model ! Configure AAA to first use the local database and then contact the RADIUS server for ! PPP authentication aaa authentication ppp default local radius ! Configure AAA network authorization and accounting by using the RADIUS server aaa authorization network default radius aaa accounting network default start-stop radius ! username ISP_NAS password 7 tunnelme username ENT_HGW password 7 tunnelme ! vpdn enable ! Prevent any new VPN sessions from being established without disturbing existing ! sessions vpdn softshut ! ! Configure VPN to accept dial-in sessions vpdn-group 1 accept-dialin ! Specify L2TP as the tunneling protocol protocol l2tp ! Specify that virtual-access interfaces be cloned from virtual template 1 virtual-template 1 ! Accept dial-in requests from a router using the tunnel name "ISP_NAS" terminate-from hostname ISP_NAS ! Identify the tunnel using the tunnel name "ENT_HGW" local name ENT_HGW ! interface Ethernet0/0 ip address 172.22.66.25 255.255.255.192 no ip directed-broadcast ! interface Virtual-Template1 ! Use the IP address of interface Ethernet 0 ip unnumbered Ethernet0 ! Returns an IP address from the default pool to the VPN client peer default ip address pool default ! Use CHAP to authenticate PPP ppp authentication chap ! ip local pool default 172.30.2.1 172.30.2.96 ip classless ip route 0.0.0.0 0.0.0.0 172.22.66.1 ! ! Specifies the RADIUS server IP address, authorization port, and accounting port radius-server host 172.22.66.13 auth-port 1645 acct-port 1646 ! Specifies the authentication key to be used with the RADIUS server radius-server key cisco
You can configure an NAS to simultaneously initiate L2TP or L2F dial-in tunnels to a tunnel server and also accept L2TP dial-out tunnels from a tunnel server.
In the following example, the VPN group of an NAS is configured to dial in using L2F and dial out using L2TP as the tunneling protocol and dialer interface 2. The example only shows the VPN group and dialer configuration:
vpdn-group 1 request-dialin protocol l2f domain jgb.com accept-dialout protocol l2tp dialer 2 local name cerise terminate-from hostname reuben initiate-to ip 172.1.2.3 ! interface Dialer2 ip unnumbered Ethernet0 encapsulation ppp dialer in-band dialer aaa dialer-group 1 ppp authentication chap
You can configure a tunnel server to simultaneously receive L2TP or L2F dial-in tunnels from an NAS and also initiate L2TP dial-out tunnels to an NAS.
In the following example, a tunnel server VPN group is configured to dial in using virtual template 1 to clone the virtual access interface and dial out using dialer pool 1. The example only shows the VPN group and dialer configuration:
vpdn-group 1 accept-dialin protocol l2tp virtual-template 1 request-dialout protocol l2tp pool-member 1 local name reuben terminate-from hostname cerise initiate-to ip 10.3.2.1 ! interface Dialer2 ip address 172.1.2.3 255.255.128 encapsulation ppp dialer remote-name reuben dialer string 5551234 dialer vpdn dialer pool 1 dialer-group 1 ppp authentication chap
Posted: Wed Sep 13 15:52:13 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.