T R
asked on
Cisco ASA ipsec vpn phase 1 issues
Hello All,
A little help and advice needed please -
I am setting up a Site-to-Site VPN connection between a Cisco ASA and a TP Link ER6120 (I know don't ask). Any way phase 1 IKE keeps failing when I initiate from the ASA side.
I get MM_Active when responding to the TP Link however when initiating from ASA side it changes to MM_Wait_msg2 and MM_Wait_msg6. I have confirmed multiple times that the timers and PSK are the same both sides and that the encryption matches. Even when MM_Active as responder the IPSEC tunnel does not form.
Running a debug on crypto isakmp on the ASA I get the following -
Removing peer from correlator table failed, no match!
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Session is being torn down. Reason: Lost Service
[IKEv1]: IP = x.x.x.x, Header invalid, missing SA payload! (next payload = 4)
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Information Exchange processing failed
[IKEv1]: Group =x.x.x.x, IP = x.x.x.x, Information Exchange processing failed
[IKEv1]: IP = x.x.x.x, Header invalid, missing SA payload! (next payload = 4)
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Information Exchange processing failed
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Information Exchange processing failed
Am I missing something obvious here? Any help would be appreciated?
A little help and advice needed please -
I am setting up a Site-to-Site VPN connection between a Cisco ASA and a TP Link ER6120 (I know don't ask). Any way phase 1 IKE keeps failing when I initiate from the ASA side.
I get MM_Active when responding to the TP Link however when initiating from ASA side it changes to MM_Wait_msg2 and MM_Wait_msg6. I have confirmed multiple times that the timers and PSK are the same both sides and that the encryption matches. Even when MM_Active as responder the IPSEC tunnel does not form.
Running a debug on crypto isakmp on the ASA I get the following -
Removing peer from correlator table failed, no match!
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Session is being torn down. Reason: Lost Service
[IKEv1]: IP = x.x.x.x, Header invalid, missing SA payload! (next payload = 4)
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Information Exchange processing failed
[IKEv1]: Group =x.x.x.x, IP = x.x.x.x, Information Exchange processing failed
[IKEv1]: IP = x.x.x.x, Header invalid, missing SA payload! (next payload = 4)
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Information Exchange processing failed
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Information Exchange processing failed
Am I missing something obvious here? Any help would be appreciated?
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
MM_WAIT_MSG2
Message 1 has been sent to the responder but there has been no reply.
Causes:
1. There is no network connectivity to the firewallsecurity device at the other end, can you ping it?
2. The IP address of the far firewall is incorrect in the tunnel-group, issue a “show run tunnel-group” command, check you have a tunnel group with the correct IP address.
3. The IP address in the “Crypto Map” is incorrect, issue a “show run crypto map” command and check the line that ends “crypto map {name} {number} set peer xxx.xxx.xxx.xxx” to make sure.
4. 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.
MM_WAIT_MSG6
If there’s a firewall ‘in-between’ make sure UDP port 4500 is open for both peers.
Check 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
e.g.
tunnel-group 123.123.123.123 ipsec-attributes pre-shared-key this-is-the-pre-shared-key
Again 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.
This error can also be seen if one end has PFS set and the other end does not. In this case the error will appear and dissapear and the connection is repeatedly “torn down”
e.g
crypto map outside_map 20 set pfs
Troubleshooting Phase 1 Cisco Site to Site (L2L) VPN Tunnels