All Cisco-Network Study Notes: Tunnel Is Not Established: Phase I Failure

Tunnel Is Not Established: Phase I Failure

If you are unable to pass any traffic across the LAN-to-LAN IPsec tunnel, you should first investigate the status of the tunnel state on both the Initiator and the Responder PIXen. You might experience tunnel establishment failure either in Phase I or Phase II. For successful tunnel establishment, you must have both Phase I And Phase II established. The Show crypto isakmp sa command allows you to view the status of the tunnel, and if it is MM_ACTIVE, this means that the Phase I is established, as shown in Example 7-18. PIX versions earlier than 7.0 shows QM_IDLE for phase I establishment.

Example 7-18. A Successful Phase I Establishment on PIX Version 7.0 and Later

PIX-A# show crypto 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: 172.16.172.163
   Type    : L2L            Role     : initiator
! The following line shows MM_ACTIVE for the initiator state which is an indication that
! Phase I is established.
   Rekey   : no             State    : MM_ACTIVE
PIX-A#

If Phase II is established, show crypto ipsec sa will provide the details as shown in Example 7-19.

Example 7-19. Phase II Establishment of Tunnel on PIX Version 7.0

PIX-A# show crypto ipsec sa
interface: outside
! The following line shows the crypto map name and the peer IP address
   Crypto map tag: mymap, local addr: 172.16.172.164
! The following two lines show the private networks of both sides whose traffic
! will be protected by the IPSec tunnel.
     local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
     remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)
     current_peer: 172.16.172.163
! The following counters are extremely important to see if the tunnel is processing any
! traffic. Encaps indicates that this side is encrypting and sending the traffic fine to
! the other side. And decrypts counter indicates that the other side is sending the reply
! and this is able to decrypt the traffic.
     #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
     #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
     #pkts compressed: 0, #pkts decompressed: 0
     #pkts not compressed: 4, #pkts comp failed: 0, #pkts decomp failed: 0
     #send errors: 0, #recv errors: 0
     local crypto endpt.: 172.16.172.164, remote crypto endpt.: 172.16.172.163

     path mtu 1500, ipsec overhead 60, media mtu 1500
     current outbound spi: 88BB86AD
! The following inbound SA has an SPI number indicating that this is established.
   inbound esp sas:
     spi: 0x1A280A9D (438831773)
        transform: esp-3des esp-md5-hmac
        in use settings ={L2L, Tunnel, }
        slot: 0, conn_id: 1, crypto-map: mymap
        sa timing: remaining key lifetime (kB/sec): (4274999/28776)
        IV size: 8 bytes
        replay detection support: Y
! The following outbound SA has an SPI number indicating that this is established.
   outbound esp sas:
     spi: 0x88BB86AD (2293991085)
        transform: esp-3des esp-md5-hmac
        in use settings ={L2L, Tunnel, }
        slot: 0, conn_id: 1, crypto-map: mymap
        sa timing: remaining key lifetime (kB/sec): (4274999/28774)
        IV size: 8 bytes
        replay detection support: Y

PIX-A#

Before exploring failure or possible causes of failure for Phase I and Phase II, it is worth dissecting the debug output of a successful LAN-to-LAN IPsec tunnel on the Initiator side, which is shown in Example 7-20.

Example 7-20. Dissection of debug Commands for a Successful IPsec Tunnel

[View full width]

PIX-A# debug crypto isakmp 7
PIX-A# debug crypto ipsec 7
! Usually level 5 will give you the details to troubleshoot most of the issues.
! Sometimes, you may run level 7. Rarely you may need to run level 255.
Jun 05 21:38:55 [IKEv1 DEBUG]: pitcher: received a key acquire message!
! The following line shows the initiation of the first packet for IPSec tunnel by the
! Initiator.
Jun 05 21:38:55 [IKEv1]: IP = 172.16.172.163, IKE Initiator: New Phase 1, Intf 2,
 IKE Peer 172.16.172.163 local Proxy Address 192.168.1.0, remote Proxy Address
 192.168.2.0, Crypto map (mymap)
