09-01-2010 05:07 PM - edited 02-21-2020 04:49 PM
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
09-04-2010 03:34 AM
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
09-07-2010 09:40 AM
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
09-07-2010 11:10 AM
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
09-07-2010 11:25 AM
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.
09-07-2010 01:18 PM
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
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