Access VPNs and Tunneling Technologies

Overview of Access VPNs and Tunneling Technologies
Introduction
A virtual private network (VPN) is a network that 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 an enterprise customers network. There are three main types of VPNs: access VPNs, intranet VPNs, and extranet VPNs.
Access VPNsProvide remote access to an enterprise customers intranet or extranet over a shared infrastructure. Access VPNs use analog, dial, ISDN, DSL, mobile IP, and cable technologies to securely connect mobile users, telecommuters, and branch ofces. Intranet VPNsLink enterprise customer headquarters, remote ofces, and branch ofces to an internal network over a shared infrastructure using dedicated connections. Intranet VPNs differ from extranet VPNs in that they only allow access to the enterprise customers employees. Extranet VPNsLink outside customers, suppliers, partners, or communities of interest to an enterprise customers network over a shared infrastructure using dedicated connections. Extranet VPNs differ from intranet VPNS in that they allow access to users outside the enterprise.
This document focuses solely on access VPNs.
Access VPNs
The main attraction of access VPNs is the way they delegate responsibilities for the network. The enterprise 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 into (called modem pools), access servers, and internetworking expertise. The enterprise customer is then only responsible for authenticating its users and maintaining its network. Instead of connecting directly to the enterprise network by using the expensive public switched telephone network (PSTN), access VPN users only need to use the PSTN to connect to the ISPs local point of presence (POP). The ISP then uses the Internet to forward users from the POP to the enterprise customer network. Forwarding a users call over the Internet provides dramatic cost saving for the enterprise customer. Access VPNs use layer 2 tunneling technologies to create a virtual point-to-point connection between users and the enterprise 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 enterprise customers headquarters.
Overview of Access VPNs and Tunneling Technologies 1
Access VPNs connect a variety of users: from a single, mobile employee to an entire branch ofce. Figure 1 illustrates the following methods of logging on to access VPNs:
Home PC by using a terminal adapter Small ofce/home ofce (SOHO) by using a router Remote ofce/branch ofce (ROBO) by using a router Mobile PC by using a modem
Logging on to Access VPNs Terminal adapter
Figure 1
Home PC Router SOHO

22416
Router ROBO Modem
PSTN
L2F tunnel
ISP
Enterprise customer
Mobile PC
Access VPN
The access VPN extends from the user to the enterprise customer. The Layer 2 Forwarding (L2F) tunnel is what makes access VPNs unique: Once the tunnel is established, the ISP is transparent to the user and the enterprise customer. The tunnel creates a secure connection between the user and the enterprise customers network over the insecure Internet and is indistinguishable from a point-to-point connection. This document describes three end-to-end access VPN case studies, which are primarily intended for ISPs who want to provide access VPN services to enterprise customers. The case studies are also useful to enterprise customers who want to establish access VPNs. This document does not provide information on the entire spectrum of VPNs, nor does it cover all the details necessary to establish a network. Instead, this document focuses on three specic case studies:
Layer 2 Forwarding Case Study Layer 2 Tunneling Protocol Case Study (under development) Layer 2 Tunneling Protocol with IPsec Case Study (under development)
Access VPN Solutions Using Tunneling Technology
Access VPN Architectures
Access VPN Architectures

Access VPNs are designed based on one of two architectural options: client-initiated or network access server (NAS)-initiated access VPNs. A NAS is an access server, maintained by the ISP, that users dial in to and that forwards the call to the enterprise network.
Client-initiated access VPNsUsers establish an encrypted IP tunnel across the ISPs shared network to the enterprise customers network. The enterprise 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. NAS-initiated access VPNsUsers dial in to the ISPs NAS, which establishes an encrypted tunnel to the enterprises private network. NAS-initiated VPNs are more robust than client-initiated VPNs, allow users to connect to multiple networks by using multiple tunnels, 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 enterprise customers because the PSTN is much more secure than the Internet.
This document focuses solely on NAS-initiated access VPNs.
ISPs and Enterprise Customers

Access VPNs involve the cooperation of two partners: an internet service provider (ISP) and an enterprise customer.
ISPResponsible for maintaining the modem pool, access servers, and internetworking expertise. Often, the ISP will lease its IT infrastructure to smaller ISPs. Enterprise CustomerResponsible for maintaining its user database and private network. Often, the enterprise customer is a smaller ISP that does not want to take on the expense and commitment of establishing its own IT infrastructure.
In this document, ISP refers to the partner that is responsible for the IT infrastructure, and enterprise customer refers to the partner that leases the IT infrastructure.
Benets
Access VPNs benet both ISPs and enterprise customers as described in the following sections.
Benets to the ISPs Offers end-to-end custom solutions that help differentiate the ISP in an increasingly competitive
market
Eliminates responsibility of managing the enterprise customers user database Allows expansion to broadband technologies (such as DSL, cable, and wireless) as they become available
Benets to the Enterprise Customers Allows enterprise customers to focus on their core business responsibilities Minimizes equipment costs Simplies complexity of upgrading technology
Eliminates need of maintaining internetworking expertise Reduces long distance and 800 number costs Increases exibility and scalability of connecting and disconnecting branch ofces, users, and external partners Prioritizes trafc to ensure bandwidth for critical applications
Access VPN Technologies

Access VPNs use L2F tunnels to tunnel the link layer of high-level protocols (for example, PPP frames or asynchronous High-Level Data Link Control). By using such tunnels, it is possible to detach the location of the ISPs NAS from the location of the enterprise customers home gateway, where the dial-up protocol connection terminates and access to the enterprise customers network is provided. ISPs congure their NASs to receive calls from users and forward the calls to the enterprise customers home gateway. The ISP only maintains information about the home gatewaythe tunnel endpoint. The enterprise customer maintains the home gateway users IP addresses, routing, and other user database functions. Administration between the ISP and home gateway is reduced to IP connectivity. Figure 2 shows the PPP link running between a client (the users hardware and software) and the home gateway. The NAS and home gateway establish an L2F tunnel that the NAS uses to forward the PPP link to the home gateway. The access VPN then extends from the client to the home gateway. The L2F tunnel creates a virtual point-to-point connection between the client and the home gateway.
Figure 2 End-to-End Access VPN Protocol Flow: L2F, PPP, and IP Enterprise company intranet
Client
PSTN cloud
NAS
Internet cloud
Home gateway
Access VPN
Legend L2F PPP IP

18987
The following sections give a functional description of the sequence of events that establish the access VPN:
Protocol Negotiation Sequence L2F Tunnel Authentication Process Three-Way CHAP Authentication Process
Protocol Negotiation Sequence
The Protocol Negotiation Sequence section is an overview of the negotiation events that take place as the access VPN is established. The L2F Tunnel Authentication Process section gives a detailed description of how the NAS and home gateway establish the L2F tunnel. The Three-Way CHAP Authentication Process section gives a detailed description of how the NAS and home gateway authenticate a user.
Protocol Negotiation Sequence

When a user wants to connect to the enterprise customers home gateway, he or she rst establishes a PPP connection to the ISPs NAS. The NAS then establishes an L2F tunnel with the home gateway. Finally, the home gateway authenticates the clients username and password, and establishes the PPP connection with the client. Figure 3 describes the sequence of protocol negotiation events between the ISPs NAS and the enterprise customers home gateway.
Figure 3 Client Protocol Negotiation Events Between Access VPN Devices NAS Home gateway
LCP Conf-Req LCP Conf-Ack 1 LCP Conf-Req LCP Conf-Ack 2 3 CHAP Challenge CHAP Response L2F_CONF PPP negotiation L2F_CONF 4 L2F Tunnel Negotiation L2F_OPEN L2F_OPEN L2F_OPEN (Mid) includes CHAP and LCP info 5 L2F Session (Mid) Negotiation L2F_OPEN (Mid)
CHAP Auth-OK PPP Packets 7 8 9

18989
Table 1 explains the sequence of events shown in Figure 3.

Table 1 Event
1 2 3 4
Protocol Negotiation Event Descriptions Description The users client and the NAS conduct a standard PPP link control protocol (LCP) negotiation. The NAS begins PPP authentication by sending a Challenge Handshake Authentication Protocol (CHAP) challenge to the client. The client replies with a CHAP response. When the NAS receives the CHAP response, either the phone number the user dialed in from (when using DNIS-based authentication) or the users domain name (when using domain name-based authentication) matches a conguration on either the NAS or its AAA server. This conguration instructs the NAS to create a VPN to forward the PPP session to the home gateway by using an L2F tunnel. Because this is the rst L2F session with the home gateway, the NAS and the home gateway exchange L2F_CONF packets, which prepare them to create the tunnel. Then they exchange L2F_OPEN packets, which open the L2F tunnel.
Once the L2F tunnel is open, the NAS and home gateway exchange L2F session packets. The NAS sends an L2F_OPEN (Mid) packet to the home gateway that includes the clients information from the LCP negotiation, the CHAP challenge, and the CHAP response. The home gateway forces this information on to a virtual-access interface it has created for the client and responds to the NAS with an L2F_OPEN (Mid) packet.
6 7 8 9
The home gateway authenticates the CHAP challenge and response (using either local or remote AAA) and sends a CHAP Auth-OK packet to the client. This completes the three-way CHAP authentication. When the client receives the CHAP Auth-OK packet, it can send PPP encapsulated packets to the home gateway. The client and the home gateway 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 home gateway) do not repeat the L2F session negotiation because the L2F tunnel is already open.
L2F Tunnel Authentication Process

When the NAS receives a call from a client that instructs it to create an L2F tunnel with the home gateway, it rst sends a challenge to the home gateway. The home gateway then sends a combined challenge and response to the NAS. Finally, the NAS responds to the home gateways challenge, and the two devices open the L2F tunnel. Before the NAS and home gateway can authenticate the tunnel, they must have a common tunnel secret. A tunnel secret is a pair of usernames with the same password that is congured on both the NAS and the home gateway. By combining the tunnel secret with random value algorithms, which are used to encrypt to the tunnel secret, the NAS and home gateway authenticate each other and establish the L2F tunnel.
L2F Tunnel Authentication Process
Figure 4 describes the tunnel authentication process.

Figure 4 NAS L2F Tunnel Authentication Process Home gateway
1 L2F_CONF name = ISP_NAS challenge = A L2F_CONF name = ENT_HGW challenge = B key=A=MD5 {A+ ISP_NAS secret} L2F_OPEN key = B' =MD5 {B + ENT_HGW secret} L2F_OPEN key = A' All subsequent messages have key = B' All subsequent messages have key = A'
18988
2 3 4 5

Table 2 Event
1 2 3
L2F Tunnel Authentication Event Descriptions Description Before the NAS and home gateway open an L2F tunnel, both devices must have a common tunnel secret in their congurations. The NAS sends an L2F_CONF packet that contains the NAS name and a random challenge value, A. After the home gateway receives the L2F_CONF packet, it sends an L2F_CONF packet back to the NAS with the home gateway name and a random challenge value, B. This message also includes a key containing A' (the MD5 of the NAS secret and the value A). When the NAS receives the L2F_CONF packet, it compares the key A' with the MD5 of the NAS secret and the value A. If the key and value match, the NAS sends an L2F_OPEN packet to the home gateway with a key containing B' (the MD5 of the home gateway secret and the value B). When the home gateway receives the L2F_OPEN packet, it compares the key B' with the MD5 of the home gateway secret and the value B. If the key and value match, the home gateway sends an L2F_OPEN packet to the NAS with the key A'. All subsequent messages from the NAS include key=B'; all subsequent messages from the home gateway include key=A'.
For more information on L2F, see RFC Level Two Forwarding (Protocol) L2F.
Three-Way CHAP Authentication Process

When establishing an access VPN, the client, NAS, and home gateway use three-way CHAP authentication to authenticate the clients username and password. CHAP is a challenge/response authentication protocol in which the password is sent as a 64-bit signature instead of as plain text. This enables the secure exchange of the users password between the users client and the home gateway. First, the NAS challenges the client, and the client responds. The NAS then forwards this CHAP information to the home gateway, which authenticates the client and sends a third CHAP message (either a success or failure message) to the client. Figure 5 describes the three-way CHAP authentication process.
Figure 5 Client Three-Way CHAP Authentication Process NAS Home gateway
CHAP challenge
2 3
CHAP response CHAP success or failure

18565

Table 3 Event
1 2
CHAP Event Descriptions Description When the user initiates a PPP session with the NAS, the NAS sends a CHAP challenge to the client. The client sends a CHAP response, which includes a plain text username, to the NAS. The NAS uses either the phone number the user dialed in from (when using DNIS-based authentication) or the users domain name (when using domain name-based authentication) to determine the IP tunnel endpoint information. At this point, PPP negotiation is suspended, and the NAS asks its AAA server for IP tunnel information. The AAA server supplies the information needed to authenticate the tunnel between the NAS and the home gateway. Next, the NAS and the home gateway authenticate each other and establish an L2F tunnel. Then the NAS forwards the PPP negotiation to the home gateway.
The third CHAP event takes place between the home gateway and the client. The home gateway authenticates the clients CHAP response, which was forwarded by the NAS, and sends a CHAP success or failure to the client.
Once the home gateway authenticates the client, the access VPN is established. The L2F tunnel creates a virtual point-to-point connection between the client and the home gateway. The NAS acts as a transparent packet forwarder. When subsequent clients dial in to the NAS to be forwarded to the home gateway, the NAS and home gateway do not need to repeat the L2F tunnel negotiation because the L2F tunnel is already open.
L2F Case Study Overview

Introduction
This case study describes how one Internet service provider (ISP) plans, designs, and implements an access virtual private network (VPN) by using Layer 2 Forwarding (L2F) as the tunneling protocol. L2F forwards Point-to-Point (PPP) sessions from one router to another router across a shared network infrastructure. This case study is primarily intended for network administrators and operations teams working for ISPs who provide access VPN services to enterprise customers. This case study is also useful to enterprise customers who want to establish access VPNs. This access VPN:
Enables remote employees to access the enterprise customers intranet resources when and where they want to Allows enterprise customers networks to span from an intranet to remote clients who are connected to analog modems
Figure 6 shows an enterprise customer with a specic business objective. The enterprise customer wants to give 500 users dial-up modem access to intranet resources through the public switched telephone network (PSTN). To do this, the enterprise customer contracts with an ISP who is responsible for the required dial hardware and wide-area network (WAN) services. The ISP and enterprise customer decide to use L2F, because it is a stable tunneling protocol supported by many vendors and client software applications.
Figure 6 End-to-End Access VPN Solution
PSTN
Internet service provider Access VPN
Enterprise customer
L2F Case Study Overview 13
18023
500 users
L2F tunnel
The ISP:
Purchases, congures, and maintains the network access server (NAS). The NAS is the point-of-presence (POP) used to forward PPP sessions to the enterprise customers network. Supports and maintains in-house modem pools. Maintains an authentication, authorization, and accounting (AAA) server that authenticates the IP tunnel endpoint and domain name assigned to the enterprise customers home gateway. Maintains an edge router that connects the ISPs network to the enterprise customers network.
The enterprise customer: Purchases, congures, and maintains a home gateway and clients. Authenticates and authorizes remote users usernames and passwords by using a AAA server.
Note This case study illustrates one example of a NAS-initiated access VPN. Networks containing
clients who initiate encrypted IP tunnels to home gateways are called client-initiated access VPNs.
Figure 7 shows the specic network devices used to build the access VPN in this case study.
The ISP is responsible for a Cisco AS5300 network access server, a CiscoSecure ACS UNIX server, and a Cisco 4500-M edge router. The enterprise customer is responsible for a Cisco 7206 home gateway, a CiscoSecure ACS NT server, and the remote clients using modems.
The L2F tunnel runs between the Cisco AS5300 and Cisco 7206. The L2F tunnel is forwarded across a Frame Relay network.
Figure 7 Access VPN Case Study Network Topology ISP's network CiscoSecure ACS UNIX server Enterprise customer's network Clients using modems PSTN POTS lines L2F tunnel Ethernet Cisco 4500-M edge router
1 DATA 2 DATA 3 DATA OK OK OK OK POWER
Cisco AS5300 network access 4 TI PRI lines server
CiscoSecure ACS NT server
Ethernet Cisco 7206 home gateway

6
Serial lines
Frame Relay data network
14
18024
Device Characteristics
This case study does not describe how to congure the edge router, the Frame Relay data network, or the serial interfaces on the home gateway. Although these components are shown in Figure 7, they are not critical in understanding how to build an access VPN solution and are outside the scope of this case study. For more information about how to congure Frame Relay and serial interfaces, refer to the Wide-Area Networking Conguration Guide for Cisco IOS Release 12.0. See Overview of Access VPNs and Tunneling Technologies earlier in this document for an overview of access VPN solutions.
Device Characteristics
Table 4 provides a more detailed description of the hardware and software components used in the case study.
Table 4 Hardware and Software Used in the Case Study CiscoSecure ACS UNIX Server Sun workstation 1 Ethernet interface
NAS Chassis type Physical interfaces Cisco AS5300 1 Ethernet interface 4 T1 PRI ports 96 terminal lines Hardware components Cisco AS5300 network access server 96 MICA modems, 2 MICA CC and 1 Quad T1/PRI T1 cable RJ45 to RJ45
Home Gateway Cisco 7206 1 Fast Ethernet interface 4 serial interfaces Cisco 7206, 6-slot chassis, 1 AC power supply Cisco 7200 series input/output controller with Fast Ethernet Cisco 7200 series network processing engine 4-port serial port adapter, enhanced V.35 cable, DTE, male, 10 feet
CiscoSecure ACS NT Server PC workstation 1 Ethernet interface
Client PC laptop 1 RJ-11 port
1 Ethernet card
1 Ethernet card
1 internal modem
Software loaded
Cisco IOS Release 11.3(7)AA Cisco AS5300 series IP
Cisco IOS Release 12.0(2)T Cisco 7200 series IP N/A
CiscoSecure ACS UNIX version 2.3.1 Solaris 2.6
CiscoSecure ACS NT version 2.1 Windows NT 4.0 N/A
Windows 95
Telephone number or username
5550945
N/A
jeremy@hgw.com password = subaru
Table 4
Hardware and Software Used in the Case Study (Continued) CiscoSecure ACS UNIX Server 128 MB RAM 128 MB swap space
NAS Memory Cisco AS5300 main DRAM upgrade (from 32 MB to 64 MB) Cisco AS5300 system Flash upgrade (from 8 MB to 16 MB) Cisco AS5300 boot Flash upgrade (from 4 MB to 8 MB) Ethernet IP Address 172.22.66.23 255.255.255.192
Home Gateway Cisco 7200 I/O PCMCIA Flash memory, 20 MB Cisco 7200 NPE 64 MB DRAM upgrade kit
CiscoSecure ACS NT Server 128 MB RAM
Client 64 MB RAM
172.22.66.25 255.255.255.192
172.22.66.18 255.255.255.192
172.22.66.13 255.255.255.192
172.30.2.12
1. This is the PRI telephone number assigned to the central site (NAS). The PRI number is often called the hunt group number, which distributes calls among the available B channels. Make sure your PRI provider assigns all four PRI trunks on the Cisco AS5300 to this number. 2. The home gateway dynamically assigns this IP address to the client in this case study.
Conguration Tasks
To build the access VPN, the ISP and enterprise customer must perform three major tasks to build the access VPN in this case study:
Task 1Conguring the NAS for Basic Dial Access Task 2Conguring the Access VPN to Work with Local AAA Task 3Conguring the Access VPN to Work with Remote AAA
Table 5 describes each task in more detail and identies the devices related to each task. A user named Jeremy with the username jeremy@hgw.com appears in many congurations, illustrations, and examples in this case study. The goal of the case study is to give Jeremy basic IP and modem services by forwarding his PPP session from the NAS to the home gateway. To help you understand how the various hardware and software components work together to forward the PPP session, follow Jeremy through the case study.
Note If you use this document to congure your own network, be sure to substitute your own IP
addresses, passwords, usernames, hostnames, and telephone numbers.
16
Configuration Tasks
Table 5 Task
Relationship Between Conguration Tasks and Devices Description Conguring the NAS for Basic Dial Access Performed by the ISP. POTS line Devices Remote clients using modems PSTN
4 TI PRI lines
Cisco AS5300 NAS

23062
Conguring the Access VPN to Work with Local AAA Performed by the ISP and the enterprise customer.
Cisco AS5300 NAS

Cisco 4500-M edge router

Cisco 7206 home gateway

5 3 1
Serial lines
23064
6 4 2 0
Conguring the Access VPN to Work with Remote AAA Performed by the ISP and the enterprise customer.
CiscoSecure ACS UNIX server
Cisco AS5300 NAS



6
LAN
Serial lines
5 3 1
23065
4 2 0
18
Configuring the NAS for Basic Dial Access

Introduction
In this rst task, the ISP:
Congures the Cisco AS5300 network access server (NAS) to support basic IP and modem services. Veries that basic dial access works before the ISP starts forwarding PPP sessions to the enterprise customers home gateway. Troubleshoots the NAS if there are problems.
Figure 8 shows the ISPs basic dial access topology. Clients using modems dial in to the NAS over four T1 PRI lines that are assigned to 555-0945.
Figure 8 Basic Dial Access Network Topology
Clients using modems PSTN POTS lines
4 TI PRI lines 555-0945
Network administrator's PC RS-232 console cable
Ethernet
After the ISP completes this task, basic dial access will function as follows:
The client dials in to the NAS. The client and the NAS successfully complete PPP negotiation. The NAS assigns an IP address to the client. The client and NAS bidirectionally support IP services.
Configuring the NAS for Basic Dial Access 19
23067
Cisco AS5300 NAS
Conguring Basic Dial Access

To congure the NAS for basic dial access, the ISP completes the following steps:
Step 1Conguring the Host Name, Enable Password, and Service Time Stamps Step 2Conguring Local AAA Step 3Conguring the LAN Interface Step 4Commissioning the T1 Controllers Step 5Conguring the Serial Channels to Let Modem Calls Come In Step 6Conguring the Modems and Asynchronous Lines Step 7Specifying the IP Address Pool and DNS Servers Step 8Conguring the Group-Async Interface
Step 1Conguring the Host Name, Enable Password, and Service Time Stamps
In this step, the ISP:

Use this command
Router> enable
Assigns a host name to the NAS Sets up conguration privileges Turns on service time stamps
To do this Access privileged EXEC mode. Access global conguration mode1.
Router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)# hostname ISP_NAS
Assign a host name to the access server. A host name distinguishes the NAS from other devices on the network.
ISP_NAS(config)# enable secret letmein
Enter a secret enable password, which secures privileged EXEC mode. An enable password allows you to prevent unauthorized conguration changes. Make sure to change letmein to your own secret password.
ISP_NAS(config)# service password-encryption ISP_NAS(config)# service timestamps debug datetime msec ISP_NAS(config)# service timestamps log datetime msec
Encrypt passwords in the conguration le. Apply millisecond time stamping to debug and logging output. These time stamps help identify debug output when there is a lot of activity on the router.
1. If the logging output generated by the NAS interferes with your terminal screen, redisplay the current command line by using the Tab key.
20
Step 2Configuring Local AAA
Step 2Conguring Local AAA

Enables the authentication, authorization, and accounting (AAA) access control system Creates a local username database
AAA provides the primary framework through which you set up access control on the NAS. Authentication identies the client; authorization tells the client what it can do; accounting records what the client did do.
Use this command
ISP_NAS(config)# aaa new-model ISP_NAS(config)# aaa authentication ppp default local ISP_NAS(config)# username jane-admin password jane-password
To do this Initiate the AAA access control system. Congure PPP authentication to use the local database. Create a local login database and username for yourselfthe network administrator1.
Note This step also prevents you from getting locked out of
the access server.

ISP_NAS(config)# username jeremy password subaru
Create a local login username for the client. The username jeremy and password subaru are locally authenticated by the NAS. Later in the case study, jeremy is authenticated by the home gateways CiscoSecure AAA server (not the NAS).
1. Make sure you use your own username and password.
Step 3Conguring the LAN Interface


Use this command
Assigns an IP address to the Ethernet interface Brings up the interface

To do this Congure the IP address and subnet mask on the Ethernet interface. Do not forget to use your own IP address and subnet mask. Bring up the interface. This command changes the state of the interface from administratively down to up1.
ISP_NAS(config)# interface ethernet 0 ISP_NAS(config-if)# ip address 172.22.66.23 255.255.255.192
ISP_NAS(config-if)# no shutdown %LINK-3-UPDOWN: Interface Ethernet0, changed state to up ISP_NAS(config-if)# exit
1. The term administratively down means that the interface is intentionally shut down by the administrator. The shutdown command is applied to the interface.
Step 4Commissioning the T1 Controllers

Denes the ISDN switch type Commissions the T1 controllers to allow modem calls to come into the NAS. The ISP must specify the following information for each controller: Framing type Line code type Clock source Timeslot assignments
Use this command

ISP_NAS(config)# isdn switch-type primary-5ess
To do this Enter the telco switch type, which is 5ESS in this case study. An ISDN switch type that is specied in global conguration mode is automatically propagated into the individual serial interfaces (for example, interface serial 0:23, 1:23, 2:23, and 3:23).
ISP_NAS(config)# controller t1 0
Access controller conguration mode for the rst T1 controller, which is number 0. The controller ports are numbered 0 through 3 on the quad T1/PRI card. Enter the T1 framing type, which is extended super frame (ESF) in this case study. Enter the T1 line code type, which is B8ZS in this case study. Congure the access server to get its primary clocking from the T1 line assigned to controller 0. Line clocking comes from the remote switch.
ISP_NAS(config-controller)# framing esf
ISP_NAS(config-controller)# linecode b8zs ISP_NAS(config-controller)# clock source line primary
ISP_NAS(config-controller)# pri-group timeslots 1-24
Assign all 24 T1 timeslots as ISDN PRI channels. After you enter this command, a D-channel serial interface is instantly created (for example S0:23) as well as individual B-channel serial interfaces (for example S0:0, S0:1, S0:2, S0:3, and so on.). The D-channel interface functions like a dialer for all the 23 B channels using the controller. If this was an E1 interface, the PRI group range would be 1 to 31. The D-channel serial interfaces would be S0:15, S1:15, S2:15, and S3:15.
ISP_NAS(config-controller)# exit ISP_NAS(config#) controller ISP_NAS(config-controller)# ISP_NAS(config-controller)# ISP_NAS(config-controller)# ISP_NAS(config-controller)# ISP_NAS(config-controller)# t1 1 framing esf linecode b8zs clock source line secondary pri-group timeslots 1-24 exit
Exit back to global conguration mode. Congure the second controller, controller T1 1. Set the clocking to secondary. If the line clocking from controller T1 0 fails, the access server receives its clocking from controller T1 1.
22
Step 5Configuring the Serial Channels to Let Modem Calls Come In
Use this command

ISP_NAS(config#) controller ISP_NAS(config-controller)# ISP_NAS(config-controller)# ISP_NAS(config-controller)# ISP_NAS(config-controller)# ISP_NAS(config-controller)# ISP_NAS(config#) controller ISP_NAS(config-controller)# ISP_NAS(config-controller)# ISP_NAS(config-controller)# ISP_NAS(config-controller)# ISP_NAS(config-controller)# ISP_NAS(config#) t1 2 framing esf linecode b8zs clock source internal pri-group timeslots 1-24 exit t1 3 framing esf linecode b8zs clock source internal pri-group timeslots 1-24 exit
To do this Congure the remaining two controllers. Set both clocking entries to internal because the primary and secondary clock sources have already been assigned.
Step 5Conguring the Serial Channels to Let Modem Calls Come In


Use this command
Congures the D channels to allow incoming voice calls to be routed to the integrated MICA modems. The D channel is the signaling channel. Uses the D channel to control the behavior of individual B channels
To do this Access conguration mode for the D-channel serial interface that corresponds to controller T1 0. The behavior of serial 0:0 through serial 0:22 is controlled by the conguration instructions provided for serial 0:23. This concept is also true for the other remaining D-channel congurations.
ISP_NAS(config)# interface serial 0:23
ISP_NAS(config-if)# isdn incoming-voice modem
Enable analog modem voice calls coming in through the B channels to be connected to the integrated modems. Exit back to global conguration mode. Congure the three remaining D channels with the same ISDN incoming-voice modem setting.
ISP_NAS(config-if)# exit ISP_NAS(config)# interface serial 1:23 ISP_NAS(config-if)# isdn incoming-voice modem ISP_NAS(config-if)# exit ISP_NAS(config)# interface serial 2:23 ISP_NAS(config-if)# isdn incoming-voice modem ISP_NAS(config-if)# exit ISP_NAS(config)# interface serial 3:23 ISP_NAS(config-if)# isdn incoming-voice modem ISP_NAS(config-if)# exit
Step 6Conguring the Modems and Asynchronous Lines

Denes a range of modem lines Enables PPP clients to dial in, bypass the EXEC facility, and automatically start PPP.
Congure the modems and lines after the ISDN channels are operational. Each modem corresponds with a dedicated asynchronous line inside the access server. The modem speed 115200 bps and hardware ow control are default values for integrated modems.
Use this command

ISP_NAS(config)# line 1 96
To do this Enter the range of modem lines that you want to congure. The NAS used in this case study has 96 integrated MICA modems. Enable PPP clients to dial in, bypass the EXEC facility, and automatically start PPP on the lines. The autoselect during-login command displays the username:password prompt as the modems connect.
Note These two autoselect commands enable EXEC (shell) and PPP services on the same lines.
ISP_NAS(config-line)# autoselect ppp ISP_NAS(config-line)# autoselect during-login
ISP_NAS(config-line)# modem inout
Support incoming and outgoing modem calls.
Step 7Specifying the IP Address Pool and DNS Servers


Use this command
Creates an IP addresses pool that contains one IP address Species a primary and secondary domain name server (DNS)
To do this Create an IP pool containing one IP address to assign to one client1. Specify the domain name servers on the network, which can be used for clients dialing in with PPP.
ISP_NAS(config)# ip local pool default 1.1.1.1
ISP_NAS(config)# async-bootp dns-server 171.68.10.70 171.68.10.140
1. Later in the case study, the client is assigned an IP address from the local IP pool configured on the home gateway. The NAS, which is maintained by the ISP, does not assign IP addresses to the enterprise customers clients when the network is configured as an access VPN.
Step 8Conguring the Group-Async Interface

Creates a group-async interface Projects protocol characteristics to 96 asynchronous interfaces
The group-async interface is a template that controls the conguration of all the asynchronous interfaces inside the NAS. Asynchronous interfaces are lines running in PPP mode. An asynchronous interface uses the same number as its corresponding line. Conguring all the asynchronous interfaces as an async group saves you time by reducing the number of conguration steps.
!
Use this command

ISP_NAS(config)# interface group-async 1 ISP_NAS(config-if)# ip unnumbered ethernet 0 ISP_NAS(config-if)# encapsulation ppp ISP_NAS(config-if)# async mode interactive
To do this Create the group-async interface. Use the IP address dened on the Ethernet interface. Enable PPP. Congure interactive mode on the asynchronous interfaces. Interactive mode means that clients can dial in to the NAS and get a router prompt or PPP session. Dedicated mode means that only PPP sessions can be established on the NAS. Clients cannot dial in and get an EXEC (shell) session.
24
Verifying Basic Dial Access
Use this command

ISP_NAS(config-if)# ppp authentication chap pap
To do this Congure CHAP and PAP authentication to be used on the interface during LCP negotiation. The access server rst authenticates with CHAP. If CHAP is rejected by the client, PAP authentication is used.
ISP_NAS(config-if)# peer default ip address pool default ISP_NAS(config-if)# group-range 1 96 Building configuration...
Assign IP addresses to clients from the default IP address pool. Specify the range of asynchronous interfaces to include in the group, which is usually equal to the number of modems in the access server.
Verifying Basic Dial Access

This section describes how to verify that the following end-to-end connections function as shown in Figure 9:
Step 1Checking the NAS Running Conguration Step 2Dialing in to the NAS Step 3Pinging the NAS Step 4Displaying Active Call Statistics on the NAS Step 5Pinging the Client Step 6Verifying That the Asynchronous Interface Is Up and That LCP Is Open
Basic Dial Access Network Topology Network administrator's PC RS-232 console cable
Figure 9 Clients using modems
4 TI PRI lines 555-0945 PSTN
POTS lines Cisco AS5300 NAS Ethernet
After you successfully test these connections, go to Conguring the Access VPN to Work with Local AAA. If you experience problems, see Troubleshooting Basic Dial Access.
Step 1Checking the NAS Running Conguration

Enter the show running-cong command in privileged EXEC mode to make sure that the NAS accepted the commands you entered:
ISP_NAS# show running-config Building configuration... Current ! version service service service configuration: 11.3 timestamps debug datetime msec timestamps log datetime msec password-encryption
23067
! hostname ISP_NAS ! aaa new-model aaa authentication ppp default local enable secret 5 $1$AXl/$27hOM6j51a5P76Enq.LCf0 ! ! username jeremy password 7 021511590A141A username jane-admin password 7 0501090A6C5C4F1A0A1218000F ! async-bootp dns-server 171.68.10.70 171.68.10.140 isdn switch-type primary-5ess ! controller T1 0 framing esf clock source line primary linecode b8zs pri-group timeslots 1-24 ! controller T1 1 framing esf clock source line secondary linecode b8zs pri-group timeslots 1-24 ! controller T1 2 framing esf clock source internal linecode b8zs pri-group timeslots 1-24 ! controller T1 3 framing esf clock source internal linecode b8zs pri-group timeslots 1-24 ! ! interface Ethernet0 ip address 172.22.66.23 255.255.255.192 ! interface Serial0:23 no ip address isdn switch-type primary-5ess isdn incoming-voice modem no cdp enable ! interface Serial1:23 no ip address isdn switch-type primary-5ess isdn incoming-voice modem no cdp enable ! interface Serial2:23 no ip address isdn switch-type primary-5ess isdn incoming-voice modem no cdp enable ! interface Serial3:23 no ip address isdn switch-type primary-5ess isdn incoming-voice modem no cdp enable
26
Step 2Dialing in to the NAS
! interface FastEthernet0 no ip address shutdown ! interface Group-Async1 ip unnumbered Ethernet0 encapsulation ppp async mode interactive peer default ip address pool default ppp authentication chap pap group-range 1 96 ! ip local pool default 1.1.1.1 ip classless ip route 0.0.0.0 0.0.0.0 172.22.66.1 ! line con 0 transport input none line 1 96 autoselect during-login autoselect ppp modem InOut line aux 0 line vty 0 4 ! end

From the client, dial in to the NAS. Use the PRI telephone number assigned to the NAS T1 trunks. Sometimes the PRI telephone is called the hunt group number. Figure 10 shows the username, password, and PRI telephone entered in the Windows 95 dial-up networking utility.
Figure 10 Windows 95 Dial-Up Networking Utility
As the call comes into the NAS, a LINK-3-UPDOWN message automatically appears on the NAS terminal screen. In this example, the call comes in to the NAS on asynchronous interface 47. The asynchronous interface is up.
*Jan 1 21:22:18.410: %LINK-3-UPDOWN: Interface Async47, changed state to up
Note No debug commands are turned on to display this log message. Start troubleshooting the NAS
if you do not see this message after 30 seconds of when the client rst transmits the call.
Step 3Pinging the NAS

Ping the NAS from the client. From the Windows 95 desktop:
(a) (b) (c) (d) (e)
Click Start. Select Run. Enter ping 172.22.66.23. See Figure 11. Click OK. Look at the ping terminal screen and verify that the NAS is sending ping reply packets to the client. See Figure 12.
Windows 95 Ping Utility
Figure 11
28
Step 4Displaying Active Call Statistics on the NAS
Figure 12
Ping Reply Packets Sent from the NAS to the Client
Step 4Displaying Active Call Statistics on the NAS

From the NAS, enter the show caller command and show caller user name command to verify that the client received an IP address. This example shows that Jeremy is using TTY line 47, asynchronous interface 47, and IP address 1.1.1.1. The network administrator jane-admin is using console 0.
ISP_NAS# show caller Line User con 0 jane-admin tty 47 jeremy As47 jeremy ISP_NAS# show caller user jeremy User: jeremy, line tty 47, service Async, active 00:01:49 TTY: Line 47, running PPP on As47, idle 00:00:00 Line: Baud rate (TX/RX) is 115200/115200, no parity, 1 stopbits, 8 databits Status: Ready, Active, No Exit Banner, Async Interface Active HW PPP Support Active Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out Modem Callout, Modem RI is CD, Line is permanent async interface, Integrated Modem Modem State: Ready Timeouts: Idle EXEC Idle Session Modem Answer Session Dispatch 00:10:00 never never not set User: jeremy, line As47, service PPP, active 00:01:45 PPP: LCP Open, CHAP (<- AAA), IPCP IP: Local 172.22.66.23, remote 1.1.1.1 Counts: 29 packets input, 1690 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 12 packets output, 255 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets Service TTY Async PPP Active 01:54:15 00:00:54 00:00:50
Note The show caller command was added to the Cisco IOS software at Release 11.3(5)AA. If your software version of software does not support the show caller command, use the show user command.
Step 5Pinging the Client

From the NAS, ping Jeremys PC at IP address 1.1.1.1:
ISP_NAS# ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.22.66.55, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 128/136/160 ms
Step 6Verifying That the Asynchronous Interface Is Up and That LCP Is Open
From the NAS, enter the show interface async 47 command to verify that the interface is up, LCP is open, and no errors are reported:
ISP_NAS# show interface async 47 Async47 is up, line protocol is up modem(slot/port)=1/46, state=CONNECTED dsx1(slot/unit/channel)=0/0/0, status=VDEV_STATUS_ACTIVE_CALL.VDEV_STATUS_ALL. Hardware is Async Serial Interface is unnumbered. Using address of Ethernet0 (172.22.66.23) MTU 1500 bytes, BW 115 Kbit, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set, keepalive not set DTR is pulsed for 5 seconds on reset LCP Open Open: IPCP Last input 00:00:46, output 00:02:42, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/10, 0 drops; input queue 1/10, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 37 packets input, 2466 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 12 packets output, 255 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions
30
Troubleshooting Basic Dial Access
Troubleshooting Basic Dial Access

This section provides the ISP with a methodology for troubleshooting basic dial access as described in Figure 13. Complete the following steps to perform basic dial-up fault isolation. The bolded lines of output indicate important information.

Figure 13
Step 1Checking the ISDN Status Step 2Troubleshooting PPP Negotiation Step 3Troubleshooting ISDN Step 4Checking the Error Status of the T1 Controllers Step 5Troubleshooting the Modem Call State Machine
Troubleshooting Flow Diagram for Basic Dial Access
Layer 1 is not active Are Layers 1 and 2 functioning properly?
Check the physical Layer Try another cable or port Check with your carrier
Check the ISDN status
No
Yes Layer 2 does not display MULTIPLE_FRAME_ESTABLISHED Troubleshoot PPP negotiation
Confirm the ISDN switch setting with the carrier Verify that the controller is up with no alarms and no errors
Turn on debug ppp negotiation and ping the NAS from the remote client
Did you see debug output on the NAS terminal screen? No
Yes
Check for failed authentication
Troubleshoot ISDN
Troubleshoot the modem call State machine

23290
If you use a Telnet session to connect to the NAS, enable the terminal monitor command, which ensures that your EXEC session is receiving the logging and debug output from the NAS. When you nish troubleshooting, enter the undebug all command to turn off all debug commands. Isolating debug output helps you efciently build a network.
Step 1Checking the ISDN Status

Enter the show isdn status command to conrm that Layer 1 is active and the display eld MULTIPLE_FRAME_ESTABLISHED appears at Layer 2. This example shows that each serial interface is functioning properly:
ISP_NAS# show isdn status Global ISDN Switchtype = primary-5ess ISDN Serial0:23 interface dsl 0, interface ISDN Switchtype = primary-5ess Layer 1 Status: ACTIVE Layer 2 Status: TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 1 Active Layer 3 Call(s) Activated dsl 0 CCBs = 1 CCB:callid=11E, sapi=0, ces=0, B-chan=12, calltype=DATA ISDN Serial1:23 interface dsl 1, interface ISDN Switchtype = primary-5ess Layer 1 Status: ACTIVE Layer 2 Status: TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 1 Active Layer 3 Call(s) Activated dsl 1 CCBs = 1 CCB:callid=12A, sapi=0, ces=0, B-chan=2, calltype=VOICE ISDN Serial2:23 interface dsl 2, interface ISDN Switchtype = primary-5ess Layer 1 Status: ACTIVE Layer 2 Status: TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 1 Active Layer 3 Call(s) Activated dsl 2 CCBs = 1 CCB:callid=143, sapi=0, ces=0, B-chan=7, calltype=DATA ISDN Serial3:23 interface dsl 3, interface ISDN Switchtype = primary-5ess Layer 1 Status: ACTIVE Layer 2 Status: TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 4 Active Layer 3 Call(s) Activated dsl 3 CCBs = 4 CCB:callid=160, sapi=0, ces=0, B-chan=14, calltype=VOICE CCB:callid=162, sapi=0, ces=0, B-chan=17, calltype=VOICE CCB:callid=167, sapi=0, ces=0, B-chan=22, calltype=VOICE CCB:callid=168, sapi=0, ces=0, B-chan=23, calltype=VOICE Total Allocated ISDN CCBs = 7
32
Step 2Troubleshooting PPP Negotiation
If Layer 1 is not active:
Check the physical layer connectivity. Try using another port or cable. Check with your PRI provider.
If the display eld MULTIPLE_FRAME_ESTABLISHED does not appear at Layer 2: Verify that the ISDN switch setting is correct. Enter the show controller command to verify that the controller is up without any alarms or errors. For an example, see Step 4Checking the Error Status of the T1 Controllers.
Note If you isolated the problem to Layers 1 or 2 and you think that you xed it, go back to the
verication steps and conrm that the problem is resolved. If the client still cannot dial in to the NAS, go to Step 2.

Troubleshoot PPP negotiation by:
(a) (b) (c)
Turning on the debug ppp negotiation command. Pinging the NAS from the client. Observing the debug output messages that appear on the NAS terminal screen. If you do not see debug output, turn off the debug ppp negotiation command and go to Step 3.
It is important to understand what a successful debug PPP sequence looks like before you troubleshoot PPP negotiation. In this way, comparing a faulty PPP debug session against a successfully completed debug PPP sequence saves you time and effort. Following is an example of a successful PPP sequence. See Table 6 for a detailed description of the output elds.
ISP_NAS# debug ppp negotiation PPP protocol negotiation debugging is on ISP_NAS# show debug PPP: PPP protocol negotiation debugging is on ISP_NAS# Mar 13 10:57:13.415: Mar 13 10:57:15.415: Mar 13 10:57:15.415: Mar 13 10:57:15.415: Mar 13 10:57:15.415: Mar 13 10:57:15.415: Mar 13 10:57:15.415: Mar 13 10:57:15.543: Mar 13 10:57:15.543: Mar 13 10:57:15.543: Mar 13 10:57:15.543: Mar 13 10:57:15.543: Mar 13 10:57:15.547: Mar 13 10:57:16.919: Mar 13 10:57:16.919: Mar 13 10:57:16.919: Mar 13 10:57:16.919: Mar 13 10:57:16.919: Mar 13 10:57:16.919: Mar 13 10:57:16.919:
%LINK-3-UPDOWN: Interface Async1, changed state to up As1 LCP: O CONFREQ [ACKrcvd] id 2 len 25 As1 LCP: ACCM 0x000A0000 (0x0206000A0000) As1 LCP: AuthProto CHAP (0x0305C22305) As1 LCP: MagicNumber 0x1084F0A2 (0x05061084F0A2) As1 LCP: PFC (0x0702) As1 LCP: ACFC (0x0802) As1 LCP: I CONFACK [REQsent] id 2 len 25 As1 LCP: ACCM 0x000A0000 (0x0206000A0000) As1 LCP: AuthProto CHAP (0x0305C22305) As1 LCP: MagicNumber 0x1084F0A2 (0x05061084F0A2) As1 LCP: PFC (0x0702) As1 LCP: ACFC (0x0802) As1 LCP: I CONFREQ [ACKrcvd] id 4 len 23 As1 LCP: ACCM 0x000A0000 (0x0206000A0000) As1 LCP: MagicNumber 0x001327B0 (0x0506001327B0) As1 LCP: PFC (0x0702) As1 LCP: ACFC (0x0802) As1 LCP: Callback 6 (0x0D0306) As1 LCP: O CONFREJ [ACKrcvd] id 4 len 7
Mar 13 10:57:16.919: Mar 13 10:57:17.047: Mar 13 10:57:17.047: Mar 13 10:57:17.047: Mar 13 10:57:17.047: Mar 13 10:57:17.047: Mar 13 10:57:17.047: Mar 13 10:57:17.047: Mar 13 10:57:17.047: Mar 13 10:57:17.047: Mar 13 10:57:17.047: Mar 13 10:57:17.047: Mar 13 10:57:17.047: Mar 13 10:57:17.047: Mar 13 10:57:17.191: Mar 13 10:57:17.191: Mar 13 10:57:17.191: Mar 13 10:57:17.191: Mar 13 10:57:17.191: Mar 13 10:57:17.303: Mar 13 10:57:17.303: 6002D0F01) Mar 13 10:57:17.303: Mar 13 10:57:17.303: Mar 13 10:57:17.303: Mar 13 10:57:17.303: Mar 13 10:57:17.303: Mar 13 10:57:17.303: Mar 13 10:57:17.303: 6002D0F01) Mar 13 10:57:17.303: Mar 13 10:57:17.303: Mar 13 10:57:17.319: Mar 13 10:57:17.319: 1) Mar 13 10:57:17.319: 0104) Mar 13 10:57:17.319: Mar 13 10:57:17.319: Mar 13 10:57:17.319: Mar 13 10:57:17.319: Mar 13 10:57:17.319: Mar 13 10:57:18.191: nged state to up Mar 13 10:57:19.191: Mar 13 10:57:19.191: Mar 13 10:57:19.191: Mar 13 10:57:19.315: Mar 13 10:57:19.315: Mar 13 10:57:20.307: Mar 13 10:57:20.307: Mar 13 10:57:20.307: Mar 13 10:57:20.307: Mar 13 10:57:20.307: Mar 13 10:57:20.307: Mar 13 10:57:20.307: Mar 13 10:57:20.307: Mar 13 10:57:20.307: Mar 13 10:57:20.419: Mar 13 10:57:20.419: Mar 13 10:57:20.419: Mar 13 10:57:20.419: Mar 13 10:57:20.419: Mar 13 10:57:20.419: Mar 13 10:57:20.419:
As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1
LCP: Callback 6 (0x0D0306) LCP: I CONFREQ [ACKrcvd] id 5 len 20 LCP: ACCM 0x000A0000 (0x0206000A0000) LCP: MagicNumber 0x001327B0 (0x0506001327B0) LCP: PFC (0x0702) LCP: ACFC (0x0802) LCP: O CONFACK [ACKrcvd] id 5 len 20 LCP: ACCM 0x000A0000 (0x0206000A0000) LCP: MagicNumber 0x001327B0 (0x0506001327B0) LCP: PFC (0x0702) LCP: ACFC (0x0802) LCP: State is Open PPP: Phase is AUTHENTICATING, by this end CHAP: O CHALLENGE id 1 len 28 from "ISP_NAS" CHAP: I RESPONSE id 1 len 30 from "jeremy" CHAP: O SUCCESS id 1 len 4 PPP: Phase is UP IPCP: O CONFREQ [Closed] id 1 len 10 IPCP: Address 172.22.66.23 (0x0306AC164217) IPCP: I CONFREQ [REQsent] id 1 len 40 IPCP: CompressType VJ 15 slots CompressSlotID (0x020 IPCP: Address 0.0.0.0 (0x030600000000) IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) IPCP: O CONFREJ [REQsent] id 1 len 22 IPCP: CompressType VJ 15 slots CompressSlotID (0x020 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) CCP: I CONFREQ [Not negotiated] id 1 len 15 CCP: MS-PPC supported bits 0x00000001 (0x12060000000 Stacker history 1 check mode EXTENDED (0x110500
As1 CCP:
As1 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP As1 LCP: (0x80FD0101000F12060000000111050001) As1 LCP: (0x04) As1 IPCP: I CONFACK [REQsent] id 1 len 10 As1 IPCP: Address 172.22.66.23 (0x0306AC164217) %LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, cha As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: TIMEout: State ACKrcvd O CONFREQ [ACKrcvd] id 2 len 10 Address 172.22.66.23 (0x0306AC164217) I CONFACK [REQsent] id 2 len 10 Address 172.22.66.23 (0x0306AC164217) I CONFREQ [ACKrcvd] id 2 len 34 Address 0.0.0.0 (0x030600000000) PrimaryDNS 0.0.0.0 (0x810600000000) PrimaryWINS 0.0.0.0 (0x820600000000) SecondaryDNS 0.0.0.0 (0x830600000000) SecondaryWINS 0.0.0.0 (0x840600000000) O CONFREJ [ACKrcvd] id 2 len 16 PrimaryWINS 0.0.0.0 (0x820600000000) SecondaryWINS 0.0.0.0 (0x840600000000) I CONFREQ [ACKrcvd] id 3 len 22 Address 0.0.0.0 (0x030600000000) PrimaryDNS 0.0.0.0 (0x810600000000) SecondaryDNS 0.0.0.0 (0x830600000000) O CONFNAK [ACKrcvd] id 3 len 22 Address 1.1.1.1 (0x030601010101) PrimaryDNS 171.68.10.70 (0x8106AB440A46)
34
Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar
13 13 13 13 13 13 13 13 13 13 13
10:57:20.419: 10:57:20.543: 10:57:20.543: 10:57:20.547: 10:57:20.547: 10:57:20.547: 10:57:20.547: 10:57:20.547: 10:57:20.547: 10:57:20.547: 10:57:20.551:
As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1
IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP: IPCP:
SecondaryDNS 171.68.10.140 (0x8306AB440A8C) I CONFREQ [ACKrcvd] id 4 len 22 Address 1.1.1.1 (0x030601010101) PrimaryDNS 171.68.10.70 (0x8106AB440A46) SecondaryDNS 171.68.10.140 (0x8306AB440A8C) O CONFACK [ACKrcvd] id 4 len 22 Address 1.1.1.1 (0x030601010101) PrimaryDNS 171.68.10.70 (0x8106AB440A46) SecondaryDNS 171.68.10.140 (0x8306AB440A8C) State is Open Install route to 1.1.1.1
Table 6 Time Stamp 10:57:15.415 10:57:15.543 10:57:16.919 10:57:16.919 10:57:17.047 10:57:17.047 10:57:17.047 10:57:17.047 to 10:57:17.191
Time Stamps and Descriptions for Debug PPP Negotiation Events Description Outgoing conguration request (O CONFREQ). The NAS sends an outgoing PPP conguration request packet to the client. Incoming conguration acknowledgment (I CONFACK). The client acknowledges the NAS PPP request. Incoming conguration request (I CONFREQ). The client wants to negotiate the callback protocol. Outgoing conguration reject (O CONFREJ). The NAS rejects the callback option. Incoming conguration request (I CONFREQ). The client requests a new set of options. Notice that Microsoft Callback is not requested this time. Outgoing conguration acknowledgment (O CONFACK). The NAS accepts the new set of options. PPP LCP negotiation is completed successfully (LCP: State is Open). Both sides have acknowledged (CONFACK) the other sides conguration request (CONFREQ). PPP authentication is completed successfully. After LCP negotiates, authentication starts. Authentication must take place before any network protocols, such as IP, are delivered. Both sides authenticate with the method negotiated during LCP. The Cisco AS5300 is authenticating the client using CHAP.
10:57:20.551
The state is open for IP Control Protocol (IPCP). A route is negotiated and installed for the IPCP peer, which is assigned IP address 1.1.1.1.
Failed authentication is a common occurrence. Miscongured or mismatched usernames and passwords create error messages in debug output. The following example shows that the username sam-admin does not have permission to dial in to the NAS, which does not have a local username congured for this user. To x the problem, use the username name password password command to add the username sam-admin to the NAS local AAA database:
Mar 13 Mar 13 Mar 13 Mar 13 Mar 13 found Mar 13 ure" Mar 13 11:01:42.399: 11:01:42.399: 11:01:42.399: 11:01:42.539: 11:01:42.539: As2 As2 As2 As2 As2 LCP: State is Open PPP: Phase is AUTHENTICATING, by this end CHAP: O CHALLENGE id 1 len 28 from "ISP_NAS" CHAP: I RESPONSE id 1 len 30 from "sam-admin" CHAP: Unable to validate Response. Username sam-admin not
11:01:42.539: As2 CHAP: O FAILURE id 1 len 26 msg is "Authentication fail 11:01:42.539: As2 PPP: Phase is TERMINATING
The following example shows that the username sam-admin is congured on the NAS. However, the password comparison failed. To x this problem, use the username name password password command to specify sam-admins correct login password:
Mar Mar Mar Mar Mar Mar 13 13 13 13 13 13 11:04:06.843: 11:04:06.843: 11:04:06.843: 11:04:06.987: 11:04:06.987: 11:04:06.987: As3 As3 As3 As3 As3 As3 LCP: State is Open PPP: Phase is AUTHENTICATING, by this end CHAP: O CHALLENGE id 1 len 28 from "ISP_NAS" CHAP: I RESPONSE id 1 len 30 from "sam-admin" CHAP: O FAILURE id 1 len 25 msg is "MD/DES compare failed" PPP: Phase is TERMINATING
Note If you isolated the problem to PPP negotiation and you think that you xed it, go back to the
verication steps and conrm that the problem is resolved. If you are still having problems, go to Step 3.
Step 3Troubleshooting ISDN

Troubleshoot ISDN if no debug output appeared when you tried debugging PPP negotiation. Turn on ISDN Q.931 debugging and verify that no other debug commands are enabled:
ISP_NAS# debug isdn q931 ISDN Q931 packets debugging is on ISP_NAS# show debug ISDN: ISDN Q931 packets debugging is on
Send a PPP modem call into the NAS. As the call enters the access server, the following successful call setup messages appear on the NAS terminal screen. Refer to Table 7 for a detailed description of the output elds.
ISP_NAS# Mar 13 11:06:01.715: Mar 13 11:06:01.715: Mar 13 11:06:01.719: Mar 13 11:06:01.719: n-ISDN Mar 13 11:06:01.719: Mar 13 11:06:01.719: Mar 13 11:06:01.719: Mar 13 11:06:01.719: Mar 13 11:06:01.719: Mar 13 11:06:01.867: Mar 13 11:06:01.895: Mar 13 11:06:33.619: Mar 13 11:06:38.903: nged state to up ISDN Se0:23: RX <- SETUP pd = 8 callref = 0x02AD Bearer Capability i = 0x8090A2 Channel ID i = 0xA98381 Progress Ind i = 0x8283 - Origination address is no Calling Party Number i = '!', 0x83, '4089548021' Called Party Number i = 0xC1, '5550945' ISDN Se0:23: TX -> CALL_PROC pd = 8 callref = 0x82AD Channel ID i = 0xA98381 ISDN Se0:23: TX -> ALERTING pd = 8 callref = 0x82AD ISDN Se0:23: TX -> CONNECT pd = 8 callref = 0x82AD ISDN Se0:23: RX <- CONNECT_ACK pd = 8 callref = 0x02AD %LINK-3-UPDOWN: Interface Async4, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4, cha
If this debug output is not displayed on your terminal screen, conrm that the client is dialing the correct telephone number. If the number is correct, troubleshoot the problem with your PRI provider. If you are still having problems, go to Step 4.
36
Step 4Checking the Error Status of the T1 Controllers
Table 7 Time Stamp 11:06:01.715 11:06:01.719 11:06:01.867 11:06:01.895
Time Stamps and Descriptions for Debug ISDN Q.931 Events Description The NAS receives (RX) the ISDN setup message for an incoming call. Call characteristics appear. The NAS transmits (TX) a call-proceeding message. The NAS has not answered the call as yet. The NAS transmits a connect message and answers the call. The NAS receives a connect acknowledgment, and the connection is established.
Step 4Checking the Error Status of the T1 Controllers

Enter the show controller t1 command to display the error status of the T1 controllers. A properly functioning T1 0 controller displays T1 0 is up and No alarms detected. The following example shows four T1 controllers in good working condition:
ISP_NAS# show controller t1 T1 0 is up. Applique type is Channelized T1 No alarms detected. Version info of slot 0: HW: 4, Firmware: 16, PLD Rev: 0 Manufacture Cookie Info: EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x42, Board Hardware Version 1.32, Item Number 800-2540-2, Board Revision A0, Serial Number 11488142, PLD/ISP Version 0.0, Manufacture Date 10-Nov-1998. Framing is ESF, Line Code is B8ZS, Clock Source is Line Primary. Data in current interval (748 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs Total Data (last 30 15 minute intervals): 0 Line Code Violations, 0 Path Code Violations, 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins, 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs T1 1 is up. Applique type is Channelized T1 No alarms detected. Version info of slot 0: HW: 4, Firmware: 16, PLD Rev: 0 Manufacture Cookie Info: EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x42, Board Hardware Version 1.32, Item Number 800-2540-2, Board Revision A0, Serial Number 11488142, PLD/ISP Version 0.0, Manufacture Date 10-Nov-1998. Framing is ESF, Line Code is B8ZS, Clock Source is Line Secondary . Data in current interval (751 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs Total Data (last 30 15 minute intervals): 0 Line Code Violations, 0 Path Code Violations, 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins, 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
T1 2 is up. Applique type is Channelized T1 No alarms detected. Version info of slot 0: HW: 4, Firmware: 16, PLD Rev: 0 Manufacture Cookie Info: EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x42, Board Hardware Version 1.32, Item Number 800-2540-2, Board Revision A0, Serial Number 11488142, PLD/ISP Version 0.0, Manufacture Date 10-Nov-1998. Framing is ESF, Line Code is B8ZS, Clock Source is Internal. Data in current interval (755 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs Total Data (last 30 15 minute intervals): 0 Line Code Violations, 0 Path Code Violations, 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins, 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs T1 3 is up. Applique type is Channelized T1 No alarms detected. Version info of slot 0: HW: 4, Firmware: 16, PLD Rev: 0 Manufacture Cookie Info: EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x42, Board Hardware Version 1.32, Item Number 800-2540-2, Board Revision A0, Serial Number 11488142, PLD/ISP Version 0.0, Manufacture Date 10-Nov-1998. Framing is ESF, Line Code is B8ZS, Clock Source is Internal. Data in current interval (757 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs Total Data (last 30 15 minute intervals): 0 Line Code Violations, 0 Path Code Violations, 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins, 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
If counters increase on a specic T1 controller, look closely at the error statistics. Focus on the current interval that is indented under the display eld Data in current interval. Error counters are recorded over a 24-hour period in 15-minute intervals. You must specify a specic controller number to see this detailed information. Enter the clear controller t1 number command before you look for current error statistics. Error counters stop increasing when the controller is congured correctly.
Step 5Troubleshooting the Modem Call State Machine

Troubleshoot the modems call state machine (CSM) by using the debug modem csm command. Troubleshoot the CSM if you do not see PPP debug output, and the show isdn status command and debug isdn q931 command demonstrate good working status:
ISP_NAS# debug modem csm Modem Management Call Switching Module debugging is on ISP_NAS# show debug Modem Management: Modem Management Call Switching Module debugging is on
38
Step 5Troubleshooting the Modem Call State Machine
Send a PPP modem call into the NAS. Transition states in the debug output signify that everything is operating properly. If you do not see transition states, look at the disconnect reason for the modem. For example, enter the show modem log 1/4 command. See the following example of successful debug output for the debug modem csm command:
ISP_NAS# Mar 13 11:13:12.487: EVENT_FROM_ISDN::dchan_idb=0x60EA108C, call_id=0x1D, ces=0x 1bchan=0x0, event=0x1, cause=0x0 Mar 13 11:13:12.487: VDEV_ALLOCATE: slot 1 and port 4 is allocated. Mar 13 11:13:12.487: EVENT_FROM_ISDN:(001D): DEV_INCALL at slot 1 and port 4 Mar 13 11:13:12.487: CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 4 Mar 13 11:13:12.487: Mica Modem(1/4): Configure(0x1 = 0x0) Mar 13 11:13:12.487: Mica Modem(1/4): Configure(0x23 = 0x0) Mar 13 11:13:12.487: Mica Modem(1/4): Call Setup Mar 13 11:13:12.611: Mica Modem(1/4): State Transition to Call Setup Mar 13 11:13:12.611: Mica Modem(1/4): Went offhook Mar 13 11:13:12.611: CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 4 Mar 13 11:13:12.631: EVENT_FROM_ISDN::dchan_idb=0x60EA108C, call_id=0x1D, ces=0x1 bchan=0x0, event=0x4, cause=0x0 Mar 13 11:13:12.631: EVENT_FROM_ISDN:(001D): DEV_CONNECTED at slot 1 and port 4 Mar 13 11:13:12.631: CSM_PROC_IC4_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 4 Mar 13 11:13:12.631: Mica Modem(1/4): Link Initiate Mar 13 11:13:13.751: Mica Modem(1/4): State Transition to Connect Mar 13 11:13:18.903: Mica Modem(1/4): State Transition to Link ISP_NAS# Mar 13 11:13:37.051: Mica Modem(1/4): State Transition to Trainup Mar 13 11:13:38.731: Mica Modem(1/4): State Transition to EC Negotiating Mar 13 11:13:39.387: Mica Modem(1/4): State Transition to Steady State Mar 13 11:13:42.007: %LINK-3-UPDOWN: Interface Async5, changed state to up Mar 13 11:13:46.751: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async5, cha nged state to up Mar 13 11:14:41.803: Mica Modem(1/4): State Transition to Steady State Speedshif ting Mar 13 11:14:44.139: Mica Modem(1/4): State Transition to Steady State Mar 13 11:17:30.475: %SYS-5-CONFIG_I: Configured from console by vty0 (171.68.20 1.22)
Note If you are still experiencing problems, contact your escalation support personnel.
40
Configuring the Access VPN to Work with Local AAA

Introduction
In this second task, the ISP and enterprise customer:
Congure their network devices to work as an access VPN Use local AAA to authenticate the tunnel and the users Verify that the access VPN works properly Troubleshoot the access VPN if there are problems
The ISP congures the NAS, and the enterprise customer congures the home gateway. After the ISP and enterprise customer verify that their access VPN works by using local AAA, they recongure their devices to use remote AAA servers. See Conguring the Access VPN to Work with Remote AAA. Figure 1 shows the access VPN network topology. The tunnel and user authentication occurs locally between the Cisco AS5300 NAS and the Cisco 7206 home gateway.
Figure 14 Access VPN Topology Using Local AAA ISP's network Enterprise customer's network
4 TI PRI lines
Cisco AS5300 NAS Ethernet


6
Serial lines Ethernet

Configuring the Access VPN to Work with Local AAA 41
23066
Once the ISP and enterprise customer have completed this task, the network will function as follows:
When the user Jeremy wants to connect to the enterprise customers network, he dials in to the NAS by using the username jeremy@hgw.com. The NAS and the client perform LCP negotiation. The NAS authenticates the domain name hgw.com and determines the tunnel endpoint information. The NAS negotiates an L2F tunnel with the home gateway. Once the tunnel is established, the NAS forwards the call to the home gateway. The home gateway authenticates the username, jeremy, and assigns the client an IP address. (It can optionally assign IP addresses for DNS and WINS servers.) The client and the home gateway can now exchange PPP packets. The NAS now acts as a transparent PPP frame forwarder.
Conguring the Access VPN

To congure the NAS and home gateway to work as an access VPN, follow these steps:
Step 1Conguring the NAS Step 2Conguring the Home Gateway
Step 1Conguring the NAS

In this step, the ISP congures the NAS for VPN using local AAA. This step contains the following sections:
Enabling VPN to Send L2F Tunnels Authenticating and Authorizing the Tunnel Removing Unnecessary Commands
Note This step assumes that you already congured the NAS for basic dial access as described in
Conguring the NAS for Basic Dial Access. The access VPN described in this case study routes calls and builds tunnels based on domain namenot dialed number identication service (DNIS).
Enabling VPN to Send L2F Tunnels

In this section, the ISP:
Turns on VPN Sends an L2F tunnel out to the home gateway Congures the NAS to rst search for domain names before searching for DNIS
42
Step 1Configuring the NAS
Use this command

ISP_NAS(config)# vpdn enable ISP_NAS(config)# vpdn-group 1
To do this Turn on VPN1. Create a VPN group. VPN group statements are not needed for remote AAA scenarios.
ISP_NAS(config-vpdn)# request dialin l2f ip 172.22.66.25 domain hgw.com
Request a tunnel to 172.22.66.25 by using L2F, IP, and the domain name hgw.com. To accept the tunnel, the home gateway is congured with the accept dialin l2f virtual-template 1 remote ISP_NAS command and local name ENT_HGW command. To create a DNIS based tunnel, replace the domain keyword with the dnis keyword and phone number. The domain name identies which tunnel the user belongs to.
ISP_NAS(config-vpdn)# local name ISP_NAS ISP_NAS(config-vpdn)# exit
Turn on authentication for L2F. This name does not have to be the same as the hostname of the access server. Congure the software to rst search for the domain name before searching for DNIS. This command decreases connectivity time, which can reduce the number of system timeouts. By default, the Cisco IOS software rst looks to see if it can build out a tunnel based on DNIS. If DNIS is not found, the software searches for a domain name. The vpdn search-order domain dnis command reverses the default.
ISP_NAS(config)# vpdn search-order domain dnis
1. The Cisco IOS command syntax uses the more specific term virtual private dialup network (VPDN) instead of VPN.
Authenticating and Authorizing the Tunnel

Adds local usernames for bidirectional authentication between the NAS and home gateway Authenticates the tunnel between the remote peers and authorize the tunnel at the NAS
Use this command

ISP_NAS(config)# username ISP_NAS password cisco ISP_NAS(config)# username ENT_HGW password cisco
To do this Add local usernames with the same password for bidirectional tunnel authentication between the NAS and the home gateway. These usernames and password are called the tunnel secret.
Note The NAS and the home gateway must both have the same usernames with the same password.
These usernames are not related to client authentication.

ISP_NAS(config)# aaa authentication ppp default local ISP_NAS(config)# aaa authorization network default local
Authenticate the tunnel between the remote peers and authorize the tunnel at the NAS. The tunnel authorization phase includes an authentication step. The tunnel must be authenticated before it can be authorized.
Removing Unnecessary Commands


Use this command
Removes the local IP address pool Deletes the clients username and password from the local database
To do this Remove the local IP address pool from the NAS. The client is assigned an IP address from the home gateways local IP address pool. Remove the clients username and password from the local AAA database. The home gateway (not the NAS) now performs username authentication.
ISP_NAS(config)# no ip local pool default 1.1.1.1 ISP_NAS(config)# interface group-async 1 ISP_NAS(config-if)# no peer default ip address pool default ISP_NAS(config-if)# exit ISP_NAS(config)# no username jeremy password subaru
Step 2Conguring the Home Gateway

In this step, the enterprise customer congures the home gateway for VPN using local AAA. This step contains the following sections:
Conguring Basic Settings Conguring Local AAA Enabling VPN to Accept L2F Tunnels Creating the Virtual Template Specifying the IP Address Pool and BOOTP Servers
44
Step 2Configuring the Home Gateway
Conguring Basic Settings

In this section, the enterprise customer:
Congures the basic global conguration settings Congures the Fast Ethernet interface Veries connectivity with the NAS
We strongly recommend using the service password-encryption command so that your username passwords do not appear in the conguration output. The service timestamps debug datetime msec command includes millisecond dating on debug output. These time stamps help identify debug output when there is a lot of activity on the router.
Use this command
Router> enable Router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)# hostname ENT_HGW ENT_HGW(config)# enable secret letmein ENT_HGW(config)# service password-encryption
To do this Enter privileged EXEC mode. Enter global conguration mode.
Change the hostname to ENT_HGW. Change the enable secret to letmein. Encrypt passwords that appear as part of the conguration. Set debug time stamps to include millisecond dating. Set the username and password for the administrator. Set the default domain name that the Cisco IOS software will use to complete unqualied host names. Set the IP address of the host that will supply Domain Name System (DNS) information. Enter interface conguration mode. Assign an IP address to the FastEthernet 0/0 interface. Bring up the interface. Exit interface conguration mode. Exit global conguration mode. Verify connectivity between the home gateway and the NAS.
ENT_HGW(config)# service timestamps debug datetime msec ENT_HGW(config)# username jane-admin password jane-password ENT_HGW(config)# ip domain-name cisco.com
ENT_HGW(config)# ip name-server 171.68.10.70
ENT_HGW(config)# interface fastethernet 0/0 ENT_HGW(config-if)# ip address 172.22.66.25 255.255.255.192 ENT_HGW(config-if)# no shutdown %LINK-3-UPDOWN: Interface FastEthernet0, changed state to up ENT_HGW(config-if)# exit ENT_HGW(config)# exit ENT_HGW# ping 172.22.66.23 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.22.66.23, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 128/131/144 ms
Conguring Local AAA

In this section, the enterprise customer congures local AAA and the usernames needed to authenticate the user and the tunnel:
Use this command
ENT_HGW(config)# aaa new-model
To do this Enable the AAA access control system. This step immediately locks down login and PPP authentication. Specify that login users will be authenticated using the local database. Specify that PPP users will be authenticated using the local database. Specify that network-related service requests will be authorized by using the local database. Add the local username that is used to authenticate the remote user. Add local usernames and passwords for bidirectional tunnel authentication between the NAS and the home gateway. These usernames are called the tunnel secret.
Note The NAS and the home gateway must both have the same usernames with the same password.
ENT_HGW(config)# aaa authentication login default local
ENT_HGW(config)# aaa authentication ppp default local
ENT_HGW(config)# aaa authorization network default local
ENT_HGW(config)# username jeremy@hgw.com password subaru
ENT_HGW(config)# username ISP_NAS password cisco ENT_HGW(config)# username ENT_HGW password cisco
These usernames are not related to client authentication.
Enabling VPN to Accept L2F Tunnels

In this section, the enterprise customer enables and congure the home gateway for VPN using L2F tunnels:
Use this command
ENT_HGW(config)# vpdn enable ENT_HGW(config)# vpdn-group 1 ENT_HGW(config-vpdn)# accept dialin l2f virtual-template 1 remote ISP_NAS
To do this Enable VPN1. Create VPN group 1. Specify that the home gateway will accept L2F tunnels from the client, ISP_NAS, and clone the new virtual-access interface from virtual template 1. To accept the tunnel, the home gateway is congured with the request dialin l2f ip 172.22.66.25 domain hgw.com command and local name ENT_HGW command.
ENT_HGW(config-vpdn)# local name ENT_HGW
Specify that the L2F tunnel identies itself with the local hostname, ENT_HGW.
Creating the Virtual Template

In this section, the enterprise customer creates the virtual template that is used to clone virtual-access interfaces:
Output
ENT_HGW(config)# interface virtual-template 1
Purpose Create virtual template 1 that is used to clone virtual-access interfaces.
46
Verifying the Access VPN
ENT_HGW(config-if)# ip unnumbered fastethernet0/0
Specify that the virtual-access interfaces use the Fast Ethernet 0/0 interfaces IP address. Enable CHAP authentication using the local username database. Return an IP address from the default pool to the client. Enable PPP encapsulation.
ENT_HGW(config-if)# ppp authentication chap ENT_HGW(config-if)# peer default ip address pool default ENT_HGW(config-if)# encapsulation ppp
Specifying the IP Address Pool and BOOTP Servers

In this section, the enterprise customer species the IP address pool and the BOOTP servers. The IP address pool is the addresses that the home gateway assigns to clients. You must congure an IP address pool. You can also provide BOOTP servers. DNS servers translate hostnames to IP addresses. WINS servers, which are specied using the async-bootp nbns-server command, provide dynamic NetBIOS names that Windows devices use to communicate without IP addresses.
Use this command
ENT_HGW(config)# ip local pool default 172.30.2.1 172.30.2.96 ENT_HGW(config)# async-bootp dns-server 172.23.1.10 172.23.2.10 ENT_HGW(config)# async-bootp nbns-server 172.23.1.11 172.23.2.11
To do this Congure the default local pool of IP address that will be used by clients. (Optional) Return the congured addresses of Domain Name Servers in response to BOOTP requests. (Optional) Return the congured addresses of Windows NT servers in response to BOOTP requests.

This section describes how to verify that the following end-to-end connections function as shown in Figure 15:
Step 1Checking the NAS Running Conguration Step 2Checking the Home Gateway Running Conguration Step 3Dialing in to the NAS Step 4Pinging the Home Gateway Step 5Displaying Active Call Statistics on the Home Gateway Step 6Pinging the Client Step 7Verifying That the Virtual-Access Interface Is Up and That LCP Is Open Step 8Viewing Active L2F Tunnel Statistics
Figure 15
Access VPN Topology Using Local AAA ISP's network Enterprise customer's network
4 TI PRI lines
Cisco AS5300 NAS Ethernet


6
Serial lines Ethernet

After you successfully test these connections, go to Conguring the Access VPN to Work with Remote AAA. If you experience problems, see Troubleshooting the Access VPN.
Step 1Checking the NAS Running Conguration

Enter the show running-cong command in privileged EXEC mode to make sure the NAS accepted the commands you entered:
ISP_NAS# show running-config Building configuration... Current configuration: ! version 11.3 service timestamps debug datetime msec service timestamps log datetime msec service password-encryption ! hostname ISP_NAS ! aaa new-model aaa authentication ppp default local aaa authorization network default local enable secret 5 $1$AXl/$27hOM6j51a5P76Enq.LCf0 ! username jane-admin password 7 0501090A6C5C4F1A0A1218000F username ENT_HGW password 7 104D000A0618 username ISP_NAS password 7 13061E010803 vpdn enable ! vpdn search-order domain dnis vpdn-group 1 request dialin l2f ip 172.22.66.25 domain hgw.com local name ISP_NAS !
48
23066
Step 1Checking the NAS Running Configuration
async-bootp dns-server 171.68.10.70 171.68.10.140 isdn switch-type primary-5ess ! ! controller T1 0 framing esf clock source line primary linecode b8zs pri-group timeslots 1-24 ! controller T1 1 framing esf clock source line secondary linecode b8zs pri-group timeslots 1-24 ! controller T1 2 framing esf clock source internal linecode b8zs pri-group timeslots 1-24 ! controller T1 3 framing esf clock source internal linecode b8zs pri-group timeslots 1-24 ! ! interface Ethernet0 ip address 172.22.66.23 255.255.255.192 ! interface Serial0:23 no ip address isdn switch-type primary-5ess isdn incoming-voice modem no cdp enable ! interface Serial1:23 no ip address isdn switch-type primary-5ess isdn incoming-voice modem no cdp enable ! interface Serial2:23 no ip address isdn switch-type primary-5ess isdn incoming-voice modem no cdp enable ! interface Serial3:23 no ip address isdn switch-type primary-5ess isdn incoming-voice modem no cdp enable ! interface FastEthernet0 no ip address shutdown ! interface Group-Async1 ip unnumbered Ethernet0 encapsulation ppp async mode interactive no peer default ip address
ppp authentication chap pap group-range 1 96 ! ip classless ip route 0.0.0.0 0.0.0.0 172.22.66.1 ! ! line con 0 transport input none line 1 96 autoselect during-login autoselect ppp modem InOut line aux 0 line vty 0 4 ! end
Step 2Checking the Home Gateway Running Conguration

Enter the more system:running-cong command in privileged EXEC mode to make sure the home gateway accepted the commands you entered:
ENT_HGW# more system:running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug datetime msec service timestamps log uptime service password-encryption ! hostname ENT_HGW ! aaa new-model aaa authentication login default local aaa authentication ppp default local aaa authorization network default local enable secret 5 $1$44oH$gZlAZLwylZJSNKGDk.BKb0 ! username jane-admin password 7 00001C05 username ISP_NAS password 7 070C285F4D06 username ENT_HGW password 7 107249D900E4 username jeremy@hgw.com password 7 140407090D163F ip subnet-zero ip domain-name cisco.com ip name-server 171.68.10.70 ! vpdn enable ! vpdn-group 1 accept dialin l2f virtual-template 1 remote ISP_NAS local name ENT_HGW ! async-bootp dns-server 172.23.1.10 172.23.2.10 async-bootp nbns-server 172.23.1.11 172.23.2.11 ! ! ! interface FastEthernet0/0 ip address 172.22.66.25 255.255.255.192 no ip directed-broadcast
50
! . . . ! interface Virtual-Template1 ip unnumbered FastEthernet0/0 peer default ip address pool default ppp authentication chap ! ip local pool default 172.30.2.1 172.30.2.96 ip classless ip route 0.0.0.0 0.0.0.0 172.22.66.1 ! ! line con 0 transport input none line aux 0 line vty 0 4 password 7 045F0405 login local ! end

From the client, dial in to the NAS by using the PRI telephone number assigned to the NAS T1 trunks. Sometimes the PRI telephone number is called the hunt group number. As the call comes into the NAS, a LINK-3-UPDOWN message automatically appears on the NAS terminal screen. In this example, the call comes in to the NAS on asynchronous interface 14. The asynchronous interface is up.
if you do not see the above message after 30 seconds of when the client rst transmits the call.
Step 4Pinging the Home Gateway

From the client, ping the home gateway. From the clients Windows 95 desktop:
(a) (b) (c) (d) (e)
Click Start. Select Run. Enter ping 172.22.66.25. Click OK. Look at the terminal screen and verify that the home gateway is sending ping reply packets to the client.
Step 5Displaying Active Call Statistics on the Home Gateway

From the home gateway, enter the show caller command and show caller user name command to verify that the client received an IP address. This example shows that Jeremy is using interface virtual-access 1 and is assigned IP address 172.30.2.1. The network administrator jane-admin is using console 0.
ENT_HGW# show caller Line User con 0 jane-admin Vi1 jeremy@hgw.com Service TTY PPP L2F Active 00:00:25 00:01:28
ENT_HGW# show caller user jeremy@hgw.com User: jeremy@hgw.com, line Vi1, service PPP L2F, active 00:01:35 PPP: LCP Open, CHAP (<- AAA), IPCP IP: Local 172.22.66.25, remote 172.30.2.1 VPDN: NAS ISP_NAS, MID 1, MID open HGW ENT_HGW, NAS CLID 36, HGW CLID 1, tunnel open Counts: 105 packets input, 8979 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 18 packets output, 295 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets
Note The show caller command was introduced in Cisco IOS Release 11.3(5)AA. If your Cisco IOS software does not include the show caller command, use the show user command instead.

From the home gateway, ping Jeremys PC at IP address 172.30.2.1:
ENT_HGW# ping 172.30.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.30.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 128/132/152 ms
Step 7Verifying That the Virtual-Access Interface Is Up and That LCP Is Open
From the home gateway, enter the show interface virtual-access 1 command to verify that the interface is up, LCP is open, and no errors are reported:
ENT_HGW# show interface virtual-access 1 Virtual-Access1 is up, line protocol is up Hardware is Virtual Access interface Interface is unnumbered. Using address of FastEthernet0/0 (172.22.66.25) MTU 1500 bytes, BW 115 Kbit, DLY 100000 usec, reliablility 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set, keepalive set (10 sec) DTR is pulsed for 5 seconds on reset LCP Open Open: IPCP Last input 00:00:02, output never, output hang never Last clearing of "show interface" counters 3d00h Queueing strategy: fifo Output queue 1/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec
52
Step 8Viewing Active L2F Tunnel Statistics
114 packets input, 9563 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 27 packets output, 864 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions

From the home gateway, display active tunnel statistics by entering the show vpdn command and show vpdn tunnel all command:
ENT_HGW# show vpdn % No active L2TP tunnels L2F Tunnel and Session NAS CLID HGW CLID NAS Name 36 1 ISP_NAS 172.22.66.23 CLID 36 MID 1 Username jeremy@hgw.com HGW Name ENT_HGW 172.22.66.25 Intf Vi1 State open
State open
ENT_HGW# show vpdn tunnel all % No active L2TP tunnels L2F Tunnel NAS name: ISP_NAS NAS CLID: 36 NAS IP address 172.22.66.23 Gateway name: ENT_HGW Gateway CLID: 1 Gateway IP address 172.22.66.25 State: open Packets out: 52 Bytes out: 1799 Packets in: 100 Bytes in: 7143
Troubleshooting the Access VPN

This section provides the ISP and enterprise customer with a methodology for troubleshooting the access VPN as described in Figure 16. Step 1 shows 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.
Step 1Comparing Your Debug Output to the Successful Debug Output Step 2Troubleshooting L2F Negotiation Step 3Troubleshooting PPP Negotiation Step 4Troubleshooting AAA Negotiation
Figure 16 describes the methodology used to troubleshoot the Access VPN.

Figure 16 Troubleshooting Flow Diagram for Access VPN with Local AAA
View successful VPDN-event debug output Yes, but client cannot ping home gateway
Does your output match successful output?
No
Troubleshoot L2F negotiation
Yes, and client can ping home gateway Access VPN functions properly Yes, but client cannot ping home gateway Troubleshoot PPP negotiation
Is L2F negotiation successful?
No
Contact support personnel
Yes, and client can ping home gateway Access VPN functions properly Is PPP negotiation successful? Contact support personnel
Troubleshoot AAA negotiation Yes, but client cannot ping home gateway Contact support personnel
Yes, but client cannot ping home gateway
No
Yes, and client can ping home gateway Is AAA negotiation successful? No Contact support personnel Access VPN functions properly
Yes, and client can ping home gateway

23834
Access VPN functions properly
54
Step 1Comparing Your Debug Output to the Successful Debug Output
If you are accessing the NAS and home gateway through a Telnet connection, enable the terminal monitor command, which ensures that your EXEC session is receiving the logging and debug output from the devices. When you nish troubleshooting, use the undebug all command to turn off all debug commands. Isolating debug output helps you efciently build a network.

Enable the debug vpdn-event command on both the NAS and the home gateway. The following debug output shows successful VPN negotiation on the NAS and home gateway:
ISP_NAS# Jan 7 00:19:35.900: Jan 7 00:19:39.532: Jan 7 00:19:39.532: Jan 7 00:19:39.540: IP172.22.66.25 Jan 7 00:19:39.540: Jan 7 00:19:39.540: Jan 7 00:19:39.540: Jan 7 00:19:39.540: Jan 7 00:19:40.540: state to up ISP_NAS# %LINK-3-UPDOWN: Interface Async9, changed state to up sVPDN: Got DNIS string As9 As9 VPDN: Looking for tunnel -- hgw.com -As9 VPDN: Get tunnel info for hgw.com with NAS ISP_NAS, As9 VPDN: Forward to address 172.22.66.25 As9 VPDN: Forwarding... As9 VPDN: Bind interface direction=1 As9 VPDN: jeremy@hgw.com is forwarded %LINEPROTO-5-UPDOWN: Line protocol on Interface Async9, changed
ENT_HGW# Jan 7 00:19:39.967: VPDN: Chap authentication succeeded for ISP_NAS Jan 7 00:19:39.967: Vi1 VPDN: Virtual interface created for jeremy@hgw.com Jan 7 00:19:39.967: Vi1 VPDN: Set to Async interface Jan 7 00:19:39.971: Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking 6w5d: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up Jan 7 00:19:40.051: Vi1 VPDN: Bind interface direction=2 Jan 7 00:19:40.051: Vi1 VPDN: PPP LCP accepted rcv CONFACK Jan 7 00:19:40.051: Vi1 VPDN: PPP LCP accepted sent CONFACK 6w5d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
If you see the above debug output but cannot ping the home gateway, go on to Step 3Troubleshooting PPP Negotiation. If you do not see the above debug output, go on to Step 2Troubleshooting L2F Negotiation.
Step 2Troubleshooting L2F Negotiation

This step describes several common miscongurations that prevent successful L2F negotiation.
Miscongured NAS Tunnel Secret Miscongured Home Gateway Tunnel Secret Miscongured Tunnel Name
Miscongured NAS Tunnel Secret

The NAS and the home gateway must both have the same usernames with the same password to authenticate the L2F tunnel. These usernames are called the tunnel secret. In this case study, 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 home gateway:
ISP_NAS# Jan 1 00:26:49.899: Jan 1 00:26:54.643: nged state to up Jan 1 00:27:00.559: Jan 1 00:27:05.559: Jan 1 00:27:05.559: Jan 1 00:27:10.559: Jan 1 00:27:10.559: Jan 1 00:27:15.559: Jan 1 00:27:15.559: Jan 1 00:27:20.559: Jan 1 00:27:20.559: Jan 1 00:27:25.559: Jan 1 00:27:25.559: tunnel ISP_NAS# %LINK-3-UPDOWN: Interface Async3, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Async3, cha L2F: L2F: L2F: L2F: L2F: L2F: L2F: L2F: L2F: L2F: L2F: Resending L2F_OPEN, Resending L2F_ECHO, Resending L2F_OPEN, Resending L2F_ECHO, Resending L2F_OPEN, Resending L2F_ECHO, Resending L2F_OPEN, Resending L2F_ECHO, Resending L2F_OPEN, Resending L2F_ECHO, Resend packet (type time #1 time #1 time #2 time #2 time #3 time #3 time #4 time #4 time #5 time #5 2) around too long, time to kill off the
ENT_HGW# Jan 1 00:26:53.645: L2F: Packet has bogus2 key C8353FAB B6369121 5w6d: %VPDN-6-AUTHENFAIL: L2F HGW , authentication failure for tunnel ISP_NAS; Invalid key 5w6d: %VPDN-5-UNREACH: L2F NAS 172.22.66.23 is unreachable Jan 1 00:27:00.557: L2F: Gateway received tunnel OPEN while in state closed ENT_HGW#
The phrase time to kill off the tunnel in the NAS debug output indicates that the tunnel was not opened. The phrase Packet has bogus2 key in the home gateway debug output indicates that the NAS has an incorrect tunnel secret. To avoid this problem, make sure that you congure both the NAS and home gateway for the same two usernames with the same password.
Miscongured Home Gateway Tunnel Secret

If one of the tunnel secrets on the home gateway 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 home gateway:
ISP_NAS# Jan 1 00:45:27.123: %LINK-3-UPDOWN: Interface Async7, changed state to up Jan 1 00:45:30.939: L2F: Packet has bogus1 key B6C656EE 5FAC6B3 Jan 1 00:45:30.939: %VPDN-6-AUTHENFAIL: L2F NAS ISP_NAS, authentication failure for tunnel ENT_HGW; Invalid key Jan 1 00:45:31.935: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async7, cha nged state to up Jan 1 00:45:35.559: L2F: Resending L2F_OPEN, time #1 Jan 1 00:45:35.559: L2F: Packet has bogus1 key B6C656EE 5FAC6B3 ISP_NAS# ENT_HGW# Jan 1 00:45:30.939: Jan 1 00:45:35.559: Jan 1 00:45:40.559: Jan 1 00:45:45.559: Jan 1 00:45:50.559:
L2F: L2F: L2F: L2F: L2F:
Tunnel authentication succeeded for ISP_NAS Gateway received tunnel OPEN while in state Gateway received tunnel OPEN while in state Gateway received tunnel OPEN while in state Gateway received tunnel OPEN while in state
open open open open
56
Notice how this output is similar to the debug output you see when the NAS has a miscongured tunnel secret. This time you see the phrase Packet has bogus1 key on the NAS instead of on the home gateway. This tells you that the home gateway has an incorrect tunnel secret. To avoid this problem, make sure that you congure both the NAS and home gateway for the same two usernames with the same password.
Miscongured Tunnel Name

If the NAS and home gateway do not have matching tunnel names, they cannot establish an L2F tunnel. These tunnel names are congured under the vpdn-group 1 command on both the NAS and the home gateway by using the local name command. The home gateway must be congured to accept tunnels from the name the NAS sends it. This is done by using the accept dialin l2f virtual-template 1 remote ISP_NAS command, where ISP_NAS is the name. The name the home gateway returns to the NAS is congured by using the local name ENT_HGW command where ENT_HGW is the name. These commands appear in the running conguration as follows:
vpdn-group 1 accept dialin l2f virtual-template 1 remote ISP_NAS local name ENT_HGW
In the following debug output, the NAS attempted to open a tunnel by using the name isp. Because the home gateway 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 home gateway:
ENT_HGW# Jan 1 01:28:54.207: L2F: L2F_CONF received Jan 1 01:28:54.207: L2X: Never heard of isp Jan 1 01:28:54.207: L2F: Couldn't find tunnel named isp
To avoid the above problem, make sure that the tunnel names match on the home gateway and on the NAS. If you xed the problem in your conguration, go back to Verifying the Access VPN. If your call still cannot successfully complete L2F negotiation, contact your support personnel.

Enable the debug ppp negotiation command on the home gateway and dial in to the NAS. You should not need to enable this command on the NAS, because you already veried dial up connectivity to the NAS in Conguring the NAS for Basic Dial Access. The following debug output shows successful PPP negotiation on the home gateway:
1d02h: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up *Feb 4 14:14:40.505: Vi1 PPP: Treating connection as a dedicated line *Feb 4 14:14:40.505: Vi1 PPP: Phase is ESTABLISHING, Active Open *Feb 4 14:14:40.505: Vi1 PPP: Treating connection as a dedicated line *Feb 4 14:14:40.505: Vi1 PPP: Phase is AUTHENTICATING, by this end *Feb 4 14:14:40.509: Vi1 PPP: Phase is UP
If your call successfully completed PPP negotiation, but you still cannot ping the home gateway, go on to Step 4Troubleshooting AAA Negotiation. If your call cannot successfully complete PPP negotiation, contact your support personnel.
Step 4Troubleshooting AAA Negotiation

This section rst shows debug output of successful AAA negotiation. It then explains a common misconguration that prevents successful AAA negotiation.
Successful AAA Negotiation Incorrect User Password
Successful AAA Negotiation

Enable the debug aaa authentication and debug aaa authorization commands on the home gateway. The following debug output shows successful AAA negotiation on the home gateway. This output has been edited to exclude repetitive lines.
Jan 15 21:35:10.902: AAA/AUTHEN: create_user (0x612C5DE4) user='ENT_HGW' ruser=' ' port='' rem_addr='' authen_type=CHAP service=PPP priv=1 Jan 15 21:35:10.902: AAA/AUTHEN/START (1765780899): port='' list='default' actio n=SENDAUTH service=PPP Jan 15 21:35:10.902: AAA/AUTHEN/START (1765780899): found list default Jan 15 21:35:10.902: AAA/AUTHEN/START (1765780899): Method=LOCAL Jan 15 21:35:10.902: AAA/AUTHEN (1765780899): status = PASS Jan 15 21:35:10.902: AAA/AUTHEN: create_user (0x612C5DE4) user='ISP_NAS' ruser=' ' port='' rem_addr='' authen_type=CHAP service=PPP priv=1 Jan 15 21:35:10.906: AAA/AUTHEN/START (990949917): port='' list='default' action =SENDAUTH service=PPP Jan 15 21:35:10.906: AAA/AUTHEN/START (990949917): found list default Jan 15 21:35:10.906: AAA/AUTHEN/START (990949917): Method=LOCAL Jan 15 21:35:10.906: AAA/AUTHEN (990949917): status = PASS 8w0d: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up Jan 15 21:35:10.994: AAA/AUTHEN: create_user (0x612E4234) user='jeremy@hgw.com' ruser='' port='Virtual-Access1' rem_addr='408/5550945' authen_type=CHAP service= PPP priv=1 Jan 15 21:35:10.994: AAA/AUTHEN/START (2063987649): port='Virtual-Access1' list= '' action=LOGIN service=PPP Jan 15 21:35:10.994: AAA/AUTHEN/START (2063987649): using "default" list Jan 15 21:35:10.994: AAA/AUTHEN/START (2063987649): Method=LOCAL Jan 15 21:35:10.994: AAA/AUTHEN (2063987649): status = PASS Jan 15 21:35:10.994: Vi1 AAA/AUTHOR/LCP: Authorize LCP Jan 15 21:35:10.994: AAA/AUTHOR/LCP Vi1 (2975944584): Port='Virtual-Access1' lis t='' service=NET Jan 15 21:35:10.994: AAA/AUTHOR/LCP: Vi1 (2975944584) user='jeremy@hgw.com' Jan 15 21:35:10.998: AAA/AUTHOR/LCP: Vi1 (2975944584) send AV service=ppp Jan 15 21:35:10.998: AAA/AUTHOR/LCP: Vi1 (2975944584) send AV protocol=lcp Jan 15 21:35:10.998: AAA/AUTHOR/LCP (2975944584) found list "default" Jan 15 21:35:10.998: AAA/AUTHOR/LCP: Vi1 (2975944584) Method=LOCAL Jan 15 21:35:10.998: AAA/AUTHOR (2975944584): Post authorization status = PASS_REPL Jan 15 21:35:10.998: Vi1 AAA/AUTHOR/FSM: We can start IPCP 8w0d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed s tate to up Jan 15 21:35:14.094: Vi1 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want 1 72.30.2.1
If this debug output appears, but you still cannot ping the home gateway, contact your support personnel and troubleshoot your networks backbone. If you do not see this debug output, troubleshoot AAA negotiation.
58
Incorrect User Password

If the user password is incorrect (or it is incorrectly congured), the tunnel will be established, but the home gateway will not authenticate the user. If the user password is incorrect, the following debug output appears on the NAS and home gateway when you dial in to the NAS and the debug vpdn l2x-errors and debug vpdn l2x-events commands are enabled:
ISP_NAS# Jan 1 01:00:01.555: %LINK-3-UPDOWN: Interface Async12, changed state to up Jan 1 01:00:05.299: L2F: Tunnel state closed Jan 1 01:00:05.299: L2F: MID state closed Jan 1 01:00:05.299: L2F: Open UDP socket to 172.22.66.25 Jan 1 01:00:05.299: L2F: Tunnel state opening Jan 1 01:00:05.299: As12 L2F: MID jeremy@hgw.com state waiting_for_tunnel Jan 1 01:00:05.303: L2F: L2F_CONF received Jan 1 01:00:05.303: L2F: Removing resend packet (L2F_CONF) Jan 1 01:00:05.303: ENT_HGW L2F: Tunnel state open Jan 1 01:00:05.307: L2F: L2F_OPEN received Jan 1 01:00:05.307: L2F: Removing resend packet (L2F_OPEN) Jan 1 01:00:05.307: L2F: Building nas2gw_mid0 Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: CLID/DNIS 4089548021/5550945 Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: NAS-Port Async12 Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: Client-Bandwidth-Kbps 115 Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: NAS-Rate L2F/26400/28800 Jan 1 01:00:05.307: As12 L2F: MID jeremy@hgw.com state opening Jan 1 01:00:05.307: L2F: Tunnel authentication succeeded for ENT_HGW Jan 1 01:00:05.391: L2F: L2F_OPEN received Jan 1 01:00:05.391: L2F: Got a MID management packet Jan 1 01:00:05.391: L2F: Removing resend packet (L2F_OPEN) Jan 1 01:00:05.391: As12 L2F: MID jeremy@hgw.com state open Jan 1 01:00:05.391: As12 L2F: MID synced NAS/HG Clid=47/12 Mid=1 Jan 1 01:00:05.523: L2F: L2F_CLOSE received Jan 1 01:00:05.523: %VPDN-6-AUTHENERR: L2F HGW ENT_HGW cannot locate a AAA server for As12 user jeremy@hgw.com; Authentication failure ENT_HGW# Jan 1 01:00:05.302: L2F: L2F_CONF received Jan 1 01:00:05.302: L2F: Creating new tunnel for ISP_NAS Jan 1 01:00:05.302: L2F: Tunnel state closed Jan 1 01:00:05.302: L2F: Got a tunnel named ISP_NAS, responding Jan 1 01:00:05.302: L2F: Open UDP socket to 172.22.66.23 Jan 1 01:00:05.302: ISP_NAS L2F: Tunnel state opening Jan 1 01:00:05.306: L2F: L2F_OPEN received Jan 1 01:00:05.306: L2F: Removing resend packet (L2F_CONF) Jan 1 01:00:05.306: ISP_NAS L2F: Tunnel state open Jan 1 01:00:05.306: L2F: Tunnel authentication succeeded for ISP_NAS Jan 1 01:00:05.310: L2F: L2F_OPEN received Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: CLID/DNIS 4089548021/5550945 Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: NAS-Port Async12 Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: Client-Bandwidth-Kbps 115 Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: NAS-Rate L2F/26400/28800 Jan 1 01:00:05.310: L2F: Got a MID management packet Jan 1 01:00:05.310: L2F: MID state closed Jan 1 01:00:05.310: L2F: Start create mid intf process for jeremy@hgw.com 5w6d: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up Jan 1 01:00:05.390: Vi1 L2X: Discarding packet because of no mid/session Jan 1 01:00:05.390: Vi1 L2F: Transfer NAS-Rate L2F/26400/28800 to LCP Jan 1 01:00:05.390: Vi1 L2F: Finish create mid intf for jeremy@hgw.com Jan 1 01:00:05.390: Vi1 L2F: MID jeremy@hgw.com state open 5w6d: %VPDN-6-AUTHENERR: L2F HGW ENT_HGW cannot locate a AAA server for Vi1 user jeremy@hgw.com; Authentication failure
If the access VPN now works by using local AAA, go on to Conguring the Access VPN to Work with Remote AAA. If you do not see this debug output, contact your support personnel.
60
Configuring the Access VPN to Work with Remote AAA

Introduction
In this third task, the ISP and the enterprise customer:
Recongure the NAS and home gateway to work as an access VPN using remote AAA. To ensure that the access VPN is using remote AAA, the ISP and enterprise customer modify the AAA and VPN congurations on the NAS and home gateway. Congure CiscoSecure ACS on the UNIX and NT servers. The NAS uses CiscoSecure UNIX to authenticate the users domain name and to determine the IP tunnel endpoint information. The home gateway uses CiscoSecure NT to authenticates the users username and password. The NAS and home gateway continue to use their local username databases to authenticate the tunnel. Verify that the access VPN works properly. Troubleshoot the access VPN if there are problems.
The ISP congures the NAS and CiscoSecure UNIX. The enterprise customer congures the home gateway and CiscoSecure NT. Figure 17 shows the access VPN network topology.
Figure 17 Access VPN Topology Using Remote AAA ISP's network CiscoSecure ACS UNIX server Enterprise customer's network Clients using modems PSTN POTS lines L2F tunnel Ethernet Cisco 4500-M edge router

6
Serial lines
Configuring the Access VPN to Work with Remote AAA 61
18024
Once the ISP and enterprise customer have completed this task, the network will function as follows:
When the user Jeremy wants to connect to the enterprise customers network, he dials in to the NAS by using the username jeremy@hgw.com. The NAS and the client perform LCP negotiation. The CiscoSecure UNIX server authenticates the domain name, hgw.com, and supplies the NAS with the tunnel endpoint information. The NAS negotiates an L2F tunnel with the home gateway. The NAS and home gateway authenticate the tunnel by using their local username databases, which contain the tunnel secret. Once the tunnel is established, the NAS forwards the call to the home gateway. The CiscoSecure NT server authenticates the username, jeremy, and assigns the client an IP address. (It can optionally assign IP addresses for DNS and WINS servers.) The client and the home gateway can now exchange PPP packets. The NAS now acts as a transparent PPP frame forwarder.
Conguring the Access VPN

To congure the access VPN solution to work with remote AAA, follow these steps:
Step 1Conguring the NAS Step 2Conguring the Home Gateway Step 3Conguring the CiscoSecure ACS UNIX Server Step 4Conguring the CiscoSecure ACS NT Server
Step 1Conguring the NAS


Use this command
Moves the responsibilities for domain name authentication and tunnel endpoint determination from the NAS to the remote CiscoSecure UNIX server Points the NAS to the CiscoSecure UNIX server Removes unnecessary commands
To do this Instruct AAA to rst use the local database and then use the RADIUS server (CiscoSecure NT) for PPP and VPN authentication. The order of authentication methods is local rst and RADIUS second because the tunnel is authenticated locally and the users domain name is authenticated by the CiscoSecure UNIX server.
ISP_NAS(config)# aaa authentication ppp default local radius
ISP_NAS(config)# aaa authorization network default radius
Instruct AAA to use the CiscoSecure UNIX server to authorize network-related service requests. Enter the CiscoSecure UNIX servers IP address.
ISP_NAS(config)# radius-server host 172.22.66.18
62
Step 2Configuring the Home Gateway
Use this command

ISP_NAS(config)# radius-server key cisco
To do this Dene a key to decrypt the data that runs between the NAS and the CiscoSecure UNIX server.
Note This key must be congured as cisco.
Ciscos RADIUS has a hard-coded password of cisco; this is separate from the NAS and home gateway passwords used to authenticate each other.
ISP_NAS(config)# no vpdn-group 1
Remove the VPN1 group. All of the tunneling information will now be retrieved using RADIUS at the CiscoSecure UNIX server.
Step 2Conguring the Home Gateway

In this step, the enterprise customer:

Use this command
Moves the responsibility for username authentication from the NAS to the remote CiscoSecure NT server Points the home gateway to the CiscoSecure NT server Removes the clients username and password from the home gateways username database
To do this Instruct AAA to rst use the local database and then use the RADIUS server (CiscoSecure NT) for PPP and VPN authentication. The order of authentication methods is local rst and RADIUS second because the tunnel is authenticated locally, and the users username and password are authenticated by the CiscoSecure NT server.
ENT_HGW(config)# aaa authentication ppp default local radius
ENT_HGW(config)# aaa authorization network default radius
Instruct AAA to use the CiscoSecure NT server to authorize network-related service requests. Enable AAA accounting that sends a stop accounting notice at the end of the requested user process. Specify the CiscoSecure NT servers IP address and the ports to be used for authentication and accounting requests. Set the authentication key and encryption key to cisco for all RADIUS communication. Remove the jeremy@hgw.com username from the local database. This ensures that the home gateway uses CiscoSecure NT instead of the local username database to authenticate the username.
ENT_HGW(config)# aaa accounting network default start-stop radius ENT_HGW(config)# radius-server host 172.22.66.13 auth-port 1645 acct-port 1646 ENT_HGW(config)# radius-server key cisco
ENT_HGW(config)# no username jeremy@hgw.com
Step 3Conguring the CiscoSecure ACS UNIX Server

In this step, the ISP congures CiscoSecure ACS UNIX to:
Authenticate VPN Discover the IP tunnel endpoint information Track the accounting information relating to VPN usage
The following procedure shows how to congure CiscoSecure UNIX by using RADIUS as the security protocol. The ISP can congure CiscoSecure UNIX by:
Using the CiscoSecure UNIX server GUI-based interface Using the UNIX command line interface (CLI)
The following procedure shows the CLI method of conguring CiscoSecure UNIX.
Note The password cisco is used throughout the following conguration. There is only one place
in the following conguration where using the password cisco is mandatory: the prole named vpdn.
Use this command

pagoda# cd /cs/CLI
To do this Change your working directory to the CLI directory in the CiscoSecure directory. Open a vi editor session and create a le called vpdn. The vpdn le contains all the VPN RADIUS authentication and authorization attributes needed for the home gateway user. In this le: 2= denes the IETF RADIUS password attribute. In this instance, the password must be cisco.
Note In this particular le, you need to use the password cisco. The vpdn prole is the one and only prole that actually interfaces directly with Cisco IOS software. Ciscos implementation of RADIUS needs a password to operate; for security reasons, that password should not reside on the NAS. Cisco has hard-coded the password cisco in Cisco IOS to address this security issue.
pagoda# vi vpdn radius=Cisco11.3 { check_items= { 2=cisco 6=5 } reply_attributes= { 9,1="vpdn:gw-password=cisco" 9,1="vpdn:nas-password=cisco" 9,1="vpdn:tunnel-id=ISP_NAS" 9,1="vpdn:ip-addresses=172.22.66.25" }
6= denes the IETF RADIUS user-service-type attribute. In this instance, 5 indicates a value of outbound user. Reply attributes send information from the RADIUS security server to the NAS. The following reply attributes need to be dened: gw-password= denes the home gateway password as cisco. nas-password= denes the NAS password as cisco. tunnel-id= denes the name of the VPN tunnel as ISP_NAS. ip-addresses= denes the IP address of the home gateway as 172.22.66.25.
:wq!
Exit the vi editor session and save the vpdn le.
64
Step 3Configuring the CiscoSecure ACS UNIX Server
Use this command

pagoda# vi ENT_HGW radius=Cisco11.3 { check_items= { 2=cisco } }
To do this Open a vi editor session and create a le called ENT_HGW that contains a password for the home gateway user. In this le: radius= denes the version of RADIUS as being that contained in Cisco IOS Release 11.3. 2= denes the password for the home gateway user. In this instance, any password can be used. Exit the vi editor session and save the ENT_HGW le. Open a vi editor session and create a le called ISP_NAS that contains the password for the user created by the tunnel-id attribute. In this le: radius= denes the version of RADIUS as being that contained in Cisco IOS Release 11.3. 2= denes the password for the home gateway user. In this instance, any password can be used. Exit the vi editor session and save the ISP_NAS le. Open a vi editor session and create a le named nas_list that adds 172.22.66.23 to the NAS list.
Note In this case study, only one NAS is used: the NAS with the IP address of 172.22.66.23. If you have more than one NAS in your network, it is imperative that all NASs be added to the NAS list or authentication will fail.
:wq! pagoda# vi ISP_NAS radius=Cisco11.3 { check_items= { 2=cisco } }
:wq! pagoda# vi nas_list NAS.172.22.66.23
:wq! pagoda# vi nas1 NASName="172.22.66.23" SharedSecret="cisco" RadiusVendor="Cisco" Dictionary="DICTIONARY.Cisco11.3"
Exit the vi editor session and save the nas_list le. Open a vi editor session and create a prole for the NAS, which in this case is a le named nas1. This le identies the RADIUS dictionary that the NAS uses, the NAS IP address, the applicable vendor, and the shared secret key. In this le: NASName= denes nas1 as being the NAS identied by the IP address 172.22.66.23. SharedSecret= denes the nas1 password as cisco. RadiusVendor= identies the vendor code as Cisco. Dictionary= denes the version of the RADIUS dictionary as being that contained in Cisco IOS Release 11.3.
:wq! pagoda# ./DeleteProfile -p 9900 -u NAS_LIST Profile Successfully Deleted pagoda#
Exit the vi editor session and save the nas1 le. The CLI does not support prole updates; you can only delete or add proles. Because the ISP added a new NAS to the NAS_list, the ISP needs to delete the existing NAS list prole and create a new one. Delete the existing NAS_LIST prole where: -p 9900 indicates that Delete Prole uses this port to connect to the database. -u NAS_LIST indicates the prole being deleted.
Use this command

pagoda# ./AddProfile -p 9900 -u NAS_LIST -s nas_list Profile Successfully Added pagoda#
To do this Create a new user prole called NAS_LIST where -p 9900 indicates that Add Prole uses this port to connect to the database. -u NAS_LIST indicates the prole name. -s nas_list indicates the le used to create this user prole.
pagoda# ./AddProfile -p 9900 -u NAS.172.22.66.23 -s nas1 Profile Successfully Added pagoda#
For each entry on the NAS_LIST, there must be a user prole for the associated NAS. Create a user prole for the NAS itself called NAS.172.22.66.23 where -p 9900 indicates that Add Prole uses this port to connect to the database. -u NAS.172.22.66.23 indicates the prole name. -s nas1 indicates the le used to create this user prole.
pagoda# ./AddProfile -p 9900 -g NAS_Group
Organize your group structure so that all VPN-related elements (such as associated NAS and home gateways) are gathered together in one group by creating a group called NAS_Group. Add the participants to the created NAS group by creating the following users for this group: VPDN, ENT_HGW, and ISP_NAS Create a domain-based VPN user called hgw.com under the group NAS_Group where -p 9900 indicates that Add Prole uses this port to connect to the database. -u hgw.com indicates the domain name. -pr NAS_Group indicates which group this user belongs to. -s vpdn indicates the le used to create this user prole.
pagoda# ./AddProfile -p 9900 -u hgw.com -pr NAS_Group -s vpdn Profile Successfully Added pagoda#
pagoda# ./AddProfile -p 9900 -u ENT_HGW -pr NAS_Group -s ENT_HGW Profile Successfully Added pagoda#
Create a home gateway user called ENT_HGW under the group NAS_Group where -p 9900 indicates that Add Prole uses this port to connect to the database. -u ENT_HGW indicates the prole name. -pr NAS_Group indicates which group this user belongs to. -s ENT_HGW indicates the le used to create this user prole.
pagoda# ./AddProfile -p 9900 -u ISP_NAS -pr NAS_Group -s ISP_NAS Profile Successfully Added pagoda#
Create a tunnel user called ISP_NAS under the group NAS_Group where -p 9900 indicates that Add Prole uses this port to connect to the database. -u ISP_NAS indicates the tunnel prole name. -pr NAS_Group indicates the group which this user belongs to. -s ISP_NAS indicates the le used to create this user prole.
66
Step 4Configuring the CiscoSecure ACS NT Server
Use this command

pagoda# cd /cs/config
To do this Modify the le called CSU.cfg to support VPN accounting records. Change your working directory to cong.
pagoda# vi CSU.cfg DOMAIN config_local_domain = { { "hgw.com", "@", suffix } };
Open a vi editor session to modify the le called CSU.cfg where: DOMAIN cong_local_domain= means that the accounting records generated are for hgw.com. hgw.com denes the name of the domain. @ denes the delimiter. sufx denes that the domain name is placed after the username. Exit the vi editor session and save the modications to the CSU.cfg le. Shut down the CiscoSecure UNIX server. Restart the CiscoSecure UNIX server.
:wq!
pagoda# /etc/rc0.d/K80CiscoSecure pagoda# /etc/rc2.d/S80CiscoSecure
Step 4Conguring the CiscoSecure ACS NT Server

In this step, the enterprise customer:
Installs CiscoSecure NT, selecting RADIUS (Cisco) as the security protocol and identifying the access server by which authentication requests are transmitted Congures CiscoSecure NT to delete the domain name from incoming usernames so that the username matches the format CiscoSecure NT uses in its username/password database Creates a CiscoSecure NT user prole, which includes a username, password, and a description of the user
In CiscoSecure NT, basic accounting services are congured by default.

Note CiscoSecure NT refers to the home gateway as the network access server or just the access
server. Make sure that when CiscoSecure NT prompts you to enter information about what it calls the access server, you enter the corresponding information about the home gateway. CiscoSecure NT does not communicate with the NAS. Therefore, the only server CiscoSecure NT refers to is the home gateway.
Use this display
To do this Install CiscoSecure NT. Before you can successfully install CiscoSecure NT, make sure you meet the following criteria: A client can successfully dial in to the NAS. If you have successfully congured the access VPN to work with local AAA, you have met this criterion. This Windows NT server can ping the NAS. If you have successfully congured the access VPN to work with local AAA, you have met this criterion. The NAS is running Cisco IOS Release 11.1 or later release. A compatible browser is installed on the Windows NT server. On the Before You Begin screen, check all the corresponding boxes when the requirements are met. Click Next. In the Choose Destination Location screen: Select the folder where Setup will install CiscoSecure NT. Click Next.
In the Authentication Database Conguration screen, dene the database where CiscoSecure NT authenticates users. You have the option to use either the: Local CiscoSecure database or Local CiscoSecure database and the Windows NT user database. In this scenario, only the local CiscoSecure database is queried for user accounts. Click CiscoSecure ACS database only. Click Next.
68
Use this display
To do this In the CiscoSecure ACS Network Access Server Details screen, select the security protocol.
Note Remember that CiscoSecure NT calls the home gateway the network access server.
Select RADIUS (Cisco) in the security protocol box. Type ENT_HGW in the Access Server Name box. Type 172.22.66.25 in the Access Server IP Address box. Type 172.22.66.13 in the Windows NT Server IP Address box. Click Next.
In the Advanced Options screen, dene the advanced options that will appear in the CiscoSecure NT user interface. Click the following advanced options: User level network access restrictions Group level network access restrictions Max sessions Default time of day/day of week specication Distributed system settings Database replication Click Next.
In the Active Service Monitoring screen: Click Enable Log-in Monitoring Select Script to execute: *Restart All. Click Next.
Use this display
To do this In the Network Access Server Conguration screen, click Next. Because you have already congured the home gateway, you do not need to use this automated conguration feature.
Note Remember, CiscoSecure NT calls the home gateway the network access server.
The installation is now complete.
In the CiscoSecure ACS Service Initiation screen, you are asked if you want to start CiscoSecure NT service immediately and if you want Setup to launch the CiscoSecure NT Administrator from the installed browser immediately. To do so: Click Yes, I want to start CiscoSecure ACS Service now Click Yes, I want Setup to launch the CiscoSecure ACS Administrator from my browser following installation Click Next.
70
Use this display
To do this In the CiscoSecure ACS Welcome screen, click Network Conguration.

Note The address 127.0.0.1 is a loopback address. If you run the browser from the same system that CiscoSecure NT is installed on, this IP address appears in the HTTP browser eld. However, if you want to run the browser on a system that is different than the one on which CiscoSecure NT has been installed, then the actual IP address of the device appears in the box.
For CiscoSecure NT to authenticate a user, you must strip the domain name from the incoming username, so that the username matches the form that CiscoSecure NT uses in its username/password database. In the Network Conguration screen: Click Add Entry below the Distribution Table.
Use this display
To do this In the Add New Distribution Entry frame of the Network Conguration window, create a distribution entry: Type @hgw.com in the Character string box. Select Sufx in the Position box. Select Yes in the Strip box. Select ENT_HGW in the Forward to: box and click the right arrow to move it to the Forward To column. Click Submit and Restart.
After you click Submit and Restart, a summary of the information you have congured appears. Click User Setup.
72
Use this display
To do this In the User Setup window, to create a user: Type jeremy in the User box. Click Add/Edit.
In the User Setup screen, add the following supplementary user information: Type Jeremy Smith in the Real Name box. Type Remote User in the Description box. Select CiscoSecure Database in the Password Authentication box. Type subaru in the Password box. Type subaru in the Conrm box. Click Submit. You have now created a user named Jeremy.

This section describes how to verify that the end-to-end connections function as shown in Figure 18:

Figure 18
Step 1Checking the NAS Final Running Conguration Step 2Checking the Home Gateway Final Running Conguration Step 3Dialing in to the NAS Step 4Pinging the Home Gateway Step 5Displaying Active Call Statistics on the Home Gateway Step 6Pinging the Client Step 7Verifying That the Virtual-Access Interface Is Up and That LCP Is Open Step 8Viewing Active L2F Tunnel Statistics
Access VPN Topology Using Remote AAA
ISP's network CiscoSecure ACS UNIX server Enterprise customer's network Clients using modems PSTN POTS lines L2F tunnel Ethernet Cisco 4500-M edge router

6
Serial lines
After you successfully test these connections, the nal end-to-end solution is built. If you experience problems, see Troubleshooting the Access VPN.
Step 1Checking the NAS Final Running Conguration

Enter the show running-cong command in privileged EXEC mode to make sure the NAS accepted the commands you entered:
ISP_NAS# show running-config Building configuration... Current configuration: ! version 11.3
74
18024
Step 1Checking the NAS Final Running Configuration
service timestamps debug datetime msec service timestamps log datetime msec service password-encryption ! hostname ISP_NAS ! aaa new-model aaa authentication ppp default radius aaa authorization network default radius enable secret 5 $1$AXl/$27hOM6j51a5P76Enq.LCf0 ! username jane-admin password 7 0501090A6C5C4F1A0A1218000F username ENT_HGW password 7 104D000A0618 username ISP_NAS password 7 13061E010803 vpdn enable ! vpdn search-order domain dnis async-bootp dns-server 171.68.10.70 171.68.10.140 isdn switch-type primary-5ess ! controller T1 0 framing esf clock source line primary linecode b8zs pri-group timeslots 1-24 ! controller T1 1 framing esf clock source line secondary linecode b8zs pri-group timeslots 1-24 ! controller T1 2 framing esf clock source internal linecode b8zs pri-group timeslots 1-24 ! controller T1 3 framing esf clock source internal linecode b8zs pri-group timeslots 1-24 ! ! interface Ethernet0 ip address 172.22.66.23 255.255.255.192 ! interface Serial0:23 no ip address isdn switch-type primary-5ess isdn incoming-voice modem no cdp enable ! interface Serial1:23 no ip address isdn switch-type primary-5ess isdn incoming-voice modem no cdp enable ! interface Serial2:23 no ip address isdn switch-type primary-5ess isdn incoming-voice modem no cdp enable
! interface Serial3:23 no ip address isdn switch-type primary-5ess isdn incoming-voice modem no cdp enable ! interface FastEthernet0 no ip address shutdown ! interface Group-Async1 ip unnumbered Ethernet0 encapsulation ppp async mode interactive no peer default ip address ppp authentication chap pap group-range 1 96 ! ip classless ip route 0.0.0.0 0.0.0.0 172.22.66.1 ! radius-server host 172.22.66.16 auth-port 1645 acct-port 1646 radius-server key cisco ! line con 0 transport input none line 1 96 autoselect during-login autoselect ppp modem InOut line aux 0 line vty 0 4 ! end
Step 2Checking the Home Gateway Final Running Conguration

Enter the more system:running-cong command in privileged EXEC mode to make sure the home gateway accepted the commands you entered:
ENT_HGW# more system:running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug datetime msec service timestamps log uptime service password-encryption ! hostname ENT_HGW ! aaa new-model aaa authentication login default local aaa authentication ppp default local radius aaa authorization network default radius aaa accounting network default start-stop radius enable secret 5 $1$44oH$gZlAZLwylZJSNKGDk.BKb0 ! username jane-admin password 7 00001C05 username ISP_NAS password 7 070C285F4D06 username ENT_HGW password 7 104D000A0618
76
ip subnet-zero ip domain-name cisco.com ip name-server 171.68.10.70 ! vpdn enable ! vpdn-group 1 accept dialin l2f virtual-template 1 remote ISP_NAS local name ENT_HGW ! async-bootp dns-server 172.23.1.10 172.23.2.10 async-bootp nbns-server 172.23.1.11 172.23.2.11 ! ! ! interface FastEthernet0/0 ip address 172.22.66.25 255.255.255.192 no ip directed-broadcast ! . . . interface Virtual-Template1 ip unnumbered FastEthernet0/0 peer default ip address pool default ppp authentication chap ! ip local pool default 172.30.2.1 172.30.2.96 ip classless ip route 0.0.0.0 0.0.0.0 172.22.66.1 ! radius-server host 172.22.66.13 auth-port 1645 acct-port 1646 radius-server key cisco ! line con 0 transport input none line aux 0 line vty 0 4 password 7 045F0405 ! end

From the client, dial in to the NAS by using the PRI telephone number assigned to the NAS T1 trunks. Sometimes this telephone number is called the hunt group number. As the call comes into the NAS, a LINK-3-UPDOWN message automatically appears on the NAS terminal screen. In this example, the call comes in to the NAS on asynchronous interface 14. The asynchronous interface is up.
if you do not see this message after 30 seconds of when the client rst transmits the call.
Step 4Pinging the Home Gateway

From the client, ping the home gateway. From the clients Windows 95 desktop:
(a) (b) (c) (d) (e)
Click Start. Select Run. Enter the ping 172.22.66.25 command. Click OK. Look at the terminal screen and verify that the home gateway is sending ping reply packets to the client.
Step 5Displaying Active Call Statistics on the Home Gateway

From the home gateway, enter the show caller command and show caller user name command to verify that the client received an IP address. This example shows that Jeremy is using interface virtual-access 1 and IP address 172.30.2.1. The network administrator jane-admin is using console 0.
ENT_HGW# show caller Line User con 0 jane-admin Vi1 jeremy@hgw.com Service TTY PPP L2F Active 00:00:25 00:01:28
ENT_HGW# show caller user jeremy@hgw.com User: jeremy@hgw.com, line Vi1, service PPP L2F, active 00:01:35 PPP: LCP Open, CHAP (<- AAA), IPCP IP: Local 172.22.66.25, remote 172.30.2.1 VPDN: NAS ISP_NAS, MID 1, MID open HGW ENT_HGW, NAS CLID 36, HGW CLID 1, tunnel open Counts: 105 packets input, 8979 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 18 packets output, 295 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets

From the home gateway, ping Jeremys PC at IP address 172.30.2.1:
ENT_HGW# ping 172.30.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.30.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 128/132/152 ms
Step 7Verifying That the Virtual-Access Interface Is Up and That LCP Is Open
From the home gateway, enter the show interface virtual-access 1 command to verify that the interface is up, LCP is open, and no errors are reported:
ENT_HGW# show interface virtual-access 1 Virtual-Access1 is up, line protocol is up Hardware is Virtual Access interface Interface is unnumbered. Using address of FastEthernet0/0 (172.22.66.25) MTU 1500 bytes, BW 115 Kbit, DLY 100000 usec, reliablility 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set, keepalive set (10 sec)
78
DTR is pulsed for 5 seconds on reset LCP Open Open: IPCP Last input 00:00:02, output never, output hang never Last clearing of "show interface" counters 3d00h Queueing strategy: fifo Output queue 1/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 114 packets input, 9563 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 27 packets output, 864 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions

From the home gateway, display active tunnel statistics by entering the show vpdn command and show vpdn tunnel all command:
ENT_HGW# show vpdn % No active L2TP tunnels L2F Tunnel and Session NAS CLID HGW CLID NAS Name 36 1 ISP_NAS 172.22.66.23 CLID 36 MID 1 Username jeremy@hgw.com HGW Name ENT_HGW 172.22.66.25 Intf Vi1 State open
State open
ENT_HGW# show vpdn tunnel all % No active L2TP tunnels L2F Tunnel NAS name: ISP_NAS NAS CLID: 36 NAS IP address 172.22.66.23 Gateway name: ENT_HGW Gateway CLID: 1 Gateway IP address 172.22.66.25 State: open Packets out: 52 Bytes out: 1799 Packets in: 100 Bytes in: 7143
Troubleshooting the Access VPN

This section provides the ISP and enterprise customer with a methodology for troubleshooting the access VPN as described in Figure 19. Step 1 shows 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.

Figure 19
Step 1Comparing Your Debug Output to the Successful Debug Output Step 2Troubleshooting L2F Negotiation Step 3Troubleshooting PPP Negotiation Step 4Troubleshooting AAA Negotiation
Troubleshooting Flow Diagram for Access VPN with Remote AAA
View successful VPDN-event debug output Yes, but client cannot ping home gateway
Does your output match successful output?
No
Troubleshoot L2F negotiation
Yes, and client can ping home gateway Access VPN functions properly Yes, but client cannot ping home gateway Troubleshoot PPP negotiation
Is L2F negotiation successful?
No
Contact support personnel
Yes, and client can ping home gateway Access VPN functions properly Is PPP negotiation successful? Contact support personnel
Troubleshoot AAA negotiation Yes, but client cannot ping home gateway Contact support personnel
Yes, but client cannot ping home gateway
No
Yes, and client can ping home gateway Is AAA negotiation successful? No Contact support personnel Access VPN functions properly
Yes, and client can ping home gateway

23834
Access VPN functions properly
80
If you are accessing the NAS and home gateway 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 nish troubleshooting, use the undebug all command to turn off all debug commands. Isolating debug output helps you efciently build a network.

Enable the debug vpdn-event command on both the NAS and the home gateway and dial in to the NAS. The following debug output shows successful VPN negotiation on the NAS and home gateway:
ISP_NAS# Jan 7 00:19:35.900: Jan 7 00:19:39.532: Jan 7 00:19:39.532: Jan 7 00:19:39.540: IP172.22.66.25 Jan 7 00:19:39.540: Jan 7 00:19:39.540: Jan 7 00:19:39.540: Jan 7 00:19:39.540: Jan 7 00:19:40.540: state to up %LINK-3-UPDOWN: Interface Async9, changed state to up sVPDN: Got DNIS string As9 As9 VPDN: Looking for tunnel -- hgw.com -As9 VPDN: Get tunnel info for hgw.com with NAS ISP_NAS, As9 VPDN: Forward to address 172.22.66.25 As9 VPDN: Forwarding... As9 VPDN: Bind interface direction=1 As9 VPDN: jeremy@hgw.com is forwarded %LINEPROTO-5-UPDOWN: Line protocol on Interface Async9, changed
ENT_HGW# Jan 7 00:19:39.967: VPDN: Chap authentication succeeded for ISP_NAS Jan 7 00:19:39.967: Vi1 VPDN: Virtual interface created for jeremy@hgw.com Jan 7 00:19:39.967: Vi1 VPDN: Set to Async interface Jan 7 00:19:39.971: Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking 6w5d: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up Jan 7 00:19:40.051: Vi1 VPDN: Bind interface direction=2 Jan 7 00:19:40.051: Vi1 VPDN: PPP LCP accepted rcv CONFACK Jan 7 00:19:40.051: Vi1 VPDN: PPP LCP accepted sent CONFACK 6w5d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
If you see the above debug output but cannot ping the home gateway, go on to Step 3Troubleshooting PPP Negotiation. If you do not see the above debug output, go on to Step 2Troubleshooting L2F Negotiation.
Step 2Troubleshooting L2F Negotiation

This step describes several common miscongurations that prevent successful L2F negotiation.
Miscongured NAS Tunnel Secret Miscongured Home Gateway Tunnel Secret Miscongured Tunnel Name
Miscongured NAS Tunnel Secret

The NAS and the home gateway must both have the same usernames with the same password to authenticate the L2F tunnel. These usernames are called the tunnel secret. In this case study, 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 home gateway:
ISP_NAS# Jan 1 00:26:49.899: Jan 1 00:26:54.643: nged state to up Jan 1 00:27:00.559: Jan 1 00:27:05.559: Jan 1 00:27:05.559: Jan 1 00:27:10.559: Jan 1 00:27:10.559: Jan 1 00:27:15.559: Jan 1 00:27:15.559: Jan 1 00:27:20.559: Jan 1 00:27:20.559: Jan 1 00:27:25.559: Jan 1 00:27:25.559: tunnel ISP_NAS# %LINK-3-UPDOWN: Interface Async3, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Async3, cha L2F: L2F: L2F: L2F: L2F: L2F: L2F: L2F: L2F: L2F: L2F: Resending L2F_OPEN, Resending L2F_ECHO, Resending L2F_OPEN, Resending L2F_ECHO, Resending L2F_OPEN, Resending L2F_ECHO, Resending L2F_OPEN, Resending L2F_ECHO, Resending L2F_OPEN, Resending L2F_ECHO, Resend packet (type time #1 time #1 time #2 time #2 time #3 time #3 time #4 time #4 time #5 time #5 2) around too long, time to kill off the
ENT_HGW# Jan 1 00:26:53.645: L2F: Packet has bogus2 key C8353FAB B6369121 5w6d: %VPDN-6-AUTHENFAIL: L2F HGW , authentication failure for tunnel ISP_NAS; Invalid key 5w6d: %VPDN-5-UNREACH: L2F NAS 172.22.66.23 is unreachable Jan 1 00:27:00.557: L2F: Gateway received tunnel OPEN while in state closed ENT_HGW#
The phrase time to kill of the tunnel in the NAS debug output indicates that the tunnel was not opened. The phrase Packet has bogus2 key in the home gateway debug output indicates that the NAS has an incorrect tunnel secret. To avoid this problem, make sure that you congure both the NAS and home gateway for the same two tunnel secret usernames with the same password.
Miscongured Home Gateway Tunnel Secret

If one of the tunnel secret usernames on the home gateway 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 home gateway.
ISP_NAS# Jan 1 00:45:27.123: %LINK-3-UPDOWN: Interface Async7, changed state to up Jan 1 00:45:30.939: L2F: Packet has bogus1 key B6C656EE 5FAC6B3 Jan 1 00:45:30.939: %VPDN-6-AUTHENFAIL: L2F NAS ISP_NAS, authentication failure for tunnel ENT_HGW; Invalid key Jan 1 00:45:31.935: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async7, cha nged state to up Jan 1 00:45:35.559: L2F: Resending L2F_OPEN, time #1 Jan 1 00:45:35.559: L2F: Packet has bogus1 key B6C656EE 5FAC6B3 ENT_HGW# Jan 1 00:45:30.939: Jan 1 00:45:35.559: Jan 1 00:45:40.559: Jan 1 00:45:45.559: Jan 1 00:45:50.559:
L2F: L2F: L2F: L2F: L2F:
Tunnel authentication succeeded for ISP_NAS Gateway received tunnel OPEN while in state Gateway received tunnel OPEN while in state Gateway received tunnel OPEN while in state Gateway received tunnel OPEN while in state
open open open open
82
Notice how this output is similar to the debug output you see when the NAS has a miscongured tunnel secret username. This time you see the phrase Packet has bogus1 key on the NAS instead of the home gateway. This tells you that the home gateway has an incorrect tunnel secret username. To avoid this problem, make sure that you congure both the NAS and home gateway for the same two tunnel secret usernames with the same password.
Miscongured Tunnel Name

If the NAS and home gateway do not have matching tunnel names, they cannot establish an L2F tunnel. On the home gateway, these tunnel names are congured under the vpdn-group 1 command by using the local name command. On the NAS, these names are congured on the CiscoSecure UNIX server. The home gateway must be congured to accept tunnels from the name the NAS sends it. This is done using the accept dialin l2f virtual-template 1 remote ISP_NAS command, where ISP_NAS is the name. The name it returns to the NAS is congured using the local name ENT_HGW command where ENT_HGW is the name. These commands appear in the running conguration as follows:
vpdn-group 1 accept dialin l2f virtual-template 1 remote ISP_NAS local name ENT_HGW
On the CiscoSecure UNIX server, the tunnel names are congured by adding proles 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 home gateway 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 home gateway:
ENT_HGW# Jan 1 01:28:54.207: L2F: L2F_CONF received Jan 1 01:28:54.207: L2X: Never heard of isp Jan 1 01:28:54.207: L2F: Couldn't find tunnel named isp
To avoid the above problem, make sure that the tunnel names match on the home gateway and on the CiscoSecure UNIX server. If you xed the problem in your conguration, go back to the section Verifying the Access VPN. If your call still cannot successfully complete L2F negotiation, contact your support personnel.

Enable the debug ppp negotiation command on the home gateway and dial in to the NAS. You should not need to enable this command on the NAS, because you already veried dial up connectivity to the NAS in Conguring the NAS for Basic Dial Access. The following debug output shows successful PPP negotiation on the home gateway:
1d02h: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up *Feb 4 14:14:40.505: Vi1 PPP: Treating connection as a dedicated line *Feb 4 14:14:40.505: Vi1 PPP: Phase is ESTABLISHING, Active Open *Feb 4 14:14:40.505: Vi1 PPP: Treating connection as a dedicated line *Feb 4 14:14:40.505: Vi1 PPP: Phase is AUTHENTICATING, by this end *Feb 4 14:14:40.509: Vi1 PPP: Phase is UP
If your call successfully completed PPP negotiation, but you still cannot ping the home gateway, go on to Step 4Troubleshooting AAA Negotiation. If your call cannot successfully complete PPP negotiation, contact your support personnel.

This section rst shows debug output of successful AAA negotiation. It then explains several common miscongurations that prevent successful AAA negotiation.
Successful AAA Negotiation Incorrect User Password Error Contacting RADIUS Server Miscongured AAA Authentication
Successful AAA Negotiation

Enable the debug aaa authentication and debug aaa authorization commands on the home gateway and dial in to the NAS. The following debug output shows successful AAA negotiation on the home gateway. This output has been edited to exclude repetitive lines.
ENT_HGW# Jan 7 19:29:44.132: AAA/AUTHEN: create_user (0x612D550C) user='ENT_HGW' ruser=' ' port='' rem_addr='' authen_type=CHAP service=PPP priv=1 Jan 7 19:29:44.132: AAA/AUTHEN/START (384300079): port='' list='default' action =SENDAUTH service=PPP Jan 7 19:29:44.132: AAA/AUTHEN/START (384300079): found list default Jan 7 19:29:44.132: AAA/AUTHEN/START (384300079): Method=LOCAL Jan 7 19:29:44.132: AAA/AUTHEN (384300079): status = PASS Jan 7 19:29:44.132: AAA/AUTHEN: create_user (0x612D550C) user='ISP_NAS' ruser=' ' port='' rem_addr='' authen_type=CHAP service=PPP priv=1 Jan 7 19:29:44.132: AAA/AUTHEN/START (2545876944): port='' list='default' actio n=SENDAUTH service=PPP Jan 7 19:29:44.132: AAA/AUTHEN/START (2545876944): found list default Jan 7 19:29:44.132: AAA/AUTHEN/START (2545876944): Method=LOCAL Jan 7 19:29:44.132: AAA/AUTHEN (2545876944): status = PASS Jan 7 19:29:44.228: AAA/AUTHEN: create_user (0x612F1F78) user='jeremy@hgw.com' ruser='' port='Virtual-Access1' rem_addr='408/5550945' authen_type=CHAP service= PPP priv=1 Jan 7 19:29:44.228: AAA/AUTHEN/START (101773535): port='Virtual-Access1' list='' action=LOGIN service=PPP Jan 7 19:29:44.228: AAA/AUTHEN/START (101773535): using "default" list Jan 7 19:29:44.228: AAA/AUTHEN/START (101773535): Method=LOCAL Jan 7 19:29:44.228: AAA/AUTHEN (101773535): status = ERROR Jan 7 19:29:44.228: AAA/AUTHEN/START (101773535): Method=RADIUS Jan 7 19:29:44.692: AAA/AUTHEN (101773535): status = PASS Jan 7 19:29:44.692: Vi1 AAA/AUTHOR/LCP: Authorize LCP Jan 7 19:29:44.692: AAA/AUTHOR/LCP Vi1 (3630870259): Port='Virtual-Access1' list='' service=NET Jan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) user='jeremy@hgw.com' Jan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) send AV service=ppp Jan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) send AV protocol=lcp Jan 7 19:29:44.692: AAA/AUTHOR/LCP (3630870259) found list "default" Jan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) Method=RADIUS Jan 7 19:29:44.692: AAA/AUTHOR (3630870259): Post authorization status = PASS_REPL Jan 7 19:29:44.696: Vi1 AAA/AUTHOR/FSM: We can start IPCP 6w5d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
84
Jan 7 19:29:47.792: Vi1 AAA/AUTHOR/IPCP: Start. 172.30.2.1
Her address 0.0.0.0, we want
If the above debug output appears, but you still cannot ping the home gateway, contact your support personnel and troubleshoot your networks 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 congured), the tunnel will be established, but the home gateway will not authenticate the user. If the user password is incorrect, the following debug output appears on the NAS and home gateway when you dial in to the NAS and the debug vpdn l2x-errors and debug vpdn l2x-events commands are enabled:
ISP_NAS# Jan 1 01:00:01.555: %LINK-3-UPDOWN: Interface Async12, changed state to up Jan 1 01:00:05.299: L2F: Tunnel state closed Jan 1 01:00:05.299: L2F: MID state closed Jan 1 01:00:05.299: L2F: Open UDP socket to 172.22.66.25 Jan 1 01:00:05.299: L2F: Tunnel state opening Jan 1 01:00:05.299: As12 L2F: MID jeremy@hgw.com state waiting_for_tunnel Jan 1 01:00:05.303: L2F: L2F_CONF received Jan 1 01:00:05.303: L2F: Removing resend packet (L2F_CONF) Jan 1 01:00:05.303: ENT_HGW L2F: Tunnel state open Jan 1 01:00:05.307: L2F: L2F_OPEN received Jan 1 01:00:05.307: L2F: Removing resend packet (L2F_OPEN) Jan 1 01:00:05.307: L2F: Building nas2gw_mid0 Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: CLID/DNIS 4089548021/5550945 Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: NAS-Port Async12 Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: Client-Bandwidth-Kbps 115 Jan 1 01:00:05.307: L2F: L2F_CLIENT_INFO: NAS-Rate L2F/26400/28800 Jan 1 01:00:05.307: As12 L2F: MID jeremy@hgw.com state opening Jan 1 01:00:05.307: L2F: Tunnel authentication succeeded for ENT_HGW Jan 1 01:00:05.391: L2F: L2F_OPEN received Jan 1 01:00:05.391: L2F: Got a MID management packet Jan 1 01:00:05.391: L2F: Removing resend packet (L2F_OPEN) Jan 1 01:00:05.391: As12 L2F: MID jeremy@hgw.com state open Jan 1 01:00:05.391: As12 L2F: MID synced NAS/HG Clid=47/12 Mid=1 Jan 1 01:00:05.523: L2F: L2F_CLOSE received Jan 1 01:00:05.523: %VPDN-6-AUTHENERR: L2F HGW ENT_HGW cannot locate a AAA server for As12 user jeremy@hgw.com; Authentication failure ENT_HGW# Jan 1 01:00:05.302: L2F: L2F_CONF received Jan 1 01:00:05.302: L2F: Creating new tunnel for ISP_NAS Jan 1 01:00:05.302: L2F: Tunnel state closed Jan 1 01:00:05.302: L2F: Got a tunnel named ISP_NAS, responding Jan 1 01:00:05.302: L2F: Open UDP socket to 172.22.66.23 Jan 1 01:00:05.302: ISP_NAS L2F: Tunnel state opening Jan 1 01:00:05.306: L2F: L2F_OPEN received Jan 1 01:00:05.306: L2F: Removing resend packet (L2F_CONF) Jan 1 01:00:05.306: ISP_NAS L2F: Tunnel state open Jan 1 01:00:05.306: L2F: Tunnel authentication succeeded for ISP_NAS Jan 1 01:00:05.310: L2F: L2F_OPEN received Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: CLID/DNIS 4089548021/5550945 Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: NAS-Port Async12 Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: Client-Bandwidth-Kbps 115 Jan 1 01:00:05.310: L2F: L2F_CLIENT_INFO: NAS-Rate L2F/26400/28800 Jan 1 01:00:05.310: L2F: Got a MID management packet Jan 1 01:00:05.310: L2F: MID state closed Jan 1 01:00:05.310: L2F: Start create mid intf process for jeremy@hgw.com 5w6d: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Jan 1 01:00:05.390: Vi1 L2X: Discarding packet because of no mid/session Jan 1 01:00:05.390: Vi1 L2F: Transfer NAS-Rate L2F/26400/28800 to LCP Jan 1 01:00:05.390: Vi1 L2F: Finish create mid intf for jeremy@hgw.com Jan 1 01:00:05.390: Vi1 L2F: MID jeremy@hgw.com state open 5w6d: %VPDN-6-AUTHENERR: L2F HGW ENT_HGW cannot locate a AAA server for Vi1 user jeremy@hgw.com; Authentication failure
Error Contacting RADIUS Server

If the aaa authorization command on the home gateway is congured with the default radius none keywords, the home gateway may allow unauthorized access to your network. This command is an instruction to rst use RADIUS for authorization. The home gateway rst contacts the RADIUS server (because of the radius keyword). If an error occurs when the home gateway contacts the RADIUS server, the home gateway does not authorize the user (because of the none keyword). To see the following debug output, enable the debug aaa authorization command on the home gateway and dial in to the NAS:
ENT_HGW# *Feb 5 17:27:36.166: *Feb 5 17:27:36.166: service=NET *Feb 5 17:27:36.166: *Feb 5 17:27:36.166: *Feb 5 17:27:36.166: *Feb 5 17:27:36.166: *Feb 5 17:27:36.166: *Feb 5 17:27:36.166: *Feb 5 17:27:36.166: *Feb 5 17:27:36.166: *Feb 5 17:27:36.166: Vi1 AAA/AUTHOR/LCP: Authorize LCP AAA/AUTHOR/LCP Vi1 (3192359105): Port='Virtual-Access1' list='' AAA/AUTHOR/LCP: Vi1 (3192359105) user='jeremy@hgw.com' AAA/AUTHOR/LCP: Vi1 (3192359105) send AV service=ppp AAA/AUTHOR/LCP: Vi1 (3192359105) send AV protocol=lcp AAA/AUTHOR/LCP (3192359105) found list "default" AAA/AUTHOR/LCP: Vi1 (3192359105) Method=RADIUS AAA/AUTHOR (3192359105): Post authorization status = ERROR AAA/AUTHOR/LCP: Vi1 (3192359105) Method=NONE AAA/AUTHOR (3192359105): Post authorization status = PASS_ADD Vi1 CHAP: O SUCCESS id 1 len 4
Using the none keyword can allow unauthorized access to your network. Because of the risk of such errors occurring, we strongly suggest that you do not use the none keyword in your aaa commands.
Caution
Miscongured AAA Authentication

If you reverse the order of the local and radius keywords in the aaa authentication ppp command on the home gateway, the L2F tunnel cannot be established. The command should be congured as aaa authentication ppp default local radius. If you congure the command as aaa authentication ppp default radius local, the home gateway rst tries to authenticate the L2F tunnel using RADIUS. The RADIUS server sends the following message to the home gateway. 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 home gateway 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 home gateway. If your call still cannot successfully complete AAA negotiation, contact your support personnel.
86 Access VPN Solutions Using Tunneling Technology
L2F Debug Output for the L2F Case Study

This appendix contains comprehensive debug output from the conguration tasks in this case study. The output is a powerful tool that can help you understand the entire process of how an access VPN is established when a user dials in. The most important lines of output in this appendix are shown in bold. Tables at the end of the output explain these bold lines. This appendix is divided into the following sections:
Debug Output from Conguring Basic Dial Access for the NAS Debug Output from Conguring Access VPN with Local AAA Debug Output from Conguring Access VPN with Remote AAA
Note If you are accessing the NAS and home gateway 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.
Debug Output from Conguring Basic Dial Access for the NAS
The following debug output is produced when a client dials into the NAS via the public switched telephone network (PSTN) and is authenticated locally on the NAS. For more information on how to congure basic dial access for the NAS, see Conguring the NAS for Basic Dial Access. Enable the following debug commands on the NAS:
debug isdn q931 debug ppp negotiation debug ppp authentication debug modem csm debug ip peer
From the client, dial the PRI telephone number assigned to the NAS T1 trunks. The username is jeremy; the password is subaru. The user is locally authenticated by the NAS. As the NAS receives the modem call from the client, the following debug command output appears on the NAS terminal screen.
L2F Debug Output for the L2F Case Study 89
ISP_NAS# *Jan 1 21:22:16.410: *Jan 1 21:22:16.410: *Jan 1 21:22:16.410: *Jan 1 21:22:18.410: *Jan 1 21:22:18.410: *Jan 1 21:22:18.410: *Jan 1 21:22:18.410: *Jan 1 21:22:18.410: *Jan 1 21:22:18.410: *Jan 1 21:22:18.410: *Jan 1 21:22:18.410: *Jan 1 21:22:18.410: *Jan 1 21:22:18.542: *Jan 1 21:22:18.542: *Jan 1 21:22:18.542: *Jan 1 21:22:18.542: *Jan 1 21:22:18.542: *Jan 1 21:22:18.542: *Jan 1 21:22:19.262: *Jan 1 21:22:19.262: *Jan 1 21:22:19.262: *Jan 1 21:22:19.262: *Jan 1 21:22:19.262: *Jan 1 21:22:19.262: *Jan 1 21:22:19.262: *Jan 1 21:22:19.262: *Jan 1 21:22:19.374: *Jan 1 21:22:19.374: *Jan 1 21:22:19.374: *Jan 1 21:22:19.374: *Jan 1 21:22:19.374: *Jan 1 21:22:19.374: *Jan 1 21:22:19.374: *Jan 1 21:22:19.374: *Jan 1 21:22:19.374: *Jan 1 21:22:19.374: *Jan 1 21:22:19.374: *Jan 1 21:22:19.374: *Jan 1 21:22:19.374: *Jan 1 21:22:19.518: *Jan 1 21:22:19.518: *Jan 1 21:22:19.518: *Jan 1 21:22:19.518: *Jan 1 21:22:19.518: *Jan 1 21:22:19.630: *Jan 1 21:22:19.630: 206002D0F01) *Jan 1 21:22:19.630: *Jan 1 21:22:19.630: *Jan 1 21:22:19.630: *Jan 1 21:22:19.630: *Jan 1 21:22:19.630: *Jan 1 21:22:19.630: *Jan 1 21:22:19.630: *Jan 1 21:22:19.630: *Jan 1 21:22:19.630: *Jan 1 21:22:19.630: *Jan 1 21:22:19.630: 206002D0F01) *Jan 1 21:22:19.630: *Jan 1 21:22:19.630: *Jan 1 21:22:19.646: *Jan 1 21:22:19.646: 001)
TTY14: destroy timer type 1 TTY14: destroy timer type 0 tty14: Modem: IDLE->READY %LINK-3-UPDOWN: Interface Async14, changed state to up As14 PPP: Treating connection as a dedicated line As14 PPP: Phase is ESTABLISHING, Active Open As14 LCP: O CONFREQ [Closed] id 1 len 25 As14 LCP: ACCM 0x000A0000 (0x0206000A0000) As14 LCP: AuthProto CHAP (0x0305C22305) As14 LCP: MagicNumber 0x151213B2 (0x0506151213B2) As14 LCP: PFC (0x0702) As14 LCP: ACFC (0x0802) As14 LCP: I CONFACK [REQsent] id 1 len 25 As14 LCP: ACCM 0x000A0000 (0x0206000A0000) As14 LCP: AuthProto CHAP (0x0305C22305) As14 LCP: MagicNumber 0x151213B2 (0x0506151213B2) As14 LCP: PFC (0x0702) As14 LCP: ACFC (0x0802) As14 LCP: I CONFREQ [ACKrcvd] id 2 len 23 As14 LCP: ACCM 0x000A0000 (0x0206000A0000) As14 LCP: MagicNumber 0x001A9072 (0x0506001A9072) As14 LCP: PFC (0x0702) As14 LCP: ACFC (0x0802) As14 LCP: Callback 6 (0x0D0306) As14 LCP: O CONFREJ [ACKrcvd] id 2 len 7 As14 LCP: Callback 6 (0x0D0306) As14 LCP: I CONFREQ [ACKrcvd] id 3 len 20 As14 LCP: ACCM 0x000A0000 (0x0206000A0000) As14 LCP: MagicNumber 0x001A9072 (0x0506001A9072) As14 LCP: PFC (0x0702) As14 LCP: ACFC (0x0802) As14 LCP: O CONFACK [ACKrcvd] id 3 len 20 As14 LCP: ACCM 0x000A0000 (0x0206000A0000) As14 LCP: MagicNumber 0x001A9072 (0x0506001A9072) As14 LCP: PFC (0x0702) As14 LCP: ACFC (0x0802) As14 LCP: State is Open As14 PPP: Phase is AUTHENTICATING, by this end As14 CHAP: O CHALLENGE id 1 len 28 from "ISP_NAS" As14 CHAP: I RESPONSE id 1 len 27 from "jeremy" As14 CHAP: O SUCCESS id 1 len 4 As14 PPP: Phase is UP As14 IPCP: O CONFREQ [Closed] id 1 len 10 As14 IPCP: Address 172.22.66.23 (0x0306AC164217) As14 IPCP: I CONFREQ [REQsent] id 1 len 40 As14 IPCP: CompressType VJ 15 slots CompressSlotID (0x0 As14 IPCP: Address 0.0.0.0 (0x030600000000) As14 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) As14 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) As14 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) As14 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) As14 IPCP: Using pool 'dialin_pool' ip_get_pool: As14: using pool dialin_pool ip_get_pool: As14: returning address = 172.22.66.55 As14 IPCP: Pool returned 172.22.66.55 As14 IPCP: O CONFREJ [REQsent] id 1 len 22 As14 IPCP: CompressType VJ 15 slots CompressSlotID (0x0 As14 As14 As14 As14 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) CCP: I CONFREQ [Not negotiated] id 1 len 15 CCP: MS-PPC supported bits 0x00000001 (0x120600000
90
Debug Output from Configuring Basic Dial Access for the NAS
*Jan 1 21:22:19.646: 000104) *Jan 1 21:22:19.646: *Jan 1 21:22:19.646: *Jan 1 21:22:19.646: *Jan 1 21:22:19.646: *Jan 1 21:22:19.646: *Jan 1 21:22:20.518: hanged state to up *Jan 1 21:22:21.518: *Jan 1 21:22:21.518: *Jan 1 21:22:21.518: *Jan 1 21:22:21.626: *Jan 1 21:22:21.626: *Jan 1 21:22:22.634: *Jan 1 21:22:22.634: *Jan 1 21:22:22.634: *Jan 1 21:22:22.634: *Jan 1 21:22:22.634: *Jan 1 21:22:22.634: *Jan 1 21:22:22.634: *Jan 1 21:22:22.634: *Jan 1 21:22:22.634: *Jan 1 21:22:22.742: *Jan 1 21:22:22.746: *Jan 1 21:22:22.746: *Jan 1 21:22:22.746: *Jan 1 21:22:22.746: *Jan 1 21:22:22.746: *Jan 1 21:22:22.746: *Jan 1 21:22:22.746: *Jan 1 21:22:22.854: *Jan 1 21:22:22.854: *Jan 1 21:22:22.858: *Jan 1 21:22:22.858: *Jan 1 21:22:22.858: *Jan 1 21:22:22.858: *Jan 1 21:22:22.858: *Jan 1 21:22:22.858: ndant *Jan 1 21:22:22.858: *Jan 1 21:22:22.858: *Jan 1 21:22:22.858: *Jan 1 21:22:22.858: *Jan 1 21:22:22.858: *Jan 1 21:22:22.858: ISP_NAS#
As14 CCP:
Stacker history 1 check mode EXTENDED (0x1105
As14 LCP: O PROTREJ [Open] id 2 len 21 protocol CCP As14 LCP: (0x80FD0101000F12060000000111050001) As14 LCP: (0x04) As14 IPCP: I CONFACK [REQsent] id 1 len 10 As14 IPCP: Address 172.22.66.23 (0x0306AC164217) %LINEPROTO-5-UPDOWN: Line protocol on Interface Async14, c As14 IPCP: TIMEout: State ACKrcvd As14 IPCP: O CONFREQ [ACKrcvd] id 2 len 10 As14 IPCP: Address 172.22.66.23 (0x0306AC164217) As14 IPCP: I CONFACK [REQsent] id 2 len 10 As14 IPCP: Address 172.22.66.23 (0x0306AC164217) As14 IPCP: I CONFREQ [ACKrcvd] id 2 len 34 As14 IPCP: Address 0.0.0.0 (0x030600000000) As14 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) As14 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) As14 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) As14 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) As14 IPCP: O CONFREJ [ACKrcvd] id 2 len 16 As14 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) As14 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) As14 IPCP: I CONFREQ [ACKrcvd] id 3 len 22 As14 IPCP: Address 0.0.0.0 (0x030600000000) As14 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) As14 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) As14 IPCP: O CONFNAK [ACKrcvd] id 3 len 22 As14 IPCP: Address 172.22.66.55 (0x0306AC164237) As14 IPCP: PrimaryDNS 171.68.10.70 (0x8106AB440A46) As14 IPCP: SecondaryDNS 171.68.10.140 (0x8306AB440A8C) As14 IPCP: I CONFREQ [ACKrcvd] id 4 len 22 As14 IPCP: Address 172.22.66.55 (0x0306AC164237) As14 IPCP: PrimaryDNS 171.68.10.70 (0x8106AB440A46) As14 IPCP: SecondaryDNS 171.68.10.140 (0x8306AB440A8C) ip_get_pool: As14: validate address = 172.22.66.55 ip_get_pool: As14: using pool dialin_pool ip_get_pool: As14: returning address = 172.22.66.55 set_ip_peer_addr: As14: address = 172.22.66.55 (3) is redu As14 As14 As14 As14 As14 As14 IPCP: O CONFACK [ACKrcvd] id 4 len 22 IPCP: Address 172.22.66.55 (0x0306AC164237) IPCP: PrimaryDNS 171.68.10.70 (0x8106AB440A46) IPCP: SecondaryDNS 171.68.10.140 (0x8306AB440A8C) IPCP: State is Open IPCP: Install route to 172.22.66.55
Table 8 describes the debug output events in more detail.

