

There is a comms error, check there’s no router with firewall capabilities in the link.ģ. The Phase 1 Policies have been agreed with both peers, the responder is waiting for the initiator to send it its keying information. > ISAKMP SA MESSAGE STATES (On the Responder) MM_WAIT_MSG3

This could indicate a pre-shared key mismatch. In this case the error will appear and dissapear and the connection is repeatedly “torn down”ĮXAMPLE PHASE 1 PRE SHARED KEYS DONT MATCHĪpr 01 15:11:47 : IP = 123.123.123.123, IKE_DECODE RECEIVED Message (msgid=5456d64e) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 56 Apr 01 15:11:47 : Group = 123.123.123.123, IP = 123.123.123.123, Received an un-encrypted PAYLOAD_MALFORMED notify message, dropping Apr 01 15:11:47 : Group = 123.123.123.123, IP = 123.123.123.123, Error, peer has indicated that something is wrong with our message. This error can also be seen if one end has PFS set and the other end does not. Tunnel-group 123.123.123.123 ipsec-attributes pre-shared-key this-is-the-pre-shared-keyĪgain if you can’t check the other end then issue the following debug and the following will tell you if there is a key mismatch. If there’s a firewall ‘in-between’ make sure UDP port 4500 is open for both peers.Ĭheck your Pre-Shared Keys match on the ASA issue a “more system:running-config” then keep pressing the space bar till you see the tunnel- group and shared key There is a comms error, check there’s no router with firewall capabilities in the link. Different Vendors equipment talking the the ASA, or simply the version of OS on the ASA have been different.Ģ. The Phase 1 Policies have been agreed with both peers, the initiator is waiting for the responder to send it its keying information. Password: Type help or ‘?’ for a list of available commands. You do not have a matching phase 1 policy with the other end, issue a “show run crypto isakmp” command make sure the other end has a matching policy, if you cant check the other end then generate some VPN traffic, issue the following command and check for the following, Note: If you see AG_ set peer ” to make sure.Ĥ. If you see MM_ACTIVE (This means phase 1 has completed in Main Mode, and is active) So phase 1 has completed successfully, you need to jump forward and troubleshoot Phase 2. Rekey : no State : MM_ACTIVE < In that case you need to do some troubleshooting and debugging. However you can’t always remove the tunnel and start again, especially if you only have control of your end of the tunnel. Just about every VPN tunnel I’ve put in that did not work, was a result of my fat fingers putting in the wrong subnet, IP address or shared secret. If I’m honest, the simplest and best answer to the problem is “Remove the Tunnel from both ends and put it back again”. Site to Site VPN’s either work faultlessly straight away, or involve head scratching and a call to Cisco TAC, or someone like me to come and take a look.