cannot create DMVPN spoke-to-spoke when spokes are behind NAT
I have a DMVPN network setup and running almost perfectly except I cannot seem to establish a spoke-to-spoke connection between devices that are behind NAT.
Spoke-to-hub is working fine and spoke-to-spoke (when one of the spokes is not behind NAT) is also working.
If I look at my NHRP registrations on the server (hub) all devices are registering their public NBMA addresses but when one spoke tries to communicate to another spoke (both behind NAT) the NHRP on one side will always say 'incomplete' while the other side has the correct information. So, if I try to ping from VPN02 to VPN04, the NHRP on VPN02 will be incomplete while VPN04 has the correct info.
I've attached my configs and a diagram, hopefully someone out there has seen this before.
Re: cannot create DMVPN spoke-to-spoke when spokes are behind NA
I think I'm running into a PAT issue. I considered this when I was first troubleshooting but was hoping that NAT-T would allow NHRP to register the port but it appears that it doesn't.
If I remove PAT and use NAT I can establish a tunnel. It looks like this will simply a restriction we will have to live with.
As far as the multicast dynamic, I put that in there to test because I wasn't sure originally if my problem was due to EIGRP and I wanted GRE to pass my routing tables whether or not the IPSEC was active. I have since removed that line.
I am advertising a mixture of summary and specific routes to the NHRP routers but the NHRP network itself is a no-summary network and individual routes are advertised.
Thanks for the help!! It looks like PAT just isn't support quite yet but at least now I know what my tunnels won't come up.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...