Table 8 Time Stamp 21:22:16.410 21:22:18:410 21:22:18:410 21:22:19:262 21:22:19:262 Time Stamps and Descriptions for Basic Dial Negotiation Events Description A modem call comes in to the access server on TTY line 14. Interface async 4 comes up. After PPP launches, TTY line 14 becomes async interface 14. An incoming PPP frame is recognized. PPP is launched on TTY line 14. Incoming cong request (I CONFREQ). The remote test PC requests a set of options to be negotiated. The PC asks the Cisco AS5300 to support the callback option. Outgoing cong reject (O CONFREJ). The Cisco AS5300 rejects the callback option. The access server is not congured to support Microsoft Callback in this case study. L2F Debug Output for the L2F Case Study 91
Time Stamp 21:22:19:374 21:22:19:374 21:22:19:374 21:22:19:374
Description Incoming cong request (I CONFREQ). The test PC requests a new set of options. Notice that Microsoft Callback is not requested. Outgoing cong acknowledgment (O CONFACK). The Cisco AS5300 accepts the new set of options. LCP is now open (LCP: State is Open). Both sides have acknowledged (CONFACK) the other sides conguration request (CONFREQ). After LCP negotiates, authentication starts. Authentication must take place before any network protocols, such as IP, are delivered. Both sides authenticate with the method negotiated during LCP. The Cisco AS5300 authenticates the client using CHAP. The client does not authenticate the access server. Outgoing challenge sent from ISP_NAS. Incoming CHAP response from the test PC, which shows the username jeremy. An outgoing success message is sent from the NASauthentication is successful. PPP is up. The Cisco AS5300 PPP link is now open and available to negotiate any network protocols supported by both peers. The client requests support for Microsoft Point-to-Point Compression (MPPC). The Cisco AS5300 rejects this request. The access servers integrated modems already support hardware compression, and the Cisco IOS is not congured to support software compression. The primary and secondary DNS addresses are negotiated. At rst, the client asks for 0.0.0.0. addresses. The access server sends out a CONFNAK and supplies the correct values, which include an IP address from the pool, the primary DNS address, and the backup DNS address. The client sends an incoming request saying that the new values are accepted. Whenever the access server sends out a CONFNAK that includes values, the client still has to accept the new values. An outgoing CONFACK is sent for IPCP. The state is open for IPCP. A route is negotiated and installed for the IPCP peer, which is assigned IP address 172.22.66.55.
21:22:19:374 21:22:19:518 21:22:19:518 21:22:19:518 21:22:19:646
21:22:22:634
21:22:22:854
21:22:22:858
Debug Output from Conguring Access VPN with Local AAA

The following debug output is produced by an access VPN that is using local AAA. The client dials in to the NAS, is forwarded to the home gateway using L2F, and the tunnel and username are authenticated using local AAA. For more information on how to congure the access VPN for local AAA, see Conguring the Access VPN to Work with Local AAA. Enable the following debug commands on the NAS.
debug isdn q931 debug modem csm debug ppp authentication debug ppp negotiation debug vpdn event debug vpdn l2x-events
92
Debug Output from Configuring Access VPN with Local AAA
Enable the following debug commands on the home gateway:
debug vpdn events debug vpdn l2x-events debug ppp negotiation debug ppp authentication debug vtemplate debug ip peer
Send an asynchronous PPP modem call in to the access server. As the call is forwarded to the home gateway, the following debug output appears on the NAS terminal screen:
ISP_NAS# *Jan 2 01:04:48.817: ISDN Se0:23: RX <- SETUP pd = 8 callref = 0x0266 *Jan 2 01:04:48.817: Bearer Capability i = 0x8090A2 *Jan 2 01:04:48.817: Channel ID i = 0xA98381 *Jan 2 01:04:48.821: Progress Ind i = 0x8283 - Origination address is n on-ISDN *Jan 2 01:04:48.821: Calling Party Number i = '!', 0x83, '4089548042' *Jan 2 01:04:48.821: Called Party Number i = 0xC1, '5550945' *Jan 2 01:04:48.821: ISDN Se0:23: TX -> CALL_PROC pd = 8 callref = 0x8266 *Jan 2 01:04:48.821: Channel ID i = 0xA98381 *Jan 2 01:04:48.821: ISDN Se0:23: TX -> ALERTING pd = 8 callref = 0x8266 *Jan 2 01:04:48.821: EVENT_FROM_ISDN::dchan_idb=0x60E9DD98, call_id=0x2E, ces=0 x1 bchan=0x0, event=0x1, cause=0x0 *Jan *Jan 2 01:04:48.821: VDEV_ALLOCATE: slot 1 and port 21 is allocated. 2 01:04:48.821: EVENT_FROM_ISDN:(002E): DEV_INCALL at slot 1 and port 21
*Jan 2 01:04:48.825: CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 21 *Jan 2 01:04:48.825: Mica Modem(1/21): Configure(0x1 = 0x0) *Jan 2 01:04:48.825: Mica Modem(1/21): Configure(0x23 = 0x0) *Jan 2 01:04:48.825: Mica Modem(1/21): Call Setup *Jan 2 01:04:48.913: Mica Modem(1/21): State Transition to Call Setup *Jan 2 01:04:48.913: Mica Modem(1/21): Went offhook *Jan 2 01:04:48.913: CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 21 *Jan 2 01:04:48.913: ISDN Se0:23: TX -> CONNECT pd = 8 callref = 0x8266 *Jan 2 01:04:48.945: ISDN Se0:23: RX <- CONNECT_ACK pd = 8 callref = 0x0266 *Jan 2 01:04:48.945: EVENT_FROM_ISDN::dchan_idb=0x60E9DD98, call_id=0x2E, ces=0 x1 bchan=0x0, event=0x4, cause=0x0 *Jan 1 *Jan slot *Jan *Jan *Jan *Jan *Jan *Jan *Jan *Jan *Jan *Jan *Jan 2 01:04:48.949: EVENT_FROM_ISDN:(002E): DEV_CONNECTED at slot 1 and port 2
2 01:04:48.949: 1, port 21 2 01:04:48.949: 2 01:04:50.049: 2 01:04:55.201: 2 01:05:12.753: 2 01:05:14.489: 2 01:05:15.149: 2 01:05:17.969: 2 01:05:17.969: 2 01:05:17.969: 2 01:05:17.969: 2 01:05:17.969:
CSM_PROC_IC4_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at Mica Modem(1/21): Link Initiate Mica Modem(1/21): State Transition to Connect Mica Modem(1/21): State Transition to Link Mica Modem(1/21): State Transition to Trainup Mica Modem(1/21): State Transition to EC Negotiating Mica Modem(1/21): State Transition to Steady State %LINK-3-UPDOWN: Interface Async22, changed state to up As22 PPP: Treating connection as a dedicated line As22 PPP: Phase is ESTABLISHING, Active Open As22 LCP: O CONFREQ [Closed] id 1 len 39 As22 LCP: ACCM 0x000A0000 (0x0206000A0000)
*Jan *Jan *Jan *Jan *Jan *Jan *Jan *Jan *Jan
2 2 2 2 2 2
01:05:17.969: 01:05:17.969: 01:05:17.969: 01:05:17.969: 01:05:17.969: 01:05:17.969:
As22 As22 As22 As22 As22 As22
LCP: LCP: LCP: LCP: LCP: LCP:
AuthProto CHAP (0x0305C22305) MagicNumber 0x15DE3BBE (0x050615DE3BBE) PFC (0x0702) ACFC (0x0802) MRRU 1524 (0x110405F4) EndpointDisc 1 Local (0x130A014953505F4E4153)
2 01:05:18.101: As22 LCP: I CONFREJ [REQsent] id 1 len 18 2 01:05:18.101: As22 LCP: MRRU 1524 (0x110405F4) 2 01:05:18.101: As22 LCP: EndpointDisc 1 Local (0x130A014953505F4E4153) As22 LCP: O CONFREQ [REQsent] id 2 len 25 As22 LCP: ACCM 0x000A0000 (0x0206000A0000) As22 LCP: AuthProto CHAP (0x0305C22305) As22 LCP: MagicNumber 0x15DE3BBE (0x050615DE3BBE) As22 LCP: PFC (0x0702) As22 LCP: ACFC (0x0802) As22 LCP: I CONFREQ [REQsent] id 2 len 23 As22 LCP: ACCM 0x000A0000 (0x0206000A0000) As22 LCP: MagicNumber 0x00E6BDE9 (0x050600E6BDE9) As22 LCP: PFC (0x0702) As22 LCP: ACFC (0x0802) As22 LCP: Callback 6 (0x0D0306) As22 LCP: O CONFREJ [REQsent] id 2 len 7 As22 LCP: Callback 6 (0x0D0306) As22 LCP: I CONFACK [REQsent] id 2 len 25 As22 LCP: ACCM 0x000A0000 (0x0206000A0000) As22 LCP: AuthProto CHAP (0x0305C22305) As22 LCP: MagicNumber 0x15DE3BBE (0x050615DE3BBE) As22 LCP: PFC (0x0702) As22 LCP: ACFC (0x0802) As22 LCP: I CONFREQ [ACKrcvd] id 3 len 20 As22 LCP: ACCM 0x000A0000 (0x0206000A0000) As22 LCP: MagicNumber 0x00E6BDE9 (0x050600E6BDE9) As22 LCP: PFC (0x0702) As22 LCP: ACFC (0x0802) As22 LCP: O CONFACK [ACKrcvd] id 3 len 20 As22 LCP: ACCM 0x000A0000 (0x0206000A0000) As22 LCP: MagicNumber 0x00E6BDE9 (0x050600E6BDE9) As22 LCP: PFC (0x0702) As22 LCP: ACFC (0x0802) As22 LCP: State is Open As22 PPP: Phase is AUTHENTICATING, by this end As22 CHAP: O CHALLENGE id 1 len 28 from "ISP_NAS" As22 CHAP: I RESPONSE id 1 len 35 from "jeremy@hgw.com" VPDN: Got DNIS string 5550945 As22 VPDN: Looking for tunnel -- hgw.com -L2F: Tunnel state closed As22 VPDN: Get tunnel info for hgw.com with NAS ISP_NAS, I As22 VPDN: Forward to address 172.22.66.25 As22 VPDN: Forwarding... As22 VPDN: Bind interface direction=1 L2F: MID state closed L2F: Open UDP socket to 172.22.66.25 L2F: Tunnel state opening As22 L2F: MID jeremy@hgw.com state waiting_for_tunnel As22 VPDN: jeremy@hgw.com is forwarded L2F: L2F_CONF received L2F: Removing resend packet (L2F_CONF) ISP_NAS L2F: Tunnel state open L2F: L2F_OPEN received L2F: Removing resend packet (L2F_OPEN) L2F: Building nas2gw_mid0 L2F: L2F_CLIENT_INFO: CLID/DNIS 4089548042/5550945
*Jan 2 01:05:18.105: *Jan 2 01:05:18.105: *Jan 2 01:05:18.105: *Jan 2 01:05:18.105: *Jan 2 01:05:18.105: *Jan 2 01:05:18.105: *Jan 2 01:05:18.213: *Jan 2 01:05:18.213: *Jan 2 01:05:18.213: *Jan 2 01:05:18.213: *Jan 2 01:05:18.213: *Jan 2 01:05:18.217: *Jan 2 01:05:18.217: *Jan 2 01:05:18.217: *Jan 2 01:05:18.229: *Jan 2 01:05:18.229: *Jan 2 01:05:18.229: *Jan 2 01:05:18.229: *Jan 2 01:05:18.233: *Jan 2 01:05:18.233: *Jan 2 01:05:18.325: *Jan 2 01:05:18.325: *Jan 2 01:05:18.325: *Jan 2 01:05:18.325: *Jan 2 01:05:18.325: *Jan 2 01:05:18.325: *Jan 2 01:05:18.325: *Jan 2 01:05:18.329: *Jan 2 01:05:18.329: *Jan 2 01:05:18.329: *Jan 2 01:05:18.329: *Jan 2 01:05:18.329: *Jan 2 01:05:18.329: *Jan 2 01:05:18.469: *Jan 2 01:05:18.469: *Jan 2 01:05:18.469: *Jan 2 01:05:18.473: *Jan 2 01:05:18.473: P 172.22.66.25 *Jan 2 01:05:18.473: *Jan 2 01:05:18.473: *Jan 2 01:05:18.473: *Jan 2 01:05:18.473: *Jan 2 01:05:18.473: *Jan 2 01:05:18.473: *Jan 2 01:05:18.473: *Jan 2 01:05:18.473: *Jan 2 01:05:18.477: *Jan 2 01:05:18.477: *Jan 2 01:05:18.477: *Jan 2 01:05:18.481: *Jan 2 01:05:18.481: *Jan 2 01:05:18.481: *Jan 2 01:05:18.481:
94
*Jan 2 01:05:18.481: *Jan 2 01:05:18.481: *Jan 2 01:05:18.481: *Jan 2 01:05:18.481: *Jan 2 01:05:18.481: *Jan 2 01:05:18.569: *Jan 2 01:05:18.569: *Jan 2 01:05:18.569: *Jan 2 01:05:18.569: *Jan 2 01:05:18.569: *Jan 2 01:05:18.569: *Jan 2 01:05:19.473: hanged state to up
L2F: L2F_CLIENT_INFO: NAS-Port Async22 L2F: L2F_CLIENT_INFO: Client-Bandwidth-Kbps 115 L2F: L2F_CLIENT_INFO: NAS-Rate L2F/0/0 As22 L2F: MID jeremy@hgw.com state opening VPDN: Chap authentication succeeded for ISP_NAS L2F: L2F_OPEN received L2F: Got a MID management packet L2F: Removing resend packet (L2F_OPEN) As22 L2F: MID jeremy@hgw.com state open As22 L2F: MID synced NAS/HG Clid=8/8 Mid=1 As22 PPP: Phase is FORWARDED %LINEPROTO-5-UPDOWN: Line protocol on Interface Async22, c

Table 9 Time Stamp 01:04:48.817 01:04:48.825 to 01:04:48.913 01:04:48.913 to 01:05:17.969 01:05:17.969 Time Stamps and Descriptions of Access VPN Events on the NAS Description The inbound call is received from the PRI TDM stream. The ISDN bearer capability reports that the call is an analog call (0x8090A2). The access server routes the call to the onboard MICA modem at 1/21 and begins negotiation with the remote site. Both sides successfully negotiate, and asynchronous interface 22 comes up. At this point, the NAS still does not know that the call is an access VPN call. The rst phase of PPP negotiation begins, which is link control protocol (LCP) negotiation. In this phase, the remote peers negotiate what type of authentication to use. The NAS demands that the client authenticate with CHAP. The client asks the NAS to support call back. The NAS denies the request. The client now resends the same request without the rejected option. The NAS sends the authentication CHAP challenge to the client. The client responds with jeremy@hgw.com. The NAS saves the clients response and later forwards it to the home gateway. The NAS found a DNIS string. VPDN authorization is about to begin. Tunnel information is found for the domain name hgw.com, tunnel name ISP_NAS, and the tunnel IP endpoint 172.22.66.25. A UDP socket interface is opened to the home gateways IP address. Because L2F is a UDP packet, a socket interface needs to be created. Because no tunnel currently exists for jeremy@hgw.com, the message waiting_for_tunnel appears. After the tunnel is established, the message jeremy@hgw.com is forwarded appears. The tunnel is authenticated and established between the NAS and home gateway. CHAP is the default tunnel authentication method. 01:05:18.473 to 01:05:18.569 01:05:18.481 The L2F protocol begins. A bidirectional authentication takes place between the NAS and the home gateway. Cisco proprietary L2F client information is forwarded to the home gateway. This information is used by the home gateway for accounting purposes. L2F uses standard AV pairs to forward this information. The PPP session is forwarded to the home gateway. Notice that IPCP negotiation does not occur on the NAS, but occurs on the home gateway. See the home gateways debug output. The asynchronous line protocol is up, which enables network layer communication.
01:05:18.213 to 01:05:18.329 01:05:18.329 01:05:18.469 01:05:18.469 01:05:18.473
01:05:18.569 01:05:19.473
As the call is forwarded from the NAS to the home gateway, the following debug output appears on the home gateways terminal screen.
ENT_HGW# *Feb 4 14:14:40.413: L2F: L2F_CONF received *Feb 4 14:14:40.413: L2F: Creating new tunnel for ISP_NAS *Feb 4 14:14:40.413: L2F: Tunnel state closed *Feb 4 14:14:40.413: L2F: Got a tunnel named ISP_NAS, responding *Feb 4 14:14:40.417: L2F: Open UDP socket to 172.22.66.23 *Feb 4 14:14:40.417: ISP_NAS L2F: Tunnel state opening *Feb 4 14:14:40.417: L2F: L2F_OPEN received *Feb 4 14:14:40.417: L2F: Removing resend packet (L2F_CONF) *Feb 4 14:14:40.417: VPDN: Chap authentication succeeded for ISP_NAS *Feb 4 14:14:40.417: ISP_NAS L2F: Tunnel state open *Feb 4 14:14:40.421: L2F: L2F_OPEN received *Feb 4 14:14:40.421: L2F: L2F_CLIENT_INFO: CLID/DNIS 4089548042/5550945 *Feb 4 14:14:40.421: L2F: L2F_CLIENT_INFO: NAS-Port Async21 *Feb 4 14:14:40.421: L2F: L2F_CLIENT_INFO: Client-Bandwidth-Kbps 115 *Feb 4 14:14:40.421: L2F: L2F_CLIENT_INFO: NAS-Rate L2F/0/0 *Feb 4 14:14:40.421: L2F: Got a MID management packet *Feb 4 14:14:40.421: L2F: MID state closed *Feb 4 14:14:40.421: L2F: Start create mid intf process for jeremy@hgw.com *Feb 4 14:14:40.421: Vi1 VTEMPLATE: Reuse Vi1, recycle queue size 0 *Feb 4 14:14:40.421: Vi1 VTEMPLATE: Hardware address 0050.d193.e000 *Feb 4 14:14:40.421: Vi1 VPDN: Virtual interface created for jeremy@hgw.com *Feb 4 14:14:40.421: Vi1 VPDN: Set to Async interface *Feb 4 14:14:40.425: Vi1 PPP: Phase is DOWN, Setup *Feb 4 14:14:40.425: Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking *Feb 4 14:14:40.425: Vi1 VTEMPLATE: Has a new cloneblk vtemplate, now it has vt emplate *Feb 4 14:14:40.425: Vi1 VTEMPLATE: ************* CLONE VACCESS1 ************** *** *Feb 4 14:14:40.425: Vi1 VTEMPLATE: Clone from Virtual-Template1 interface Virtual-Access1 default ip address no ip address encap ppp ip unnumbered fastethernet 0/0 no ip directed-broadcast ip unnumbered fastethernet 0/0 no ip directed-broadcast ppp authentication chap peer default ip address pool default encapsulation ppp ppp multilink end 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 LCP: O CONFREQ [Closed] id 1 len 39 *Feb 4 14:14:40.505: Vi1 LCP: ACCM 0x000A0000 (0x0206000A0000) *Feb 4 14:14:40.505: Vi1 LCP: AuthProto CHAP (0x0305C22305) *Feb 4 14:14:40.505: Vi1 LCP: MagicNumber 0x566F3EA8 (0x0506566F3EA8) *Feb 4 14:14:40.505: Vi1 LCP: PFC (0x0702) *Feb 4 14:14:40.505: Vi1 LCP: ACFC (0x0802) *Feb 4 14:14:40.505: Vi1 LCP: MRRU 1524 (0x110405F4) *Feb 4 14:14:40.505: Vi1 LCP: EndpointDisc 1 Local (0x130A01454E545F484757) *Feb 4 14:14:40.505: Vi1 VPDN: Bind interface direction=2 *Feb 4 14:14:40.505: Vi1 PPP: Treating connection as a dedicated line *Feb 4 14:14:40.505: Vi1 LCP: I FORCED CONFREQ len 21 *Feb 4 14:14:40.505: Vi1 LCP: ACCM 0x000A0000 (0x0206000A0000) *Feb 4 14:14:40.505: Vi1 LCP: AuthProto CHAP (0x0305C22305) *Feb 4 14:14:40.505: Vi1 LCP: MagicNumber 0x15B7E4FD (0x050615B7E4FD) *Feb 4 14:14:40.505: Vi1 LCP: PFC (0x0702)
96
*Feb 4 14:14:40.505: Vi1 LCP: ACFC (0x0802) *Feb 4 14:14:40.505: Vi1 VPDN: PPP LCP accepted rcv CONFACK *Feb 4 14:14:40.505: Vi1 VPDN: PPP LCP accepted sent CONFACK *Feb 4 14:14:40.505: Vi1 PPP: Phase is AUTHENTICATING, by this end *Feb 4 14:14:40.505: Vi1 CHAP: O CHALLENGE id 2 len 28 from "ENT_HGW" *Feb 4 14:14:40.505: Vi1 L2F: Transfer NAS-Rate L2F/0/0 to LCP *Feb 4 14:14:40.509: Vi1 CHAP: I RESPONSE id 1 len 35 from "jeremy@hgw.com" *Feb 4 14:14:40.509: Vi1 L2F: Finish create mid intf for jeremy@hgw.com *Feb 4 14:14:40.509: Vi1 L2F: MID jeremy@hgw.com state open *Feb 4 14:14:40.509: Vi1 CHAP: O SUCCESS id 1 len 4 *Feb 4 14:14:40.509: Vi1 PPP: Phase is UP *Feb 4 14:14:40.509: Vi1 IPCP: O CONFREQ [Closed] id 1 len 10 *Feb 4 14:14:40.509: Vi1 IPCP: Address 172.22.66.25 (0x0306AC164219) *Feb 4 14:14:40.617: Vi1 IPCP: I CONFREQ [REQsent] id 1 len 40 *Feb 4 14:14:40.617: Vi1 IPCP: CompressType VJ 15 slots CompressSlotID (0x02 06002D0F01) *Feb 4 14:14:40.617: Vi1 IPCP: Address 0.0.0.0 (0x030600000000) *Feb 4 14:14:40.617: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) *Feb 4 14:14:40.617: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) *Feb 4 14:14:40.621: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) *Feb 4 14:14:40.621: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) *Feb 4 14:14:40.621: Vi1 IPCP: Using pool 'default' *Feb 4 14:14:40.621: ip_get_pool: Vi1: using pool default *Feb 4 14:14:40.621: ip_get_pool: Vi1: returning address = 172.30.2.1 *Feb 4 14:14:40.621: Vi1 IPCP: Pool returned 172.30.2.1 *Feb 4 14:14:40.621: Vi1 IPCP: O CONFREJ [REQsent] id 1 len 10 *Feb 4 14:14:40.621: Vi1 IPCP: CompressType VJ 15 slots CompressSlotID (0x02 06002D0F01) *Feb 4 14:14:40.633: Vi1 CCP: I CONFREQ [Not negotiated] id 1 len 15 *Feb 4 14:14:40.633: Vi1 CCP: MS-PPC supported bits 0x00000001 (0x1206000000 01) *Feb 4 14:14:40.633: Vi1 CCP: Stacker history 1 check mode EXTENDED (0x11050 00104) *Feb 4 14:14:40.633: Vi1 LCP: O PROTREJ [Open] id 2 len 21 protocol CCP *Feb 4 14:14:40.633: Vi1 LCP: (0x80FD0101000F12060000000111050001) *Feb 4 14:14:40.633: Vi1 LCP: (0x04) *Feb 4 14:14:40.633: Vi1 IPCP: I CONFACK [REQsent] id 1 len 10 *Feb 4 14:14:40.637: Vi1 IPCP: Address 172.22.66.25 (0x0306AC164219) 1d02h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up *Feb 4 14:14:42.505: Vi1 LCP: TIMEout: State Open *Feb 4 14:14:42.509: Vi1 IPCP: TIMEout: State ACKrcvd *Feb 4 14:14:42.509: Vi1 IPCP: O CONFREQ [ACKrcvd] id 2 len 10 *Feb 4 14:14:42.509: Vi1 IPCP: Address 172.22.66.25 (0x0306AC164219) *Feb 4 14:14:42.613: Vi1 IPCP: I CONFACK [REQsent] id 2 len 10 *Feb 4 14:14:42.617: Vi1 IPCP: Address 172.22.66.25 (0x0306AC164219) *Feb 4 14:14:43.621: Vi1 IPCP: I CONFREQ [ACKrcvd] id 2 len 34 *Feb 4 14:14:43.621: Vi1 IPCP: Address 0.0.0.0 (0x030600000000) *Feb 4 14:14:43.621: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) *Feb 4 14:14:43.621: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) *Feb 4 14:14:43.621: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) *Feb 4 14:14:43.621: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) *Feb 4 14:14:43.621: Vi1 IPCP: O CONFNAK [ACKrcvd] id 2 len 34 *Feb 4 14:14:43.621: Vi1 IPCP: Address 172.30.2.1 (0x0306AC1E0201) *Feb 4 14:14:43.621: Vi1 IPCP: PrimaryDNS 172.23.1.10 (0x8106AC17010A) *Feb 4 14:14:43.621: Vi1 IPCP: PrimaryWINS 172.23.1.11 (0x8206AC17010B) *Feb 4 14:14:43.621: Vi1 IPCP: SecondaryDNS 172.23.2.10 (0x8306AC17020A) *Feb 4 14:14:43.621: Vi1 IPCP: SecondaryWINS 172.23.2.11 (0x8406AC17020B) *Feb 4 14:14:43.749: Vi1 IPCP: I CONFREQ [ACKrcvd] id 3 len 34 *Feb 4 14:14:43.749: Vi1 IPCP: Address 172.30.2.1 (0x0306AC1E0201) *Feb 4 14:14:43.749: Vi1 IPCP: PrimaryDNS 172.23.1.10 (0x8106AC17010A) *Feb 4 14:14:43.749: Vi1 IPCP: PrimaryWINS 172.23.1.11 (0x8206AC17010B) *Feb 4 14:14:43.749: Vi1 IPCP: SecondaryDNS 172.23.2.10 (0x8306AC17020A) *Feb 4 14:14:43.749: Vi1 IPCP: SecondaryWINS 172.23.2.11 (0x8406AC17020B) *Feb 4 14:14:43.749: ip_get_pool: Vi1: validate address = 172.30.2.1
*Feb 4 14:14:43.749: *Feb 4 14:14:43.749: *Feb 4 14:14:43.749: nt *Feb 4 14:14:43.749: *Feb 4 14:14:43.749: *Feb 4 14:14:43.749: *Feb 4 14:14:43.749: *Feb 4 14:14:43.753: *Feb 4 14:14:43.753: *Feb 4 14:14:43.753: *Feb 4 14:14:43.753: ENT_HGW#
ip_get_pool: Vi1: using pool default ip_get_pool: Vi1: returning address = 172.30.2.1 set_ip_peer_addr: Vi1: address = 172.30.2.1 (3) is redunda Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 IPCP: O CONFACK [ACKrcvd] id 3 len 34 IPCP: Address 172.30.2.1 (0x0306AC1E0201) IPCP: PrimaryDNS 172.23.1.10 (0x8106AC17010A) IPCP: PrimaryWINS 172.23.1.11 (0x8206AC17010B) IPCP: SecondaryDNS 172.23.2.10 (0x8306AC17020A) IPCP: SecondaryWINS 172.23.2.11 (0x8406AC17020B) IPCP: State is Open IPCP: Install route to 172.30.2.1

