Two WAN Circuits, One Gateway: Why Physical Redundancy Can Still Be One Failure Domain

Published: October 7, 2026 | Last Technically Reviewed: October 7, 2026

Quick Answer

Fiber plus RF may provide useful redundancy-but only against the failures where those paths are genuinely independent. Different media do not automatically mean different Layer 2 domains, gateways, provider cores, or upstream routing paths.

And:

Conclusion

Two WAN circuits are not automatically two independent failure domains. A fiber circuit and an RF backup can protect against one physical last-mile failure while still sharing the same provider Layer 2 domain, next-hop gateway, aggregation infrastructure, routing domain, or upstream outage. The correct design question is therefore not "How many WAN ports do I have?" but "Which failures can take both paths down at the same time?"

The firewall must also be able to represent and monitor the circuits as usable, distinguishable forwarding paths. This becomes especially important when a provider hands off two physical services using the same subnet and the same gateway. Sophos Firewall 22.0 explicitly warns that configuring more than one WAN interface in the same subnet can cause ARP problems and make gateways unreachable; its current WAN documentation recommends an alias or LAG-based architecture for specific same-subnet designs rather than assuming two standalone WAN interfaces are interchangeable.

A September 4, 2026 r/networking thread titled Help needed: Failover troubleshooting provides a useful real-world trigger. The reported environment used a Sophos XGS 5500 HA cluster behind a Ruckus ICX switch. One ISP supplied a primary fiber service and a backup RF service. The engineer reported that the provider bridged the two connections upstream; bringing both customer-facing switch ports into the same VLAN immediately produced a broadcast loop and severe MAC flapping. Packet captures reportedly showed that the provider equipment did not pass the expected RSTP BPDUs or the engineer's custom Layer 2 probes. The same ISP also assigned both handoffs addresses from one public subnet with a shared gateway.

That is a public field report, not a Network-Switch.com customer case, and the underlying provider topology was not independently audited. It should not be generalized into "two circuits from one ISP always form a loop" or "Ruckus STP failed." Its value is narrower and stronger: it shows how two physically different WAN services can expose shared dependencies at Layer 2 and Layer 3 that are invisible on a simple topology diagram.

Two Circuits Do Not Automatically Mean Two Failure Domains

The first question in any redundancy review should be:

Suppose a provider delivers:

Fiber 
           Same ISP
RF 

At the physical-media layer, those links are different.

That may be enough to survive a local fiber cut.

But continue tracing upstream:

Fiber 
           Provider Aggregation
RF 
               
          Shared Gateway
               
          Provider Core
               
        Transit / Peering

The point at which the two paths merge determines which failures remain common.

Physical Diversity vs Network Diversity

This table is a template, not a statement about the actual ISP network in the Reddit case.

The important distinction is:

Different medium different provider path.

A fiber cut might take down Circuit A and leave RF working perfectly.

A provider aggregation failure might take down both.

A provider route leak or regional core outage may affect both even though one enters the building as glass and the other through radio.

This is why saying "we have two WAN links" is incomplete.

A more useful description is:

Three Different Failovers

Think about redundancy in three levels:

1. LINK FAILOVER

Physical link fails
        
Alternate physical link


2. PATH / GATEWAY FAILOVER

Ethernet remains UP
but upstream path becomes unhealthy
        
Alternate forwarding path


3. PROVIDER FAILOVER

Provider domain fails
        
Alternate provider/domain

A design that survives Level 1 does not automatically survive Level 2.

A design that survives Level 2 does not automatically survive Level 3.

Why Two ISP Handoffs Can Create a Layer-2 Loop

The September field report described a provider-side topology that, from the customer's perspective, looked approximately like this:

             PROVIDER SIDE

Fiber 
                  Bridged Domain
RF 
                       
                       
                       

       CUSTOMER SWITCH
        Port A     Port B
             \     /
              VLAN X

Simplified from a public engineering discussion; not a complete ISP topology.

If both provider handoffs really enter the same Layer 2 domain upstream and the customer then joins them again into the same VLAN downstream, the result can create a redundant Layer 2 forwarding path.

Symptoms can include:

• broadcast amplification;
• rapidly moving MAC entries;
• MAC flapping;
• unstable forwarding;
• widespread disruption.

That is what the engineer reported.

Why Didn't RSTP Automatically Block One Path?

Spanning Tree does not understand business intent such as:

RSTP makes decisions from the Layer 2 topology information it can observe through BPDUs and port state.

Cisco's current RSTP documentation describes BPDUs as carrying bridge, port-role, proposal/agreement, and topology-change information. RSTP depends on that information exchange to determine forwarding roles and react to topology changes.

In the public field case, the engineer reported that packet captures did not show the expected 802.1w BPDUs traversing the provider path. If the customer switch cannot observe the other side of a redundant Layer 2 path through the expected control-plane mechanism, it cannot simply infer the hidden provider topology from the fact that two ports happen to belong to one VLAN.

That leads to a broader principle:

This is not evidence that the Ruckus ICX failed to run RSTP correctly. The reported visibility boundary existed outside the switch.

What About Bridging on the Firewall Instead?

Sophos Firewall supports bridge interfaces, and its current documentation allows STP on a bridge specifically to protect against Layer 2 loops created by redundant paths.

But moving the bridge from the switch to the firewall does not automatically remove the upstream provider topology.

That is the key distinction:

Why Separate VLANs Do Not Solve a Shared Subnet and Gateway

A reasonable first reaction to the Layer 2 loop is:

Fiber  VLAN 100  Firewall WAN1
RF     VLAN 200  Firewall WAN2

This can be useful.

Sophos's own VLAN documentation describes VLANs as isolated broadcast domains. Splitting the two handoffs therefore prevents the customer's switch from directly placing both ports into the same local broadcast domain.

But solving the Layer 2 problem exposes the next question:

Suppose both are still expected to use:

Same public subnet
       +
Same next-hop gateway

The firewall now has to resolve:

Destination
    
Route
    
Gateway
    
Interface
    
Layer-2 Neighbor / MAC

The difficult part is not that two interfaces physically exist.

The difficult part is representing the same connected network and same next-hop identity through two separate physical paths without creating ambiguous neighbor or routing behavior.

Sophos Firewall 22.0 is unusually explicit about this. Its current Interfaces documentation states that more than one WAN interface in the same subnet causes ARP issues and can make the gateways unreachable. The page suggests alias or LAG interfaces for ISP address space belonging to the same subnet.

The current WAN Link Manager documentation adds another important nuance: for two WAN interfaces used for load balancing in the same subnet with the same gateway, Sophos recommends using a LAG to avoid routing or gateway stability problems.

Historical Sophos Community discussions describe the same class of symptom-one gateway remaining down, gateway state flapping, or load balancing failing when two WAN interfaces shared the same subnet/gateway. Those posts are historical corroboration only; current Sophos 22.0 documentation is the authoritative source for present behavior.

This does not justify saying:

That would be wrong.

The correct rule is:

And:

Can SD-WAN or an Active-Passive LAG Fix the Design?

Neither answer should be reduced to a universal Yes or No.

What SD-WAN Can Actually Select

Sophos Firewall 22.0 SD-WAN profiles operate across configured gateways. The firewall can choose the first available gateway or load-balance traffic and can evaluate path performance using latency, jitter, and packet loss. Health checks probe hosts behind the gateway using ping or TCP, and a failed gateway can be removed from the selection algorithm.

That is more sophisticated than:

Port UP?
Yes  use it

But SD-WAN still needs paths that the firewall can represent as distinct forwarding choices.

So the useful question is not:

It is:

If the underlying handoff does not expose two independently usable paths, adding more SD-WAN policy does not create physical or provider diversity.

What About LAG?

Sophos defines a LAG as multiple physical links combined into a single logical connection. Its current documentation supports active-backup and LACP modes and describes link redundancy/failover among member interfaces.

That can be exactly the right abstraction for certain same-subnet provider handoffs.

But a LAG solves a different problem from end-to-end Internet health.

A historical Sophos Community test illustrates the boundary: an active-backup LAG switched when the physical connection disappeared, while shutting down a remote switch interface did not produce the same local link-down indication in that test. Again, that old discussion should be treated as historical field experience, not current universal Sophos behavior.

The larger principle is:

Firewall HA Is Another Failure Domain

The original field case also used an XGS 5500 HA cluster.

That adds device resilience, but firewall HA and WAN diversity answer different questions.

FIREWALL FAILURE DOMAIN

   FW-A  =====  FW-B
          HA

----------------------------

WAN FAILURE DOMAIN

      Fiber     RF
         \     /
        Provider
           
        Gateway

Sophos's current HA documentation defines failover around the firewall nodes themselves, including heartbeat loss, monitored-port state, and device unavailability caused by hardware, software, or power failure.

Therefore:

Link Up, Gateway Up and Internet Healthy Are Different States

WAN monitoring becomes useful only when the health check is aligned with the failure you actually care about.

Level 1 - Interface Link

Ethernet link = UP

This proves the local electrical/optical Ethernet relationship exists.

It does not prove the provider can route traffic.

Level 2 - Gateway Reachability

