DMVPN spoke to HUB issues (spoke behind NAT device)

[sebastianpotok]

Hello all,

I have been looking into this issue for quite some time now.. it is time to reach out to the community.

I have this simple set up, i'm just labbing this out for now, for DMVPN. One hub and one spoke. Hub is mGRE and spoke is PtoP GRE.

Working topology (without NAT)

rt-home01 192.168.254.1/24 fa0/1/0

!

rt-home01-test 192.168.254.2/24 fa0/0

when both of those IPs/Interfaces are used as tunnel source/destination.. all is good.

the two routers are just directly connected via cat3560

Here is the issue:

Non-working topology (with NAT)

rt-home01  192.168.254.1/24 fa0/1/0

int lo0 1.1.1.1/32 (tunnel 1 source)

!

rt-home01-test fa0/0 192.168.254.2/24 (nat outside)

int lo2 2.2.2.2/32 (tunnel source, nat inside)

int lo3 3.3.3.3/32 (nat outside) 2.2.2.2 is natted to 3.3.3.3

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.

[Marcin Latosiewicz]

Odd setup to be honest (the NAT you've setup if I understand it correctly).

1) Usage of AH and ESP in same transform set. Start with pure ESP first. 

2) Your symptoms:

2a) Hub message

002889: Nov  3 2013 14:48:53.494 MST: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=1.1.1.1, prot=50, spi=0x32040000(839122944), srcaddr=2.2.2.2, input interface=FastEthernet0/1/0

2b) Hub IPsec SA:

   local  ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/47/0)

   remote ident (addr/mask/prot/port): (3.3.3.3/255.255.255.255/47/0)

2c) Spoke IPsec SA:

   local  ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/47/0)

   remote ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/47/0)

[sebastianpotok]

Hi Marcin,

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 3.3.3.3, 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 2.2.2.2 rather than 3.3.3.3, 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."