0

Please excuse the brain-dump - trying to solve a problem that's had be running around in circles for an entire day!

TL;DR - Clients on two networks separated by a L3 switch can see and ping eachother, but only VLAN 99 can access the Internet, despite a default gateway being set (and routable) on the switch. Packets end up reaching the gateway and go no further, proven by traceroutes.

VLANs:

  • 192.168.50.0/24 (Legacy - VLAN 99)
  • 10.50.1.0/24 (New - VLAN 1)

Kit:

  • SonicWALL NSA220 with a LAN interface on 192.168.50.1 and a WAN address. The SonicWALL is configured to NAT all LAN addresses to the WAN.
  • HP 2920 Layer 3 switch, with interfaces on 192.168.50.254 and 10.50.1.254 and default gateway set to 192.168.50.1.

Default gateways:

  • VLAN 99: 192.168.50.1 (SonicWALL)
  • VLAN 1: 10.50.1.254 (HP)

Implementation details:

  • I have pushed a static route via DHCP for 10.50.1.0/24 with the gateway 192.168.50.254 to avoid ICMP redirects from the SonicWALL to 2920.
  • I have 10.50.1.0/24 statically routed to 192.168.1.254 and zoned as a LAN network on the SonicWALL.

Routing table on the 2920:

core-switch-01# show ip route

IP Route Entries

Destination        Gateway         VLAN Type      Sub-Type   Metric     Dist.
------------------ --------------- ---- --------- ---------- ---------- -----
0.0.0.0/0          192.168.50.1    99   static               1          1    
10.50.1.0/24       MGMT            1    connected            1          0    
127.0.0.0/8        reject               static               0          0    
127.0.0.1/32       lo0                  connected            1          0    
192.168.50.0/24    OLD_NET         99   connected            1          0

Please comment if anyone needs further detail.

Craig Watson
  • 9,370
  • 3
  • 30
  • 46
  • All the address you give are private addresses, so you wouldn't expect to get access to the Internet directly. Presumably you have some box doing NAT for you, and that's where I'd start looking. If you're hoping that the 2920 will do that for you, unfortunately not. – richardb Oct 16 '14 at 17:05
  • @richardb - the default gateway for VLAN 1 is the switch, and the default gateway of the switch is the SonicWALL, and the gateway of the SonicWALL is our upstream ISP router. Surely anything that isn't statically routable should flow through the default gateway? – Craig Watson Oct 16 '14 at 17:09

1 Answers1

1

The SonicWall needs a route to the 10.50.1.0/24 network via 192.168.50.254. 10.50.1.0/24 is not directly connected to the SonicWall so it has no idea how to route traffic back to that network.

Also, I don't understand this statement:

I have pushed a static route via DHCP for 10.50.1.0/24 with the gateway 192.168.50.254 to avoid ICMP redirects from the SonicWALL to 2920.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
  • Apologies, I left this detail out of the question, I have already statically routed 10.50.1.0/24 to 192.168.50.254 on the SonicWALL. – Craig Watson Oct 16 '14 at 17:17
  • Clarification on the ICMP redirects - without pushing the route via DHCP, I get ICMP redirect messages because there is technically a quicker route (192.168.50.254) on the subnet than bouncing via the SonicWALL (192.168.50.1). – Craig Watson Oct 16 '14 at 17:19
  • Can the SonicWall ping any 10.50.1.0 host? – joeqwerty Oct 16 '14 at 17:34
  • I got it. I had a little trouble understanding that statement. That being said, why not just use 192.168.50.254 as the DG for the 192.168.50.0/24 hosts? That's how it's typically done with L3 switches. That avoids the need for the routing entry to deal with the ICMP redirects and simplifies the management a little bit. You'd be able to change the ip of the SonicWall without having to change the DG on all of the clients. You'd simply have to make one change on the switch. – joeqwerty Oct 16 '14 at 17:40
  • That's the plan in the long-term (ideally 192.168.50.0/24 wouldn't exist) but we're in transition at the moment! – Craig Watson Oct 16 '14 at 19:42
  • Seems the issue was the static routing policy on the SonicWALL - tested the routing via the "Find Network Path" diagnostics tool and found that it was trying to route 10.50.1.254 via the WAN. The SonicWALL was set up to route anything from the X0 subnet, but once I'd changed the policy to Any, it worked. Props for the "can the SonicWALL ping 10.50.1.254" hint though, thanks! – Craig Watson Oct 16 '14 at 20:08
  • Glad to help... – joeqwerty Oct 16 '14 at 20:10