Table 10 Time Stamp 14:14:40.413 to 14:14:40:417 14:14:40:421 14:14:40:421 to 14:14:40:425 Time Stamps and Descriptions of Access VPN Events on the Home Gateway Description The home gateway receives the request from the NAS to open an L2F tunnel. The home gateway authenticates the tunnel and opens it. The NAS forwards the clients client information to the home gateway. A virtual-access interface is cloned from virtual template 1, which is not a physical interface, but it is treated like a regular interface that uses the IP address of the Fast Ethernet 0/0 interface The debug output following interface Virtual-Access1 lists every command that has been congured for virtual template 1. Enter the clear vtemplate command to reset the command history. 14:14:40.505 14:14:40:505 to 14:14:40:509 14:14:40:621 14:14:40:637 14:14:43.621 14:14:43.749 to 14:14:43.753 14:14:43:753 The NAS forces the information from the LCP negotiation with the client onto the virtual-access interface. The home gateway sends a CHAP challenge to the client. The client responds and is authenticated by the home gateway. The home gateway assigns the client the IP address 172.30.2.1 from the default pool. The line protocol on interface Virtual-Access1 is changed to the up state. The client requests IP addresses of DNS and WINS servers. The home gateway receives a positive acknowledgment from the client conrming the IP addresses of the DNS and WNIS servers. The home gateway installs the route to the clients IP address, 172.30.2.1
98
Debug Output from Configuring Access VPN with Remote AAA
Debug Output from Conguring Access VPN with Remote AAA

