DMVPN from Spoke behind NAT device to Hub

Unanswered Question
Jul 28th, 2008

Is it possible to create a DMVPN tunnel between a Hub and Spoke if the Spoke is behind a separate NAT device and is receiving a private address on its "external" interface?

Here is a basic rundown of the layout:

1 Hub with many spoke sites all successfully creating tunnels using DMVPN. One spoke site, however will not create a tunnel--or perhaps it is an issue with IPSec.

The spoke site is behind a NAT router which issues it a class C private address. I assume the hub sees the spoke's return address as this class C private IP address and not the public address owned by the NAT router. And this is why the tunnel cannot come up?

Maybe i am wrong?

Thanks in advance!

I have this problem too.
1 vote
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

Absolutely Cisco IPSEC vpn's DMVPN, Static IPSEC or GRE/IPSEC all use UDP 4500 (nat-t) when nat is detected in the path during IKE phase 1.

i just labbed this up for you in dynamips.

I have provided the config files for the spoke1 router and the ISP Edge router, doing the nat.

Please review.

Note: an access-list on the core monitoring the traffic confirms the fact the DMVPN traffic is nat'd inside of UDP 4500 packets. this is true for static one to one nat of the spoke and overload pat.

show crypto ipsec sa on SPOKE1 also confirms this.

SPOKE1#show crypto ipsec sa

interface: Tunnel1

Crypto map tag: Tunnel1-head-0, local addr 10.230.1.2

protected vrf: (none)

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

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

current_peer 67.80.80.1 port 4500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 44, #pkts encrypt: 44, #pkts digest: 44

#pkts decaps: 48, #pkts decrypt: 48, #pkts verify: 48

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 43, #recv errors 0

local crypto endpt.: 10.230.1.2, remote crypto endpt.: 67.80.80.1

path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0

current outbound spi: 0x68C5857E(1757775230)

inbound esp sas:

spi: 0x5580D9D9(1434507737)

transform: esp-192-aes esp-sha-hmac ,

in use settings ={Tunnel UDP-Encaps, }

conn id: 2001, flow_id: SW:1, crypto map: Tunnel1-head-0

sa timing: remaining key lifetime (k/sec): (4396212/86195)

IV size: 16 bytes

replay detection support: Y

Status: ACTIVE

spi: 0xFE115B08(4262550280)

transform: esp-192-aes esp-sha-hmac ,

in use settings ={Tunnel UDP-Encaps, }

conn id: 2003, flow_id: SW:3, crypto map: Tunnel1-head-0

sa timing: remaining key lifetime (k/sec): (4383091/86195)

IV size: 16 bytes

replay detection support: Y

Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0xC469E3A(205954618)

transform: esp-192-aes esp-sha-hmac ,

in use settings ={Tunnel UDP-Encaps, }

conn id: 2002, flow_id: SW:2, crypto map: Tunnel1-head-0

sa timing: remaining key lifetime (k/sec): (4396212/86195)

IV size: 16 bytes

replay detection support: Y

Status: ACTIVE

spi: 0x68C5857E(1757775230)

transform: esp-192-aes esp-sha-hmac ,

in use settings ={Tunnel UDP-Encaps, }

conn id: 2004, flow_id: SW:4, crypto map: Tunnel1-head-0

sa timing: remaining key lifetime (k/sec): (4383093/86195)

IV size: 16 bytes

replay detection support: Y

Status: ACTIVE

outbound ah sas:

outbound pcp sas:

protected vrf: (none)

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

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

current_peer 66.118.90.1 port 4500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 31, #pkts encrypt: 31, #pkts digest: 31

#pkts decaps: 20, #pkts decrypt: 20, #pkts verify: 20

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 51, #recv errors 0

local crypto endpt.: 10.230.1.2, remote crypto endpt.: 66.118.90.1

path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0

current outbound spi: 0xEDD35CF(249378255)

ISP-CORE#show access-list

Extended IP access list 101

10 permit esp any any log

20 permit udp any any eq non500-isakmp (48 matches)

30 permit ip any any (21 matches)

-Joe

mherald Mon, 07/28/2008 - 17:56

Well ... yes it is possible ... with some caviats ... The HUB has to know the spoke as it's NAT'ed address. AH transforms may have some challenges depending on how the NAT'ing device performs and handles the NAT.

