DMVPN tunnel up but can't ping anything off the router

[John Hinckley]

Topology:

ISR4321 => NAT THROUGH FW => ***INTERNET*** <= 7301

Relative Config:

ISR4321

interface GigabitEthernet0/0/1
ip address 192.168.0.1 255.255.255.0  <==behind a NAT
negotiation auto
h323-gateway voip interface
h323-gateway voip bind srcaddr 192.168.0.1
end

interface Tunnel0
description Tunnel to Colo
ip address 10.41.4.18 255.255.255.252
no ip redirects
ip mtu 1400
ip nhrp authentication telcion
ip nhrp map multicast 67.x.x.x
ip nhrp map 10.41.4.17 67.x.x.x
ip nhrp network-id 2005
ip nhrp holdtime 10
ip nhrp nhs 10.41.4.17
ip tcp adjust-mss 1300
tunnel source GigabitEthernet0/0/1
tunnel mode gre multipoint
tunnel key 2005
tunnel protection ipsec profile cust-dmvpn
end

interface Loopback2005
ip address 106.106.106.106 255.255.255.255

crypto ipsec transform-set ESP-SHA esp-aes 256 esp-sha-hmac
mode transport

crypto ipsec profile cust-dmvpn
set transform-set ESP-SHA

crypto isakmp policy 1
encr aes 256
authentication pre-share
group 2

crypto isakmp key ********** address 67.x.x.x

ip route 105.105.105.105 255.255.255.255 Tunnel0

7301 VPE Router:

interface GigabitEthernet0/0
ip address 67.x.x.x 255.255.255.0
duplex auto
speed auto
media-type rj45
no negotiation auto

interface Tunnel2005
description Tunnel for CXX
ip vrf forwarding CU_XXXXX
ip address 10.41.4.17 255.255.255.252
no ip redirects
ip mtu 1400
ip nhrp authentication telcion
ip nhrp map multicast dynamic
ip nhrp network-id 2005
ip nhrp holdtime 10
ip nhrp shortcut
ip tcp adjust-mss 1300
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
tunnel key 2005
tunnel protection ipsec profile cust-dmvpn shared

interface Loopback2005
ip address 105.105.105.105 255.255.255.255
end

crypto ipsec transform-set ESP-SHA esp-aes 256 esp-sha-hmac
mode transport require

crypto ipsec profile cust-dmvpn
set transform-set ESP-SHA

crypto isakmp policy 1
encr aes 256
authentication pre-share
group 2

crypto isakmp key ********** address 12.x.x.x

ip route vrf CU_XXXXX 106.106.106.106 255.255.255.255 10.41.4.18

I can bring up the tunnel between the peers just fine and I'm able to ping router LAN address, tunnel IP and loopback IP (from tunnel IP only!) in either direction.  However, from the 7301 I am unable to ping anything on the LAN behind the 4321.  The default GW for the LAN is the 4321 so I don't understand why I'm not getting any replies.  

I setup loopbacks on both sides but I can't ping from loopback to loopback.  I can however, ping from the tunnel IP to the loopback IP in either direction.

Am I missing something?

Thanks,

John 

[rmfalconer]

Is the public interface on the 7301 in a different vrf or just the global?

Is that public interface used for general internet or just for DMVPN?

What are you trying to accomplish with putting the tunnel interface in a different vrf?

[John Hinckley]

rmfalconer:

Thanks for the post.  The public IP of the 7301 is global and used strictly for DMVPN termination (sitting in a colo).  On the private interface of the 7301 are a bunch of subs for connecting to various voice subnets.  The tunnels are used only for voice services out of our collocation center. 

We already have a DMVPN tunnel into a different customer that works just fine.  The scenario on the problematic tunnel is virtually identical.  

It makes no sense that I can ping the loopback IP across the tunnel using the tunnel IP but not the local loopback IP.  The route for the loopback is in the VRF route table. 

Thanks,

-John

[rmfalconer]

Is the working tunnel also in a different vrf? How are you doing routing over these tunnels?

When I've done DMVPN, we've used the Front Door vrf configuration for the tunnels. This would mean having the public interface in vrf xxx and then tying the transport of the tunnel to that same vrf by using the 'tunnel vrf xxx' instead of 'ip vrf forwarding'. The routing information that's learned over the tunnel will be put in the global table, not the vrf table.

[John Hinckley]

That sounds like a great design but we won't be able to use it due to restrictions.  We can't allow any possibility of customers being able to route to each other's subnet.  

[rmfalconer]

What are the resources on the inside of the 7301? Are there multiple subinterfaces configured, each for a specific customer?

[John Hinckley · Accepted solution]

I found the problem.  Kind of embarrassing actually but I didn't configure the tunnel interface to be a part of the trusted security zone.  After adding it the problem went away.  

I'll never do that again. 

-John