Scenario 4: 3002 Connection Problems | Troubleshooting Remote Access Networks (CCIE Professional Development)

This scenario is designed to solve some fundamental problems you might run into when deploying a Cisco VPN 3002 solution within your company. The cases focus on establishing the connection to the concentrator, and on some general debugging techniques that you can perform on the 3002. To simplify matters, the Cisco recommendation for authentication is used in the scenarios. However, there are five different authentication mechanisms/systems that can be used with the Cisco VPN 3000 concentrator, which are as follows:

NT domain
RADIUS or RADIUS proxy
RSA security SecurID (SDI)
Digital certificates
Internal authentication

Cisco recommends using RADIUS authentication. As you know, many companies already use RADIUS with their current dialup environment, so they can use the already built infrastructure. Also, the configuration required on the VPN concentrator to authenticate using a RADIUS server is relatively easy.

Using RADIUS to authenticate 3002 clients is more secure than internal authentication because you can deny access to specific users immediately and easily. Internal authentication requires that you add users individually to the concentrator; therefore, users are authenticated by the concentrator itself. It is not the preferred method of authentication because many companies already have a dialup environment that uses RADIUS, so instead of managing two types of user authentication, RADIUS and internal VPN, just use the existing one. With one method, if you need to terminate a user's access to all devices, you can simply terminate one account on the RADIUS server.

The following "Can't connect to the Concentrator" scenario, as shown in Figure 22-9, is entirely based on 3002 authentication by a RADIUS server.

Figure 22-9. The VPN 3002 Network Model Used in Scenario 4

In this case, the user connects the 3002 to a generic DSL modem, and uses PPPoE for the standard DSL connection, and RADIUS for the concentrator. If you are not using PPPoE, the trouble shooting process is less difficult because you either use a static IP address or pull one through DHCP. If not using PPPoE, ignore the PPPoE section. You try to establish a VPN connection with the 3002 client to the concentrator, but are unable to establish a tunnel. You should take three troubleshooting steps to resolve this issue:

Check the interfaces status on the 3002
Confirm the group name and password are correct
Confirm the username and password are valid

Check the Interfaces Status on the 3002

The first thing to check is the status of the interfaces. Are they Up or Down? To view interfaces on the 3002, go to Configuration, Interfaces. From there, if you have been given an IP address, subnet information, and your allocated DNS servers, you can check status (Up/Down). See Figure 22-10.

Figure 22-10. Checking the Interface Status on the VPN 3002

In Figure 22-10, both the public and private interfaces are Up. The private interface is to your private network (internal LAN), and the public interface is to the public network, which uses the IP address provided by your ISP.

There are a total of nine different operational status messages that can be associated to either Public or Private interfaces. The status messages are as follows:

UP (green) Configured, enabled, and operational; ready to pass data traffic.
DOWN (red) Configured but disabled or disconnected.
Testing In test mode; no regular data traffic can pass.
Dormant (red) Configured and enabled but waiting for an external action, such as an incoming connection.
Not Present (red) Missing hardware components.
Lower Layer Down Not operational because a lower-layer interface is down.
Unknown (red) Not configured or not able to determine status.
Not Configured Present but not configured.
Waiting for DHCP/PPPoE Waiting for DHCP or PPPoE to assign an IP address.

If the interface is Down, the problem can be one of two things. Either there is a problem with the ISP's physical connection or the PPPoE connection is failing. Before calling the ISP, always check to see if you have entered a bad username or password. One way to do this is to run two event classes, PPPOEDBG and PPPOE. To add event classes on the 3002, go to Configuration, System, Events, Classes and click Add. Scroll down the list until you find PPPOEDBG or PPPOE, and change the severity to log to 1-9, then click Add. The severity to log determines what is sent to the log based on the severity level.

After you have the event classes (debugs) set up, go to the Filterable Event Log that is located under Monitoring, Filterable Event Log, and click Get Log. If you see a display similar to Example 22-7, you know it is either the PPPoE username or password. Try re-entering the username and password on the Public interface, then retest. If the PPPoE authentication is still failing, work with your ISP to reset your PPPoE username and password.