I would avoid this siutation if I could, especially if the NAT'ing device was outside of my control.

Mike

graham.fleming Tue, 07/29/2008 - 07:57

OK. Thank you everyone for your replies and help. Those configs look very similar to what I have set up. Although I just realized one difference:

There is a double-NAT translation happening. The customer router is NATing the internal addresses to the ISP assigned private IP address which is then getting NATed again to the ISP public IP address.

Could this be my issue? Is there a way around this one?

I'll get my configs up here in a sec...

no. should be double nat.

the tunnelX interface should be sourced from the private IP THE ISP GAVE YOU. they would nat this, and using Nat-T the dmvpn would establish.

Please note: dmvpn was designed to be a "work anywhere" technology. Nat has little or no effect on DMVPN, IMHE.

I used to drop 871/2801 routers all over the place and we were sometimes natted.

-Joe

graham.fleming Tue, 07/29/2008 - 08:15

Thanks Joe for the information. I'm confused though about the NAT thing.

In my mind, we have an internal address (10.0.0.0) that is getting NATted by the NAT process on the customer router to the ISP assigned private address (192.168.0.0). And then the NAT process on the ISP router is NATting this address to a public IP.

I get stuck here because I assume the NAT-T will recognize the customer router as the NATting point and will ignore any subsequent NAT traversals. Or am I just wrong on this one?

You are correct that the internal client internet traffic (from 10.0.0.0) is being natted twice, at your router, and at the ISP's router.

Dont get stuck, it not that bad...

the internal traffic gets natted twice, but the DMVPN router only gets natted once. its tunnelX interface is SOURCED from an INTERFACE on your router's IP NAT OUTSIDE interface. It just leaves from there and is natted by the ISP, meaning your router's nat rules dont NAT its own VPN traffic. Your router's source for DMVPN is different being directly inside the ISP private IP SPACE, than your own private IP space, back in your network.

The ISP does that.

There is NAT-T (which is detected when IKE negotiates IPSEC) and is for router to router traffic. ESP, IP PROTO 50 is encapsulated in UDP 4500 packets to make it through nat devices IKE determines exist in the path.

graham.fleming Tue, 07/29/2008 - 08:45

Here are some partial configuration files regarding interfaces and routing:

HUB

interface Tunnel0

bandwidth 1500

ip address 172.16.0.20 255.255.255.0

no ip redirects

ip mtu 1350

no ip next-hop-self eigrp 1

ip nhrp authentication XXX

ip nhrp map multicast dynamic

ip nhrp network-id 100000

ip nhrp holdtime 600

no ip route-cache cef

no ip split-horizon eigrp 1

delay 1000

tunnel source GigabitEthernet0/0

tunnel mode gre multipoint

tunnel key 100000

tunnel protection ipsec profile dynVPNGREProfile shared

interface GigabitEthernet0/0

description LAN

bandwidth 100000

ip address 209.x.x.x 255.255.255.248

ip access-group INBOUND in

no ip redirects

ip nat outside

ip inspect fw out

no ip virtual-reassembly

ip route-cache flow

no ip mroute-cache

duplex full

speed 100

no keepalive

no cdp enable

crypto map VPNMap

h323-gateway voip interface

router eigrp 1000

redistribute static metric 1000 0 255 1 1500 route-map rmapREDIST-TO-GLOBAL

network 172.16.1.0 0.0.0.255

no auto-summary

SPOKE

interface Tunnel0

ip address 172.16.0.32 255.255.255.0

no ip redirects

ip mtu 1350

ip flow ingress

no ip next-hop-self eigrp 1

ip nhrp authentication XXX

ip nhrp map multicast 209.x.x.x

ip nhrp map 172.16.0.20 209.x.x.x.

ip nhrp network-id 100000

ip nhrp holdtime 300

ip nhrp nhs 172.16.0.20

no ip route-cache cef

no ip split-horizon eigrp 1

load-interval 30

delay 1000

tunnel source FastEthernet0/1

tunnel mode gre multipoint

tunnel key 100000

tunnel protection ipsec profile dynVPNGREProfile

interface FastEthernet0/0.100

description Data/Voice VLAN

encapsulation dot1Q 100

ip address 10.3.20.254 255.255.255.0

ip nat inside

ip virtual-reassembly

interface FastEthernet0/1

