SonicWall VPN between 2800

[DrVoIP]

I am looking for any recommendations on this issue:

I have two CISCO 2800 routers tied together over a Metro Ethernet bewteen an HQ location and a Colocation facility.    There are multiple subnets on both sides of the MAN.   All things work in this regard.

I added two new Interfaces to the routers to create a VPN failover should the above MAN go down.  I use IP SLA to track the MAN, then move to the VPN route when reachability is down.

I can source ping from one CISCO router Interface to the other, through the two interfaces to the Sonicwalls and reach the router interface of the CISCO on the other side of the VPN tunnel.      

Problem: I can not ping any subnet behind the interface I ping through the Sonicwall VPN tunnel?  

Example 2800 G0/2 interface 100.1.1.41 /30 through Sonicwal over Internet to other Sonicwall and out ot the G0/2 100.1.10.41 /30 interface on the other 2800 router.  Ping is fine.

Now ping a subnet 10.100.8.129 /128 (a directly connected subinterface on that router) at the other end of this same tunnel, using a source ping to force the traffic over that link, and you can not PING anything.

Ping this over the main MAN connection and no issue!

Any ideas?   (network sketch attached).

Peter Buswell (aka DrVoIP)
http://blog.drvoip.com       

[Rahul Kukreja]

Hi,

Source ping from the router will not send the traffic over the interface from which you are trying to ping.

It will just change the source of the ip echo packet as by default it will take the primary address of the exit interface.

But the packet will still leave out of the same exit interface through which the route is defined.

So I beleive the test is not correct. You need to check the Routing on both the sides ..

Regards,

Rahul

[DrVoIP]

http://youtu.be/LRw-zuWXNoE  I created a video presentaiton of the issue using packet tracer to hopefully make things more clear!

Peter Buswell (aka DrVoIP)
http://blog.drvoip.com

[Rahul Kukreja]

Peter,

Thanks for the explanation, if Sonic FW is a L3 device, then it should know the route for both the source and destination ip, if the routes are not there then the echo request packet itself will be dropped.

You may enable debug ip icmp on router and you will be able to see who sent the unreachable packet to router.

Example -

when I ping 1.1.1.1 ( which follows the default route)

*Mar  1 00:18:17.932: ICMP: dst (155.1.13.1) host unreachable rcv from 155.1.13.3

155.1.13.1 was my exit interface and 155.1.13.3 was the router which does not know about 1.1.1.1

- HTH

Rahul

[John Blakley]

Peter,

Can you post the routes from the sonic wall on both sides too?

John

Sent from Cisco Technical Support iPhone App

[DrVoIP]

I am not able to do so, but I beleive them to be correct.  Lets summarize:

(a) There is a diagram above for those really interested;

(b) we are attempting to ping from the 192.168.0.0 /24 subnet at the HQ location; to the 10.100.8.128 /25 network at the Colocation facility. 

(c) This all works no problem when traffic goes over the 10.100.8.0 /30 interfaces.

(d) as that route is a Metro E we built a backup route over a VPN between the same two routers.

(e) 192.168.0.1 is a directly connected interface on the HQ router; 10.100.8.129 is a direclty connected interface at Colo

(f) VPN is connected thus" 100.1.1.41 on cisco at HQ to 100.1.1.42 on SonicWall at HQ; VPN over to 100.1.10.42 on Sonicwall at Colo then to 100.1.10.41 cisco router interface at colo router.

(g) you can ping each of the four reference interfaces using no problem.  So from inside the router at HQ I "ping 10.1.1.42 source g0/2 and we are good;  take it the next step and "ping 10.1.10.42 source g0/2" and we are good across the VPN; Next we "ping 10.1.10.41 source g0/2" and we are good to the router interface at the colo. 

(h) no we ping a directly connected interface on that router and we fail!  so "ping 10.100.8.129 source g0/2" just flat fails.

(i ) If i take a computer 192.168.0.2 and change its DG from .1 the cisco router; to .250 the SW, the ping completes no problem.  This all seesm to suggest that the VPN is connected and working. 

I am not on crack!  I have no idea why this very simple router configuration does not work! 

Peter Buswell (aka DrVoIP)
http://blog.drvoip.com

[John Blakley]

Peter,

I had some time to look at this today. It looks like the router that has 10.100.8.1 doesn't change it's default gateway and you don't have a specific router for the 192.168.0.0/24 subnet on there. From the routes that you show from that router, the default isn't tracked like it is on your other router, so all of the traffic comes from 192.168.0.0/24 gets routed to the default gateway of 10.100.8.130. Actually, let me correct myself, you're tracking the route but don't have a failover route:

ip route 192.168.0.0 255.255.255.0 10.100.8.2 track 1

ip route 0.0.0.0 0.0.0.0 10.100.8.130

ip route 100.1.1.40 255.255.255.252 100.1.10.42

ip route 192.168.3.0 255.255.255.0 100.1.10.42 10

ip route 192.168.5.0 255.255.255.0 100.1.10.42 10

ip route 192.168.10.0 255.255.255.0 100.1.10.42 10

On that router, try adding "192.168.0.0/24 10.1.10.41 10" and please report back to let me know.

HTH,

John

*** Please rate all useful posts ***

[DrVoIP]

John I must have fat figered it when I copy it the post as it is absolutely there as you can see both sides below.   The 0.0.0.0 0.0.0.0 10.100.8.130 needs to stay as that is how both sides get to the Internet.  192.168.0.0 has a route of 100.10.1.42 (G0/2) which is correct as the track is unreachable, and the metro route has been replaced to point to the VPN failover.

In either case it would not explain why you can ping from Router A over the VPN to Router B from either end, but you can not ping a directly connected interface in either router?

Gateway of last resort is 10.100.8.130 to network 0.0.0.0

S*    0.0.0.0/0 [15/0] via 10.100.8.130

      10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks

S        10.1.1.40/30 [1/0] via 100.1.10.42

C        10.100.8.0/30 is directly connected, GigabitEthernet0/0.900

L        10.100.8.1/32 is directly connected, GigabitEthernet0/0.900

C        10.100.8.128/25 is directly connected, GigabitEthernet0/1.100

L        10.100.8.129/32 is directly connected, GigabitEthernet0/1.100

      100.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

S        100.1.1.40/30 [1/0] via 100.1.10.42

C        100.1.10.40/30 is directly connected, GigabitEthernet0/2

L        100.1.10.41/32 is directly connected, GigabitEthernet0/2

S     192.168.0.0/24 [10/0] via 100.1.10.42

S     192.168.3.0/24 [10/0] via 100.1.10.42

S     192.168.5.0/24 [10/0] via 100.1.10.42

S     192.168.10.0/24 [10/0] via 100.1.10.42

Here is corp HQ side  sh ip route:

CO-Pompano(config)#int gigabitEthernet 0/0

CO-Pompano(config-if)#shutdown

CO-Pompano(config-if)#exit

CO-Pompano(config)#exit

CO-Pompano#sh ip route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP

       + - replicated route, % - next hop override

Gateway of last resort is 100.1.1.42 to network 0.0.0.0

S*    0.0.0.0/0 [10/0] via 100.1.1.42

      100.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

C        100.1.1.40/30 is directly connected, GigabitEthernet0/2

L        100.1.1.41/32 is directly connected, GigabitEthernet0/2

S        100.1.10.40/30 [1/0] via 100.1.1.42

      192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.0.0/24 is directly connected, GigabitEthernet0/1

L        192.168.0.1/32 is directly connected, GigabitEthernet0/1

S     192.168.3.0/24 [1/0] via 192.168.0.25

S     192.168.5.0/24 [1/0] via 192.168.0.25

S     192.168.10.0/24 [1/0] via 192.168.0.25

Peter Buswell (aka DrVoIP)
http://blog.drvoip.com

[John Blakley]

Can you do a traceroute from a host in the 192.168.0.0/24 subnet and with it failed over (g0/0 shut). Also, is your colo on the left or right of the picture?

[DrVoIP]

john - if your talking about the picture in the diagram I uploaded, the colo is on the right side.  It is the side that has the 10.100.8.128 /25 network.   

When I do a "ping 10.100.8.136 source g0/2" from the HQ router, it fails, yet if i do a "ping 100.1.10.41 source g0/2" it is successful.  The same thing using a tracert just generates *** and never even shows the first interface?   You would think if you can ping the router interface, you could ping any directly connected interface on the same router, woudl you not?

Last week I was at a CCboot camp for an advance Voice Certication and I showed this to a bunch of CCIE's and nobody coudl find anyhting wrong with my config.

At this point I am offering a cash reward for anyone who can figure this out!

Thanks for being so interested, you can write me directly at peter@drvoip.com

Peter Buswell (aka DrVoIP)
http://blog.drvoip.com

[John Blakley]

What happens if you ping the 10.100.8.129 interface of the router at the colo? Do you lose packets there too? If not, what's the default gateway set to for the .136 host on that same subnet? Let's do a couple of things. Do you have any acls on g0/2 on the colo side? If not, let's try this:

create an acl:

access-list 100 permit ip host 100.1.1.41 host 10.100.8.136

Then debug on the colo router applying this acl:

debug ip packet detail 100

Then try your ping again. After that, post the results back here and let's see if we can figure out what the colo router is doing.

John

[DrVoIP]

as soon as I can get a maintenanc window I will try your recommendation and post result.

From within the router at the Colo, I can ping the directly connected interface of 10.100.8.129 and also ping the .136 machine.   Interestingly, if I type "ping 10.100.8.129 source G0/2" it fails?  Remember that 100.1.1.41 is the router interface of the other CISCO router at the other end of the VPN tunnel.  That G0/2 interface can ping 100.1.10.41the G0/2 of the Colo router.

The default gateway for all devices in the 10.100.8.128 /25 network is the .129 router interface.

Peter Buswell (aka DrVoIP)
http://blog.drvoip.com

[DrVoIP]

very strange.

I put the suggested ACL on the interface and tried to ping and got nothing.   At that point the client reported that the Internet was down;  I removed the ACL, the internet was sitll down.   I checked SHOW IP ROUTE and noted that the default route on the Colo router had changed to 100.1.10.42 .   I quickly re-entered the correct default route of .130 and the itnernet came back up.  Why an ACL on the G0/2 would impact the default route is a mystery?

the running configuration at this point on that router was:

ip default route 0.0.0.0 0.0.0.0 10.100.8.130 15

ip default route 0.0.0.0 0.0.0.0 100.1.10.42 10

Why did that happen?

Peter Buswell (aka DrVoIP)
http://blog.drvoip.com

[DrVoIP]

Is it possible that the next hop router should be the Interface of the CISCO router on the other end and not the SW?  Maybe that is the issue, the SW is a tunnel and I am treating it like a next hop router?

Peter Buswell (aka DrVoIP)
http://blog.drvoip.com

[John Blakley]

Peter,

The acl is to be applied to the debug command above and not directly on the interface. You shouldn't lose traffic by applying this acl to te debug command.

If you can do that sometime today, I'll have more time this evening to look over te debug output.

Thanks!

Sent from Cisco Technical Support iPhone App