Jun 05 21:38:55 [IKEv1 DEBUG]: IP = 172.16.172.163, constructing ISA_SA for isakmp
Jun 05 21:38:55 [IKEv1 DEBUG]: IP = 172.16.172.163, constructing Fragmentation VID +
 extended capabilities payload
Jun 05 21:38:55 [IKEv1]: IP = 172.16.172.163, IKE DECODE SENDING Message (msgid=0)
 with payloads : HDR + SA (1) + VENDOR (13) + NONE (0) total length : 144
Jun 05 21:38:56 [IKEv1]: IP = 172.16.172.163, IKE DECODE RECEIVED Message (msgid=0)
 with payloads : HDR + SA (1) + VENDOR (13) + NONE (0) total length : 104
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, processing SA payload
! The following line indicates that IKE phase I policy is accepted by the other side
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, Oakley proposal is acceptable
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, processing VID payload
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, Received Fragmentation VID
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, IKE Peer included IKE
 fragmentation capability flags:  Main Mode:        True Aggressive Mode: True
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, constructing ke payload
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, constructing nonce payload
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, constructing Cisco Unity VID
 payload
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, constructing xauth V6 VID payload
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, Send IOS VID
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, Constructing ASA spoofing IOS
 Vendor ID payload (version: 1.0.0, capabilities: 20000001)
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, constructing VID payload
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, Send Altiga/Cisco VPN3000/Cisco
 ASA GW VID
Jun 05 21:38:56 [IKEv1]: IP = 172.16.172.163, IKE DECODE SENDING Message (msgid=0)
 with payloads : HDR + KE (4) +
NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total
 length : 256
Jun 05 21:38:56 [IKEv1]: IP = 172.16.172.163, IKE DECODE RECEIVED Message (msgid=0)
 with payloads : HDR + KE (4) +
NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total
 length : 256
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, processing ke payload
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, processing ISA_KE
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, processing nonce payload
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, processing VID payload
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, Received Cisco Unity client VID
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, processing VID payload
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, Received xauth V6 VID
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, processing VID payload
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, Processing VPN3000/ASA spoofing
IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, processing VID payload
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, Received Altiga/Cisco VPN3000/
 Cisco ASA GW VID
! The following shows that the tunnel group configuration is found. This is where the
! pre-shared key is defined.
Jun 05 21:38:56 [IKEv1]: IP = 172.16.172.163, Connection landed on tunnel_group
 172.16.172.163
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 Generating keys for Initiator...
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 constructing ID
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 construct hash payload
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 computing hash
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, Constructing IOS keep alive
 payload: proposal=32767/32767 sec.
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 constructing dpd vid payload
Jun 05 21:38:56 [IKEv1]: IP = 172.16.172.163, IKE DECODE SENDING Message (msgid=0)
 with payloads : HDR + ID (5) + HASH (8) +
IOS KEEPALIVE (14) + VENDOR (13) + NONE (0) total length : 92
Jun 05 21:38:56 [IKEv1]: IP = 172.16.172.163, IKE DECODE RECEIVED Message (msgid=0)
 with payloads : HDR + ID (5) + HASH (8) +
IOS KEEPALIVE (14) + VENDOR (13) + NONE (0) total length : 92
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 Processing ID
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 processing hash
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 computing hash
Jun 05 21:38:56 [IKEv1 DEBUG]: IP = 172.16.172.163, Processing IOS keep alive
 payload: proposal=32767/32767 sec.
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 processing VID payload
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163, Received
 DPD VID
Jun 05 21:38:56 [IKEv1]: IP = 172.16.172.163, Connection landed on tunnel_group
 172.16.172.163
! Following line is an indication of phase I establishment and the beginning of phase II
! negotiation.
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163, Oakley
 begin quick mode
! The following message affirms the phase I establishment
Jun 05 21:38:56 [IKEv1]: Group = 172.16.172.163, IP = 172.16.172.163, PHASE 1 COMPLETED
Jun 05 21:38:56 [IKEv1]: IP = 172.16.172.163, Keep-alive type for this connection: DPD
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163, Starting
 phase 1 rekey timer: 41040000 (ms)