ip address dhcp

ip nat outside

ip virtual-reassembly

ip policy route-map VPN-Client

duplex auto

speed auto

crypto map VPNMap

router eigrp 1

network 10.3.0.0 0.0.255.255

network 172.16.0.0 0.0.0.255

no auto-summary

Let me know if you need more info. To reiterate, the Hub router has many successful connections with other spoke routers. This spoke router here that doesn't connect is the only one behind a second NAT device.

graham.fleming Tue, 07/29/2008 - 08:58

And here is the debug nhrp output from the spoke router after shut/no shut on the tunnel interface:

Jul 29 16:46:39.429: NHRP: if_up: Tunnel0 proto 0

Jul 29 16:46:40.433: NHRP: Attempting to send packet via DEST 172.16.0.20

Jul 29 16:46:40.433: NHRP: Send Registration Request via Tunnel0 vrf 0, packet size: 83

Jul 29 16:46:40.433: NHRP: Encapsulation failed for destination 172.16.0.20 out Tunnel0

Jul 29 16:46:41.249: NHRP: Setting retrans delay to 2 for nhs dst 172.16.0.20

Jul 29 16:46:41.249: NHRP: Attempting to send packet via DEST 172.16.0.20

Jul 29 16:46:41.249: NHRP: Send Registration Request via Tunnel0 vrf 0, packet size: 83

Jul 29 16:46:41.249: NHRP: Encapsulation failed for destination 172.16.0.20 out Tunnel0

Jul 29 16:46:41.425: NHRP: if_up: Tunnel0 proto 0

Jul 29 16:46:41.425: NHRP: Adding Tunnel Endpoints (VPN: 172.16.0.20, NBMA: 209.x.x.x)

Jul 29 16:46:41.429: NHRP: Attempting to send packet via DEST 172.16.0.20

Jul 29 16:46:41.429: NHRP: NHRP successfully resolved 172.16.0.20 to NBMA 209.x.x.x

Jul 29 16:46:41.429: NHRP: Encapsulation succeeded. Tunnel IP addr 209.x.x.x

Jul 29 16:46:41.429: NHRP: Send Registration Request via Tunnel0 vrf 0, packet size: 103

Jul 29 16:46:41.429: NHRP: 131 bytes out Tunnel0

Jul 29 16:46:41.429: NHRP: Resetting retransmit due to hold-timer for 172.16.0.20

Jul 29 16:46:41.913: NHRP: Setting retrans delay to 1 for nhs dst 172.16.0.20

Jul 29 16:46:41.913: NHRP: Attempting to send packet via DEST 172.16.0.20

Jul 29 16:46:41.913: NHRP: NHRP successfully resolved 172.16.0.20 to NBMA 209.x.x.x

Jul 29 16:46:41.913: NHRP: Encapsulation succeeded. Tunnel IP addr 209.x.x.x

Jul 29 16:46:41.913: NHRP: Send Registration Request via Tunnel0 vrf 0, packet size: 103

Jul 29 16:46:41.913: NHRP: 131 bytes out Tunnel0

..

..

Same output with retrans delay doubling each time

..

..

Jul 29 16:48:38.391: NHRP: Setting retrans delay to 64 for nhs dst 172.16.0.20

Jul 29 16:48:38.391: NHRP: Attempting to send packet via DEST 172.16.0.20

Jul 29 16:48:38.391: NHRP: NHRP successfully resolved 172.16.0.20 to NBMA 209.x.x.x

Jul 29 16:48:38.391: NHRP: Encapsulation succeeded. Tunnel IP addr 209.x.x.x

Jul 29 16:48:38.391: NHRP: Send Registration Request via Tunnel0 vrf 0, packet size: 103

Jul 29 16:48:38.391: NHRP: 131 bytes out Tunnel0

Jul 29 16:49:31.124: NHRP: Setting retrans delay to 64 for nhs dst 172.16.0.20

Jul 29 16:49:31.124: NHRP: Attempting to send packet via DEST 172.16.0.20

Jul 29 16:49:31.124: NHRP: NHRP successfully resolved 172.16.0.20 to NBMA 209.x.x.x

Jul 29 16:49:31.124: NHRP: Encapsulation succeeded. Tunnel IP addr 209.x.x.x

Jul 29 16:49:31.124: NHRP: Send Registration Request via Tunnel0 vrf 0, packet size: 103

