02-10-2019 10:35 AM - edited 03-05-2019 11:15 AM
Hi there,
Thanks for reading.
I have a pair of routers with IPSEC tunnels configured. The routers can ping each other's public IPs. There are crypto isakmp keys with appropriate peer-router IP addresses. There are spot-on matching crypto isakmp policies in naming and protocols.
Debug crypto isakmp shows that it's not even attempting to connect.
Thanks!
Bob
Solved! Go to Solution.
02-11-2019 09:08 AM
Bob
Thanks for posting the information. There may be more than one issue involved and I will start with the most significant and if that does not resole the issue then we will look further. I assume that your intention was to configure this vpn using VTI. On each of the tunnel interfaces you have configured the tunnel mode for ipsec. But neither tunnel interface includes the tunnel protection command. Please add tunnel protection to both tunnel interfaces using profile VTI-aes256. Try this and let us know if the behavior changes.
HTH
Rick
02-10-2019 10:37 AM
Hello,
post the configs of both routers, you might be missing something small...
02-10-2019 10:40 AM
Bob
You describe some symptoms but give us no detail to work with. Can we start with getting configs of both routers. And perhaps some additional information such as output of show ip interface brief and of show ip route?
HTH
Rick
02-10-2019 02:34 PM
02-10-2019 03:36 PM
how are you attempting to bring the tunnel up? by generating interesting traffic is assume?
if that interesting traffic entering the FW in question?
02-11-2019 09:08 AM
Bob
Thanks for posting the information. There may be more than one issue involved and I will start with the most significant and if that does not resole the issue then we will look further. I assume that your intention was to configure this vpn using VTI. On each of the tunnel interfaces you have configured the tunnel mode for ipsec. But neither tunnel interface includes the tunnel protection command. Please add tunnel protection to both tunnel interfaces using profile VTI-aes256. Try this and let us know if the behavior changes.
HTH
Rick
02-11-2019 02:35 PM
02-11-2019 02:53 PM
Bob
Thanks for the update. Glad to know that adding the tunnel protection profile was a step in the right direction. At least now they are negotiating. It is not clear from the debug what is the issue. Perhaps debug from the other side might have helpful information?
HTH
Rick
02-11-2019 04:22 PM
02-11-2019 05:30 PM
When a device has multiple vpn tunnels to various remote peers Cisco has developed a tool to help with this, which is crypto conditional debug. See this link for information which I hope will be useful.
using conditional crypto debug you can identify the specific remote peer you are interested in and then debug for crypto (both isakmp and ipsec) will display output for that particular peer. Give that a try and post the output specific to the peer we are interested in.
HTH
Rick
02-11-2019 08:23 PM
02-12-2019 10:48 AM
Bob
I am a bit confused and hope you can clarify for me. You sent me debug output from rtmx602. In that debug I see isakmp negotiation with 91.212.206.133 which I expected. And it appears that negotiation was successful. It also received isakmp negotiation with 91.212.206.134 which I did not expect. There is no mention of that address in the configuration. So what is this address and why is it attempting isakmp negotiation with rtmx602? Looking at the debug it appears that it is the negotiation with this address that has the error about attributes not acceptable.
I then suggested that you post debug from the other side. You mentioned how many peers and I suggested conditional debug. The conditional debug that you posted was more debug from rtmx602. Can we get conditional debug from rthv1 for rtmx6002?
HTH
Rick
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide