Basic question about routing a new subnet through a core switch that is not the default gateway

Currently, our SonicWall is set as the default gateway for all devices (via DHCP and everything we’ve assigned static IPs to) because we haven’t had a core switch until recently.

Now that we have a core switch, I was curious if I could set up another subnet on a dedicated VLAN so devices on that VLAN are addressable by computers on the LAN, but they are on their own broadcast domain.

What would be the best way of tackling this?

Up until now, I’ve just used the SonicWall, but if I could route straight through the core switch instead of adding even more work for the SonicWall and yet another hop, that would be awesome. Is it possible to do this without changing the default gateway on everyone’s machine? Even if it went through the SonicWall first, is it possible to tell the SonicWall to route all of the traffic to the interface IP of the VLAN on the core switch?

Thanks, I realize this is a very basic question and I’m probably just not thinking about it correctly.

I’ve not tried this, but it’s an interesting concept. I’d think if the new subnet wasn’t listed in the local device routing tables, traffic to it would still be directed to the router, even if the switch could help it get to the VLAN. Sounds like you need virtual interfaces of the VLAN on each LAN machine that needs to address other machines on the VLAN. I know how to do that on the Linux or Mac side…

Here is a template of VLANs that we found helpful Design VLAN Structure template - Google Sheets

Your core switch should be the default gateway… You will need to setup ACLs restrict traffic from VLAN to VLAN traffic

1 Like


It’s fairly straight forward to do what you’re asking. Let’s assume that your Core switch is at, Your Sonicwall is at and your new network segment is

My apologies for sticking all of the screenshots in one image - the forum only allows new users to include 1 image.

  • First, you’ll the add the new Network segment and the core as address objects in the sonicwall.
  • Next, you’ll add a route to the Sonicwall that tells it your new network is behind the core switch.
  • Finally, you’ll need to ensure your core switch has a route to the Internet pointed at the Sonicwall (this is on a ProCurve).

Now, that being said, a layer 3 switch is probably a better router than the firewall and you might be better off moving the routing to the switch. You won’t need to change all of your static devices, however. You’ll simply swap the addresses between the switch and firewall. (You will need to do a lot of other configuration on both the switch and firewall, but you won’t need to change DHCP or static gateway assignments on your other network segments.)



@jamesvavra gave a great example. Though, it seems like the thread is really focused on implementation without providing a high level way of looking at it first. The SonicWALL won’t need to know about all the networks behind it. The Layer 3 switch will take care of all routing with traffic rules you generate, and anything going somewhere that it doesn’t know about gets sent along that default route. The SonicWALL does the same, and takes care of all the UTM stuff.

If you want site-to-site VPNs, though, the SonicWALL will need to know what networks are behind the Core Switch though. In fact, the more I think about it, the more it seems to be at least a good idea to have the SonicWALL setup with the different networks.

Internally to the Core Switch, VLANs can be passed using whatever method you like. Cisco has VTP, I think most HP switches have to have the same VLAN configuration manually entered in each, etc. Think of it as two seperate Layer 3 domains, if that helps.

Once you have a good idea of what you’re trying to implement, and what the network should look like logically, the understanding and creation will more naturally follow.

Oh, I nearly forgot to mention: as a point of interest, we had an HP switch that we had not configured for any layer 3 switching, but it did it out of the box, without being asked. So, depending on your switches, there’s a possibility it will generally allow all traffic between VLANs that it knows about unless access rules are implemented. Just something to be cautious of.

1 Like

Hey @OneSeventeen - Believe it or not I started typing a response last night, but got so engrossed in it I didn’t finish until just a moment ago.

Suffice to say, you have gotten some great answers as to how you should go about accomplishing your request. @jamesvavra made the most important point already about moving your L3 subnet gateway ip’s to the L3 switch and turning up a switch-sonicwall route to handle traffic to preserve your client config. @MagnaVis gave some great additional context as well.

It was @BenCarlson who linked to an IP spreadsheet that really got my excited though. Proper subnet planning and how that intersects with route layout is something most people don’t recognize the importance of until far after it is to late. That subject is essentially what I am addressing in my post Which you can find here.

Regardless. Great question.


Thanks everyone for all the great insight! Ironically I now feel like the current “small task” of creating a subnet to drop broadcast chatter for a few devices needs to be tabled while I design my dream network first rather than adding more knots to the Christmas light strand :slight_smile:

I think I’ll be combining all of the information here to draw up a plan and will post back with an idea. Once all is said and done, I’ll probably start a new thread with the final plan so others setting up a more robust network in the future can benefit from all of the information and guidance everyone has been providing.

I’m more grateful than you could imagine for how supportive and knowledgeable this thread has been without being judgemental. I do know I’m asking beginner level questions and I’m humbled by the caring responses.

Keep in mind once you have a roadmap it’s super easy to phase in the new VLANs over time, so you don’t need to just shut everything down for a couple weeks while you reconfigure everything from scratch.