Jul 29 16:49:31.124: NHRP: 131 bytes out Tunnel0

Jul 29 16:50:01.433: NHRP: Attempting to send packet via DEST 172.16.0.20

Jul 29 16:50:01.433: NHRP: NHRP successfully resolved 172.16.0.20 to NBMA 209.x.x.x

Jul 29 16:50:01.433: NHRP: Encapsulation succeeded. Tunnel IP addr 209.x.x.x

Jul 29 16:50:01.433: NHRP: Send Registration Request via Tunnel0 vrf 0, packet size: 103

Jul 29 16:50:01.433: NHRP: 131 bytes out Tunnel0

Jul 29 16:50:01.433: NHRP: Resetting retransmit due to hold-timer for 172.16.0.20

Jul 29 16:51:00.246: NHRP: Setting retrans delay to 64 for nhs dst 172.16.0.20

Jul 29 16:51:00.246: NHRP: Attempting to send packet via DEST 172.16.0.20

Jul 29 16:51:00.246: NHRP: NHRP successfully resolved 172.16.0.20 to NBMA 209.x.x.x

Jul 29 16:51:00.246: NHRP: Encapsulation succeeded. Tunnel IP addr 209.x.x.x

Jul 29 16:51:00.246: NHRP: Send Registration Request via Tunnel0 vrf 0, packet size: 103

Jul 29 16:51:00.246: NHRP: 131 bytes out Tunnel0

And then, after shutting the interfacE:

Jul 29 16:52:16.468: NHRP: if_down: Tunnel0 proto IPv4

Jul 29 16:52:16.472: NHRP: Deleting delayed event for NBMA 209.x.x.x on list (Tunnel0).

Jul 29 16:52:16.476: NHRP: if_down: Tunnel0 proto IPv4

graham.fleming Tue, 07/29/2008 - 09:26

I believe all of those are for VPN client connections for remote VPNs. Unrelated to the site-to-site DMVPNs. But perhaps it is conflicting?:

crypto map VPNMap 1 ipsec-isakmp dynamic dynmap

crypto dynamic-map dynmap 10

set transform-set GRETransform

set isakmp-profile VPNClient

reverse-route

crypto ipsec transform-set GRETransform esp-3des esp-md5-hmac

mode transport

crypto isakmp profile VPNClient

match identity group VPNClientGroup

client authentication list VPNClientAuthen

isakmp authorization list VPNClientAuthor

client configuration address respond

route-map VPN-Client permit 10

match ip address 144

set ip next-hop 10.11.0.2

Note: there is no matching ACL 144. Must look into this. But again, I do'nt believe it is related to DMVPN.

Tunnel Crypto:

crypto ipsec profile dynVPNGREProfile

set transform-set VPNTransform

set isakmp-profile DMVPN

crypto ipsec transform-set VPNTransform esp-3des esp-md5-hmac

mode transport

crypto isakmp profile DMVPN

keyring dmvpnspokes

match identity address 0.0.0.0

AJAZ NAWAZ Thu, 05/28/2009 - 04:23

I'm replying to mherald's post:

Well ... yes it is possible ... with some caviats ... The HUB has to know the spoke as it's NAT'ed address. AH transforms may have some challenges depending on how the NAT'ing device performs and handles the NAT.

I would avoid this siutation if I could, especially if the NAT'ing device was outside of my control.

Mike

----------------------------------------

Well I have a situation where the NAT device is outside of my control. My question is can this work?, and if yes - what specific configuration will make it happen?

AJAZ NAWAZ Fri, 06/05/2009 - 01:11

In reply to my own post I can confirm this does work. However make sure to avoid:

124-12c advanced IP (hub or spoke).

After upgrade to 124-24.T the issues are eliminated. We are using OSPF and the following symptoms were being observed:

During INIT phase - output from debug ip ospf adj:

Cannot see ourself in hello from x.x.x.x

After this both hub&spoke are Stuck in Exchange (OSPF).

louis.engelbrecht Fri, 07/03/2009 - 07:06

Do you need to use two physical inferfaces?

my spoke has a private ip and sits behind a ASA.

i just want to NAT a public ip directly to the private ip of the router, but im having problems getting the tunnel established.

has anyone got some example configs for this (im not double natting)

Actions

This Discussion