Jun 05 21:38:56 [IKEv1 DEBUG]: IKE got SPI from key engine: SPI = 0xbb5bb46c
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163, oakley
 constructing quick mode
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 constructing blank hash
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 constructing ISA_SA for ipsec
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 constructing ipsec nonce payload
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 constructing proxy ID
! The following lines show the interesting traffic ACL getting exchanged. These ACL
! should be the mirror image of each other.
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 Transmitting Proxy Id:
 Local subnet: 192.168.1.0   mask 255.255.255.0 Protocol 0  Port 0
 Remote subnet: 192.168.2.0  Mask 255.255.255.0 Protocol 0  Port 0
Jun 05 21:38:56 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 constructing qm hash
Jun 05 21:38:56 [IKEv1]: IP = 172.16.172.163, IKE DECODE SENDING Message
 (msgid=529335a6) with payloads : HDR + HASH (8) + SA (1) + NONCE (10) + ID (5) +
 ID (5) + NOTIFY (11) + NONE (0) total length : 192
Jun 05 21:38:57 [IKEv1]: IP = 172.16.172.163, IKE DECODE RECEIVED Message
 (msgid=529335a6) with payloads : HDR + HASH (8) + SA (1) + NONCE (10) + ID (5) +
 ID (5) + NONE (0) total length : 164
Jun 05 21:38:57 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 processing hash
Jun 05 21:38:57 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 processing SA payload
Jun 05 21:38:57 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 processing nonce payload
Jun 05 21:38:57 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 Processing ID
Jun 05 21:38:57 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 Processing ID
Jun 05 21:38:57 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163, loading
 all IPSEC SAs
Jun 05 21:38:57 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 Generating Quick Mode Key!
Jun 05 21:38:57 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163,
 Generating Quick Mode Key!
! The negotiation for phase II shows completed here.
Jun 05 21:38:57 [IKEv1]: Group = 172.16.172.163, IP = 172.16.172.163, Security
 negotiation complete for LAN-to-LAN
Group (172.16.172.163) Initiator, Inbound SPI = 0xbb5bb46c, Outbound SPI = 0x7ea88a9e
Jun 05 21:38:57 [IKEv1 DEBUG]: Group = 172.16.172.163, IP = 172.16.172.163, oakley
 constructing final quick mode
Jun 05 21:38:57 [IKEv1]: IP = 172.16.172.163, IKE DECODE SENDING Message
 (msgid=529335a6) with payloads : HDR + HASH (8) +
NONE (0) total length : 72
Jun 05 21:38:57 [IKEv1 DEBUG]: IKE got a KEY_ADD msg for SA: SPI = 0x7ea88a9e
Jun 05 21:38:57 [IKEv1 DEBUG]: pitcher: rcv KEY_UPDATE, spi 0xbb5bb46c
Jun 05 21:38:57 [IKEv1]: Group = 172.16.172.163, IP = 172.16.172.163, Starting P2 Rekey
 timer to expire in 27360 seconds
! The following line confirms phase II completion, hence complete establishment of IPSec
! LAN-to-LAN tunnel.
Jun 05 21:38:57 [IKEv1]: Group = 172.16.172.163, IP = 172.16.172.163, PHASE 2
 COMPLETED (msgid=529335a6)
PIX-A#

Now that you are comfortable with the show and debug command output of a successful IPsec LAN-to-LAN tunnel, if your Phase I for tunnel build-up fails, work through the following steps to correct the problem:

Step 1.

Check for connectivity problems.

If you have problems with phase I establishment, first be sure that you can ping the responder from the initiator, and vice versa. This will ensure that you have proper routing configured for the peer IP address. If the peer IP address is not reachable, then Phase I negotiation will not take place.

Step 2.

Be sure you get IKE Packets in the Initiator Debug Output.

If all parameters are configured properly on the Initiator, you should see the IKE packets with the debug crypto ISAKMP command. If you do not see any debug output, then work through the following steps to correct the problem:

- ISAKMP is turned offUnlike Cisco IOS router, ISAKMP is disabled by default on the PIX Firewall. So, if you do not turn it on, ISAKMP will not be triggered, and debug will not show any IKE packets. You can verify this by executing the command shown in Example 7-21. This example also shows how to enable ISAKMP on the interface.

Example 7-21. Verifying and Correcting the Problem of ISAKMP Not Being Applied

PIX-A(config)# show running-config isakmp | include enable
! As nothing is shown, ISAKMP is not turned on the interface. The following
! command shows how to turn on ISAKMP on the outside interface
PIX-A(config)# show running-config isakmp | include enable
! The following line indicates that ISAKMP is enabled on the outside interface.
isakmp enable outside
PIX-A(config)# exit
PIX-A#

- Routing Problem on the InitiatorIf ISAKMP is enabled on the interface, but you still do not see the IKE packets on the initiator debug, you may have problems with routing on the initiator. You must have a route on the initiator (PIX-A) for the private network (192.168.2.0/24) of the responder (PIX-B), which is pointing towards the interface where ISAKMP is applied. This can be done either through a static route or default gateway. Example 7-22 shows how to verify whether the route exists on the routing table for the private network.

Example 7-22. Verifying that a Route for the Private Network Exists Through Outside Interface for the Responder Private Network

PIX-A(config)# show route
! The following default gateway is on the outside interface of the PIX firewall
! where ISAKMP is applied. This is how the private network that needs to be
! protected via tunnel can be reached. The requirement is that the private
! traffic that needs to be go through the tunnel needs to hit the interface (in
! this case outside interface) where the crypto map and ISAKMP is applied.
S    0.0.0.0 0.0.0.0 [1/0] via 172.16.172.1, outside
! The following two lines are for directly connected networks
C    172.16.172.0 255.255.255.0 is directly connected, outside
C    192.168.1.0 255.255.255.0 is directly connected, inside
PIX-A(config)#

- Crypto Map is not applied or is applied to the wrong interfaceAfter verifying and fixing the routing problem on the initiator for the private network of the responder, if you are still unable to see IKE packets, be sure that you have crypto map applied to the outgoing interface. This is the interface through which the private network on the Responder will be reached by the initiator as per the routing table, even though the packet may not be able to reach due to the private address. However, sending the packet on the outgoing interface is required to trigger Phase II And Phase I of the PIX Firewall. If the crypto map is not applied, or applied on the wrong interface, Phase I will not come up as it is brought into action by the crypto map. Use the command shown in Example 7-23 to verify if and where the crypto map is applied.

Example 7-23. Initiator (PIX-A) Properly Has the Crypto Map Applied on the Outside Interface of the PIX Firewall

PIX-A# show running-config crypto map | include interface
crypto map mymap interface outside
PIX-A#

- The incorrect interesting traffic access-list is configuredThe traffic that needs to go through the tunnel is defined by the access-list that is applied to the crypto map. So, if the access-list does not include the source or destination network that should go through the tunnel, the tunnel will not be triggered, even if everything else is configured correctly. Remember that this access-list needs to be configured as mirror images on the initiator and responder. Example 7-24 shows that the access-list is properly configured on the PIX-A.

Example 7-24. Access-list Configured on the Initiator (PIX-A)

PIX-A# show running-config crypto | include address
! Following line indicates access-list 101 is applied to crypto map
crypto map mymap 10 match address 101
PIX-A# show running-config access-list 101
! Following line shows the network for which ACL is configured that needs to be
! protected by the IPSec tunnel.
access-list 101 extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0
 255.255.255.0
PIX-A#

- Tunnel group is not configured, or is configured with the wrong peer IP addressIf you do not have the tunnel group configured on the initiator/responder, or it is configured with the wrong Peer IP address for the tunnel-group name, Phase I will not be established. Example 7-25 shows the debug message that appears on the initiator (PIX-A), when the tunnel group is not configured with the IP address of the peer (PIX-B).

Example 7-25. debug Message on the Initiator when the Tunnel Group Is Not Configured

