DMVPN + NAT/PPTP conflict?

JOHN PAUL MORRISON · ‎09-01-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 10.11.12.13 1723 interface FastEthernet0/0 1723

access-list 2 remark SDM_ACL Category=2

access-list 2 permit 10.11.12.0 0.0.0.255

Marcin Latosiewicz · ‎09-04-2010

John,

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?

Marcin

JOHN PAUL MORRISON · ‎09-07-2010

Cleared NAT on the hub router

NAT looked like:

Pro Inside global Inside local Outside local Outside global

gre 72.163.4.161:0 10.11.12.6:0 15.217.120.22:0 15.217.120.22:0

gre 72.163.4.161:33767 10.11.12.6:33767 15.217.120.22:33767 15.217.120.22:33767

Hub config:

interface Tunnel0

bandwidth 1000

ip address 10.13.14.1 255.255.255.0

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 72.163.4.161 255.255.255.0

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 10.11.12.1 255.255.255.0

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 10.11.12.6 1723 interface FastEthernet0/0 1723

access-list 2 permit 10.11.12.0 0.0.0.255

end

Marcin Latosiewicz · ‎09-07-2010

John,

Those NAT translations are for 10.11.12.6 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 15.217.120.22 is also a spoke...

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

Marcin

JOHN PAUL MORRISON · ‎09-07-2010

15.217.120.22 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 · ‎09-07-2010

John,

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.

Marcin