The following debug output is produced by an access VPN using remote AAA. The client dials in to the NAS, is forwarded to the home gateway using L2F. The NAS authenticates the tunnel using CiscoSecure UNIX, and the home gateway authenticates the username using CiscoSecure NT. For more information on how to congure the access VPN for remote AAA, see Conguring the Access VPN to Work with Remote AAA. Enable the following debug commands on the NAS:
debug isdn q931 debug modem csm debug radius debug aaa authentication debug aaa authorization debug ppp authentication debug ppp negotiation debug vpdn event debug vpdn l2x-event
Enable the following debug commands on the home gateway: debug radius debug aaa authentication debug aaa authorization debug ppp negotiation debug ppp authentication debug vtemplate debug ip peer debug vpdn l2x-errors debug vpdn l2x-events debug vpdn events
Launch an asynchronous PPP modem call in to the NAS. As the NAS receives the call and forwards it to the home gateway, the following debug output appears on the NAS:
ISP_NAS# Jan 7 19:29:15.775: ISDN Se0:23: RX <- SETUP pd = 8 callref = 0x0301 Jan 7 19:29:15.775: Bearer Capability i = 0x9090A2 Jan 7 19:29:15.775: Channel ID i = 0xA98381 Jan 7 19:29:15.775: Calling Party Number i = 0x0083, '408' Jan 7 19:29:15.775: Called Party Number i = 0xC1, '5550945' Jan 7 19:29:15.779: ISDN Se0:23: TX -> CALL_PROC pd = 8 callref = 0x8301 Jan 7 19:29:15.779: Channel ID i = 0xA98381 Jan 7 19:29:15.779: ISDN Se0:23: TX -> ALERTING pd = 8 callref = 0x8301 Jan 7 19:29:15.779: EVENT_FROM_ISDN::dchan_idb=0x60E97CDC, call_id=0x53, ces=0x 1 bchan=0x0, event=0x1, cause=0x0 Jan 7 19:29:15.779: VDEV_ALLOCATE: slot 1 and port 10 is allocated.
Jan Jan Jan Jan Jan Jan Jan Jan 10 Jan Jan Jan 1
7 19:29:15.779: EVENT_FROM_ISDN:(0053): DEV_INCALL at slot 1 and port 10 7 7 7 7 7 7 7 19:29:15.779: 19:29:15.779: 19:29:15.779: 19:29:15.779: 19:29:15.923: 19:29:15.923: 19:29:15.923: CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 10 Mica Modem(1/10): Configure(0x1 = 0x0) Mica Modem(1/10): Configure(0x23 = 0x0) Mica Modem(1/10): Call Setup Mica Modem(1/10): State Transition to Call Setup Mica Modem(1/10): Went offhook CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port
7 19:29:15.923: ISDN Se0:23: TX -> CONNECT pd = 8 callref = 0x8301 7 19:29:15.939: ISDN Se0:23: RX <- CONNECT_ACK pd = 8 callref = 0x0301 7 19:29:15.943: EVENT_FROM_ISDN::dchan_idb=0x60E97CDC, call_id=0x53, ces=0x bchan=0x0, event=0x4, cause=0x0
Jan Jan slot Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan Jan
7 19:29:15.943: EVENT_FROM_ISDN:(0053): DEV_CONNECTED at slot 1 and port 10 7 19:29:15.943: 1, port 10 7 19:29:15.943: 7 19:29:17.059: 7 19:29:22.211: 7 19:29:33.715: 7 19:29:36.951: 7 19:29:37.491: 7 19:29:40.339: 7 19:29:40.339: 7 19:29:40.339: 7 19:29:40.339: 7 19:29:40.339: 7 19:29:40.339: 7 19:29:40.339: 7 19:29:40.339: 7 19:29:40.339: 7 19:29:40.339: 7 19:29:40.443: 7 19:29:40.443: 7 19:29:40.443: 7 19:29:40.443: 7 19:29:40.443: 7 19:29:40.443: 7 19:29:40.859: 7 19:29:40.859: 7 19:29:40.859: 7 19:29:40.859: 7 19:29:40.859: 7 19:29:40.859: 7 19:29:40.859: 7 19:29:40.859: 7 19:29:42.339: 7 19:29:42.339: 7 19:29:42.339: 7 19:29:42.339: 7 19:29:42.339: 7 19:29:42.339: 7 19:29:42.339: 7 19:29:42.439: 7 19:29:42.439: 7 19:29:42.439: 7 19:29:42.439: 7 19:29:42.439: 7 19:29:42.439: 7 19:29:43.859: 7 19:29:43.859: CSM_PROC_IC4_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at Mica Modem(1/10): Link Initiate Mica Modem(1/10): State Transition to Connect Mica Modem(1/10): State Transition to Link Mica Modem(1/10): State Transition to Trainup Mica Modem(1/10): State Transition to EC Negotiating Mica Modem(1/10): State Transition to Steady State %LINK-3-UPDOWN: Interface Async11, changed state to up As11 PPP: Treating connection as a dedicated line As11 PPP: Phase is ESTABLISHING, Active Open As11 AAA/AUTHOR/FSM: (0): LCP succeeds trivially As11 LCP: O CONFREQ [Closed] id 3 len 25 As11 LCP: ACCM 0x000A0000 (0x0206000A0000) As11 LCP: AuthProto CHAP (0x0305C22305) As11 LCP: MagicNumber 0x33911E0F (0x050633911E0F) As11 LCP: PFC (0x0702) As11 LCP: ACFC (0x0802) As11 LCP: I CONFACK [REQsent] id 3 len 25 As11 LCP: ACCM 0x000A0000 (0x0206000A0000) As11 LCP: AuthProto CHAP (0x0305C22305) As11 LCP: MagicNumber 0x33911E0F (0x050633911E0F) As11 LCP: PFC (0x0702) As11 LCP: ACFC (0x0802) As11 LCP: I CONFREQ [ACKrcvd] id 2 len 23 As11 LCP: ACCM 0x000A0000 (0x0206000A0000) As11 LCP: MagicNumber 0x0002D813 (0x05060002D813) As11 LCP: PFC (0x0702) As11 LCP: ACFC (0x0802) As11 LCP: Callback 6 (0x0D0306) As11 LCP: O CONFREJ [ACKrcvd] id 2 len 7 As11 LCP: Callback 6 (0x0D0306) As11 LCP: TIMEout: State ACKrcvd As11 LCP: O CONFREQ [ACKrcvd] id 4 len 25 As11 LCP: ACCM 0x000A0000 (0x0206000A0000) As11 LCP: AuthProto CHAP (0x0305C22305) As11 LCP: MagicNumber 0x33911E0F (0x050633911E0F) As11 LCP: PFC (0x0702) As11 LCP: ACFC (0x0802) As11 LCP: I CONFACK [REQsent] id 4 len 25 As11 LCP: ACCM 0x000A0000 (0x0206000A0000) As11 LCP: AuthProto CHAP (0x0305C22305) As11 LCP: MagicNumber 0x33911E0F (0x050633911E0F) As11 LCP: PFC (0x0702) As11 LCP: ACFC (0x0802) As11 LCP: I CONFREQ [ACKrcvd] id 3 len 23 As11 LCP: ACCM 0x000A0000 (0x0206000A0000)
100
Jan 7 19:29:43.859: As11 LCP: MagicNumber 0x0002D813 (0x05060002D813) Jan 7 19:29:43.863: As11 LCP: PFC (0x0702) Jan 7 19:29:43.863: As11 LCP: ACFC (0x0802) Jan 7 19:29:43.863: As11 LCP: Callback 6 (0x0D0306) Jan 7 19:29:43.863: As11 LCP: O CONFREJ [ACKrcvd] id 3 len 7 Jan 7 19:29:43.863: As11 LCP: Callback 6 (0x0D0306) Jan 7 19:29:44.003: As11 LCP: I CONFREQ [ACKrcvd] id 4 len 20 Jan 7 19:29:44.003: As11 LCP: ACCM 0x000A0000 (0x0206000A0000) Jan 7 19:29:44.003: As11 LCP: MagicNumber 0x0002D813 (0x05060002D813) Jan 7 19:29:44.003: As11 LCP: PFC (0x0702) Jan 7 19:29:44.003: As11 LCP: ACFC (0x0802) Jan 7 19:29:44.007: As11 LCP: O CONFACK [ACKrcvd] id 4 len 20 Jan 7 19:29:44.007: As11 LCP: ACCM 0x000A0000 (0x0206000A0000) Jan 7 19:29:44.007: As11 LCP: MagicNumber 0x0002D813 (0x05060002D813) Jan 7 19:29:44.007: As11 LCP: PFC (0x0702) Jan 7 19:29:44.007: As11 LCP: ACFC (0x0802) Jan 7 19:29:44.007: As11 LCP: State is Open Jan 7 19:29:44.007: As11 PPP: Phase is AUTHENTICATING, by this end Jan 7 19:29:44.007: As11 CHAP: O CHALLENGE id 2 len 28 from "ISP_NAS" Jan 7 19:29:44.115: As11 CHAP: I RESPONSE id 2 len 35 from "jeremy@hgw.com" Jan 7 19:29:44.115: As11 PPP: Phase is FORWARDING Jan 7 19:29:44.115: sVPDN: Got DNIS string As11 Jan 7 19:29:44.119: As11 VPDN: Looking for tunnel -- hgw.com -Jan 7 19:29:44.119: AAA: parse name=Async11 idb type=10 tty=11 Jan 7 19:29:44.119: AAA: name=Async11 flags=0x11 type=4 shelf=0 slot=0 adapter= 0 port=11 channel=0 Jan 7 19:29:44.119: AAA: parse name=Serial0:0 idb type=12 tty=-1 Jan 7 19:29:44.119: AAA: name=Serial0:0 flags=0x51 type=1 shelf=0 slot=0 adapte r=0 port=0 channel=0 Jan 7 19:29:44.119: AAA/AUTHEN: create_user (0x6118F250) user='hgw.com' ruser=' ' port='Async11' rem_addr='' authen_type=NONE service=LOGIN priv=0 Jan 7 19:29:44.119: AAA/AUTHOR/VPDN (338468652): Port='Async11' list='default' service=NET Jan 7 19:29:44.119: AAA/AUTHOR/VPDN: (338468652) send AV service=ppp Jan 7 19:29:44.119: AAA/AUTHOR/VPDN: (338468652) send AV protocol=vpdn Jan 7 19:29:44.119: AAA/AUTHOR/VPDN (338468652) found list "default" Jan 7 19:29:44.119: AAA/AUTHOR/VPDN: (338468652) Method=RADIUS Jan 7 19:29:44.119: RADIUS: authenticating to get author data Jan 7 19:29:44.119: RADIUS: ustruct sharecount=2 Jan 7 19:29:44.119: RADIUS: Initial Transmit Async11 id 52 172.22.66.18:1645, A ccess-Request, len 71 Jan 7 19:29:44.119: Attribute 4 6 AC164217 Jan 7 19:29:44.119: Attribute 5 6 0000000B Jan 7 19:29:44.119: Attribute 61 6 00000000 Jan 7 19:29:44.119: Attribute 1 9 6867772E Jan 7 19:29:44.119: Attribute 2 18 99DFD8F8 Jan 7 19:29:44.119: Attribute 6 6 00000005 Jan 7 19:29:44.123: RADIUS: Received from id 52 172.22.66.18:1645, Access-Accep t, len 153 Jan 7 19:29:44.123: Attribute 26 31 0000000901197670 Jan 7 19:29:44.123: Attribute 26 32 00000009011A7670 Jan 7 19:29:44.123: Attribute 26 31 0000000901197670 Jan 7 19:29:44.123: Attribute 26 39 0000000901217670 Jan 7 19:29:44.123: RADIUS: saved authorization data for user 6118F250 at 61075 698 Jan 7 19:29:44.127: RADIUS: cisco AVPair "vpdn:gw-password=cisco" Jan 7 19:29:44.127: RADIUS: cisco AVPair "vpdn:nas-password=cisco" Jan 7 19:29:44.127: RADIUS: cisco AVPair "vpdn:tunnel-id=ISP_NAS" Jan 7 19:29:44.127: RADIUS: cisco AVPair "vpdn:ip-addresses=172.22.66.25" Jan 7 19:29:44.127: AAA/AUTHOR (338468652): Post authorization status = PASS_AD D Jan 7 19:29:44.127: AAA/AUTHOR/VPDN: Processing AV service=ppp Jan 7 19:29:44.127: AAA/AUTHOR/VPDN: Processing AV protocol=vpdn Jan 7 19:29:44.127: AAA/AUTHOR/VPDN: Processing AV gw-password=cisco Jan 7 19:29:44.127: AAA/AUTHOR/VPDN: Processing AV nas-password=cisco
Jan 7 19:29:44.127: AAA/AUTHOR/VPDN: Processing AV tunnel-id=ISP_NAS Jan 7 19:29:44.127: AAA/AUTHOR/VPDN: Processing AV ip-addresses=172.22.66.25 Jan 7 19:29:44.127: As11 VPDN: Get tunnel info for hgw.com with NAS ISP_NAS, IP 172.22.66.25 Jan 7 19:29:44.127: AAA/AUTHEN: free_user (0x6118F250) user='hgw.com' ruser='' port='Async11' rem_addr='' authen_type=NONE service=LOGIN priv=0 Jan 7 19:29:44.127: L2F: Tunnel state closed Jan 7 19:29:44.127: As11 VPDN: Forward to address 172.22.66.25 Jan 7 19:29:44.127: As11 VPDN: Forwarding... Jan 7 19:29:44.127: AAA: parse name=Async11 idb type=10 tty=11 Jan 7 19:29:44.127: AAA: name=Async11 flags=0x11 type=4 shelf=0 slot=0 adapter= 0 port=11 channel=0 Jan 7 19:29:44.127: AAA: parse name=Serial0:0 idb type=12 tty=-1 Jan 7 19:29:44.127: AAA: name=Serial0:0 flags=0x51 type=1 shelf=0 slot=0 adapte r=0 port=0 channel=0 Jan 7 19:29:44.127: AAA/AUTHEN: create_user (0x612B7E1C) user='jeremy@hgw.com' ruser='' port='Async11' rem_addr='408/5550945' authen_type=CHAP service=PPP priv =1 Jan 7 19:29:44.127: As11 VPDN: Bind interface direction=1 Jan 7 19:29:44.127: L2F: MID state closed Jan 7 19:29:44.127: L2F: Open UDP socket to 172.22.66.25 Jan 7 19:29:44.131: L2F: Tunnel state opening Jan 7 19:29:44.131: As11 L2F: MID jeremy@hgw.com state waiting_for_tunnel Jan 7 19:29:44.131: As11 VPDN: jeremy@hgw.com is forwarded Jan 7 19:29:44.135: L2F: L2F_CONF received Jan 7 19:29:44.135: L2F: Removing resend packet (L2F_CONF) Jan 7 19:29:44.135: ENT_HGW L2F: Tunnel state open Jan 7 19:29:44.135: L2F: L2F_OPEN received Jan 7 19:29:44.139: L2F: Removing resend packet (L2F_OPEN) Jan 7 19:29:44.139: L2F: Building nas2gw_mid0 Jan 7 19:29:44.139: L2F: L2F_CLIENT_INFO: CLID/DNIS 408/5550945 Jan 7 19:29:44.139: L2F: L2F_CLIENT_INFO: NAS-Port Async11 Jan 7 19:29:44.139: L2F: L2F_CLIENT_INFO: Client-Bandwidth-Kbps 115 Jan 7 19:29:44.139: L2F: L2F_CLIENT_INFO: NAS-Rate L2F/28800/50000 Jan 7 19:29:44.139: As11 L2F: MID jeremy@hgw.com state opening Jan 7 19:29:44.139: RADIUS: ustruct sharecount=3 Jan 7 19:29:44.139: RADIUS: Initial Transmit Async11 id 53 172.22.66.18:1646, A ccounting-Request, len 108 Jan 7 19:29:44.139: Attribute 4 6 AC164217 Jan 7 19:29:44.139: Attribute 5 6 0000000B Jan 7 19:29:44.139: Attribute 61 6 00000000 Jan 7 19:29:44.139: Attribute 1 16 6A657265 Jan 7 19:29:44.139: Attribute 30 9 35373130 Jan 7 19:29:44.139: Attribute 31 5 34303828 Jan 7 19:29:44.139: Attribute 40 6 00000001 Jan 7 19:29:44.139: Attribute 45 6 00000002 Jan 7 19:29:44.139: Attribute 6 6 00000002 Jan 7 19:29:44.139: Attribute 44 10 30303030 Jan 7 19:29:44.139: Attribute 7 6 00000001 Jan 7 19:29:44.139: Attribute 41 6 00000000 Jan 7 19:29:44.227: L2F: L2F_OPEN received Jan 7 19:29:44.227: L2F: Got a MID management packet Jan 7 19:29:44.227: L2F: Removing resend packet (L2F_OPEN) Jan 7 19:29:44.227: As11 L2F: MID jeremy@hgw.com state open Jan 7 19:29:44.227: As11 L2F: MID synced NAS/HG Clid=64/34 Mid=1 Jan 7 19:29:44.227: As11 PPP: Phase is FORWARDED Jan 7 19:29:44.795: RADIUS: Received from id 53 172.22.66.18:1646, Accounting-r esponse, len 20 Jan 7 19:29:45.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async11, ch anged state to up
102

