Configuring Virtual Private Networks
Available Languages
Table Of Contents
Configuring Virtual Private Networks
PPTP Dial-In with MPPE Encryption
L2F Tunnel Authentication Process
VPN Tunnel Authentication Search Order
VPN Tunnel Lookup Based on Domain Name
VPN Tunnel Lookup Based on DNIS Information
VPN Tunnel Lookup Based on Both Domain Name and DNIS Information
NAS AAA Tunnel Definition Lookup
VPN Configuration Modes Overview
Specifying the IP Address Pool and BOOTP Servers on the Tunnel Server
Commissioning the T1 Controllers on the NAS
Configuring the Serial Channels for Modem Calls on the NAS
Configuring the Modems and Asynchronous Lines on the NAS
Configuring the Group-Asynchronous Interface on the NAS
Configuring the Dialer on a NAS
Configuring the Dialer on a Tunnel Server
Configuring VPN Tunnel Authentication Configuration
Disabling VPN Tunnel Authentication for L2TP Tunnels
Configuring VPN Tunnel Authentication Using the Host Name or Local Name
Configuring VPN Tunnel Authentication Using the L2TP Tunnel Password
Configuring Client-Initiated Dial-In VPN
Configuring a Tunnel Server to Accept PPTP Tunnels
Configuring MPPE on the ISA Card
Configuring NAS-Initiated Dial-In VPN
Configuring a NAS to Request Dial-In
Configuring a Tunnel Server to Accept Dial-In
Creating the Virtual Template on the Network Server
Configuring a Tunnel Server to Request Dial-Out
Configuring a NAS to Accept Dial-Out
Configuring Advanced VPN Features
Configuring Advanced Remote AAA Features
Configuring Preservation of IP ToS Field
Limiting the Number of Allowed Simultaneous VPN Sessions
Enabling Soft Shutdown of VPN Tunnels
Setting the History Table Size
Verifying a Client-Initiated VPN
Monitoring and Maintaining VPNs
L2TP Dial-In Debug Output on NAS Example
L2TP Dial-In Debug Output on a Tunnel Server Example
L2TP Dial-Out Debug Output on a NAS Example
L2TP Dial-Out Debug Output on a Tunnel Server Example
VPN Troubleshooting Methodology
Comparing Your Debug Output to the Successful Debug Output
Troubleshooting VPN Negotiation
Troubleshooting PPP Negotiation
Troubleshooting AAA Negotiation
Configuration Examples for VPN
Client-Initiated Dial-In Configuration Example
VPN Tunnel Authentication Examples
Tunnel Secret Configured Using the Local Name Command
Tunnel Secret Configured Using the L2TP Tunnel Password Command
Tunnel Secret Configuration Using Different Tunnel Authentication Methods
NAS Comprehensive Dial-In Configuration Example
Tunnel Server Comprehensive Dial-in Configuration Example
NAS Configured for Both Dial-In and Dial-Out Example
Tunnel Server Configured for Both Dial-In and Dial-Out Example
Configuring Virtual Private Networks
This chapter describes how to configure, verify, maintain, and troubleshoot a Virtual Private Network (VPN). It includes the following main sections:
•
Monitoring and Maintaining VPNs
•
To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature, or refer to the software release notes for a specific release. For more information, see the "Identifying Supported Platforms" section in the "Using Cisco IOS Software" chapter.
For a complete description of the commands mentioned in this chapter, refer to the Cisco IOS Dial Technologies Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
VPN Technology Overview
A VPN carries private data over a public network and 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 VPNs or, more appropriately, 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), the access servers, and the 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 need only 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 savings 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:
•
•
•
Using one of these protocols, an ISP or other access service can create a virtual tunnel to link customer remote sites or remote users with corporate home networks. In particular, a network access server (NAS) at the ISP POP exchanges PPP messages with the remote users and communicates by L2F, L2TP, or PPTP requests and responses with the customer tunnel server to set up tunnels.
L2F, L2TP, and PPTP pass protocol-level packets through the virtual tunnel between endpoints of a point-to-point connection.
Frames from the remote users are accepted by the ISP POP, stripped of any linked framing or transparency bytes, encapsulated in L2F, L2TP or PPTP, and forwarded over the appropriate tunnel. The customer tunnel server accepts these frames, strips the Layer 2 encapsulation, and processes the incoming frames for the appropriate interface.
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.
VPDN MIB
The VPDN MIB offers a mechanism to track failures of user calls in a VPN system, allowing Simple Network Management Protocol (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.
VPN Hardware Terminology
As new tunneling protocols have been developed for VPNs, new terminology has been created to describe the hardware involved in VPNs. Fundamentally, two routers are needed for a VPN:
•
•
For the sake of clarity, we will use these generic terms, and not the technology-specific terms. Table 29 lists the generic terms ant the technology-specific terms that are often used for these devices.
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.
VPN Architectures
VPNs are designed on the basis of one of two architectural options:
•
•
Client-Initiated VPNs
Users establish a tunnel across the ISP shared network to the customer network without an intermediate NAS participating in the tunnel negotiation and establishment. The customer manages the client software that initiates the tunnel. The main advantage of client-initiated VPNs is that they secure the connection between the client and the ISP. However, client-initiated VPNs are not as scalable and are more complex than NAS-initiated VPNs.
Client-initiated VPNs are also referred to as voluntary tunneling.
NAS-Initiated VPNs
Users dial in to the ISP NAS, which establishes a tunnel to the private network. NAS-initiated VPNs are more robust than client-initiated VPNs and do not require the client to maintain the tunnel-creating software. NAS-initiated VPNs do not encrypt the connection between the client and the ISP, but this is not a concern for most customers because the PSTN is much more secure than the Internet.
NAS-initiated VPNs are also referred to as compulsory tunneling.
Note
PPTP Dial-In with MPPE Encryption
PPTP is a network protocol that enables the secure transfer of data from a remote client to a private enterprise server by creating a VPN across TCP/IP-based data networks. PPTP supports on-demand, multiprotocol, virtual private networking over public networks, such as the Internet.
Cisco supports client-initiated VPNs using PPTP. Therefore only the client and the tunnel server need to be configured. The client first establishes basic connectivity by dialing in to an ISP. Once the client has established a PPP session, it initiates a PPTP tunnel to the tunnel server. The tunnel server is configured to terminate PPTP tunnels and clone virtual-access interfaces from virtual templates.
Microsoft Point-to-Point Encryption (MPPE) is an outcropping technology that can be used to encrypt PPTP VPNs. It encrypts the entire session from the client to the tunnel server.
This section describes the following aspects of PPTP and MPPE:
PPTP Tunnel Negotiation
The following describes the protocol negotiation events that establish a PPTP tunnel:
1.
2.
3.
4.
5.
6.
7.
8.
Flow Control Alarm
The flow control alarm is a new function that indicates if PPTP detects congestion or lost packets. When a flow control alarm goes off, PPTP reduces volatility and additional control traffic by establishing an accompanying stateful MPPE session.
For more information, see the pptp flow-control static-rtt command and the output from the show vpdn session command in the "Verifying a Client-Initiated VPN" section.
MPPE Overview
MPPE is an encryption technology developed by Microsoft to encrypt point-to-point links. These PPP connections can be over a dialup line or over a VPN tunnel. MPPE works as a subfeature of Microsoft Point-to-Point Compression (MPPC).
MPPC is a scheme used to compress PPP packets between Cisco and Microsoft client devices. The MPPC algorithm is designed to optimize bandwidth utilization in order to support multiple simultaneous connections.
MPPE is negotiated using bits in the MPPC option within the Compression Control Protocol (CCP) MPPC configuration option (CCP configuration option number 18).
MPPE uses the RC4 algorithm with either 40- or 128-bit keys. All keys are derived from the cleartext authentication password of the user. RC4 is stream cipher; therefore, the sizes of the encrypted and decrypted frames are the same size as the original frame. The Cisco implementation of MPPE is fully interoperable with that of Microsoft and uses all available options, including historyless mode. Historyless mode can increase throughput in lossy environments such as VPNs, because neither side needs to send CCP Resets Requests to synchronize encryption contexts when packets are lost.
MPPE Encryption Types
Two modes of MPPE encryption are offered:
Stateful MPPE Encryption
Stateful encryption provides the best performance but may be adversely affected by networks that experience substantial packet loss. If you choose stateful encryption, you should also configure flow control to minimize the detrimental effects of this lossiness.
Because of the way that the RC4 tables are reinitialized during stateful synchronization, it is possible that two packets may be encrypted using the same key. For this reason, stateful encryption may not be appropriate for lossy network environments (such as Layer 2 tunnels on the Internet).
Stateless MPPE Encryption
Stateless encryption provides a lower level of performance, but will be more reliable in a lossy network environment.
Caution
L2F Dial-In
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 to forward the calls to the customer tunnel server. Usually, the ISP maintains only 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 the tunnel server is reduced to IP connectivity.
Figure 71 shows the PPP link that runs 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.
Figure 71 End-to-End Access VPN Protocol Flow: L2F, PPP, and IP
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 provides an overview of the negotiation events that take place as the VPN is established. The "L2F Tunnel Authentication Process" section provides a detailed description of how the NAS and tunnel server establish the L2F tunnel.
Protocol Negotiation Sequence
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 72 shows the sequence of protocol negotiation events between the ISP NAS and the customer tunnel server.
Figure 72 Protocol Negotiation Events Between Access VPN Devices
The following explains the sequence of events shown in Figure 72:
1.
2.
3.
4.
This configuration instructs the NAS to create a VPN to forward the PPP session to the tunnel server by using an L2F tunnel.
Because this is the first L2F session with the tunnel server, the NAS and the tunnel server exchange L2F_CONF packets, which prepare them to create the tunnel. Then they exchange L2F_OPEN packets, which open the L2F tunnel.
5.
The tunnel server forces this information on to a virtual access interface that it has created for the client and responds to the NAS with an L2F_OPEN (Mid) packet.
6.
7.
The client and the tunnel server can now exchange I/O PPP encapsulated packets. The NAS acts as a transparent PPP frame forwarder.
Subsequent PPP incoming sessions (designated for the same tunnel server) do not repeat the L2F tunnel negotiation because the L2F tunnel is already open.
L2F Tunnel Authentication Process
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 Using the L2TP Tunnel Password" 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 73 shows the tunnel authentication process.
Figure 73 L2F Tunnel Authentication Process
The following explains the sequence of events shown in Figure 73:
1.
2.
3.
4.
5.
6.
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, the NAS and tunnel server need not repeat the L2F tunnel negotiation because the L2F tunnel is already open.
L2TP Dial-In
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 30 offers a comparison of L2F and L2TP feature components.
Traditional dialup networking services support only 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 74 shows the L2TP architecture in a typical dialup environment.
Figure 74 L2TP Architecture
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 remote sites or remote users with corporate home networks. The NAS located at the POP of the ISP exchanges PPP messages with remote users and communicates by way of L2TP requests and responses with the 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 POP of the ISP, stripped of any linked framing or transparency bytes, encapsulated in L2TP and forwarded over the appropriate tunnel. The customer tunnel server accepts these L2TP frames, strips the L2TP encapsulation, and processes the incoming frames for the appropriate interface. Figure 75 shows the L2TP tunnel detail and how user "lsmith" connects to the tunnel server to access the designated corporate intranet.
Figure 75 L2TP Tunnel Structure
Incoming Call Sequence
The following describes the events required to establish 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:
1.
2.
3.
4.
5.
6.
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 76 offers a pictorial account of the L2TP incoming call sequence with its own corresponding sequence numbers. Note that the sequence numbers in Figure 76 are not related to the sequence numbers described in the previous table.
Figure 76 L2TP Incoming Call Flow
VPN Tunnel Authentication Search Order
When a call to a NAS is to be tunneled to a tunnel server, the NAS must identify the tunnel server to which the call is to be forwarded. You can configure the router to authenticate users and also to select the outgoing tunnel on the basis of the following criteria:
•
•
•
VPN Tunnel Lookup Based on Domain Name
When a NAS is configured to forward VPN calls on the basis of 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.
VPN Tunnel Lookup Based on DNIS Information
When a NAS is configured to forward VPN calls on the basis of the user DNIS information, the NAS identifies the user DNIS information, which is provided on ISDN lines, and then forwards the call to the proper tunnel server.
The ability to select a tunnel on the basis of DNIS information provides additional flexibility to network service providers that offer VPN services and to the corporations that use the services. Instead of having to use only the domain name for tunnel selection, tunnel selection can be based on the dialed number.
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 NAS at the service provider POP. The service provider can select the tunnel to the appropriate services or portion of the corporate network on the basis of the dialed number.
VPN Tunnel Lookup Based on Both Domain Name and DNIS Information
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.
NAS AAA Tunnel Definition Lookup
Authentication, authorization, and accounting (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:
•
•
For example:
request dialin l2tp ip 172.21.9.13 domain hoser.coml2tp local name dustiel2tp local secret partneris equivalent to the following RADIUS server configuration:
acme.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"
Note
L2TP Dial-Out
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
L2TP dial-out involves two devices: a tunnel server and a 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) that the tunnel server wants to dial out to.
Figure 77 shows a typical L2TP dial-out scenario.
Figure 77 L2TP Dial-Out Process
The following explains the sequence of events described in Figure 77:
1.
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.
3.
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.
5.
6.
7.
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
VPN Configuration Modes Overview
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 a NAS, but not both. But individual routers can have both tunnel server VPN groups and NAS VPN groups.
Table 31 list four VPDN group configuration commands that correspond to the configuration modes listed above. These command modes are accessed from VPN group mode; therefore, they are generically referred to as VPN subgroups.
The keywords and arguments for the previous accept-dialin and request-dialin VPDN group configuration commands are now independent commands. The previous syntax is still supported, but when you display the configuration, the commands will appear in the new format.
For example, to configure a NAS to request dial-in, you could use the old command, as follows:
request-dialin l2tp ip 10.1.2.3 domain jgb.comHowever when you view the configuration, the keywords and arguments are displayed in the new format with individual commands:
request dialinprotocol l2tpdomain jgb.cominitiate-to ip 10.1.2.3Similarly, the accept-dialout and request-dialout commands have subgroup commands that are used to specify information such as the tunneling protocol and dialer resource.
Table 32 lists the new VPN subgroup commands and which command modes they apply to:
The other VPN group commands are dependent on which VPN subgroups exist on the VPN group.
Table 33 lists the VPN group commands and which subgroups you need to enable in order for them to be configurable.
Table 33 VPN Group Commands
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
1 Tunnel server VPN groups can be configured for accept-dialin and/or request-dialout.
2 NAS VPN groups can be configured for accept-dialout and/or request-dialin.
Prerequisites for VPNs
Before configuring a VPN, you must complete the prerequisites described in Table 34. These prerequisites are discussed in the sections that follow.
Table 34 VPN Prerequisites
Required
Required
Required
Optional
Required
Required
Specifying the IP Address Pool and BOOTP Servers on the Tunnel Server
Required
Required
N/A
N/A
Required
N/A
N/A
Required
N/A
N/A
Required
N/A
N/A
Required
N/A
N/A
N/A
Required
N/A
N/A
Required
Configuring the LAN Interface
To assign an IP address to the interface that will be carrying the VPN traffic and that brings up the interface, use the following commands on both the NAS and the tunnel server beginning in global configuration mode:
Configuring AAA
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 the tacacs-server host command.
Refer to the Cisco IOS Security Configuration Guide, Release 12.2, for a complete list of commands and configurable options for security and AAA implementation.
For information on configuring remote AAA servers, refer to the CiscoSecure ACS documentation at: http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/index.htm.
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)# vpdn aaa override-server {aaa-server-ip-address | aaa-server-name}
(Optional) Specifies the AAA servers to be used for VPDN tunnel authorization. If this command is not configured, the default AAA server configured for network authorization is used for VPDN authorization.
Step 7
Router(config)# vpdn aaa attribute [{nas-ip-address vpdn-nas}| (nas-port vpdn-nas}]
(Optional) Enables the reporting of AAA attributes from the HGW to the configured RADIUS or TACACS+ AAA server. This command is applicable only on the tunnel server and is disabled by default.
Step 8
Router(config)# vpdn aaa untagged
(Optional) Enables the application of untagged attribute values to all attribute sets for VPDN tunnels, unless a value for that attribute is already specified in the attribute set. This command is enabled by default, therefore configuration of this command is required only if the command has been previously disabled.
Step 9
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 for all RADIUS communication.
Note
Specifies the TACACS+ server IP address and optionally the port to be used, and an authentication and encryption key.
1 If you specify more than one method, AAA will query the servers or databases in the order that they are entered.
Specifying the IP Address Pool and BOOTP Servers on the Tunnel Server
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 System (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.
Commissioning the T1 Controllers on the NAS
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:
Configuring the Serial Channels for Modem Calls on the NAS
To configure the D channels (the signaling 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:
Configuring the Modems and Asynchronous Lines on the NAS
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 of 115200 bps and hardware flow control are default values for integrated modems.
Configuring the Group-Asynchronous Interface on the NAS
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.
Configuring the Dialer on a NAS
To configure the dialer on a NAS for L2TP dial-out, use the following commands beginning in global configuration mode:
Configuring the Dialer on a Tunnel Server
To configure the dialer on an a tunnel server for L2TP dial-out, use the following commands beginning in global configuration mode:
How to Configure a VPN
Configuration for both dial-in and dial-out VPNs is described in the following sections:
•
•
•
•
•
See the section "Configuration Examples for VPN" later in this chapter for examples of how you can implement VPN in your network.
Enabling a VPN
To enable a VPN tunnel, use the following command in global configuration mode:
Router(config)# vpdn1 enable
Enables VPN.
1 The Cisco IOS command syntax uses the more specific term VPDN (virtual private dialup network) 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.
Configuring VPN Tunnel Authentication Configuration
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.
Disabling VPN Tunnel Authentication for L2TP Tunnels
To disable VPN tunnel authentication for L2TP tunnels, use the following commands beginning in global configuration mode:
Note
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, Release 12.2.
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:
•
The tunnel secret is configured as a password by using the username command.
•
The tunnel secret is configured by using the l2tp tunnel password command.
Configuring VPN Tunnel Authentication Using the Host Name or Local Name
To configure VPN tunnel authentication using the hostname or local name commands, use the following commands beginning in global configuration mode:
Configuring VPN Tunnel Authentication Using the L2TP Tunnel Password
To configure VPN tunnel authentication using the l2tp tunnel password command, use the following commands beginning in global configuration:
For sample VPN tunnel authentication configurations, see the "VPN Tunnel Authentication Examples" section later in this chapter.
Configuring Client-Initiated Dial-In VPN
For client-initiated dial-in VPNs, complete the following tasks:
•
•
•
When configuring PPTP and MPPE, you should consider the following restrictions:
•
•
•
•
•
•
•
•
Configuring a Tunnel Server to Accept PPTP Tunnels
To configure a tunnel to accept tunneled PPP connections from a client, use the following commands beginning in global configuration mode:
Configuring MPPE on the ISA Card
To offload MPPE encryption from the tunnel server processor to the ISA card, use the following commands beginning in global configuration mode:
Step 1
PNS(config)# controller isa slot/portEnters controller configuration mode on the ISA card.
Step 2
PNS(config-controller)# encryption mppe
Enables MPPE encryption
Tuning PPTP
To tune PPTP, use one or more of the following commands in VPDN configuration mode:
Configuring NAS-Initiated Dial-In VPN
The following tasks must be completed for NAS-initiated dial-in VPNs:
•
•
•
Configuring a NAS to Request Dial-In
The NAS is a device that is typically (although not always) located at a service provider POP; initial configuration and ongoing management are done by the service provider.
To configure a NAS to accept PPP calls and tunnel them to a tunnel server, use the following commands beginning in global configuration mode:
Configuring a Tunnel Server to Accept Dial-In
To configure a tunnel server to accept tunneled PPP connections from a 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.
See the section "Tunnel Server Comprehensive Dial-in Configuration Example" later in this chapter for a configuration example.
Creating the Virtual Template on the Network Server
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, use the following commands beginning in global configuration mode:
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 this publication.
Configuring Dial-Out VPN
The following tasks must be completed for dial-out VPNs:
•
•
Configuring a Tunnel Server to Request Dial-Out
To configure a tunnel server to request dial-out tunneled PPP connections to a NAS, use the following commands beginning in global configuration mode:
Configuring a NAS to Accept Dial-Out
To configure a NAS to accept tunneled dial-out connections from a tunnel server, use the following commands beginning in global configuration mode:
Configuring Advanced VPN Features
The following optional tasks provide advanced VPN features:
•
•
•
•
•
Configuring Advanced Remote AAA Features
This section describes the following two advanced remote AAA features for VPNs:
•
Tunnel Server Load Balancing on the NAS AAA Server
NAS AAA servers can forward users of the same domain name or DNIS to more than one tunnel server. The NAS AAA server can be configured to balance the load of calls equally among the tunnel servers, or it can designate different priority levels to the tunnel servers.
To configure load balancing on a NAS RADIUS server, configure multiple IP addresses in the vpdn:ip-addresses attribute value (AV) pair. The IP addresses can be separated by either spaces or by commas. The following example shows a profile that will equally balance the load between three tunnel servers.
user = terrapin.com{profile_id = 29profile_cycle = 7radius=Cisco {check_items= {2=cisco}reply_attributes= {9,1="vpdn:l2tp-tunnel-password=cisco123"9,1="vpdn:tunnel-type=l2tp"9,1="vpdn:ip-addresses=172.16.171.11 172.16.171.12 172.16.171.13"9,1="vpdn:tunnel-id=tunnel"}}}To specify different priorities for the tunnel servers, separate the IP addresses with a slash. The following AV pair instructs the RADIUS server to equally balance calls between 172.16.171.11 and 172.16.171.12. If both of those tunnel servers are unavailable, the RADIUS server will tunnel calls to 172.16.171.13.
9,1="vpdn:ip-addresses=172.16.171.11 172.16.171.12/172.16.171.13"DNS Name Support
NAS AAA servers can resolve DNS names and translate them into IP addresses. The server will first look up the name in its name cache. If the name is not in the name cache, the server will resolve the name by using a DNS server. The following AV pair instructs the RADIUS server to resolve the DNS name "terrapin" and tunnel calls to the appropriate IP addresses:
9,1="vpdn:ip-addresses=terrapin"For detailed information about remote AAA configuration, refer to the CiscoSecure ACS documentation at http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/index.htm.
Configuring Per-User VPN
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 sends only the user domain name (when performing authentication based on domain name) or the telephone number the user dialed in from (when performing authentication based on DNIS).
Per-user VPN configuration sends the entire structured username to the AAA server the first time the router contacts the AAA server. This enables 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 software sends only the domain name or DNIS to determine VPN tunnel attribute information. Then, if no VPN tunnel attributes are returned, Cisco IOS software sends the entire username string.
Note
To configure per-user VPN, use the following commands beginning in global configuration mode:
Configuring Preservation of IP ToS Field
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 ToS field of the IP packets' onto the L2TP data packets when they are created at the tunnel server virtual access interface, use the following commands beginning in global configuration mode:
Note
Note
Shutting Down a VPN Tunnel
To shut down a VPN tunnel, use the following command in privileged EXEC mode:
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.
Limiting the Number of Allowed Simultaneous VPN Sessions
To set a limit for the maximum number of allowed simultaneous VPN sessions, use the following command in global configuration mode:
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
Step 1
Step 2
Step 3
Step 4
00:11:17:%VPDN-6-MAX_SESS_EXCD:L2F HGW great_went has exceeded configured local session-limit and rejected user wilson@soam.comStep 5
User:wilson@soam.comNAS:cliford_ball, IP address = 172.25.52.8, CLID = 2Gateway:great_went, IP address = 172.25.52.7, CLID = 13Log time:00:04:21, Error repeat count:1Failure type:Exceeded configured VPDN maximum session limit.Failure reason:
Enabling Soft Shutdown of VPN Tunnels
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:
Router(config)# vpdn softshut1
Prevents new sessions from being established on a VPN tunnel without disturbing existing sessions.
1 When 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 a 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 1
Step 2
Step 3
ENT_HGW# show vpdn% No active L2TP tunnelsL2F Tunnel and SessionNAS CLID HGW CLID NAS Name HGW Name State36 1 cliford_ball great_went open172.25.52.8 172.25.52.7CLID MID Username Intf State36 1 mockingbird@gamehendge.com Vi1 openStep 4
Step 5
00:11:17:%VPDN-6-SOFTSHUT:L2F HGW great_went has turned on softshut and rejected user wilson@soam.comStep 6
User:wilson@soam.comNAS:cliford_ball, IP address = 172.25.52.8, CLID = 2Gateway:great_went, IP address = 172.25.52.7, CLID = 13Log time:00:04:21, Error repeat count:1Failure type:VPDN softshut has been activated.Failure reason:
Configuring Event Logging
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:
Setting the History Table Size
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:
Router(config)# vpdn history failure table-size entries
(Optional) Sets the failure history table depth.
Verifying VPN Sessions
The following sections detail the procedures used for verifying VPN sessions:
•
•
Verifying a Client-Initiated VPN
To verify that a PPTP network functions properly, complete the following verification steps:
Step 1
Step 2
Step 3
a.
b.
c.
d.
e.
Step 4
PNS# show vpdn% No active L2TP tunnels% No active L2F tunnelsPPTP Tunnel and Session Information (Total tunnels=1 sessions=1)LocID RemID Remote Name State Remote Address Port Sessions13 13 10.1.2.41 estabd 10.1.2.41 1136 1LocID RemID TunID Intf Username State Last Chg13 0 13 Vi3 estabd 000030Step 5
PNS# show vpdn session all% No active L2TP tunnels% No active L2F tunnelsPPTP Session Information (Total tunnels=1 sessions=1)Call id 13 is up on tunnel id 13Remote tunnel name is 10.1.2.41Internet Address is 10.1.2.41Session username is unknown, state is estabdTime since change 000106, interface Vi3Remote call id is 010 packets sent, 10 received, 332 bytes sent, 448 receivedSs 11, Sr 10, Remote Nr 10, peer RWS 160 out of order packetsFlow alarm is clear.The last line of output from the show vpdn session window command indicates the current status of the flow control alarm (under the heading "Congestion") and the number of flow control alarms that have gone off during the session (under the heading "Alarms").
PNS# show vpdn session window% No active L2TP tunnels% No active L2F tunnelsPPTP Session Information (Total tunnels=1 sessions=1)LocID RemID TunID ZLB-tx ZLB-rx Congestion Alarms Peer-RWS13 0 13 0 1 clear 0 16Step 6
PNS# show ppp mppe virtual-access3Interface Virtual-Access3 (current connection)Hardware (ISA5/1, flow_id=13) encryption, 40 bit encryption, Stateless modepackets encrypted = 0 packets decrypted = 1sent CCP resets = 0 receive CCP resets = 0next tx coherency = 0 next rx coherency = 0tx key changes = 0 rx key changes = 0rx pkt dropped = 0 rx out of order pkt= 0rx missed packets = 0To update the key change information, reissue the show ppp mppe virtual-access3 command.
PNS# show ppp mppe virtual-access3Interface Virtual-Access3 (current connection)Hardware (ISA5/1, flow_id=13) encryption, 40 bit encryption, Stateless modepackets encrypted = 0 packets decrypted = 1sent CCP resets = 0 receive CCP resets = 0next tx coherency = 0 next rx coherency = 0tx key changes = 0 rx key changes = 1rx pkt dropped = 0 rx out of order pkt= 0rx missed packets = 0
Verifying a NAS-Initiated VPN
This section describes how to verify that an L2F dial-in scenario functions as shown in Figure 78. To verify connectivity, complete the following verification steps:
•
•
•
•
•
•
Figure 78 L2F Dial-In Topology Using Remote AAA
Step 1
As the call comes in to 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
Step 2
a.
b.
c.
d.
e.
Step 3
ENT_HGW# show callerLine User Service Activecon 0 jane-admin TTY 00:00:25Vi1 jeremy@hgw.com PPP L2F 00:01:28ENT_HGW# show caller user jeremy@hgw.comUser: jeremy@hgw.com, line Vi1, service PPP L2F, active 00:01:35PPP: LCP Open, CHAP (<- AAA), IPCPIP: Local 172.22.66.25, remote 172.30.2.1VPDN: NAS ISP_NAS, MID 1, MID openHGW ENT_HGW, NAS CLID 36, HGW CLID 1, tunnel openCounts: 105 packets input, 8979 bytes, 0 no buffer0 input errors, 0 CRC, 0 frame, 0 overrun18 packets output, 295 bytes, 0 underruns0 output errors, 0 collisions, 0 interface resetsStep 4
ENT_HGW# ping 172.30.2.1Type 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 msStep 5
ENT_HGW# show interface virtual-access 1Virtual-Access1 is up, line protocol is upHardware is Virtual Access interfaceInterface is unnumbered. Using address of FastEthernet0/0 (172.22.66.25)MTU 1500 bytes, BW 115 Kbit, DLY 100000 usec,reliablility 255/255, txload 1/255, rxload 1/255Encapsulation PPP, loopback not set, keepalive set (10 sec)DTR is pulsed for 5 seconds on resetLCP OpenOpen: IPCPLast input 00:00:02, output never, output hang neverLast clearing of "show interface" counters 3d00hQueueing strategy: fifoOutput queue 1/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec114 packets input, 9563 bytes, 0 no bufferReceived 0 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort27 packets output, 864 bytes, 0 underruns0 output errors, 0 collisions, 0 interface resets0 output buffer failures, 0 output buffers swapped out0 carrier transitionsStep 6
ENT_HGW# show vpdn% No active L2TP tunnelsL2F Tunnel and SessionNAS CLID HGW CLID NAS Name HGW Name State36 1 ISP_NAS ENT_HGW open172.22.66.23 172.22.66.25CLID MID Username Intf State36 1 jeremy@hgw.com Vi1 openENT_HGW# show vpdn tunnel all% No active L2TP tunnelsL2F TunnelNAS name: ISP_NASNAS CLID: 36NAS IP address 172.22.66.23Gateway name: ENT_HGWGateway CLID: 1Gateway IP address 172.22.66.25State: openPackets out: 52Bytes out: 1799Packets in: 100Bytes in: 7143
Monitoring and Maintaining VPNs
To display useful information for monitoring and maintaining VPN sessions, use the following commands in privileged EXEC mode:
Troubleshooting VPNs
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:
Successful Debug Examples
The following sections provide examples of debug output from successful VPN sessions:
•
•
•
•
Figure 79 shows the topology used for the L2TP dial-in debug examples.
Figure 79 Topology Diagram for L2TP Dial-In Debug Example
L2TP Dial-In Debug Output on NAS Example
The following is debug output from a successful L2TP dial-in session on a NAS for the topology shown in Figure 79:
DJ# debug vpdn eventVPDN events debugging is onDJ# debug vpdn l2x-eventsL2X protocol events debugging is onDJ# show debuggingVPN:L2X protocol events debugging is onVPDN events debugging is onDJ#20:47:33: %LINK-3-UPDOWN: Interface Async7, changed state to up20:47:35: As7 VPDN: Looking for tunnel -- hoser.com --20:47:35: As7 VPDN: Get tunnel info for hoser.com with NAS DJ, IP 172.21.9.1320:47:35: As7 VPDN: Forward to address 172.21.9.1320:47:35: As7 VPDN: Forwarding...20:47:35: As7 VPDN: Bind interface direction=120:47:35: Tnl/Cl 8/1 L2TP: Session FS enabled20:47:35: Tnl/Cl 8/1 L2TP: Session state change from idle to wait-for-tunnel20:47:35: As7 8/1 L2TP: Create session20:47:35: Tnl 8 L2TP: SM State idle20:47:35: Tnl 8 L2TP: Tunnel state change from idle to wait-ctl-reply20:47:35: Tnl 8 L2TP: SM State wait-ctl-reply20:47:35: As7 VPDN: kath@hoser.com is forwarded20:47:35: Tnl 8 L2TP: Got a challenge from remote peer, DJ20:47:35: Tnl 8 L2TP: Got a response from remote peer, DJ20:47:35: Tnl 8 L2TP: Tunnel Authentication success20:47:35: Tnl 8 L2TP: Tunnel state change from wait-ctl-reply to established20:47:35: Tnl 8 L2TP: SM State established20:47:35: As7 8/1 L2TP: Session state change from wait-for-tunnel to wait-reply20:47:35: As7 8/1 L2TP: Session state change from wait-reply to established20:47:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async7, changed state to upL2TP Dial-In Debug Output on a Tunnel Server Example
The following is debug output from a successful L2TP dial-in session on a tunnel server for the topology shown in Figure 79:
tunnel# debug vpdn l2x-eventsL2X protocol events debugging is on20:19:17: L2TP: I SCCRQ from DJ tnl 820:19:17: L2X: Never heard of DJ20:19:17: Tnl 7 L2TP: New tunnel created for remote DJ, address 172.21.9.420:19:17: Tnl 7 L2TP: Got a challenge in SCCRQ, DJ20:19:17: Tnl 7 L2TP: Tunnel state change from idle to wait-ctl-reply20:19:17: Tnl 7 L2TP: Got a Challenge Response in SCCCN from DJ20:19:17: Tnl 7 L2TP: Tunnel Authentication success20:19:17: Tnl 7 L2TP: Tunnel state change from wait-ctl-reply to established20:19:17: Tnl 7 L2TP: SM State established20:19:17: Tnl/Cl 7/1 L2TP: Session FS enabled20:19:17: Tnl/Cl 7/1 L2TP: Session state change from idle to wait-for-tunnel20:19:17: Tnl/Cl 7/1 L2TP: New session created20:19:17: Tnl/Cl 7/1 L2TP: O ICRP to DJ 8/120:19:17: Tnl/Cl 7/1 L2TP: Session state change from wait-for-tunnel to wait-connect20:19:17: Tnl/Cl 7/1 L2TP: Session state change from wait-connect to established20:19:17: Vi1 VPDN: Virtual interface created for kath@hoser.com20:19:17: Vi1 VPDN: Set to Async interface20:19:17: Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking20:19:18: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up20:19:18: Vi1 VPDN: Bind interface direction=220:19:18: Vi1 VPDN: PPP LCP accepting rcv CONFACK20:19:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to upL2TP Dial-Out Debug Output on a NAS Example
The following is sample output from the debug dialer events and show debugging EXEC commands for a successful dial-out session on a NAS:
NAS# debug dialer eventsDial on demand events debugging is onNAS# show debuggingDial on demand:Dial on demand events debugging is onVPN:L2X protocol events debugging is onVPDN events debugging is onNAS#*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 71014L2TP Dial-Out Debug Output on a Tunnel Server Example
The following is sample 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 eventsDial on demand events debugging is onLNS# debug ppp negotiationPPP protocol negotiation debugging is onLNS# debug ppp chapPPP authentication debugging is onLNS# show debuggingDial on demand:Dial on demand events debugging is onPPP:PPP authentication debugging is onPPP protocol negotiation debugging is onVPN:VPDN events debugging is onVPDN errors debugging is onLNS#*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 upVPN Troubleshooting Methodology
This section describes a methodology for troubleshooting the VPN shown in Figure 80. 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.
The following sections detail the steps involved in VPN troubleshooting:
•
•
•
•
Figure 80 Troubleshooting Flow Diagram for Access VPN with Remote AAA
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.
Comparing Your Debug Output to the Successful Debug Output
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:
NAS#Jan 7 00:19:35.900: %LINK-3-UPDOWN: Interface Async9, changed state to upJan 7 00:19:39.532: sVPDN: Got DNIS string As9Jan 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.25Jan 7 00:19:39.540: As9 VPDN: Forward to address 172.22.66.25Jan 7 00:19:39.540: As9 VPDN: Forwarding...Jan 7 00:19:39.540: As9 VPDN: Bind interface direction=1Jan 7 00:19:39.540: As9 VPDN: jeremy@hgw.com is forwardedJan 7 00:19:40.540: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async9, changed state to upENT_HGW#Jan 7 00:19:39.967: VPDN: Chap authentication succeeded for ISP_NASJan 7 00:19:39.967: Vi1 VPDN: Virtual interface created for jeremy@hgw.comJan 7 00:19:39.967: Vi1 VPDN: Set to Async interfaceJan 7 00:19:39.971: Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking6w5d: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to upJan 7 00:19:40.051: Vi1 VPDN: Bind interface direction=2Jan 7 00:19:40.051: Vi1 VPDN: PPP LCP accepted rcv CONFACKJan 7 00:19:40.051: Vi1 VPDN: PPP LCP accepted sent CONFACK6w5d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to upIf 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.
Troubleshooting VPN Negotiation
The following sections describe several common misconfigurations that prevent successful VPN (either L2F or L2TP) negotiation:
•
•
•
Misconfigured NAS Tunnel Secret
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:
NAS#Jan 1 00:26:49.899: %LINK-3-UPDOWN: Interface Async3, changed state to upJan 1 00:26:54.643: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async3, changed state to upJan 1 00:27:00.559: L2F: Resending L2F_OPEN, time #1Jan 1 00:27:05.559: L2F: Resending L2F_ECHO, time #1Jan 1 00:27:05.559: L2F: Resending L2F_OPEN, time #2Jan 1 00:27:10.559: L2F: Resending L2F_ECHO, time #2Jan 1 00:27:10.559: L2F: Resending L2F_OPEN, time #3Jan 1 00:27:15.559: L2F: Resending L2F_ECHO, time #3Jan 1 00:27:15.559: L2F: Resending L2F_OPEN, time #4Jan 1 00:27:20.559: L2F: Resending L2F_ECHO, time #4Jan 1 00:27:20.559: L2F: Resending L2F_OPEN, time #5Jan 1 00:27:25.559: L2F: Resending L2F_ECHO, time #5Jan 1 00:27:25.559: L2F: Resend packet (type 2) around too long, time to kill off the tunnelNAS#ENT_HGW#Jan 1 00:26:53.645: L2F: Packet has bogus2 key C8353FAB B63691215w6d: %VPDN-6-AUTHENFAIL: L2F HGW , authentication failure for tunnel ISP_NAS; Invalid key5w6d: %VPDN-5-UNREACH: L2F NAS 172.22.66.23 is unreachableJan 1 00:27:00.557: L2F: Gateway received tunnel OPEN while in state closedENT_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.
Misconfigured Tunnel Server Tunnel Secret
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:
NAS#Jan 1 00:45:27.123: %LINK-3-UPDOWN: Interface Async7, changed state to upJan 1 00:45:30.939: L2F: Packet has bogus1 key B6C656EE 5FAC6B3Jan 1 00:45:30.939: %VPDN-6-AUTHENFAIL: L2F NAS ISP_NAS, authentication failurefor tunnel ENT_HGW; Invalid keyJan 1 00:45:31.935: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async7, changed state to upJan 1 00:45:35.559: L2F: Resending L2F_OPEN, time #1Jan 1 00:45:35.559: L2F: Packet has bogus1 key B6C656EE 5FAC6B3ENT_HGW#Jan 1 00:45:30.939: L2F: Tunnel authentication succeeded for ISP_NASJan 1 00:45:35.559: L2F: Gateway received tunnel OPEN while in state openJan 1 00:45:40.559: L2F: Gateway received tunnel OPEN while in state openJan 1 00:45:45.559: L2F: Gateway received tunnel OPEN while in state openJan 1 00:45:50.559: L2F: Gateway received tunnel OPEN while in state openNotice 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 phrase 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.
Misconfigured Tunnel Name
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 that 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 1accept-dialin l2f virtual-template 1 remote ISP_NASlocal name ENT_HGWOn 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 receivedJan 1 01:28:54.207: L2X: Never heard of ispJan 1 01:28:54.207: L2F: Couldn't find tunnel named ispTo avoid the problem described, make sure that the tunnel names match on the tunnel server and on the RADIUS server.
Control Packet Problem on the NAS
The following example assumes that you suspect an error in parsing control packets. You can use the debug vpdn packet command with the control keyword to verify control packet information.
ISP_NAS# debug vpdn packet control20:50:27: %LINK-3-UPDOWN: Interface Async7, changed state to up20:50:29: Tnl 9 L2TP: O SCCRQ20:50:29: Tnl 9 L2TP: O SCCRQ, flg TLF, ver 2, len 131, tnl 0, cl 0, ns 0, nr 020:50:29: contiguous buffer, size 131C8 02 00 83 00 00 00 00 00 00 00 00 80 08 00 0000 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 0000 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 SCCRP20:50:29: Tnl 9 L2TP: Parse AVP 2, len 8, flag 0x0x8000 (M)20:50:29: Tnl 9 L2TP: Protocol Ver 25620:50:29: Tnl 9 L2TP: Parse AVP 3, len 10, flag 0x0x8000 (M)20:50:29: Tnl 9 L2TP: Framing Cap 0x0x320:50:29: Tnl 9 L2TP: Parse AVP 4, len 10, flag 0x0x8000 (M)20:50:29: Tnl 9 L2TP: Bearer Cap 0x0x320:50:29: Tnl 9 L2TP: Parse AVP 6, len 8, flag 0x0x020:50:29: Tnl 9 L2TP: Firmware Ver 0x0x112020:50:29: Tnl 9 L2TP: Parse AVP 7, len 12, flag 0x0x8000 (M)20:50:29: Tnl 9 L2TP: Hostname DJ20:50:29: Tnl 9 L2TP: Parse AVP 8, len 25, flag 0x0x020: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 820:50:29: Tnl 9 L2TP: Parse AVP 10, len 8, flag 0x0x8000 (M)20:50:29: Tnl 9 L2TP: Rx Window Size 420:50:29: Tnl 9 L2TP: Parse AVP 11, len 22, flag 0x0x8000 (M)20:50:29: Tnl 9 L2TP: Chlng D807308D106259C5933C6162ED3A168920:50:29: Tnl 9 L2TP: Parse AVP 13, len 22, flag 0x0x8000 (M)20:50:29: Tnl 9 L2TP: Chlng Resp 9F6A3C70512BD3E2D44DF183C3FFF2D120:50:29: Tnl 9 L2TP: No missing AVPs in SCCRP20:50:29: Tnl 9 L2TP: Clean Queue packet 020:50:29: Tnl 9 L2TP: I SCCRP, flg TLF, ver 2, len 153, tnl 9, cl 0, ns 0, nr 1contiguous pak, size 153C8 02 00 99 00 09 00 00 00 00 00 01 80 08 00 0000 00 00 02 80 08 00 00 00 02 01 00 80 0A 00 0000 03 00 00 00 03 80 0A 00 00 00 04 00 00 00 ...20:50:29: Tnl 9 L2TP: I SCCRP from DJ20:50:29: Tnl 9 L2TP: O SCCCN to DJ tnlid 820:50:29: Tnl 9 L2TP: O SCCCN, flg TLF, ver 2, len 42, tnl 8, cl 0, ns 1, nr 120:50:29: contiguous buffer, size 42C8 02 00 2A 00 08 00 00 00 01 00 01 80 08 00 0000 00 00 03 80 16 00 00 00 0D 4B 2F A2 50 30 13E3 46 58 D5 35 8B 56 7A E9 8520:50:29: As7 9/1 L2TP: O ICRQ to DJ 8/020:50:29: As7 9/1 L2TP: O ICRQ, flg TLF, ver 2, len 48, tnl 8, cl 0, ns 2, nr 120:50:29: contiguous buffer, size 48C8 02 00 30 00 08 00 00 00 02 00 01 80 08 00 0000 00 00 0A 80 08 00 00 00 0E 00 01 80 0A 00 0000 0F 00 00 00 04 80 0A 00 00 00 12 00 00 00 ...20:50:29: Tnl 9 L2TP: Clean Queue packet 120:50:29: Tnl 9 L2TP: Clean Queue packet 220:50:29: Tnl 9 L2TP: I ZLB ctrl ack, flg TLF, ver 2, len 12, tnl 9, cl 0, ns 1, nr 2contiguous pak, size 12C8 02 00 0C 00 09 00 00 00 01 00 0220:50:30: As7 9/1 L2TP: Parse AVP 0, len 8, flag 0x0x8000 (M)20:50:30: As7 9/1 L2TP: Parse ICRP20:50:30: As7 9/1 L2TP: Parse AVP 14, len 8, flag 0x0x8000 (M)20:50:30: As7 9/1 L2TP: Assigned Call ID 120:50:30: As7 9/1 L2TP: No missing AVPs in ICRP20:50:30: Tnl 9 L2TP: Clean Queue packet 220:50:30: As7 9/1 L2TP: I ICRP, flg TLF, ver 2, len 28, tnl 9, cl 1, ns 1, nr 3contiguous pak, size 28C8 02 00 1C 00 09 00 01 00 01 00 03 80 08 00 0000 00 00 0B 80 08 00 00 00 0E 00 0120:50:30: As7 9/1 L2TP: O ICCN to DJ 8/120:50:30: As7 9/1 L2TP: O ICCN, flg TLF, ver 2, len 203, tnl 8, cl 1, ns 3, nr 220:50:30: contiguous buffer, size 203C8 02 00 CB 00 08 00 01 00 03 00 02 80 08 00 0000 00 00 0C 80 0A 00 00 00 18 00 00 DA C0 80 0A00 00 00 13 00 00 00 02 00 28 00 00 00 1B 02 ...20:50:30: Tnl 9 L2TP: Clean Queue packet 320:50:30: As7 9/1 L2TP: I ZLB ctrl ack, flg TLF, ver 2, len 12, tnl 9, cl 1, ns 2, nr 4contiguous pak, size 12C8 02 00 0C 00 09 00 01 00 02 00 0420:50:30: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async7, changed state to upIf 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.
Troubleshooting PPP Negotiation
This section first shows debug output of successful PPP negotiation. The subsequent sections 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.
Successful PPP Negotiation Debug Output
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 UPIf 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.
Non-Cisco Device Connectivity Problem
The debug ppp authentication and debug ppp negotiation 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 authenticationPPP authentication debugging is onRouter# debug ppp negotiationPPP protocol negotiation debugging is on3:22:53: ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/53:22:53: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = C6091F.3:22:55: ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/53:22:55: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = C6091F3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x0 (??)3:22:55: PPP BRI0: B-Channel 1: rcvd unknown option 0x0 rejected3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x1 (MRU) value = 0x5F4 rejected3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x3 (AUTHTYPE) value= 0xC223 value = 0x5 acked3:22:55: PPP BRI0: B-Channel 1: received config for type = 0x11 (MULTILINK_MRRU)rejected3: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 rejected3:22:55: ppp: config REJ received, type = 3 (CI_AUTHTYPE), value = C223/53:22:55: ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/53:22:55: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = C6091F3: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 acked3:22:55: ppp: config REJ received, type = 3 (CI_AUTHTYPE), value = C223/53:22:55: ppp: BRI0: B-Channel 1 closing connection because remote won't authenticate3:22:55: ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/53:22:55: ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = C6091F3:22:55: %ISDN-6-DISCONNECT: Interface BRI0: B-Channel 1 disconnected from 01235820040 , call lasted 2 seconds3:22:56: %LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to downIndication:Mismatched Username Example
The following debug ppp chap sample output excerpt shows a CHAP authentication failure caused by a configuration mismatch between devices. Verifying and correcting any username and password mismatch should remedy this problem.
Router# debug ppp chapppp: received conf.ig for type = 5 (MAGICNUMBER) value = 1E24718 ackedPPP BRI0: B-Channel 1: state = ACKSENT fsm_rconfack(C021): rcvd id E6ppp: config ACK received, type = 3 (CI_AUTHTYPE), value = C223ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 28CEF76CBRI0: B-Channel 1: PPP AUTH CHAP input code = 1 id = 83 len = 16BRI0: B-Channel 1: PPP AUTH CHAP input code = 2 id = 96 len = 28BRI0: B-Channel 1: PPP AUTH CHAP input code = 4 id = 83 len = 21BRI0: B-Channel 1: Failed CHAP authentication with remote.Remote message is: MD compare failedIf your call cannot successfully complete PPP negotiation, contact your support personnel.
Troubleshooting AAA Negotiation
This section first shows debug output of successful AAA negotiation. The subsequent sections explain several common misconfigurations that prevent successful AAA negotiation:
•
•
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=1Jan 7 19:29:44.132: AAA/AUTHEN/START (384300079): port='' list='default' action=SENDAUTH service=PPPJan 7 19:29:44.132: AAA/AUTHEN/START (384300079): found list defaultJan 7 19:29:44.132: AAA/AUTHEN/START (384300079): Method=LOCALJan 7 19:29:44.132: AAA/AUTHEN (384300079): status = PASSJan 7 19:29:44.132: AAA/AUTHEN: create_user (0x612D550C) user='ISP_NAS' ruser='' port='' rem_addr='' authen_type=CHAP service=PPP priv=1Jan 7 19:29:44.132: AAA/AUTHEN/START (2545876944): port='' list='default' action=SENDAUTH service=PPPJan 7 19:29:44.132: AAA/AUTHEN/START (2545876944): found list defaultJan 7 19:29:44.132: AAA/AUTHEN/START (2545876944): Method=LOCALJan 7 19:29:44.132: AAA/AUTHEN (2545876944): status = PASSJan 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=1Jan 7 19:29:44.228: AAA/AUTHEN/START (101773535): port='Virtual-Access1' list='' action=LOGIN service=PPPJan 7 19:29:44.228: AAA/AUTHEN/START (101773535): using "default" listJan 7 19:29:44.228: AAA/AUTHEN/START (101773535): Method=LOCALJan 7 19:29:44.228: AAA/AUTHEN (101773535): status = ERRORJan 7 19:29:44.228: AAA/AUTHEN/START (101773535): Method=RADIUSJan 7 19:29:44.692: AAA/AUTHEN (101773535): status = PASSJan 7 19:29:44.692: Vi1 AAA/AUTHOR/LCP: Authorize LCPJan 7 19:29:44.692: AAA/AUTHOR/LCP Vi1 (3630870259): Port='Virtual-Access1' list='' service=NETJan 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=pppJan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) send AV protocol=lcpJan 7 19:29:44.692: AAA/AUTHOR/LCP (3630870259) found list "default"Jan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) Method=RADIUSJan 7 19:29:44.692: AAA/AUTHOR (3630870259): Post authorization status = PASS_REPLJan 7 19:29:44.696: Vi1 AAA/AUTHOR/FSM: We can start IPCP6w5d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to upJan 7 19:29:47.792: Vi1 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want 172.30.2.1If 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.
Incorrect User Password
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 upJan 1 01:00:05.299: L2F: Tunnel state closedJan 1 01:00:05.299: L2F: MID state closedJan 1 01:00:05.299: L2F: Open UDP socket to 172.22.66.25Jan 1 01:00:05.299: L2F: Tunnel state openingJan 1 01:00:05.299: As12 L2F: MID jeremy@hgw.com state waiting_for_tunnelJan 1 01:00:05.303: L2F: L2F_CONF receivedJan 1 01:00:05.303: L2F: Removing resend packet (L2F_CONF)Jan 1 01:00:05.303: ENT_HGW L2F: Tunnel state openJan 1 01:00:05.307: L2F: L2F_OPEN receivedJan 1 01:00:05.307: L2F: Removing resend packet (L2F_OPEN)Jan 1 01:00:05.307: L2F: Building nas2gw_mid0Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: CLID/DNIS 4089548021/5550945Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: NAS-Port Async12Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: Client-Bandwidth-Kbps 115Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: NAS-Rate L2F/26400/28800Jan 1 01:00:05.307: As12 L2F: MID jeremy@hgw.com state openingJan 1 01:00:05.307: L2F: Tunnel authentication succeeded for ENT_HGWJan 1 01:00:05.391: L2F: L2F_OPEN receivedJan 1 01:00:05.391: L2F: Got a MID management packetJan 1 01:00:05.391: L2F: Removing resend packet (L2F_OPEN)Jan 1 01:00:05.391: As12 L2F: MID jeremy@hgw.com state openJan 1 01:00:05.391: As12 L2F: MID synced NAS/HG Clid=47/12 Mid=1Jan 1 01:00:05.523: L2F: L2F_CLOSE receivedJan 1 01:00:05.523: %VPDN-6-AUTHENERR: L2F HGW ENT_HGW cannot locate a AAA server for As12 user jeremy@hgw.com; Authentication failureENT_HGW#Jan 1 01:00:05.302: L2F: L2F_CONF receivedJan 1 01:00:05.302: L2F: Creating new tunnel for ISP_NASJan 1 01:00:05.302: L2F: Tunnel state closedJan 1 01:00:05.302: L2F: Got a tunnel named ISP_NAS, respondingJan 1 01:00:05.302: L2F: Open UDP socket to 172.22.66.23Jan 1 01:00:05.302: ISP_NAS L2F: Tunnel state openingJan 1 01:00:05.306: L2F: L2F_OPEN receivedJan 1 01:00:05.306: L2F: Removing resend packet (L2F_CONF)Jan 1 01:00:05.306: ISP_NAS L2F: Tunnel state openJan 1 01:00:05.306: L2F: Tunnel authentication succeeded for ISP_NASJan 1 01:00:05.310: L2F: L2F_OPEN receivedJan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: CLID/DNIS 4089548021/5550945Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: NAS-Port Async12Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: Client-Bandwidth-Kbps 115Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: NAS-Rate L2F/26400/28800Jan 1 01:00:05.310: L2F: Got a MID management packetJan 1 01:00:05.310: L2F: MID state closedJan 1 01:00:05.310: L2F: Start create mid intf process for jeremy@hgw.com5w6d: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to upJan 1 01:00:05.390: Vi1 L2X: Discarding packet because of no mid/sessionJan 1 01:00:05.390: Vi1 L2F: Transfer NAS-Rate L2F/26400/28800 to LCPJan 1 01:00:05.390: Vi1 L2F: Finish create mid intf for jeremy@hgw.comJan 1 01:00:05.390: Vi1 L2F: MID jeremy@hgw.com state open5w6d: %VPDN-6-AUTHENERR: L2F HGW ENT_HGW cannot locate a AAA server for Vi1 user jeremy@hgw.com; Authentication failureError Contacting RADIUS Server
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
Misconfigured AAA Authentication
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.
Configuration Examples for VPN
This section provides the following configuration examples:
•
•
•
•
•
•
Client-Initiated Dial-In Configuration Example
The following example shows the running configuration of a tunnel server configured for PPTP using an ISA card to perform 40-bit MPPE encryption. It does not have an AAA configuration.
Current configuration!version 12.0service timestamps debug uptimeservice timestamps log uptimeno service password-encryption!hostname PNS!no logging console guaranteedenable password lab!username tester41 password 0 lab41!ip subnet-zerono ip domain-lookup!vpdn enable!vpdn-group 1! Default PPTP VPDN groupaccept-dialinprotocol pptpvirtual-template 1local name cisco_pns!memory check-interval 1!controller ISA 5/0encryption mppe!process-max-time 200!interface FastEthernet0/0ip address 10.1.1.12 255.255.255.0no ip directed-broadcastduplex autospeed auto!interface FastEthernet0/1ip address 10.1.2.12 255.255.255.0no ip directed-broadcastduplex autospeed auto!interface Serial1/0no ip addressno ip directed-broadcastshutdownframing c-bitcablelength 10dsu bandwidth 44210!interface Serial1/1no ip addressno ip directed-broadcastshutdownframing c-bitcablelength 10dsu bandwidth 44210!interface FastEthernet4/0no ip addressno ip directed-broadcastshutdownduplex half!interface Virtual-Template1ip unnumbered FastEthernet0/0no ip directed-broadcastip mroute-cacheno keepaliveppp encrypt mppe 40ppp authentication ms-chap!ip classlessip route 172.29.1.129 255.255.255.255 1.1.1.1ip route 172.29.63.9 255.255.255.255 1.1.1.1no ip http server!line con 0exec-timeout 0 0transport input noneline aux 0line vty 0 4login!endVPN Tunnel Authentication Examples
The following examples shows several possibilities for performing local tunnel authentication. These examples only show the information relevant to tunnel authentication.
Tunnel Secret Configured Using the Local Name Command
The following examples are 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.
NAS Configuration
The NAS tunnel name is specified by the local name command. The tunnel server tunnel name and tunnel secret are specified by the username command.
username ENT_HGW password 7 tunnelme...vpdn-group 1local name ISP_NASTunnel Server Configuration
The tunnel server tunnel name is specified by the local name command. The NAS tunnel name and tunnel secret are specified by the username command.
username ISP_NAS password 7 tunnelme...vpdn-group 1local name ENT_HGWTunnel Secret Configured Using the L2TP Tunnel Password Command
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 1request-dialinprotocol l2tpl2tp tunnel password tunnelmeTunnel Server Configuration
vpdn-group 1accept-dialinprotocol l2tpl2tp tunnel password tunnelmeTunnel Secret Configuration Using Different Tunnel Authentication Methods
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 1local name stellaTunnel Server Configuration
vpdn-group 1accept--dialinprotocol l2tplocal name adrianl2tp tunnel password garf1eldNAS Comprehensive Dial-In Configuration Example
The following example shows a NAS configured to tunnel PPP calls to a tunnel server using L2TP and local authentication and authorization:
! Enable AAA authentication and authorization with RADIUS as the default methodaaa new-modelaaa authentication ppp default radiusaaa authorization network default radius!username ISP_NAS password 7 tunnelmeusername ENT_HGW password 7 tunnelme!vpdn enable!! Configure VPN to first search on the client domain name and then on the DNISvpdn search-order domain dnis! Allow a maximum of 10 simultaneous VPN sessionsvpdn session-limit 10!! Configure VPN to initiate VPN dial-in sessionsvpdn-group 1request-dialin! Specify L2TP as the tunneling protocolprotocol l2TP! Tunnel clients with the domain name "hgw.com"domain hgw.com! Establish a tunnel with IP address 172.22.66.25initiate-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-5essisdn switch-type primary-5ess!! Commissions the T1 controller to allow modem calls in to the NAScontroller T1 0framing esfclock source line primarylinecode b8zspri-group timeslots 1-24!interface Ethernet0ip address 172.22.66.23 255.255.255.192!! Configure the Serial channel to allow modem calls in to the NASinterface Serial0:23no ip addressisdn switch-type primary-5essisdn incoming-voice modemno cdp enable!!interface Group-Async1ip unnumbered Ethernet0encapsulation pppasync mode interactiveno peer default ip addressppp authentication chap papgroup-range 1 96!ip classlessip route 0.0.0.0 0.0.0.0 172.22.66.1!! Specifies the RADIUS server IP address, authorization port, and accounting portradius-server host 172.22.66.16 auth-port 1645 acct-port 1646! Specifies the authentication key to be used with the RADIUS serverradius-server key cisco!line con 0transport input none! Configures the modemsline 1 96autoselect during-loginautoselect pppmodem InOutline aux 0line vty 0 4!endTunnel Server Comprehensive Dial-in Configuration Example
The following example show a tunnel server configured to accept L2TP tunnels from a 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 authenticationaaa authentication ppp default local radius! Configure AAA network authorization and accounting by using the RADIUS serveraaa authorization network default radiusaaa accounting network default start-stop radius!username ISP_NAS password 7 tunnelmeusername ENT_HGW password 7 tunnelme!vpdn enable! Prevent any new VPN sessions from being established without disturbing existing ! sessionsvpdn softshut!! Configure VPN to accept dial-in sessionsvpdn-group 1accept-dialin! Specify L2TP as the tunneling protocolprotocol l2tp! Specify that virtual-access interfaces be cloned from virtual template 1virtual-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/0ip address 172.22.66.25 255.255.255.192no ip directed-broadcast!interface Virtual-Template1! Use the IP address of interface Ethernet 0ip unnumbered Ethernet0! Returns an IP address from the default pool to the VPN clientpeer default ip address pool default! Use CHAP to authenticate PPPppp authentication chap!ip local pool default 172.30.2.1 172.30.2.96ip classlessip route 0.0.0.0 0.0.0.0 172.22.66.1!! Specifies the RADIUS server IP address, authorization port, and accounting portradius-server host 172.22.66.13 auth-port 1645 acct-port 1646! Specifies the authentication key to be used with the RADIUS serverradius-server key ciscoNAS Configured for Both Dial-In and Dial-Out Example
You can configure a 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 a NAS is configured to dial in using L2F and to dial out using L2TP as the tunneling protocol and dialer interface 2. The example only shows the VPN group and dialer configuration:
vpdn-group 1request-dialinprotocol l2fdomain jgb.comaccept-dialoutprotocol l2tpdialer 2local name ceriseterminate-from hostname reubeninitiate-to ip 172.1.2.3!interface Dialer2ip unnumbered Ethernet0encapsulation pppdialer in-banddialer aaadialer-group 1ppp authentication chapTunnel Server Configured for Both Dial-In and Dial-Out Example
You can configure a tunnel server to simultaneously receive L2TP or L2F dial-in tunnels from a NAS and also initiate L2TP dial-out tunnels to a 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 to dial out using dialer pool 1. The example only shows the VPN group and dialer configuration:
vpdn-group 1accept-dialinprotocol l2tpvirtual-template 1request-dialoutprotocol l2tppool-member 1local name reubenterminate-from hostname ceriseinitiate-to ip 10.3.2.1!interface Dialer2ip address 172.19.2.3 255.255.128encapsulation pppdialer remote-name reubendialer string 5551234dialer vpdndialer pool 1dialer-group 1ppp authentication chapRADIUS Profile Examples
The following sections show VPN RADIUS profiles configured using CiscoSecure version 2.3.1:
RADIUS Domain Profile
The following example show a profile that is configured on the NAS RADIUS server to tunnel calls from users who dial-in with the domain name terrapin.com. The NAS will balance calls between the tunnel servers at 172.16.171.11 and 172.16.171.12. If both of those tunnel servers are unavailable, the NAS will tunnel calls to 172.16.171.13.
user = terrapin.com{profile_id = 29set server current-failed-logins = 0profile_cycle = 7radius=Cisco {check_items= {2=cisco}reply_attributes= {9,1="vpdn:l2tp-tunnel-password=cisco123"9,1="vpdn:tunnel-type=l2tp"9,1="vpdn:ip-addresses=172.16.171.11 172.16.171.12/172.16.171.13"9,1="vpdn:tunnel-id=tunnel"}}}
Note
RADIUS User Profile
The following example shows a profile that is configured on the tunnel server RADIUS server to authorize and authenticate user sailor@terrapin.com:
user = sailor@terrapin.com{profile_id = 28profile_cycle = 2radius=Cisco {check_items= {2=cisco}reply_attributes= {6=27=1}}}
Note
TACACS+ Profile Examples
The following sections show VPN TACACS+ profiles configured using CiscoSecure version 2.2.2:
TACACS+ Domain Profile
The following example shows a profile that is configured on the NAS TACACS+ server to tunnel users who dial in with the domain name guava.com:
user = guava.com{profile_id = 83profile_cycle = 1service=ppp {protocol=vpdn {set tunnel-id=ispset ip-addresses="10.31.1.50"set nas-password="little"set gw-password="birdies"}protocol=lcp {}}}TACACS+ User Profile
The following example shows a profile that is configured on the tunnel server TACACS+ to authorize and authenticate user geaner@guava.com:
user = geaner@guava.com{profile_id = 85profile_cycle = 1password = chap "daisies"service=ppp {protocol=ip {default attribute=permit}protocol=lcp {}}}TACACS+ Tunnel Profiles
The following examples show a profile that is configured on the tunnel server TACACS+ server to authenticate the tunnel. See the "Configuring VPN Tunnel Authentication Using the Host Name or Local Name" and "Configuring VPN Tunnel Authentication Using the L2TP Tunnel Password" sections earlier in this chapter for more information on tunnel authentication.
Note
user = tunnel-server {profile_id = 82profile_cycle = 1password = chap "3stone"service=ppp {protocol=ip {default attribute=permit}protocol=lcp {}}}CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0809R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental. © 2007-2008 Cisco Systems, Inc. All rights reserved.
Feedback