07-28-2008 04:10 PM - edited 02-21-2020 03:51 PM
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!
07-28-2008 05:55 PM
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
07-28-2008 05:56 PM
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
07-29-2008 07:57 AM
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...
07-29-2008 08:08 AM
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
07-29-2008 08:15 AM
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?
07-29-2008 08:23 AM
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.
07-29-2008 08:45 AM
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.
07-29-2008 08:58 AM
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
07-29-2008 09:18 AM
sure why
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 <--- "dmvpn doesnt need a crypto map on the interface"
please post these items and all crypto, route-maps and acls
thanks,
Joe
07-29-2008 09:26 AM
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
05-28-2009 04:23 AM
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?
06-05-2009 01:11 AM
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).
07-03-2009 07:06 AM
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)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide