• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 821
  • Last Modified:

Subnetting existing network and dealing with multiple default gateways

I'm in a bit of a pickle. We seem, to me at least, to have an overly complex network. I understand how it ended up this way but it's complexity is causing all kinds of issues.
Here's the setup in words, I've attached a sanitized network map to assist.

All the firewalls referred to are sonicwalls.

Our main campus has two large buildings. They share the 192.168.100.x/ network. There are way more than 254 devices. The buildings have fiber between them so they are essentially the same. But….

This same network has TWO default gateways (different firewalls) utilizing different ISPs, both are in different buildings. Hosts in both buildings use a mashup of different gateways depending on the ISP they need to use. So building A may have devices that use the DG from building B and vice versa.

Adding to this mess are the off campus sites that VPN into building B’s firewall. Those sites of course have their own subnets, their own local internet connections etc.  

Building A’s firewall has routes in it so that it knows that the VPNs exist on firewall B.

The help alleviate some of the address shortage I created 192.168.103.x for my network devices.

To do this I activated an interface on firewall A with the address and all the devices on that subnet point to that DG.

Firewall B has a route for 192.168.103.x that points to its lan interface (X0) with a DG of firewall A.

This has helped and all devices, irrespective of their DG can contact all of the other networks.

Here’s the pickle.

We need to be able to use firewall A as a backup VPN gateway for firewall B. Meaning if B’s internet goes down, all the VPN connections need to go to firewall A. This works fine. The off campus sites renegotiate and connect to firewall A without issue. But, since all the routing is static, when the sites reconnect to firewall A they can’t connect to any of the networks on firewall A because, I’m guessing, the devices they need to talk to use firewall B as a DG.

If this situation existed for hours or days I’d just change the routes (which I know works). However, this is usually a 10 or 20 minute failover and I can’t make all the changes that quick. I should think that this kind of thing is a normal failover situation that has a solution.

The bigger issue for me is that firewall A and B are in different physical locations so I can’t technically wire them together for a normal failover unless I’m missing something.

Keep in mind- these firewalls are on the same network- 192.168.100.x.

All that said here’s what I’m after:

I want to breakup this network, preferably without vlans.

I’d like the firewalls to work in tandem for VPN failover without the need to manually change routes- and possibly allow workstations and servers to utilize them in the same way without all the routing issues.

Ideally I’d like the main network to be 192.168.100.x, wifi devices on 192.168.101.x and my management/devices on 192.168.103.x.

My preference is to do this without vlans. The thought of having to configure the switches port by port for a vlan worries me and I believe adds another layer of complexity.

Any thoughts, guidance, advice, direction are welcome.
  • 2
  • 2
1 Solution
Can you elaborate and be as specific as possible when you say that when the VPN fails over to the other Firewall the clients/remote sites are unable to access the networks they need to get to? What kind of Subnet do the remote sites use? What subnet are they trying to reach? Where is this subnet located?  

What are you using right now to allow the remote sites to failover to the other SonicWALL's internet connection? Are you just specifying a secondary Gateway that points to the other Site's IP Address?

Things that are confusing to me:
 -You state that you have two building that have a /24 subnet, but you have way more than 254 devices. If this is the case how are they connected to the network. What subnet are you using for these hosts? What about the gateways, are they a mashup between building A and buildinb B as well?
 - What is the purpose of all of the different ISP's?
 - You referenced that You can change the routes when the failover occurs to resolve the problem but this is not feasible since the failover only is present for 10 to 20 minutes. What routes are you changing that the VPN users are unable to get to when they failover to the secondary VPN Gateway?

In a nutshell. I think it would be worth your time and effort to segment the network properly by rolling out VLAN's and keeping a 1:1 VLAN:Subnet ratio setup. This is going to cause a headache for you down the road and the broadcast traffic on the network is going to be an issue eventually where everything is very slow.

I think based on what I read so far is that you need to implement a Network Monitor Policy with Policy Based Routing that will automagically install the necessary routes into the routing table based on whether or not the alternative site is reachable or not. What this will do is allow you setup a "probe" that will check the other side of the network and in the event that it is unreachable the Policy Based portion of this with kick in and either enable or disable the necessary routes in the routing table to allow the end users/vpn clients to access what they need. Below is a link for an Administrators Guide. I know this may not match your current version of SonicWALL but the concepts are the same and you just need to custom tailor it to meet your needs. Once the PDF is downloaded do a search for "Probe Enabled Policy Based Routing".

I hope this helps
digitalwavIT Infrastructure ManagerAuthor Commented:
The remote firewalls use two gateways for their VPNs- one for A and one for B. When one is unavailable they connect to the second. That part works (as far as connecting to the two VPN gateways on fw A and B. The end points on the VPNs are trying to contact any hosts on the 192.168.100.x subnets. The remote sites are 192.168.1.x and 192.168.200.x. They can contact everything properly so long as the VPN is connected to firewall B.

To temporarily resolve the lack of addresses no the main /24 subnet I moved many of the network devices- like APs, switches etc. to the 192.168.103.x subnet. To enable access to these devices I had to physically connect one of the firewall's interfaces back to the network (technically creating a loop) and give it an address of and creating a route to it on both firewalls.

I think you're probably right about just doing the VLAN properly. I'll read up on the sonicwall guide and see what it says. I seem to recall that the sonicwalls should be able to work together to change routing based on VPN status.

As for the ip shortage the vlan sounds like it is the only way this will work without making things worse.

BTW- I don't see a link for the guide.
Sorry about that. Here is the link:


What kind of switches are you working with internally that you would need to setup a VLAN's for?

I think this guide will definitely solve the problem for you. I think using the Network Monitoring with Policy Based routing will be your best best rather than working with static routes and trying to set it up with higher vs lower administrative distances to specify what route to use and when. I was also thinking of using a dynamic routing protocol which would likely address your issues but I think the VLAN's at this point and Network Monitoring with Policy Based Routing will be the best route to go and really help you in cleaning up your internal network.
digitalwavIT Infrastructure ManagerAuthor Commented:
All the switches are HP 2520, 2610 series with a few 2910 and 1910s.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Simple Misconfiguration =Network Vulnerability

In this technical webinar, AlgoSec will present several examples of common misconfigurations; including a basic device change, business application connectivity changes, and data center migrations. Learn best practices to protect your business from attack.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now