DMVPN + NAT/PPTP conflict?

Unanswered Question
Sep 1st, 2010

I ran into a problem with DMVPN and what looks like a conflict with PPTP/NAT.

There are some posts here recommending 12.3(9) - is there a 12.4 mainline release or CSC for the issue that I can find working releases?

Hub is 12.4(25c) and spokes are 12(4)15-T3

ipsec dmvpn tunnels were mysteriously dropping, while straight ipip point to point tunnels had no issue. crypto was working etc. but showing no encaps on the hub and no nhrp being resolved.

clear ip nhrp seemed to fix it once, but then on recurrence it didn't

Then I noticed gre translations in nat - did clear ip nat translation * and the DMVPN tunnel came back up.

- already using ipsec transport mode

NAT is

ip nat inside source list 2 interface FastEthernet0/0 overload

ip nat inside source static tcp 1723 interface FastEthernet0/0 1723
access-list 2 remark SDM_ACL Category=2
access-list 2 permit
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Marcin Latosiewicz Sat, 09/04/2010 - 03:34


That's intersting,

Did you clear nat on hub or spoke devices? Do you have the nat table backed up?

Can you share configuration for DMVPN tunnel and physical interface?


JOHN PAUL MORRISON Tue, 09/07/2010 - 09:40

Cleared NAT on the hub router

NAT looked like:

Pro Inside global         Inside local          Outside local         Outside global



Hub config:

interface Tunnel0

bandwidth 1000

ip address

no ip redirects

ip mtu 1400

ip hold-time eigrp 1 30

ip nhrp authentication DMVPN_NW

ip nhrp map multicast dynamic

ip nhrp network-id 100000

ip nhrp holdtime 360

ip tcp adjust-mss 1360

no ip split-horizon eigrp 1

delay 1000

qos pre-classify

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel key 100000

tunnel protection ipsec profile SDM_Profile1

interface FastEthernet0/0
description $ETH-WAN$
ip address
ip nbar protocol-discovery
ip nat outside
ip virtual-reassembly
duplex full
speed auto
service-policy output SDM-QoS-Policy-2
interface FastEthernet0/1
description $ETH-LAN$
ip address
ip nat inside
ip virtual-reassembly
duplex full
speed auto

ip nat inside source list 2 interface FastEthernet0/0 overload
ip nat inside source static tcp 1723 interface FastEthernet0/0 1723

access-list 2 permit
Marcin Latosiewicz Tue, 09/07/2010 - 11:10


Those NAT translations are for host on your inside interface... which looks like a PPTP server on the inside. PPTP will establish GRE for data traffic.

I don't see a reason how DMVPN could fail in this case unless is also a spoke...

I think it will be something different, but we'd need to understand what was triggered by clearing translations.


JOHN PAUL MORRISON Tue, 09/07/2010 - 11:25 is also a spoke

I assume a remote user fired up a pptp client, but am not clear on whether it immediately triggers the problem or took some time.

The spoke had no gre entry because nat was cleared by reboot. After clearing nat on the hub, the tunnel starting passing traffic for this site.

Marcin Latosiewicz Tue, 09/07/2010 - 13:18


Frankly I'm a bit puzzled, both behaviors seem to be correct, however indeed two of those features seem not to work together.

Can you please move either nat translation or DMVPN source interface to a different IP address? (NAT being prefered option).

This should fix it. I'm actually not so sure if this is expected behavior - but was not able to find any bugs matching this description.

Would it be possible for you to open a SR with TAC? If you're willing - let me know the number.

I can also check which software releases are currently "recommended", not sure if that would help you.



This Discussion