S2S IPSec VPN tunnel - maximum number of retransmissions reached from one peer

[tickermcse76]

I have a S2S IPsec VPN tunnel between Peer_C and Peer_R, both are Cisco ASA on different code levels but 9.x.  Peer_C can always initiate the tunnel, however Peer_R fails the large majority of the time with:

IKEv2 Negotiation aborted due to ERROR: Maximum number of retransmissions reached

It seems Peer_R can only successfully initiate the tunnel in the scenario where Peer_C establishes the tunnel, the tunnel is manually torn down, Peer_R then immediately makes the attempt - in some cases it will succeed.

Note that we initially used IKEv1 and had the same issue.

Also note that we have a Juniper firewall, Peer_B, that initially had a similar "retransmissions reached" error with a VPN tunnel to Peer_C but it has gone away without any specific actions taken and the tunnel now establishes reliably.

For Peer_R initiating to Peer_C,  the debug log shows Peer_R sending the 7 configured IPSec proposals to Peer_C but no response is received.  I still need to get further validation for Peer_C but my understanding is it does not log the requests from Peer_R.

For Peer_R, Peer_C, and Peer_B, unfortunately I don't have access to the devices themselves as they are hosted platforms but I do have read access to the configuration and some syslog output. 

Any advice on how to further troubleshoot?  It would seem Peer_C has a more restrictive policy in place as we've seen similar errors from both ASA and Juniper peers.  But the configuration is fairly standard, a recent build, and no specific requirements put in place to prevent remote peer from initiating the tunnel.

[Richard Burts]

Is it possible that one of the peers has a dynamic IP address or one of the peers is using a dynamic crypto map?

HTH

Rick

[tickermcse76]

Rick - Thanks for the response - but none of those conditions are in place.

[Richard Burts · Accepted solution]

Thanks for the clarification that neither of the peers have dynamic IP addresses being assigned or a dynamic crypto map. I have seen these factors limit which peer could initiate a site to site VPN. But apparently that is not the case here.

So it sounds like something happens when peer C has initiated the VPN that allows peer R to start the tunnel, if the tunnel was manually torn down and peer R tries immediately to start the tunnel. Is there any type of address translation done (either for the outside interface on which the VPN is terminated or for the inside addresses which will send traffic to be encrypted)?

HTH

Rick

[tickermcse76]

Rick - after troubleshooting with Cisco we determined the root cause - there was a static NAT in place on the outside interface on peer C.  The NAT was in place to allow a host internet access sourced from the outside interface IP.  We changed the NAT to dynamic and it resolved our issue.   

[Richard Burts]

Thanks for the update. I am glad that you were able to find the cause of the problem and to correct it. And I am happy that my suggestion pointed toward the problem perhaps relating to a NAT.

HTH

Rick