10-25-2018 03:00 PM - edited 02-21-2020 09:29 PM
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
Solved! Go to Solution.
10-29-2018 11:03 AM
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
10-26-2018 12:07 PM
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?
10-26-2018 01:32 PM
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
10-26-2018 01:53 PM
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.
10-26-2018 04:02 PM
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.
10-29-2018 09:49 AM
What are the resources on the inside of the 7301? Are there multiple subinterfaces configured, each for a specific customer?
10-29-2018 11:03 AM
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
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