PIX-A# show running-config tunnel-group
! Nothing shows, meaning no tunnel-group configured.
PIX-A# debug crypto isakmp 5
PIX-A# debug crypto ipsec 5
! Only showing the relevant information
06 03:09:59 [IKEv1 DEBUG]: IP = 172.16.172.163, Oakley proposal is acceptable
06 03:09:59 [IKEv1 DEBUG]: IP = 172.16.172.163, IKE Peer included IKE fragmentation
 capability flags:  Main Mode:       True  Aggressive Mode:  True
! The following line shows the tunnel-group not configured.
06 03:09:59 [IKEv1]: Group = 172.16.172.163, IP = 172.16.172.163, Can't find a valid
 tunnel group, aborting...!
PIX-A#

Step 3.

Be sure the responder is receiving IKE packets.

If you see the IKE packets generated on the initiator, not on the responder, then the problem is that the responder is not receiving the IKE request. This can be caused by the following:

- Connectivity issuePerform the ping test from both initiator and responder to each other and be sure they have the proper connectivity to each other.

- Wrong peer IP address on the InitiatorIf you have the wrong peer, then the actual responder will not see the packet, as the initiator will be sending an IKE Phase I request to the wrong IP.

- IKE Packets are blocked by the FirewallPhase I and phase II negotiation occurs using UDP/500. If there is a NAT device, and NAT-T is configured on the PIX firewall, the negotiation also takes place on UDP/4500. So, if there is a firewall between, be sure that both UDP/4500 and UDP/500 are allowed through the firewall.

Step 4.

Check for policy mismatches.

If there is a mismatch in IKE policy, Phase I negotiation will fail. The initiator sends all the IKE policies configured along with the default one (65535). If the receiver is not configured with a matching policy, you will see an error message, as shown in Example 7-26 on the initiator, which is PIX-A.

Example 7-26. debug Output of ISAKMP Failure Message on Initiator Due to Policy Mismatch

PIX-A# debug crypto isakmp 5
PIX-A# debug crypto ipsec 5
Jun 05 23:50:50 [IKEv1]: IP = 172.16.172.163, IKE Initiator: New Phase 1, Intf 2,
 IKE Peer 172.16.172.163 local Proxy Address 192.168.1.0, remote Proxy Address
 192.168.2.0, Crypto map (mymap)
! The following notification came from responder informing initiator that none
! of the policies is acceptable that are sent by the initiator
Jun 05 23:50:50 [IKEv1]: IP = 172.16.172.163, Received an un-encrypted
 NO_PROPOSAL_CHOSEN notify message, dropping
Jun 05 23:50:50 [IKEv1]: IP = 172.16.172.163, Information Exchange processing failed
PIX-A#

The debug messages that appear due to policy mismatch on the responder, which is PIX-B, are shown in Example 7-27.

Example 7-27. debug Output of ISAKMP Failure Message on Responder Due to Policy Mismatch

PIX-B# debug crypto isakmp 5
PIX-B# debug crypto ipsec 5
! The following message clearly indicates the responder is not finding a similar
! policy sent by the Initiator.
Jun 05 23:55:26 [IKEv1 DEBUG]: IP = 172.16.172.164, All SA proposals found
 unacceptable
Jun 05 23:55:26 [IKEv1]: IP = 172.16.172.164, Error processing payload: Payload ID: 1
Jun 05 23:55:26 [IKEv1 DEBUG]: IP = 172.16.172.164, IKE MM Responder FSM error
 history (struct &0x1a07d68) , : MM_DONE, EV_ERROR-->MM_START,
 EV_RCV_MSG-->MM_START, EV_START_MM-->MM_START, EV_START_MM
PIX-B#

The solution is to compare the IKE policy configuration on both sides of the tunnel and configure a common ISAKMP policy on both peers. Example 7-28 shows the IKE policy configured on the initiator, PIX-A.

Example 7-28. IKE Policy Configured on the Initiator, PIX-A

PIX-A# show running-config isakmp
isakmp enable outside
! Policy 10 is configured on the initiator by administrator
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 43200
! Policy 65535 is a default policy.
isakmp policy 65535 authentication pre-share
! Encryption for 65535 policy is 3DES by default which is modified to DES
isakmp policy 65535 encryption des
isakmp policy 65535 hash sha
isakmp policy 65535 group 2
isakmp policy 65535 lifetime 86400
PIX-A#