Example 22-7. Log from a VPN 3002 Using PPPOEDBG and PPPOE Event Classes and a Bad PPPoE Username

 23 03/02/2002 03:55:36.240 SEV=6 PPPOEDBG/4 RPT=11 Building PADI Packet. ! Usually the first step in the PPPoE connection. 24 03/02/2002 03:55:36.240 SEV=8 PPPOEDBG/11 RPT=19 Sending Packet down to IP. 25 03/02/2002 03:55:36.260 SEV=8 PPPOEDBG/12 RPT=214 Received Packet from IP. 26 03/02/2002 03:55:36.260 SEV=6 PPPOEDBG/7 RPT=9 Processing Received PADO Packet. 27 03/02/2002 03:55:36.260 SEV=6 PPPOEDBG/5 RPT=8 Building PADR Packet. 28 03/02/2002 03:55:36.260 SEV=8 PPPOEDBG/11 RPT=20 Sending Packet down to IP. 29 03/02/2002 03:55:36.280 SEV=8 PPPOEDBG/12 RPT=215 Received Packet from IP. 30 03/02/2002 03:55:36.280 SEV=6 PPPOEDBG/8 RPT=8 Processing Received PADS Packet. 31 03/02/2002 03:55:36.280 SEV=7 PPPOEDBG/10 RPT=8 Building PPP Stream. 32 03/02/2002 03:55:36.310 SEV=8 PPPOEDBG/12 RPT=216 Received Packet from IP. 33 03/02/2002 03:55:36.310 SEV=8 PPPOEDBG/13 RPT=192 Sending Packet to PPP. 34 03/02/2002 03:55:36.310 SEV=8 PPPOEDBG/12 RPT=217 Received Packet from IP. 35 03/02/2002 03:55:36.310 SEV=8 PPPOEDBG/13 RPT=193 Sending Packet to PPP. 36 03/02/2002 03:55:37.710 SEV=8 PPPOEDBG/12 RPT=218 Received Packet from IP. 37 03/02/2002 03:55:37.710 SEV=8 PPPOEDBG/13 RPT=194 Sending Packet to PPP. 38 03/02/2002 03:55:37.710 SEV=2 PPP/39 RPT=8 PAP authentication failed received.. check/verify username/password . ! This indicates either the username or password is incorrectly configured. 39 03/02/2002 03:55:37.710 SEV=8 PPPOEDBG/12 RPT=219 Received Packet from IP. 40 03/02/2002 03:55:37.710 SEV=8 PPPOEDBG/13 RPT=195 Sending Packet to PPP. 41 03/02/2002 03:55:39.720 SEV=8 PPPOEDBG/12 RPT=220 Received Packet from IP. 42 03/02/2002 03:55:39.720 SEV=6 PPPOEDBG/9 RPT=8 Processing Received PADT Packet. 43 03/02/2002 03:55:39.720 SEV=6 PPPOE/6 RPT=18 PPPoE Session Terminated. ! The PPPoE session terminated so there is no connectivity.

After you get the public/PPPoE interface up, you should be able to ping external devices such as www.cisco.com. To ping on the 3002, go to Administration, Ping, then enter the host name or IP address of any host (for example, www.cisco.com). If the ping says Alive, you have Internet connectivity.

Confirm the Group Name and Password Are Correct

Now that a physical connection to the Internet is confirmed, try to connect to the concentrator. The best way to ensure that you have the correct username and password stored on the 3002 is to re-enter it. The location of the group name and password is found under Configuration, System, Tunneling Protocols, IPSec. If you do not know the group name and password, contact the network administrator.

Cisco recommends turning on six event classes when troubleshooting this type of case, to cover a wide spectrum of possible issues. Do not set the severity to log level to 1-13, because this would capture too much information to digest at once; 1-9 severity level should suffice. The list of event classes that should run when troubleshooting is below. It is easier to read the output in the log if you run them in coordinating pairs, such as AUTH and AUTHDBG:

AUTH
AUTHDBG
IPSEC
IPSECDB
IKE
IKEDBG

While running the capture log, if there is a bad group name or password, unfortunately there is no error indication; however, many phase 1 initializations are displayed. See Example 22-8.

Example 22-8. Common Log of Output if There Is a Group Name or Password Failure

 5 03/02/2002 05:47:32.410 SEV=4 IKE/41 RPT=368 10.0.0.1 IKE Initiator: New Phase 1, Intf 12, IKE Peer 10.0.0.1 local Proxy Address 66.1.1.2, remote Proxy Address 10.0.0.1, SA (ESP-3DES-MD5) 6 03/02/2002 05:48:21.211 SEV=4 IKE/41 RPT=368 10.0.0.1 IKE Initiator: New Phase 1, Intf 12, IKE Peer 10.0.0.1 local Proxy Address 66.1.1.2, remote Proxy Address 10.0.0.1, SA (ESP-3DES-MD5) 7 03/02/2002 05:48:49.182 SEV=4 IKE/41 RPT=368 10.0.0.1 IKE Initiator: New Phase 1, Intf 12, IKE Peer 10.0.0.1 local Proxy Address 66.1.1.2, remote Proxy Address 10.0.0.1, SA (ESP-3DES-MD5)

Problems with User Authentication

Depending on your VPN authentication method, verify that you have a valid corporate username and password with the organization that manages authentication and controls the RADIUS servers, digital certificate servers, NT domain, and VPN 3000 concentrators.