I've established a IPSEC GRE tunnel between two sites but cannot ping either end. I'm not seeing errors on the tunnel, it's up and active. The research I've done hasn't been helpful in my particular situation. I believe my ACL's are correct. My configs are attached. Can anyone help me with this?
Solved! Go to Solution.
If you are sourcing your ping from another interface (not the GRE tunnel interface), then you need to have some sort of routing going on for the tunnel endpoints to learn of each other's interfaces. If you just try to ping the tunnel interface, does it succeed? If so, then you probably just need to enable dynamic routing on the tunnel interface and add your other interfaces into the process.
Thanks for posting the configurations. Pinging from one end of the tunnel to the other end of the tunnel should be straightforward from a routing perspective since the destination address is in a connected subnet. I do have a couple of things to ask about and to suggest.
1) on farend you have a static route for 10.192.0.0 255.255.0.0 192.168.200.1. Why is this? That subnet is the subnet of the tunnel. So why have a static route? And why would the static route next hop be out the outbound interface when the subnet is a locally connected subnet. I suggest that you remove this from the config.
2) farend has the tunnel destination as 220.127.116.11. I assume that this is a disguise for the real address and that is ok. Can the farend router ping that address?
3) headend has policy based routing configured on the tunnel. I do not understand why and believe that it is flawed as configured. The PBR acl permits everything with a source address of the tunnel subnet to any destination. I do not understand why you would select traffic with the tunnel subnet. And I believe that the set ip default address is incorrect. It specifies the next hop as 192.168.100.97 which is the address of interface Gig0/0/0. At least as a test I suggest that you remove the PBR. Once we get the tunnel working correctly we can discuss whether you want to put PBR back in. But for now please remove it.
Good catch about the mask of the static route. However that is a typo on my part. Checking the config again I see that the mask of the static route is really 255.255.255.0. I stand by my (corrected) comment that this static route makes no sense.
Thanks for the confirmation that the static route was a holdover and is not necessary. I am not surprised that debug for isakmp and for ipsec was not very helpful and nhrp was crucial. If it is a standard GRE tunnel with ipsec, and especially if it is a tunnel VTI then isakmp and ipsec are important in bringing up the tunnel. But your tunnel is multipoint GRE (for DMVPN) and for this type of tunnel nhrp is the critical element. Glad to know that you have it sorted out.
Have you tried using VTI instead of GRE over IPsec, will most likely make your configuration a bit simpler?
Theres helps of articles out there for it, but here is one i just found. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_vpnips/configuration/zZ-Archive/IPsec_Virtual_Tunnel_Interface.html
I use it in my network to get rid of the need for GRE tunnels