int lo3 184.108.40.206/32 (nat outside) 220.127.116.11 is natted to 18.104.22.168
the two routers are just directly connected via cat3560
When i use NAT, the following happens. ISAKAMP appears to be happy on both sides. IPsec, appears to be happy at the spoke, i can see the spoke attempts to send traffic, e.g. EIGRP hello packets. This traffic however, does not appear to arrive at the hub! I see no traffic arriving/leaving the hub.
Nat-T appears to be in use.
Please see the attached outpus for more info. Thanks in advance.
DMVPN spoke to HUB issues (spoke behind NAT device)
thanks for your reply. The NAT was set up in a way it was/is just to simulate the spoke to be behind NAT device.
About AH and ESP, you are correct there... this was actually my issue. I should have used pure ESP. At the end, TAC actually assisted me with this. Before I called TAC, i did notice the following. ISAKMP traffic was NATed to 22.214.171.124, as expected. Anything after that, did not work and it has to with NAT and AH. Traffic was no longer NATed so the hub, saw the traffic come from 126.96.36.199 rather than 188.8.131.52, you can also see that in the error message you have pointed out. I also saw it in my packet captures. That caught my eye and i started troubleshooting it. I did not understand that AH can't be NATed, Below is TAC's explanation. All is good now. Thanks
. Essentially, it comes down to the fact that AH will encapsulate the entire IP packet (hence why it is the outermost header) with the exception of a few mutable fields, including the DSCP/ToS, ECN, flags, fragment offset, TTL, and the header checksum. Since the source/destination IP addresses & port numbers are actually protected by the AH integrity checking, this means that a device performing a NAT operation on the packet will alter these IP header fields and effectively cause the hub router to drop the packet due to AH failure.
Conversely, ESP traffic is able to properly traverse NAT because it doesn't include the IP header addresses & ports in its integrity check. In addition, ESP doesn't need to be the outermost header of the packet in order to work, which is why devices will attach an outer UDP/4500 header on the traffic going over NAT."
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :