Check VPN L2L proposals from Third party firewall

[mawright1]

Hello, 

Can someone confirm the process on how to locate the proposals coming into my Firewall from a third party, in the 1st phase of L2L VPN setup as i'm having an issues which the debugging messages show there are no matching proposals on my firewall, i'm aware i can ask the third party what they have configured at their end, but i wanted to see if they was a way i could view whats being recivced and change mine accordingly. 

Firewall is a Cisco 5512 running ASA verison 9.1(2).

Thanks!

[cofee]

Hi there, 

debug output may not exactly reveal if there is any mismatch in the phase 1 of isakmp parameters. So pretty much at this point it could be anything from pre-shared key (if you are using one), encryption or the hash. It's a good practice to agree on what the security parameters will be for the VPN if you don't have access to the remote VPN device. 

Can you share debug output And also phase 1 configuration ?

[mawright1]

Thanks for the reply,

debug message below:

Dec 20 11:48:54 [IKEv1 DEBUG]IP = 154.59.154.147, IKE MM Initiator FSM error history (struct &0x00007fffaa850bb0) <state>, <event>: MM_DONE, EV_ERROR-->MM_WAIT_MSG2, EV_RETRY-->MM_WAIT_MSG2, EV_TIMEOUT-->MM_WAIT_MSG2, NullEvent-->MM_SND_MSG1, EV_SND_MSG-->MM_SND_MSG1, EV_START_TMR-->MM_SND_MSG1, EV_RESEND_MSG-->MM_WAIT_MSG2, EV_RETRY

crypto ikev1 policy 10
authentication pre-share
encryption aes-256
hash sha
group 2
lifetime 86400

crypto ikev1 policy 20
authentication pre-share
encryption aes
hash sha
group 2
lifetime 28800

crypto ikev1 policy 30
authentication pre-share
encryption aes-256
hash sha
group 5
lifetime 86400

[cofee]

This is what's going on:

1) IKE initator sends MM_SND_MSG1 and goes into MM_WAIT_MSG2 state
2) IKE responder receives MM_SND_MSG1 and sends MM_SND_MSG2 back to the initiator and goes into a MM_WAIT_MSG3 state, expecting MM_SND_MSG3 as the next exchage from the initiator
3) IKE initiator having not received MM_SND_MSG2 from the responder, resends MM_SND_MSG1, resulting in the “Duplicate first packet detected” being logged on the responder.

In the debug (from the initiator) you can see this occuring:Jan 24 09:02:44 [IKEv1 DEBUG]: IP = 123.123.123.123, IKE MM Initiator FSM error history (struct &0xafd4cc28)  <state>, <event>:  MM_DONE, EV_ERROR–>MM_WAIT_MSG2, EV_RETRY–>MM_WAIT_MSG2, EV_TIMEOUT–>MM_WAIT_MSG2, NullEvent–>MM_SND_MSG1, EV_SND_MSG–>MM_SND_MSG1, EV_START_TMR–>MM_SND_MSG1, EV_RESEND_MSG–>MM_WAIT_MSG2, EV_RETRY

For some reason you are not getting reply back from the responder which is other end of VPN. It could be an issue with routing on their end. Did you check connectivity between the vpn endpoints? are you able to ping the other side? 

[mawright1]

Thanks, 

I'm unable to ping the other side, but i believe that's because they have blocked ICMP. Yesterday I was getting  a message saying 'All SA proposals found unacceptable' so i thought i was getting the response but there wasn't an agreement on the proposals?

[cofee]

I understand, but based on the debug output you posted your firewall is complaining that it's not getting reply back from it's peer to bring up phase 1 of isakmp. You will need to work with the team that's handling the remote VPN device and see if they are receiving MM_SND_MSG1 sent by your firewall. That way we will know that you have connectivity to the remote site and then work on why return traffic is not making it back. 

[mawright1]

The third party changed their end and we established a VPN connection! 

Thanks for your help! 

[MANI .P]

Hi ,

when Message 3  sending to res ponders & not accepting .

Means that Initiator sending DH group is not accepting Res ponder .

can you share the both running configuration ?

thanks,

Mani 

[Farhan Mohamed]

I understand, but based on the debug output you posted your firewall is complaining that it's not getting reply back from it's peer to bring up phase 1 of isakmp. You will need to work with the team that's handling the remote VPN device and see if they are receiving MM_SND_MSG1 sent by your firewall. That way we will know that you have connectivity to the remote site and then work on why return traffic is not making it back.