Gateway responds

This is stronger evidence.

But the provider could still have a failure beyond that gateway.

Level 3 - Remote Probe Target

Probe target responds

Sophos SD-WAN can send ping or TCP probes to hosts behind configured gateways, which lets the firewall evaluate more than local next-hop link state. It can also use two probe targets and measure latency, jitter, and packet loss for SLA decisions.

Level 4 - Business Service Validation

Even a successful Internet probe does not prove the service the business needs is healthy.

Examples include:

• DNS actually resolves the required domains;
• HTTPS reaches a required SaaS endpoint;
• VPN reaches a private application;
• voice registration succeeds.

Link vs Gateway vs Service Health

The core model is:

Sophos's current SD-WAN profile also includes failback margins for latency and jitter so that the firewall does not repeatedly move traffic between gateways when performance is only marginally different. That matters because a failover design can itself become unstable if return-to-primary behavior is not considered.

What Should You Ask the ISP Before Calling the Circuit Redundant?

Do not start with:

That may or may not match the service architecture.

Some carriers intentionally provide transparent provider-managed failover where the customer sees a single logical handoff.

The correct objective is to understand who owns failover and where the two paths actually separate.

ISP Handoff Questions Checklist

Layer 1

• Are the physical access routes genuinely different?
• Do they enter the building through separate conduits or entrances?
• Do they terminate on separate access equipment?

Layer 2

• Are the handoffs bridged upstream?
• Are both expected to be connected simultaneously?
• Are BPDUs forwarded, filtered, or terminated?
• Does the provider expect customer-side spanning tree?

Layer 3

• Are both handoffs in the same subnet?
• Is the public block shared?
• Do both use the same next hop?
• Are they two routed interfaces or one logical service?

Failover Ownership

• Does the ISP perform the failover?
• Does the firewall perform it?
• Does a router/SD-WAN edge perform it?
• Is failover transparent to the customer?

Health Detection

• What condition declares the primary service failed?
• Link loss?
• CPE failure?
• Loss of upstream routing?
• Remote reachability?

Routing

Depending on the service, the handoff may use:

• static routing;
• provider-managed routing;
• BGP;
• another routed architecture.

BGP is not automatically required, and it should not be treated as a synonym for "real redundancy."

Do You Need a Second ISP?

Ask again:

If the requirement is:

Local fiber cut

A same-provider RF backup may be entirely useful.

If the requirement is:

Access-network failure

You need to know whether the two access networks actually remain independent upstream.

If the requirement is:

Provider-wide routing/core failure

Two last-mile services from the same provider may not deliver the required isolation.

A second ISP can reduce provider-level common dependencies, but it still does not guarantee zero overlap.

Two carriers may still share:

• building entrance;
• riser;
• conduit;
• meet-me room;
• local power;
• carrier hotel;
• wholesale access;
• upstream transit.

So:

The more precise procurement statement is:

Prove the Redundancy by Mapping and Testing the Failure Domains

The strongest way to evaluate WAN redundancy is to stop counting ports and map the entire dependency chain.

WAN Failure Domain Map

Business LAN
     
Firewall Pair
     
Customer Switching
     
Provider CPE A / B
     
Fiber / RF Access
     
Provider Aggregation
     
Gateway / PE
     
Provider Core
     
Transit / Peering
     
Internet / SaaS

For every layer, record:

Path A
Path B
Shared?
Independent?
Unknown?
Failure Tested?
Evidence?

Failure Domain Matrix

Do not fill unknown parts with assumptions.

Unknown is a legitimate engineering answer.

WAN Redundancy Acceptance Test

A diagram proves very little until failures are tested or independently documented.

Test 1 - Physical Link Failure

Disable or physically isolate the primary handoff.

Measure:

• failover occurred?
• detection time?
• recovery time?
• existing sessions affected?
• VPNs re-established?

Test 2 - Upstream Failure With Ethernet Still Up

The more important test is:

Port = UP
Upstream path = unavailable

Can the health-check mechanism detect it?

This validates path failure, not merely link failure.

Test 3 - Probe-Target Failure

A single probe target can itself fail.

Verify that your chosen monitoring design does not incorrectly declare an entire ISP down merely because one unrelated probe destination is unavailable. Sophos supports two probe targets in a profile, though the exact probing behavior should be understood before designing around it.

Test 4 - Failback

When the preferred circuit recovers:

• does traffic return automatically?
• how long does it wait?
• are sessions disrupted again?
• does the path oscillate between circuits?

Test 5 - Provider-Level Failure

Customers usually cannot safely simulate a provider-core outage.

This is where documentation matters.

Ask the carrier for:

• access-path diversity;
• shared CPE/aggregation information;
• SLA scope;
• provider-managed failover behavior;
• diversity guarantees.

The final rule is:

Before ordering WAN-edge hardware or a second Internet circuit, document the handoff, Layer 2 model, addressing, gateway behavior, failover ownership, monitoring method, and shared infrastructure first. Network-Switch's Engineering & Network Readiness Review can be used to review firewall/router selection, interfaces, optics, branch BOMs, uplinks, and resilience as part of the same design rather than treating "WAN2" as an isolated port purchase.

The five questions worth carrying into every redundancy project are:

And the summary principle remains:

Source and Evidence Boundary

Recent Community Initial Problem

The September 4, 2026 r/networking thread establishes the reported real-world topology and symptoms:

• Sophos XGS 5500 HA;
• Ruckus ICX;
• same-provider fiber and RF;
• provider-side bridging;
• loop/MAC flapping when both customer ports were active;
• reported BPDU visibility problem;
• same public subnet;
• shared gateway.

Source:
https://www.reddit.com/r/networking/comments/1w73bhp/help_needed_failover_troubleshooting/

These observations are not presented as Sophos, Ruckus, BSNL, or ISP-industry-wide defects.

Actual Community Follow-Up

The replies broadened the question from physical failover to:

• separate VLANs;
• firewall bridging;
• SD-WAN;
• active-passive bonding;
• provider independence;
• second ISP;
• BGP/routed handoffs.

Those replies are practitioner suggestions, not vendor specifications.

Historical Community Corroboration

Older Sophos Community discussions describe similar same-subnet/same-gateway ARP and gateway-state problems and active-backup LAG observations. They are used only as historical corroboration because versions and architectures have changed.

Official Sophos Product Facts

Current Sophos Firewall 22.0 documentation establishes:

• same-subnet multi-WAN ARP warning;
• alias/LAG recommendations in applicable designs;
• WAN Link Manager behavior;
• SD-WAN gateway/SLA/probe monitoring;
• bridge/STP capability;
• LAG behavior;
• HA failover triggers.

Standards-Based Networking Facts

RSTP's use of BPDUs, bridge roles, proposal/agreement, and topology-change signaling is supported by current Cisco documentation implementing IEEE 802.1w behavior.

Engineering Framework

The following are Network-Switch editorial frameworks:

• Physical Diversity vs Network Diversity;
• Three Levels of WAN Failover;
• WAN Failure Domain Map;
• Shared / Independent / Unknown classification;
• WAN Redundancy Acceptance Test;
• the five-question proof-of-redundancy model.

They are not Sophos methodologies.

First-Party Lab Evidence

No Network-Switch first-party test of this specific Sophos/ISP topology is claimed.

Current Official External Sources

Sophos Firewall 22.0 - Interfaces
https://docs.sophos.com/nsg/sophos-firewall/22.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Network/Interfaces/index.html

Sophos Firewall 22.0 - WAN Link Manager
https://docs.sophos.com/nsg/sophos-firewall/22.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Network/WANLinkManager/index.html

Sophos Firewall 22.0 - SD-WAN Profiles
https://docs.sophos.com/nsg/sophos-firewall/22.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Routing/SDWANRoutes/SDWANProfiles/index.html

Sophos Firewall 22.0 - Bridge Interfaces
https://docs.sophos.com/nsg/sophos-firewall/22.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Network/Interfaces/NetworkBridgeInterfaces/index.html

Sophos Firewall 22.0 - Link Aggregation Groups
https://docs.sophos.com/nsg/sophos-firewall/22.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Network/Interfaces/NetworkLinkAggregationGroups/index.html

Sophos Firewall 22.0 - HA Failover
https://docs.sophos.com/nsg/sophos-firewall/22.0/Help/en-us/webhelp/onlinehelp/HighAvailablityStartupGuide/AboutHA/HAFailover/index.html

Cisco - Rapid Spanning Tree Protocol / 802.1w
https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24062-146.html

Recent Public Field Discussion
https://www.reddit.com/r/networking/comments/1w73bhp/help_needed_failover_troubleshooting/

Historical Sophos Community - Same Gateway / Subnet
https://community.sophos.com/sophos-xg-firewall/f/discussions/121854/2-wan-one-is-active-the-other-is-inactive

Historical Sophos Community - Multi-WAN With Same Gateway
https://community.sophos.com/sophos-xg-firewall/f/discussions/76309/multi-wan-with-same-gateway

Historical Sophos Community - Active-Backup LAG
https://community.sophos.com/sophos-xg-firewall/f/discussions/130301/when-does-lag-active-backup-fail-over