Table 11 Time Stamp 19:29:44:007 to 19:29:44:115 19:29:44:119 19:29:44:119 19:29:44:119 Time Stamps and Descriptions of Access VPN Events on the NAS Description LCP negotiation is nished. The NAS sends a CHAP challenge to the client. The client sends a CHAP response with the username jeremy@hgw.com. The NAS is searching for tunnel information. The AAA subsystem inside the Cisco IOS software displays the call-path information. The current call uses TTY line 11, asynchronous interface 11, and serial B-channel 0:0. The local authorization module is accessed. The running conguration wants authorization for PPP and VPN services, and a AAA list called default. The default authorization method is RADIUS. The RADIUS module inside the Cisco IOS software transmits authentication and authorization attributes to the remote RADIUS server. The server is located at IP address 172.22.66.18. RADIUS authentication on UNIX platforms listens to port 1645. All authentication packets go out this port. The NAS requests RADIUS attributes to be negotiated by the AAA server. 19:29:44:123 19:29:44:127 The remote RADIUS server performs its authentication and authorization for hgw.com. The NAS receives vendor specic AV pairs from the AAA server. The RADIUS module transfers the attribute information to the local AAA subsystem. The post authorization status is equal to pass. The domain name hgw.com has been authenticated (see the free_user eld). The NAS attempts to forward the L2F tunnel to the home gateway at IP address 172.22.66.25. The home gateway authenticates the tunnel. A UDP socket is opened from the NAS to 172.22.66.25. The rst IP connection is made between the NAS and the home gateway. An accounting packet is sent to the AAA RADIUS server at IP address 172.22.66.18. RADIUS accounting listens on port 1646 on UNIX platforms. All accounting packets go out this port. The line protocol on asynchronous interface 11 is up, which means the L2F tunnel is established between the NAS and the home gateway.
19:29:44:119
19:29:44:127
19:29:44:139 19:29:45:131
The following debug output appears on the home gateways terminal screen.
ENT_HGW# Jan 7 19:29:44.132: L2F: L2F_CONF received Jan 7 19:29:44.132: L2F: Creating new tunnel for ISP_NAS Jan 7 19:29:44.132: L2F: Tunnel state closed Jan 7 19:29:44.132: L2F: Got a tunnel named ISP_NAS, responding Jan 7 19:29:44.132: AAA: parse name=<no string> idb type=-1 tty=-1 Jan 7 19:29:44.132: AAA/AUTHEN: create_user (0x612D550C) user='ENT_HGW' ruser=' ' port='' rem_addr='' authen_type=CHAP service=PPP priv=1 Jan 7 19:29:44.132: AAA/AUTHEN/START (384300079): port='' list='default' action =SENDAUTH service=PPP Jan 7 19:29:44.132: AAA/AUTHEN/START (384300079): found list default Jan 7 19:29:44.132: AAA/AUTHEN/START (384300079): Method=LOCAL Jan 7 19:29:44.132: AAA/AUTHEN (384300079): status = PASS Jan 7 19:29:44.132: AAA/AUTHEN: free_user (0x612D550C) user='ENT_HGW' ruser='' port='' rem_addr='' authen_type=CHAP service=PPP priv=1 Jan 7 19:29:44.132: AAA: parse name=<no string> idb type=-1 tty=-1 Jan 7 19:29:44.132: AAA/AUTHEN: create_user (0x612D550C) user='ISP_NAS' ruser=' ' port='' rem_addr='' authen_type=CHAP service=PPP priv=1 Jan 7 19:29:44.132: AAA/AUTHEN/START (2545876944): port='' list='default' actio n=SENDAUTH service=PPP Jan 7 19:29:44.132: AAA/AUTHEN/START (2545876944): found list default Jan 7 19:29:44.132: AAA/AUTHEN/START (2545876944): Method=LOCAL
Jan 7 19:29:44.132: AAA/AUTHEN (2545876944): status = PASS Jan 7 19:29:44.132: AAA/AUTHEN: free_user (0x612D550C) user='ISP_NAS' ruser='' port='' rem_addr='' authen_type=CHAP service=PPP priv=1 Jan 7 19:29:44.132: L2F: Open UDP socket to 172.22.66.23 Jan 7 19:29:44.132: ISP_NAS L2F: Tunnel state opening Jan 7 19:29:44.136: L2F: L2F_OPEN received Jan 7 19:29:44.136: L2F: Removing resend packet (L2F_CONF) Jan 7 19:29:44.136: AAA: parse name=<no string> idb type=-1 tty=-1 Jan 7 19:29:44.136: AAA/AUTHEN: create_user (0x612D550C) user='ISP_NAS' ruser=' ' port='' rem_addr='' authen_type=CHAP service=PPP priv=1 Jan 7 19:29:44.136: AAA/AUTHEN/START (1465065509): port='' list='default' actio n=LOGIN service=PPP Jan 7 19:29:44.136: AAA/AUTHEN/START (1465065509): found list default Jan 7 19:29:44.136: AAA/AUTHEN/START (1465065509): Method=LOCAL Jan 7 19:29:44.136: AAA/AUTHEN (1465065509): status = PASS Jan 7 19:29:44.136: VPDN: Chap authentication succeeded for ISP_NAS Jan 7 19:29:44.136: AAA/AUTHEN: free_user (0x612D550C) user='ISP_NAS' ruser='' port='' rem_addr='' authen_type=CHAP service=PPP priv=1 Jan 7 19:29:44.136: ISP_NAS L2F: Tunnel state open Jan 7 19:29:44.140: L2F: L2F_OPEN received Jan 7 19:29:44.140: L2F: L2F_CLIENT_INFO: CLID/DNIS 408/5550945 Jan 7 19:29:44.140: L2F: L2F_CLIENT_INFO: NAS-Port Async11 Jan 7 19:29:44.140: L2F: L2F_CLIENT_INFO: Client-Bandwidth-Kbps 115 Jan 7 19:29:44.140: L2F: L2F_CLIENT_INFO: NAS-Rate L2F/28800/50000 Jan 7 19:29:44.140: L2F: Got a MID management packet Jan 7 19:29:44.140: L2F: MID state closed Jan 7 19:29:44.140: L2F: Start create mid intf process for jeremy@hgw.com Jan 7 19:29:44.140: Vi1 VTEMPLATE: Reuse Vi1, recycle queue size 0 Jan 7 19:29:44.140: Vi1 VTEMPLATE: Hardware address 0050.d193.e000 Jan 7 19:29:44.140: Vi1 VPDN: Virtual interface created for jeremy@hgw.com Jan 7 19:29:44.140: Vi1 VPDN: Set to Async interface Jan 7 19:29:44.140: Vi1 PPP: Phase is DOWN, Setup Jan 7 19:29:44.140: Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking Jan 7 19:29:44.140: Vi1 VTEMPLATE: Has a new cloneblk vtemplate, now it has vte mplate Jan 7 19:29:44.140: Vi1 VTEMPLATE: ************* CLONE VACCESS1 *************** ** Jan 7 19:29:44.144: Vi1 VTEMPLATE: Clone from Virtual-Template1 interface Virtual-Access1 default ip address no ip address encap ppp ip unnumbered fastethernet 0/0 no ip directed-broadcast ip unnumbered fastethernet 0/0 no ip directed-broadcast ppp authentication chap peer default ip address pool default encapsulation ppp ppp multilink end 6w5d: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up Jan 7 19:29:44.224: Vi1 PPP: Treating connection as a dedicated line Jan 7 19:29:44.224: Vi1 PPP: Phase is ESTABLISHING, Active Open Jan 7 19:29:44.224: Vi1 AAA/AUTHOR/FSM: (0): LCP succeeds trivially Jan 7 19:29:44.224: Vi1 LCP: O CONFREQ [Closed] id 1 len 39 Jan 7 19:29:44.224: Vi1 LCP: ACCM 0x000A0000 (0x0206000A0000) Jan 7 19:29:44.224: Vi1 LCP: AuthProto CHAP (0x0305C22305) Jan 7 19:29:44.224: Vi1 LCP: MagicNumber 0x47ADAD67 (0x050647ADAD67) Jan 7 19:29:44.224: Vi1 LCP: PFC (0x0702) Jan 7 19:29:44.224: Vi1 LCP: ACFC (0x0802) Jan 7 19:29:44.224: Vi1 LCP: MRRU 1524 (0x110405F4) Jan 7 19:29:44.224: Vi1 LCP: EndpointDisc 1 Local (0x130A01454E545F484757) Jan 7 19:29:44.224: Vi1 VPDN: Bind interface direction=2
104
Jan 7 19:29:44.224: Vi1 PPP: Treating connection as a dedicated line Jan 7 19:29:44.224: Vi1 LCP: I FORCED CONFREQ len 21 Jan 7 19:29:44.224: Vi1 LCP: ACCM 0x000A0000 (0x0206000A0000) Jan 7 19:29:44.224: Vi1 LCP: AuthProto CHAP (0x0305C22305) Jan 7 19:29:44.224: Vi1 LCP: MagicNumber 0x33911E0F (0x050633911E0F) Jan 7 19:29:44.224: Vi1 LCP: PFC (0x0702) Jan 7 19:29:44.224: Vi1 LCP: ACFC (0x0802) Jan 7 19:29:44.224: Vi1 VPDN: PPP LCP accepted rcv CONFACK Jan 7 19:29:44.224: Vi1 VPDN: PPP LCP accepted sent CONFACK Jan 7 19:29:44.224: Vi1 PPP: Phase is AUTHENTICATING, by this end Jan 7 19:29:44.224: Vi1 CHAP: O CHALLENGE id 3 len 28 from "ENT_HGW" Jan 7 19:29:44.224: Vi1 L2F: Transfer NAS-Rate L2F/28800/50000 to LCP Jan 7 19:29:44.228: Vi1 CHAP: I RESPONSE id 2 len 35 from "jeremy@hgw.com" Jan 7 19:29:44.228: Vi1 L2F: Finish create mid intf for jeremy@hgw.com Jan 7 19:29:44.228: Vi1 L2F: MID jeremy@hgw.com state open Jan 7 19:29:44.228: AAA: parse name=Virtual-Access1 idb type=21 tty=-1 Jan 7 19:29:44.228: AAA: name=Virtual-Access1 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=1 channel=0 Jan 7 19:29:44.228: AAA/AUTHEN: create_user (0x612F1F78) user='jeremy@hgw.com' ruser='' port='Virtual-Access1' rem_addr='408/5550945' authen_type=CHAP service= PPP priv=1 Jan 7 19:29:44.228: AAA/AUTHEN/START (101773535): port='Virtual-Access1' list=' ' action=LOGIN service=PPP Jan 7 19:29:44.228: AAA/AUTHEN/START (101773535): using "default" list Jan 7 19:29:44.228: AAA/AUTHEN/START (101773535): Method=LOCAL Jan 7 19:29:44.228: AAA/AUTHEN (101773535): status = ERROR Jan 7 19:29:44.228: AAA/AUTHEN/START (101773535): Method=RADIUS Jan 7 19:29:44.228: RADIUS: ustruct sharecount=1 Jan 7 19:29:44.228: RADIUS: Initial Transmit Virtual-Access1 id 119 172.22.66.1 3:1645, Access-Request, len 99 Jan 7 19:29:44.228: Attribute 4 6 AC164219 Jan 7 19:29:44.228: Attribute 5 6 00000001 Jan 7 19:29:44.228: Attribute 61 6 00000005 Jan 7 19:29:44.228: Attribute 1 16 6A657265 Jan 7 19:29:44.228: Attribute 30 9 35373130 Jan 7 19:29:44.228: Attribute 31 5 34303803 Jan 7 19:29:44.228: Attribute 3 19 02A4F6DD Jan 7 19:29:44.228: Attribute 6 6 00000002 Jan 7 19:29:44.228: Attribute 7 6 00000001 Jan 7 19:29:44.692: RADIUS: Received from id 119 172.22.66.13:1645, Access-Acce pt, len 38 Jan 7 19:29:44.692: Attribute 6 6 00000002 Jan 7 19:29:44.692: Attribute 7 6 00000001 Jan 7 19:29:44.692: Attribute 8 6 FFFFFFFE Jan 7 19:29:44.692: AAA/AUTHEN (101773535): status = PASS Jan 7 19:29:44.692: Vi1 AAA/AUTHOR/LCP: Authorize LCP Jan 7 19:29:44.692: AAA/AUTHOR/LCP Vi1 (3630870259): Port='Virtual-Access1' lis t='' service=NET Jan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) user='jeremy@hgw.com' Jan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) send AV service=ppp Jan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) send AV protocol=lcp Jan 7 19:29:44.692: AAA/AUTHOR/LCP (3630870259) found list "default" Jan 7 19:29:44.692: AAA/AUTHOR/LCP: Vi1 (3630870259) Method=RADIUS Jan 7 19:29:44.692: AAA/AUTHOR (3630870259): Post authorization status = PASS_R EPL Jan 7 19:29:44.692: Vi1 AAA/AUTHOR/LCP: Processing AV service=ppp Jan 7 19:29:44.692: Vi1 CHAP: O SUCCESS id 2 len 4 Jan 7 19:29:44.692: Vi1 PPP: Phase is UP Jan 7 19:29:44.696: Vi1 AAA/AUTHOR/FSM: (0): Can we start IPCP? Jan 7 19:29:44.696: AAA/AUTHOR/FSM Vi1 (2925705703): Port='Virtual-Access1' lis t='' service=NET Jan 7 19:29:44.696: AAA/AUTHOR/FSM: Vi1 (2925705703) user='jeremy@hgw.com' Jan 7 19:29:44.696: AAA/AUTHOR/FSM: Vi1 (2925705703) send AV service=ppp Jan 7 19:29:44.696: AAA/AUTHOR/FSM: Vi1 (2925705703) send AV protocol=ip Jan 7 19:29:44.696: AAA/AUTHOR/FSM (2925705703) found list "default"
Jan 7 19:29:44.696: AAA/AUTHOR/FSM: Vi1 (2925705703) Method=RADIUS Jan 7 19:29:44.696: RADIUS: Using NAS default peer Jan 7 19:29:44.696: RADIUS: Authorize IP address 0.0.0.0 Jan 7 19:29:44.696: AAA/AUTHOR (2925705703): Post authorization status = PASS_R EPL Jan 7 19:29:44.696: Vi1 AAA/AUTHOR/FSM: We can start IPCP Jan 7 19:29:44.696: Vi1 IPCP: O CONFREQ [Closed] id 1 len 10 Jan 7 19:29:44.696: Vi1 IPCP: Address 172.22.66.25 (0x0306AC164219) Jan 7 19:29:44.696: RADIUS: ustruct sharecount=2 Jan 7 19:29:44.696: RADIUS: Initial Transmit Virtual-Access1 id 120 172.22.66.1 3:1646, Accounting-Request, len 108 Jan 7 19:29:44.696: Attribute 4 6 AC164219 Jan 7 19:29:44.696: Attribute 5 6 00000001 Jan 7 19:29:44.696: Attribute 61 6 00000005 Jan 7 19:29:44.696: Attribute 1 16 6A657265 Jan 7 19:29:44.696: Attribute 30 9 35373130 Jan 7 19:29:44.696: Attribute 31 5 34303828 Jan 7 19:29:44.696: Attribute 40 6 00000001 Jan 7 19:29:44.696: Attribute 45 6 00000001 Jan 7 19:29:44.696: Attribute 6 6 00000002 Jan 7 19:29:44.700: Attribute 44 10 30303030 Jan 7 19:29:44.700: Attribute 7 6 00000001 Jan 7 19:29:44.700: Attribute 41 6 00000000 Jan 7 19:29:44.740: RADIUS: Received from id 120 172.22.66.13:1646, Accountingresponse, len 20 Jan 7 19:29:44.804: Vi1 IPCP: I CONFREQ [REQsent] id 1 len 40 Jan 7 19:29:44.804: Vi1 IPCP: CompressType VJ 15 slots CompressSlotID (0x020 6002D0F01) Jan 7 19:29:44.804: Vi1 IPCP: Address 0.0.0.0 (0x030600000000) Jan 7 19:29:44.804: Vi1 IPCP: PrimaryDNS 171.68.10.70 (0x8106AB440A46) Jan 7 19:29:44.804: Vi1 IPCP: PrimaryWINS 171.68.235.228 (0x8206AB44EBE4) Jan 7 19:29:44.804: Vi1 IPCP: SecondaryDNS 171.68.10.140 (0x8306AB440A8C) Jan 7 19:29:44.808: Vi1 IPCP: SecondaryWINS 171.68.235.229 (0x8406AB44EBE5) Jan 7 19:29:44.808: Vi1 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want 0 .0.0.0 Jan 7 19:29:44.808: Vi1 AAA/AUTHOR/IPCP: Processing AV service=ppp Jan 7 19:29:44.808: Vi1 AAA/AUTHOR/IPCP: Processing AV addr=0.0.0.0 Jan 7 19:29:44.808: Vi1 AAA/AUTHOR/IPCP: Authorization succeeded Jan 7 19:29:44.808: Vi1 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0, we want 0. 0.0.0 Jan 7 19:29:44.808: Vi1 IPCP: Using pool 'default' Jan 7 19:29:44.808: ip_get_pool: Vi1: using pool default Jan 7 19:29:44.808: ip_get_pool: Vi1: returning address = 172.30.2.1 Jan 7 19:29:44.808: Vi1 IPCP: Pool returned 172.30.2.1 Jan 7 19:29:44.808: Vi1 IPCP: O CONFREJ [REQsent] id 1 len 10 Jan 7 19:29:44.808: Vi1 IPCP: CompressType VJ 15 slots CompressSlotID (0x020 6002D0F01) Jan 7 19:29:44.808: Vi1 CCP: I CONFREQ [Not negotiated] id 1 len 15 Jan 7 19:29:44.808: Vi1 CCP: MS-PPC supported bits 0x00000001 (0x12060000000 1) Jan 7 19:29:44.808: Vi1 CCP: Stacker history 1 check mode EXTENDED (0x110500 0104) Jan 7 19:29:44.808: Vi1 LCP: O PROTREJ [Open] id 2 len 21 protocol CCP Jan 7 19:29:44.808: Vi1 LCP: (0x80FD0101000F12060000000111050001) Jan 7 19:29:44.808: Vi1 LCP: (0x04) Jan 7 19:29:44.808: Vi1 IPCP: I CONFACK [REQsent] id 1 len 10 Jan 7 19:29:44.808: Vi1 IPCP: Address 172.22.66.25 (0x0306AC164219) 6w5d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed s tate to up Jan 7 19:29:46.224: Vi1 LCP: TIMEout: State Open Jan 7 19:29:46.696: Vi1 IPCP: TIMEout: State ACKrcvd Jan 7 19:29:46.696: Vi1 IPCP: O CONFREQ [ACKrcvd] id 2 len 10 Jan 7 19:29:46.696: Vi1 IPCP: Address 172.22.66.25 (0x0306AC164219) Jan 7 19:29:46.784: Vi1 IPCP: I CONFACK [REQsent] id 2 len 10 Jan 7 19:29:46.784: Vi1 IPCP: Address 172.22.66.25 (0x0306AC164219)
106
Jan 7 19:29:47.792: Jan 7 19:29:47.792: Jan 7 19:29:47.792: Jan 7 19:29:47.792: Jan 7 19:29:47.792: Jan 7 19:29:47.792: Jan 7 19:29:47.792: 72.30.2.1 Jan 7 19:29:47.792: Jan 7 19:29:47.792: Jan 7 19:29:47.792: Jan 7 19:29:47.792: 2.30.2.1 Jan 7 19:29:47.792: Jan 7 19:29:47.792: Jan 7 19:29:47.792: Jan 7 19:29:47.792: Jan 7 19:29:47.792: Jan 7 19:29:47.792: Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: t 172.30.2.1 Jan 7 19:29:47.952: st='' service=NET Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: EPL Jan 7 19:29:47.952: t Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: Jan 7 19:29:47.952: 172.30.2.1 Jan 7 19:29:47.952: Jan 7 19:29:47.956: Jan 7 19:29:47.956: Jan 7 19:29:47.956: Jan 7 19:29:47.956: Jan 7 19:29:47.956: Jan 7 19:29:47.956: Jan 7 19:29:47.956: ENT_HGW#
Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1
IPCP: I CONFREQ [ACKrcvd] id 2 len 34 IPCP: Address 0.0.0.0 (0x030600000000) IPCP: PrimaryDNS 171.68.10.70 (0x8106AB440A46) IPCP: PrimaryWINS 171.68.235.228 (0x8206AB44EBE4) IPCP: SecondaryDNS 171.68.10.140 (0x8306AB440A8C) IPCP: SecondaryWINS 171.68.235.229 (0x8406AB44EBE5) AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want 1 AAA/AUTHOR/IPCP: AAA/AUTHOR/IPCP: AAA/AUTHOR/IPCP: AAA/AUTHOR/IPCP: Processing AV service=ppp Processing AV addr=0.0.0.0 Authorization succeeded Done. Her address 0.0.0.0, we want 17
IPCP: O CONFNAK [ACKrcvd] id 2 len 34 IPCP: Address 172.30.2.1 (0x0306AC1E0201) IPCP: PrimaryDNS 172.23.1.10 (0x8106AC17010A) IPCP: PrimaryWINS 172.23.1.11 (0x8206AC17010B) IPCP: SecondaryDNS 172.23.2.10 (0x8306AC17020A) IPCP: SecondaryWINS 172.23.2.11 (0x8406AC17020B) IPCP: I CONFREQ [ACKrcvd] id 3 len 34 IPCP: Address 172.30.2.1 (0x0306AC1E0201) IPCP: PrimaryDNS 172.23.1.10 (0x8106AC17010A) IPCP: PrimaryWINS 172.23.1.11 (0x8206AC17010B) IPCP: SecondaryDNS 172.23.2.10 (0x8306AC17020A) IPCP: SecondaryWINS 172.23.2.11 (0x8406AC17020B) AAA/AUTHOR/IPCP: Start. Her address 172.30.2.1, we wan
AAA/AUTHOR/IPCP Vi1 (1744344778): Port='Virtual-Access1' li AAA/AUTHOR/IPCP: Vi1 (1744344778) user='jeremy@hgw.com' AAA/AUTHOR/IPCP: Vi1 (1744344778) send AV service=ppp AAA/AUTHOR/IPCP: Vi1 (1744344778) send AV protocol=ip AAA/AUTHOR/IPCP: Vi1 (1744344778) send AV addr*172.30.2.1 AAA/AUTHOR/IPCP (1744344778) found list "default" AAA/AUTHOR/IPCP: Vi1 (1744344778) Method=RADIUS RADIUS: Using NAS default peer RADIUS: Authorize IP address 172.30.2.1 AAA/AUTHOR (1744344778): Post authorization status = PASS_R set_ip_peer_addr: Vi1: address = 172.30.2.1 (4) is redundan Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 Vi1 AAA/AUTHOR/IPCP: AAA/AUTHOR/IPCP: AAA/AUTHOR/IPCP: AAA/AUTHOR/IPCP: Processing AV service=ppp Processing AV addr=172.30.2.1 Authorization succeeded Done. Her address 172.30.2.1, we want
IPCP: O CONFACK [ACKrcvd] id 3 len 34 IPCP: Address 172.30.2.1 (0x0306AC1E0201) IPCP: PrimaryDNS 172.23.1.10 (0x8106AC17010A) IPCP: PrimaryWINS 172.23.1.11 (0x8206AC17010B) IPCP: SecondaryDNS 172.23.2.10 (0x8306AC17020A) IPCP: SecondaryWINS 172.23.2.11 (0x8406AC17020B) IPCP: State is Open IPCP: Install route to 172.30.2.1

Table 12 Time Stamp 19:27:36.066 to 19:27:36.074 19:27:36.070 19:27:36.074 19:27:36.074 19:27:36.074 to 19:27:36.078 19.27.36.078 19:27:36.078 to 19:27:36.082 Time Stamps and Descriptions of Access VPN Events on the Home Gateway Description The home gateway receives a request from the NAS to open an L2F tunnel. The home gateway authenticates the tunnel and opens it. The home gateway receives a SENDAUTH packet from the NAS, which wants to authenticate the home gateway. The NAS authenticates the home gateway and sends an L2F_OPEN packet to open the tunnel. The home gateway authenticates the tunnel by using local AAA. The L2F tunnel is opened. The NAS forwards the client information to the home gateway. A virtual-access interface is cloned from virtual template 1, which is not a physical interface, but is treated like a regular interface that uses the IP address of the Fast Ethernet 0/0 interface. The debug output following interface Virtual-Access1 lists every command that has been congured for virtual template 1. Enter the clear vtemplate command to reset the command history. 19:27:36.162 19:27:36.162 19:27:36.282 19:27:36.294 19:27:39.282 19:27:39.414 19:27:39.414 The NAS forces the information from the LCP negotiation with the client onto the virtual-access interface. The home gateway sends a CHAP challenge to the client, who responds and is authenticated by the home gateway. The home gateway assigns the client the IP address 172.30.2.1 from the default pool. The line protocol on interface Virtual-Access1 changes to the up state. The client requests IP addresses of DNS and WINS servers. The home gateway receives a positive acknowledgment from the client conrming the IP addresses of the DNS and WNIS servers. The home gateway installs the route to the clients IP address, 172.30.2.1.
108
Glossary
attribute-value pair (AV pair)A generic pair of values passed from a AAA server to a AAA client. For example, in the AV pair user = bill, user is the attribute and bill is the value. calling line identication (CLID)A unique number that informs the called party of the phone number of the calling party. challenge handshake authentication protocol (CHAP)A PPP cryptographic challenge/response authentication protocol in which the cleartext password is not passed over the line. CHAP allows the secure exchange of a shared secret between the two endpoints of a connection. clientThe hardware and software that the user uses to establish the PPP session. Because all clients discussed in these case studies are remote clients, the term client refers to any remote client. cloningCreating and conguring a virtual access interface by applying a specic virtual template interface. The template is the source of the generic user and router-dependent information. The result of cloning is a virtual access interface congured with all the commands in the template. control messagesExchange messages between the NAS and home gateway pairs, operating in-band within the tunnel protocol. Control messages govern the aspects of the tunnel and sessions within the tunnel. Dialed Number identication Service (DNIS)The called party number used by call centers or a central ofce where different numbers are assigned to a specic service. home gatewayThe device, maintained by the enterprise customer, where a tunnel terminates. A home gateway is analogous to the L2TP network server. Integrated Services Digital Network (ISDN)Communication protocols offered by telephone companies that permit telephone networks to carry date, voice, and other source trafc. Layer 2 Forwarding (L2F)A Layer 2 tunneling protocol that establishes a secure tunnel across a public infrastructure (such as the Internet) that connects an ISP POP to a enterprise home gateway. This tunnel creates a virtual point-to-point connection between the user and the enterprise customers network. L2F is the most established and stable Layer 2 tunneling protocol. Layer 2 Tunnel Protocol (L2TP)A Layer 2 tunneling protocol that is an extension of the PPP protocol used for virtual private networks (VPNs). L2TP merges the best features of two existing tunneling protocols: Microsofts PPTP and Ciscos L2F. L2TP is the emerging IETF standard, currently being drafted by participants from Ascend, Cisco Systems, Copper Mountain Networks, IBM, Microsoft, and 3Com. Link Control Protocol (LCP)A protocol that establishes, congures, and tests data link connections used by the PPP.
Glossary 109
L2TP access concentrator (LAC)In L2TP technology, a device that the client directly connects to and through which PPP frames are tunneled to the L2TP network server (LNS). The LAC need only implement the media over which L2TP is to operate to pass trafc to one or more LNSs. The LAC may tunnel any protocol carried within PPP. The LAC initiates incoming calls and receives outgoing calls. A LAC is analogous to an L2F network access server (NAS). L2TP network server (LNS)In L2TP technology, a termination point for L2TP tunnels, and an access point where PPP frames are processed and passed to higher layer protocols. An LNS can operate on any platform that terminates PPP. The LNS handles the server side of the L2TP protocol. L2TP relies only on the single media over which L2TP tunnels arrive. The LNS may have a single LAN or WAN interfaceyet it can terminate calls arriving at any of the LACs full range of PPP interfaces (asynchronous, synchronous, ISDN, V.120, etc.). The LNS initiates outgoing calls and receives incoming calls. An LNS is analogous to a home gateway in L2F technology. Message Digest 5 (MD5)An algorithm used for message authentication in SNMP v.2. MD5 veries the integrity of the communication, authenticates the origin, and checks for timeliness. Multiplex Identier (MID)The number associated with a specic users L2TP/L2F session. Multilink PPP Protocol (MLP)A protocol that splits and recombines packets to a single end system across a logical pipe (also called a bundle) formed by multiple links. Multilink PPP provides bandwidth on demand and reduces transmission latency across WAN links. Network Access Server (NAS)A device providing temporary, on-demand network access to users. The access is typically point-to-point using PSTN or ISDN lines. In Ciscos implementation for L2TP, the NAS serves as a LAC for incoming calls and serves as a LNS for outgoing calls. A NAS is analogous to an L2TP access server (LAC). Network Control protocol (NCP)A PPP protocol for negotiating OSI Layer 3 (the network layer) parameters. Password Authentication Protocol (PAP)A simple PPP authentication mechanism where a cleartext username and password are transmitted to prove identity. PAP is not as secure as CHAP because the password is passed in cleartext. point-of-presence (POP)The access point to a service providers network. The device that the user dials in to. Point-to-Point Protocol (PPP)A protocol that encapsulates network layer protocol information over point-to-point links. The RFC for PPP is RFC 1661. Point-to-Point Tunneling Protocol (PPTP)A Microsoft proprietary tunneling protocol that was combined with L2F to create L2TP. public switched telephone network (PSTN)Telephone networks and services in place worldwide. remote clientSee client. remote userSee user. sessionA single tunneled PPP call. tunnelA virtual pipe between the ISP and home gateway that can carry multiple PPP sessions. tunnel IDA two-octet value that denotes a tunnel between an ISP and a home gateway. userInstigator of a PPP session. Because all users discussed in these case studies are remote users, the term user refers to any remote user.
110
virtual access interfaceA unique virtual interface that is created dynamically and exists temporarily. Virtual access interfaces can be created and congured differently by different applications, such as virtual proles and virtual private dialup networks. Virtual access interfaces are cloned from virtual template interfaces. In access VPNs, the home gateway clones a virtual access interface for VPN users. virtual templateA template that is used to create a logical interface congured with generic conguration information for a specic purpose or common conguration. The template takes the form of a list of Cisco IOS interface commands that are applied to virtual access interfaces, as needed. In access VPNs, the virtual template is congured on the home gateway and used to clone virtual access interfaces for VPN users. virtual private dialup networking (VPDN)See virtual private network. virtual private network (VPN)A system that permits networks to extend beyond a physical home networks while giving the appearance and functonality of being directly connected to a home network. VPNs use L2TP and L2F to extend the Layer 2 and higher parts of the network connection from the ISP to the home gateway. The specic term VPDN is being replaced by the more general term VPN.
Glossary 111
112

Access VPNs and Tunneling Technologies

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Access VPNs and Tunneling Technologies

Încărcat de

Drepturi de autor:

Formate disponibile

Overview of Access VPNs and Tunneling Technologies

This document focuses solely on access VPNs.

Overview of Access VPNs and Tunneling Technologies 1

Home PC Router SOHO

Router ROBO Modem

Access VPN Solutions Using Tunneling Technology

Access VPN Architectures

Access VPN Architectures

This document focuses solely on NAS-initiated access VPNs.

ISPs and Enterprise Customers

Access VPN Technologies

Legend L2F PPP IP

Access VPN Solutions Using Tunneling Technology

Protocol Negotiation Sequence

Protocol Negotiation Sequence

CHAP Auth-OK PPP Packets 7 8 9

Overview of Access VPNs and Tunneling Technologies 5

Table 1 explains the sequence of events shown in Figure 3.

L2F Tunnel Authentication Process

Access VPN Solutions Using Tunneling Technology

L2F Tunnel Authentication Process

Figure 4 describes the tunnel authentication process.

Table 2 explains the sequence of events shown in Figure 4.

Overview of Access VPNs and Tunneling Technologies 7

Three-Way CHAP Authentication Process

CHAP response CHAP success or failure

Table 3 explains the sequence of events shown in Figure 5.

Access VPN Solutions Using Tunneling Technology

L2F Case Study Overview

Internet service provider Access VPN

L2F Case Study Overview 13

Cisco AS5300 network access 4 TI PRI lines server

CiscoSecure ACS NT server

Ethernet Cisco 7206 home gateway

Access VPN Solutions Using Tunneling Technology

CiscoSecure ACS NT Server PC workstation 1 Ethernet interface

Client PC laptop 1 RJ-11 port

Cisco IOS Release 11.3(7)AA Cisco AS5300 series IP

Cisco IOS Release 12.0(2)T Cisco 7200 series IP N/A

CiscoSecure ACS UNIX version 2.3.1 Solaris 2.6

CiscoSecure ACS NT version 2.1 Windows NT 4.0 N/A

Telephone number or username

jeremy@hgw.com password = subaru

L2F Case Study Overview 15

CiscoSecure ACS NT Server 128 MB RAM

addresses, passwords, usernames, hostnames, and telephone numbers.

Access VPN Solutions Using Tunneling Technology

Cisco AS5300 NAS

Cisco AS5300 NAS

Cisco 4500-M edge router

Cisco 7206 home gateway

CiscoSecure ACS UNIX server

CiscoSecure ACS NT server

Cisco AS5300 NAS

Cisco 4500-M edge router

Cisco 7206 home gateway

L2F Case Study Overview 17

Access VPN Solutions Using Tunneling Technology

Configuring the NAS for Basic Dial Access

Clients using modems PSTN POTS lines

4 TI PRI lines 555-0945

Network administrator's PC RS-232 console cable

Configuring the NAS for Basic Dial Access 19

Cisco AS5300 NAS