Now look at the ISAKMP policy on the responder, PIX-B, as shown in Example 7-29.

Example 7-29. Policy Configured on the Responder, PIX-B

PIX-B# show running-config isakmp
isakmp enable outside
isakmp policy 10 authentication pre-share
! Encryption algorithm is 3DES but the initiator is using DES.
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 43200
isakmp policy 65535 authentication pre-share
! Encryption algorithm for the default policy us is 3DES but the initiator is
! using DES.
isakmp policy 65535 encryption 3des
isakmp policy 65535 hash sha
isakmp policy 65535 group 2
isakmp policy 65535 lifetime 86400
PIX-B#

As you can see, both policies (including the default policy) mismatch on both sides for the encryption algorithm. To correct the problem, you need to match the encryption algorithm for at least one of the policies, as shown in Example 7-30 for PIX-A.

Example 7-30. Correcting the Policy Configuration for Encryption Algorithm on Initiator, PIX-A

PIX-A# configure terminal
! The following two lines define the encryption protocol with 3DES for both user
! defined policy 10, and the default policy 65535
PIX-A(config)# isakmp policy 10 encryption 3des
PIX-A(config)# isakmp policy 65535 encryption 3des
PIX-A(config)#

Step 5.

Check for authentication failure.

If the ISAKMP policy matches on both sides, Phase I still might fail due to authentication failure. Authentication failure might occur if you have a pre-shared key mismatch on both sides of the tunnel. Example 7-31 shows the debug output with the failure message that displays to indicate that the pre-shared key mismatches. The same types of message also can be seen on the responder.

Example 7-31. Sample Output of the debug Commands on Initiator with Pre-shared Key Mismatch

PIX-A# debug crypto isakmp 5
PIX-A# debug crypto ipsec 5
! Only relevant message is presented
Jun 05 22:27:06 [IKEv1]: IP = 172.16.172.163, Connection landed on tunnel_group
 172.16.172.163
! The following message is an indication of pre-shared key mismatch
Jun 05 22:27:06 [IKEv1]: Group = 172.16.172.163, IP = 172.16.172.163, Received an
 un-encrypted PAYLOAD_MALFORMED notify message, dropping
! The following message affirms it again that it's a pre-shared key mismatch
! issue
Jun 05 22:27:06 [IKEv1]: Group = 172.16.172.163, IP = 172.16.172.163, Error, peer
 has indicated that something is wrong with our message. This could indicate a
 pre-shared key mismatch.
Jun 05 22:27:06 [IKEv1]: Group = 172.16.172.163, IP = 172.16.172.163, Information
 Exchange processing failed
Jun 05 22:27:14 [IKEv1]: Group = 172.16.172.163, IP = 172.16.172.163, Duplicate
 Phase 1 packet detected. Retransmitting last packet.
Jun 05 22:27:14 [IKEv1]: Group = 172.16.172.163, IP = 172.16.172.163, Duplicate
 Phase 1 packet detected. Retransmitting last packet.
Jun 05 22:27:14 [IKEv1]: Group = 172.16.172.163, IP = 172.16.172.163, Duplicate
 Phase 1 packet detected. Retransmitting last packet.
! Only shows the relevant information
PIX-A#

Identify the tunnel involved and re-enter the pre-shared key on both sides as in Example 7-32. This example shows how to define the pre-shared key on PIX-A. The same procedure can be used to define the pre-shared key on PIX-B.

Example 7-32. Defining the Pre-Shared Key

! Following line shows which tunnel you need to make changes.
PIX-A# show running-config tunnel
tunnel-group 172.16.172.163 type ipsec-l2l
tunnel-group 172.16.172.163 ipsec-attributes
pre-shared-key *
PIX-A# configure terminal
! Following lines define pre-shared key
PIX-A(config)# tunnel-group 172.16.172.163 ipsec-attributes
PIX-A(config-ipsec)# pre-shared-key cisco123
PIX-A(config-ipsec)# end
PIX-A#