ISAKMP/IKE Phase 1 Connections
ISAKMP IKE Phase 1 Connections
In the first part of this chapter I'll focus on troubleshooting ISAKMP/IKE Phase 1 connections. If you recall from Chapter 3, "IPsec," the management connection built during Phase 1 is used to pass IPsec management traffic; no user data traverses this connection. This connection is important, however, because it is used to build the two data connections for Phase 2. I've broken this part of the chapter into three areas:
- An overview of the ISAKMP/IKE Phase 1 troubleshooting commands
- Examining your management connections
- Examining the building of L2L and remote access management connections
- Troubleshooting Easy VPN connections on a Remote
Overview of the Phase 1 Commands
You can use several commands to troubleshoot ISAKMP/IKE Phase 1 connections on the security appliances, including the following:
- show isakmp sa [detail] Displays the status of any management connections.
- show [crypto] isakmp stats Displays the statistics of the management connections (FOS 7.0 only).
- show [crypto] isakmp ipsec-over-tcp stats Displays the statistics of any IPsec over TCP connections the management connection is managing (FOS 7.0 only).
- debug crypto isakmp Displays the steps taken to build a management connection and data connections via the management connection.
- debug crypto vpnclient Displays the interaction between the appliance, acting as an Easy VPN Remote, and the Easy VPN Server (FOS 6.3 only).
- debug crypto ca [messages | transactions] Displays the interaction between the appliance and CA for certificate enrollment and authentication functions; the optional parameters are new in FOS 7.0. The 7.0 version of this command produces similar output compared to the debug crypto pki command discussed in Chapter 19; therefore, I won't cover it in this chapter.
- debug crypto engine Displays events related to the encryption/decryption problems on the appliance.
- clear [crypto] isakmp sa [SA_ID_#] Deletes all the management SAs or a specific management connection by specifying the SA ID number.
As you can see from the above list, not all commands are supported in all FOS versions. The following sections will discuss some of the more important commands, related to troubleshooting connectivity processes, in more depth.
Note
Before FOS 7.0, I found the output of debug commands less administrator-friendly than the debug output from IOS routers. In FOS 6.3 and earlier, I tended to try to troubleshoot IPsec problems from the remote peer and would look at the PIX's debug output only when I was still having problems trying to pinpoint the problem. However, Cisco has rectified most of my concerns in regard to this in FOS 7.0. In FOS 7.0, the debug output is much more similar to the debug output of IOS-based routers.
The show isakmp sa Command
Example 23-1 illustrates the use of the show isakmp sa command with an appliance running FOS 6.3. The output of this command is very similar to the show crypto isakmp sa command in Chapter 16, "Router ISAKMP/IKE Phase 1 Connectivity." Table 16-1 in that chapter explains the states. If you recall, QM_IDLE indicates the successful setup of the connection to the associated peer. If you're seeing MM_NO_STATE or AG_NO_STATE, this indicates that there is a problem with the initial setup of the connection. The two most common problems that might cause this are:
- You forgot to activate the crypto map or profile on the remote peer router's interface.
- There is no matching ISAKMP/IKE Phase 1 policy on the remote peer.
If you see a state of MM_KEY_EXCH or AG_INIT_EXCH, then probably the culprit is failed device authentication. For pre-shared keys, be sure you've configured the keys correctly. For certificates, verify that they haven't expired, that the date and time are correct on the peers, and that they haven't been revoked.
Tip
You can use the debug [crypto] isakmp sa command for more detailed troubleshooting based on the output of the show crypto isakmp sa command.
Example 23-1. The show crypto isakmp sa Command in 6.3
pix63(config)# show isakmp sa Total : 1 Embryonic : 0 dst src state pending created 192.1.1.101 192.1.1.40 QM_IDLE 0 0
In FOS 7.0, the output of the command is different, as shown in Example 23-2. Instead of seeing "QM_IDLE" when the management connection has completed, you'll see either "MM_Active" or "AG_Active," depending on whether main mode or aggressive mode was used to build the management connection, respectively.
Example 23-2. The show crypto isakmp sa Command in 7.0
pix70(config-general)# show isakmp sa Active SA: 1 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey) Total IKE SA: 1 1 IKE Peer: 192.1.1.40 Type : L2L Role : responder Rekey : no State : MM_ACTIVE
The debug crypto isakmp Command
In most instances, you'll use the debug crypto isakmp command to assist in detailed troubleshooting of building ISAKMP/IKE Phase 1 management connections as well as Phase 2 data connections the management connection builds. Deciphering the output of this command is not that simple. The following two sections will take a look at a few examples of L2L and remote access sessions.
Note
Because the output of the debug commands in FOS 6.3 and earlier is somewhat similar to that of Cisco routers, the following sections will focus on the use of the commands in FOS 7.0.
L2L Sessions
To understand how an L2L session is successfully set up, view the output from the debug crypto isakmp command in Example 23-3. In this example, the output is from a simple L2L configuration where the appliance is accepting a session setup request from a remote L2L peer. I've added steps to the right of some of the output, which are explained below the example.
Example 23-3. Successful Building of the Management Connection in FOS 7.0
[IKEv1 DEBUG]: IP = 192.1.1.40, processing SA payload (1)
[IKEv1 DEBUG]: IP = 192.1.1.40, Oakley proposal is acceptable
Here's a brief description of the references in Example 23-3 (the output the debug crypto isakmp command is very verbose, so I've omitted some of it):
|
1. |
Main mode exchange is beginning; no policies have been shared yet and the peers are still in an MM_NO_STATE.
|
|
2. |
The remote peer is testing for the use of NAT-T.
|
|
3. |
The comparison of ISAKMP/IKE policies begins here.
|
|
4. |
This message indicates that a matching policy has been found.
|
|
5. |
The management connection is being built.
|
|
6. |
The peer is associated with the "192.1.1.40" L2L tunnel group and the encryption and hash keys are being generated.
|
|
7. |
This is where authentication begins with pre-shared keys: remember that authentication occurs on both peers, and thus you'll see two sets of corresponding authentication processes.
|
|
8. |
DPD is being negotiated.
|
|
9. |
Phase 1 is complete.
|
|
10. |
Phase 2 (quick mode) begins.
|
|
11. |
The remote subnet (192.168.0.0/24) is received and compared to the local subnet (192.168.2.0/24).
|
|
12. |
A matching static crypto entry is looked for and found.
|
|
13. |
The appliance finds a matching data transform for the data connections.
|
|
14. |
A check is performed for mirrored crypto ACLs.
|
|
15. |
Keys are generated for the data SAs.
|
|
16. |
SPIs are assigned to the data SAs.
|
|
17. |
Phase 2 completes.
|
|
18. |
A DPD keepalive is being sent to the remote peer on the management connection.
|
Caution
Also in 7.0, you control the debugging level by specifying a number from 1255 after the debug command: this affects the amount of output you see from the debug command. A level of 1 will give you little information, if any, and 255 will show partial packet contents (the most in-depth). Therefore, you'll want to specify a number like 100 or 150 for the debug level to give you a reasonable amount of output to troubleshoot problems. Also, if you enter the debug command without specifying a level number, it defaults to level 1; therefore, if you don't see any output from your debug command, this is the first thing I would check: use the show debug command to determine what debug functions you've enabled and for what output level they've been configured.
If there is a mismatch in the ISAKMP/IKE Phase 1 policy, between the peers, your debug output will look like that in Example 23-4.
Example 23-4. Mismatch ISAKMP/IKE Phase 1 Policies in 7.0
[IKEv1 DEBUG]: IP = 192.1.1.40, processing SA payload [IKEv1]: IP = 192.1.1.40, IKE DECODE SENDING Message (msgid=0) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 100 [IKEv1 DEBUG]: IP = 192.1.1.40, All SA proposals found unacceptable [IKEv1]: IP = 192.1.1.40, Error processing payload: Payload ID: 1 [IKEv1 DEBUG]: IP = 192.1.1.40, IKE MM Responder FSM error history (struct &0x19f49a0) , : MM_DONE, EV_ERROR-->MM_START, EV_RCV_MSG-->MM_START, EV_ START_MM-->MM_START, EV_START_MM [IKEv1 DEBUG]: IP = 192.1.1.40, IKE SA MM:2d31c23f terminating: flags 0x01000002, refcnt 0, tuncnt 0 [IKEv1 DEBUG]: sending delete/delete with reason message
Tip
I've found out, the hard way, in certain FOS releases that even if the ISAKMP policies match on the two peers, you still could get the dreaded "All SA proposals found unacceptable" message. Apparently, certain combinations of policies, especially for the two data connections, will not work, even though you can configure them on the appliance, like AES-128 and SHA. Playing around, I've found out that in most instances, any encryption algorithm and MD5 will work; but only certain encryption algorithms and SHA will work. Therefore, before you waste your time troubleshooting this problem with either a Phase 1 or, more likely, Phase 2 connection, first I would try a proposal that supported MD5 with your selected encryption algorithm.
If there is a mismatch in a key used for pre-shared key authentication, the output of the debug crypto isakmp command will look like that found in Example 23-5.
Example 23-5. Mismatched Pre-shared Key Illustration in 7.0
[IKEv1 DEBUG]: IP = 192.1.1.40, processing SA payload
[IKEv1 DEBUG]: IP = 192.1.1.40, Oakley proposal is acceptable
Tip
One of the problems I've seen with the output of the FOS debug commands is that the nomenclature and verbiage has a tendency of changing from one FOS release to another. This is very apparent if you compare the 6.3 output to that of 7.0. Therefore, you have to scrutinize the output carefully to determine the exact problem. In certain cases, you might want to look at the debug output from a connection that works from the same FOS revision that you're using on a connection that is failing. You can use the successful connection output as a baseline when comparing this debug output to the debug output from a failed connection attempt. I've also found the FOS 7.0 debug output more user-friendly in deciphering its messages than with the 6.x and earlier releases.
Remote Access Sessions
The debug output from setting up a remote access session can be very verboseabout 20 pages in length! Example 23-6 shows the output of the debug crypto isakmp command from a 7.0 Easy VPN Server, where I've omitted much of the output to keep it brief. I explain the numbered references below the example output.
Example 23-6. Establishing a Remote Access Connection to an Easy VPN Server Running 7.0
[IKEv1 DEBUG]: IP = 192.1.1.77, processing SA payload (1)
Here's an explanation of the debug output from Example 23-6:
|
1. |
The Remote (192.1.1.77) initiates a session to the appliance (acting as a Server).
|
|
2. |
The Remote sends its identity type to the Server, along with the group it wants to connect to ("salesgroup").
|
|
3. |
A matching Phase 1 policy is found: policy 5 of the Remote matches the first policy of the Server).
|
|
4. |
The Remote initiates IKE Mode Config and the appliance is determining which parameters it has configured for the associated group.
|
|
5. |
The group authentication is successful, as is the XAUTH authentication via the user account "salesuser"; notice that this message appears here rather than before IKE Mode Config, because the appliance needs to verify whether or not the user is allowed access to the group.
|
|
6. |
The Remote sends an IKE Mode Config request for the policies defined for the salesgroup group.
|
|
7. |
During IKE Mode Config, the appliance learns the client type and version.
|
|
8. |
The Server sends back the IKE Mode Config parameters.
|
|
9. |
This completes ISAKMP/IKE Phase 1.
|
|
10. |
Quick mode begins with an exchange of policies.
|
|
11. |
The internal address of the client is 192.168.2.200 and the proxy message it sends indicates that all of its traffic is to be protected (the group policy is split tunneling disabled).
|
|
12. |
A check is performed to make sure that the client isn't reconnecting (the Initial Contact feature for Easy VPN); in this example, the client is initiating a new connection.
|
|
13. |
The appliance compares the proxy information with its first crypto map entry (which is a static one) and finds that it doesn't match this entry (the proxy information doesn't match).
|
|
14. |
The appliance compares the proxy information with its second crypto map entry, which is a dynamic crypto map for remote access users.
|
|
15. |
A matching data transform is found.
|
|
16. |
There is a difference in the data SA lifetime values between the two devices: the lower one (28,800 seconds) is negotiated.
|
|
17. |
The two IPsec data SAs (inbound and outbound) are created and SPIs are assigned.
|
|
18. |
Because RRI is enabled, a static route for the Remote's internal address (192.168.2.200) is added to the Server's local routing table.
|
|
19. |
Phase 2 has completed.
|
|
20. |
Because DPD was negotiated in Phase 1, DPD now takes place; in this instance, the Remote is initiating DPD (however, both sides of the tunnel will do this periodically based on their local keepalive counters).
|
The debug crypto vpnclient Command
For 6.x PIXs configured as Easy VPN Remotes, you can use the debug crypto vpnclient command to troubleshoot client-specific configuration and connection setup issues. Example 23-7 illustrates the use of this command, where the client is using network extension mode. Below the example, I explain the numbered references found in the example.
Example 23-7. Establishing a Remote Access Connection from an Easy VPN Remote Running 6.3
VPNC CFG: transform set unconfig attempt done (1)
VPNC CLI: no isakmp keepalive 10 5
VPNC CLI: no isakmp nat-traversal 20
VPNC CFG: IKE unconfig successful
VPNC CLI: no crypto map _vpnc_cm
VPNC CFG: crypto map deletion attempt done
VPNC CFG: crypto unconfig successful
VPNC CLI: no global (outside) 65001
VPNC CLI: no nat (inside) 0 access-list _vpnc_acl
VPNC CFG: nat unconfig attempt failed
VPNC CLI: no http 192.168.3.1 255.255.255.0 inside
VPNC CLI: no http server enable
VPNC CLI: no access-list _vpnc_acl
VPNC CFG: ACL deletion attempt failed
VPNC CLI: no crypto map _vpnc_cm interface outside
VPNC CFG: crypto map de/attach failed
VPNC CFG: transform sets configured (2)
VPNC CFG: crypto config successful
VPNC CLI: isakmp keepalive 10 5
VPNC CLI: isakmp nat-traversal 20
VPNC CFG: IKE config successful
VPNC CLI: http 192.168.3.1 255.255.255.0 inside
VPNC CLI: http server enable
VPNC CLI: aaa-server _vpnc_nwp_server protocol tacacs+
VPNC CLI: aaa-server _vpnc_nwp_server (outside) host 192.1.1.100
VPNC CLI: access-list _vpnc_nwp_acl permit ip any any
VPNC CLI: aaa authentication match _vpnc_nwp_acl outbound
vpnc_nwp_server
VPNC CLI: no access-list _vpnc_acl
VPNC CFG: ACL deletion attempt failed
VPNC CLI: access-list _vpnc_acl permit ip host 192.1.1.101 (3)
host 192.1.1.100
VPNC CLI: crypto map _vpnc_cm 10 match address _vpnc_acl
VPNC CFG: crypto map acl update successful
VPNC CLI: no crypto map _vpnc_cm interface outside
VPNC CLI: crypto map _vpnc_cm interface outside
VPNC INF: IKE trigger request done (4)
VPNC INF: Constructing policy download req
VPNC INF: Packing attributes for policy request
VPNC INF: Attributes being requested
VPNC ATT: INTERNAL_IP4_DNS: 4.2.2.1
VPNC ATT: ALT_PFS: 0
VPNC INF: Received application version 'Cisco Systems, Inc (5)
PIX-515 Version 7.0(1) built by builders on
Thu 31-Mar-05 14:37'
VPNC ATT: ALT_CFG_SEC_UNIT: 0
VPNC ATT: ALT_CFG_USER_AUTH: 0
VPNC CLI: no aaa authentication match _vpnc_nwp_acl outbound _
vpnc_nwp_server
VPNC CLI: no access-list _vpnc_nwp_acl permit ip any any
VPNC CLI: no aaa-server _vpnc_nwp_server
VPNC CLI: no access-list _vpnc_acl
VPNC CLI: access-list _vpnc_acl permit ip (6)
192.168.3.0 255.255.255.0 any
VPNC CLI: access-list _vpnc_acl permit ip
host 192.1.1.101 any
VPNC CLI: access-list _vpnc_acl permit ip
host 192.1.1.101 host 192.1.1.100
VPNC CFG: _vpnc_acl no ST define done
VPNC CLI: crypto map _vpnc_cm 10 match address _vpnc_acl
VPNC CFG: crypto map acl update successful
VPNC CLI: no crypto map _vpnc_cm interface outside
VPNC CLI: crypto map _vpnc_cm interface outside
VPNC CLI: no global (outside) 65001 (7)
VPNC CLI: no nat (inside) 0 access-list _vpnc_acl
VPNC CFG: nat unconfig attempt failed
VPNC CLI: nat (inside) 0 access-list _vpnc_acl
VPNC INF: IKE trigger request done (8)
Here is an explanation of the numbered references in Example 23-7:
|
1. |
This is the first time the VPN Remote functionality was enabled on the PIX, so the PIX is first removing any VPN commands that could cause any type of conflict.
|
|
2. |
After attempting to remove all VPN-related commands, the Remote then configures the necessary VPN commands.
|
|
3. |
An ACL is built to allow communications between this PIX (192.1.1.101) and the Easy VPN Server (192.1.1.100).
|
|
4. |
The PIX Remote initiates its connection to the Server and sends its policies.
|
|
5. |
The Server is a PIX 515 running FOS 7.0.
|
|
6. |
Based on the split tunneling policy passed to it by the Server, the client PIX builds an appropriate crypto ACL.
|
|
7. |
Based on the split tunneling policy, the appropriate address translation policy is configured.
|
|
8. |
The tunnel is now established to the Server.
|
Tip
Unfortunately, the debug crypto vpnclient command is not that useful for troubleshooting the setup of an IPsec session. If something is misconfigured on the Remote or Server, you'll see something like that in Example 23-8 repeated over and over; however, as you'll notice in the output, there is nothing that indicates what the problem is. In this example, the Remote was configured for network extension mode, but the group on the Server didn't have this policy defined. For example, with the output of the debug crypto isakmp command on the Server, you would see a message like this: "[IKEv1]: Group = salesgroup, Username = salesuser, IP = 192.1.1.101, Hardware Client connection rejected! Network Extension Mode is not allowed for this group!" Unfortunately, the debug output from the same command on a 6.3 Remote isn't as verbose, making the troubleshooting of this problem more difficult, if not impossible, from the Remote end using the debug crypto vpnclient command.
Example 23-8. A Failed Remote Access Connection from an Easy VPN Remote Running 6.3
VPNC INF: Constructing policy download req VPNC INF: Packing attributes for policy request VPNC INF: Attributes being requested VPNC CLI: no access-list _vpnc_acl VPNC CLI: access-list _vpnc_acl permit ip host 192.1.1.101 host 192.1.1.100 VPNC CLI: crypto map _vpnc_cm 10 match address _vpnc_acl VPNC CFG: crypto map acl update successful VPNC CLI: no crypto map _vpnc_cm interface outside VPNC CLI: crypto map _vpnc_cm interface outside VPNC INF: IKE trigger request done