Why a Redundant Internet Connection Doesn’t Necessarily Provide the Redundancy You Might Think It Does

You’ve done the responsible thing. You signed up for a second internet connection from a different provider, installed it alongside your primary one, and told your team or staff, “Now we’re covered if anything goes wrong.”

Schools during state testing weeks, businesses running cloud apps and VoIP phones—everyone feels better knowing there’s a backup line.

But here’s the hard truth most organizations discover the hard way: just having two connections does not mean automatic failover. In many cases, when the primary line dies, the second one sits idle while users stare at spinning wheels. And even when you get the failover working, a single accident can still knock both lines offline at once.

The Classic Setup (and Why It Usually Fails)

Most networks are configured like this:

• Your firewall or router has one “primary” WAN port connected to ISP A.
• Devices on your local network point to that firewall as their default gateway (think of it as the front door everyone uses to leave the building).
• The secondary connection on ISP B is plugged in… but never used unless someone manually changes settings.

When ISP A goes down, the firewall may detect the link is dead, but your computers, phones, printers, and servers still believe “the way out is through the primary gateway.” They keep sending packets to a dead interface. No magic switch happens.

This is exactly the scenario many experience: the device still thinks its gateway is alive, even though the path beyond it is broken.

What “Multi-WAN” or “Dual-WAN” Actually Gives You

Modern firewalls (like pfSense, Sophos, FortiGate, Cisco, Ubiquiti, and others) support multi-WAN setups. You can configure:

• Failover — The device pings a reliable internet target (like 8.8.8.8) every few seconds. If the primary fails those checks, it shifts all new outbound traffic to the secondary link.
• Load balancing — Split everyday traffic across both links for better speed when both are working.

This handles outbound traffic (browsing, email, cloud apps) reasonably well.

But big limitations remain:

1. Inbound traffic (web servers, VPN, remote desktop, email servers) stays tied to the IP addresses of the failed ISP. Remote users or visitors trying the old public IP hit a dead end.
2. Active sessions break. A Zoom call or file upload in progress usually drops and needs to reconnect.
3. DNS and public IP changes. If the backup link uses different public IPs, services pointing to the old ones become unreachable until DNS updates (which can take hours).

The Hidden Trap: Shared Physical Paths (The Fiber Cut That Kills Both)

Even if you pick two completely different internet service providers (ISPs), your connections might still travel over the same physical fiber optic cable for the “last mile”—the final stretch from the street or nearby utility pole right to your building.

Think of the last mile like the driveway to your house. Multiple roads might lead to your neighborhood, but if everyone’s driveway shares the same narrow bridge over a creek, one backhoe digging nearby can cut off all traffic at once.

In many areas—especially urban and suburban spots—different ISPs lease space on the same underground conduits, poles, or even the same multi-strand fiber cable. A construction crew, a car hitting a pole, or a natural event severs that shared cable, and both “redundant” connections go dark simultaneously. Reliable sources in networking communities and provider guides confirm this is a common gotcha: even “different carriers” often converge on the same last-mile infrastructure because building entirely separate physical paths to every building is extremely expensive.

This is why true path diversity (completely separate physical routes) is hard to achieve with wired connections alone. Some providers offer “diverse routing” options for an extra fee, but you have to ask—and verify.

The Real Gold Standard: BGP Multi-Homing

For seamless redundancy—both outbound and inbound, with the same public IP addresses working through either path—you need BGP (Border Gateway Protocol). BGP is like the internet’s traffic director: it lets your organization announce your public IP block to multiple ISPs. If one path fails, internet routers worldwide quickly learn to send traffic the other way, often in seconds.

The catch? BGP is advanced, enterprise-level setup:

• You typically need your own public Autonomous System Number (ASN) and a block of public IPs (at least a /24 subnet).
• Both ISPs must agree to peer with you.
• It requires capable routers and careful configuration to avoid mistakes.
• It’s costly and complex—usually overkill for schools and mid-sized businesses.

So What Should You Actually Do?

1. Start with a proper multi-WAN firewall and set up monitored failover plus load balancing. This covers most day-to-day outages.
2. Ask about physical diversity. When buying the second connection, specifically request confirmation that the last-mile paths are diverse (different conduits, poles, or entry points). Some providers can provide this; others can’t.
3. Mix connection types for better odds. Pair fiber with fixed wireless, cable, or cellular backup. Wireless avoids buried cables entirely, so a fiber cut won’t affect it.
4. For critical inbound services, use DNS failover tools (like those from Cloudflare or similar) or a hosted load balancer that can switch between both public IPs.
5. Consider managed SD-WAN or “blended internet” services. These intelligently combine multiple carriers and often handle path selection automatically.
6. Test regularly. Every quarter, simulate a failure (unplug the primary or ask the ISP to simulate an outage) and see what really happens. You’ll spot surprises fast.
7. Document everything. Make sure your IT person (or managed service provider) knows the setup and what fails when.

Bottom Line

A second internet connection remains one of the smartest moves you can make for uptime. But redundancy isn’t just buying another line—it’s ensuring traffic actually moves when needed, and that a single shovel doesn’t kill both paths.

Do it thoughtfully—with real failover configured, path diversity where possible, and regular testing—and you’ll stay connected when it counts most. Do it halfway, and you might find “we have two connections” doesn’t mean “we’re always online.”