Dual ISP Setup for Offices: Failover, Load Balancing and Testing

By Yogesh Sagale | APYS Projects

When the office internet goes down, everything stops. VoIP calls drop, cloud apps freeze, the VPN disconnects and the phones start ringing. A single ISP link is a single point of failure, however good the provider. Fibre gets cut by roadworks, last-mile equipment fails, and maintenance windows overrun.

A properly designed dual ISP setup reduces dependence on one provider, but only if it is designed and tested properly. Plugging two cables into a router does not make a resilient network. This guide covers how to plan it, configure failover and load balancing, handle the awkward parts (inbound services, VPNs, email), and prove it works before you depend on it.

Failover vs. Load Balancing vs. Bonding

These terms are often mixed up, and they solve different problems.

Key point: ordinary load balancing does not make a single download twice as fast. A 500 Mbps link plus a 300 Mbps link gives a nominal combined downlink capacity of 800 Mbps across suitable simultaneous flows, before overhead, contention and device limits, but one file transfer still runs over one link at that link’s speed.

Part 1: Planning the Design

Choose ISPs for real diversity

Two contracts are not the same as two independent paths. Ask these questions:

• Different last-mile technology? Different access technologies can reduce some common failures, but verified route and upstream diversity matter more than the provider names or technology labels alone.
• Different physical route into the building? Two fibres in the same duct are cut by the same digger.
• Different upstream providers? Many “different” ISPs resell the same wholesale network. If the upstream fails, both fail.
• Different power and equipment? Each ISP’s terminating device should have its own power socket, ideally on UPS.
• Are the SLAs meaningful? A business-grade line with a repair-time commitment is different from a consumer line with best-effort support.

For a lower-cost second path, a 4G/5G backup is a sensible choice. It avoids your wired last-mile path, but may share tower power, fiber backhaul, upstream networks or congestion with your primary provider. Check signal, busy-hour performance, data allowance and CGNAT.

Pick the right hardware

You need a device that can handle two WAN connections intelligently:

• Dual-WAN business router or firewall from vendors such as Fortinet, Palo Alto, Sophos, Ubiquiti, MikroTik, Cisco Meraki or Peplink, or open-source options such as pfSense and OPNsense.
• At least two WAN ports (or one port plus VLAN tagging, which is less ideal).
• Health-check probing, policy routing, and per-WAN NAT.
• Enough throughput with firewall, VPN and inspection features turned on. Datasheet figures often assume no inspection.
• Optional: a second firewall in an HA pair, so the firewall itself is not the new single point of failure.

Typical topology

Concept topology: ISP A → ONT → WAN1, and ISP B → CPE → WAN2. Both WANs terminate on the dual-WAN firewall, followed by the core switch and the office VLANs / WiFi.

If you add a pair of firewalls for HA, connect each ISP to a small switch or VLAN first so both firewalls can reach both providers.

Part 2: Addressing and Basic Configuration

Information to collect from each ISP

• WAN IP type: static, DHCP or PPPoE
• IP address, subnet mask, gateway
• DNS servers
• Whether the connection is CGNAT (carrier-grade NAT, no public IP of your own)
• Whether the ISP provides its own router and whether it can run in bridge mode

Avoid double NAT

If the ISP gives you a router, use supported bridge mode or genuine IP passthrough where available and suitable. A DMZ host setting generally forwards unsolicited inbound traffic but does not remove NAT or guarantee that the firewall receives a public IP. Double NAT does not break every application, but complicates inbound access and some VPN arrangements. Document the actual design.

Set up routing basics

Each WAN gets its own gateway. The device then needs rules for which gateway to use:

• A default route with metrics (primary lower metric, backup higher), for simple failover.
• Equal-cost or weighted routes, for load balancing.
• Policy routes that match source, destination or application and select a gateway.

For ordinary private-IPv4 LAN internet access, configure source NAT for each WAN using the appropriate interface address or the provider-authorized public address. Routed public subnets and IPv6 require their own design rather than blanket masquerading. Do not assume ISP B is authorised to carry ISP A’s source addresses. Provider filtering and return routing can prevent that traffic from working; use the provider-approved addressing and NAT design.

Part 3: Configuring Failover

Why link-state alone is not enough

A basic failover triggers when the cable is unplugged and the interface goes down. Another important outage is different: the link stays up while the internet is dead. The modem still shows a light, the ISP gateway still answers, but something upstream is broken. If your router only watches the interface state, it never fails over.

Use health checks (probes)

Configure the router to test actual reachability:

• Probe more than the ISP gateway. The gateway can answer while the rest of the network is down.
• Use two or three external targets, such as well-known public DNS servers, and treat the link as down only when all (or most) fail. A single target going offline should not trigger a failover.
• Use more than ICMP where possible. DNS queries or HTTP/TCP checks catch problems that ping misses.
• Send probes out of the specific WAN interface, not through the default route.

Tune the timers

The timer values above are illustrative starting points, not settings supported by every platform. Detection depends on probe timeout, scheduling, loss windows and failure logic; interval × threshold alone is only a simplified estimate. For example, 3 s × 4 suggests about 12 seconds in a simple consecutive-miss model. Faster detection means more risk of false alarms, so balance it against how sensitive your applications are.

Decide on failback behaviour

When the primary returns, you can:

• Fail back automatically after a stability delay. This is normal.
• Stay on the backup until an operator approves failback when the primary is unstable or a controlled return is required. For a metered backup, remaining there increases costs; plan alerts and a prompt, stable return. Decide whether existing sessions remain on backup while new sessions return to primary.

What users will notice

On failover, the public source IP changes. That means:

• Existing TCP sessions drop and must reconnect. Web pages reload, downloads restart, and some apps log in again.
• VoIP calls in progress can drop, and the recovery time for new calls must be measured.
• VPN tunnels rebuild on the new link.

This is normal for standard dual-WAN. If existing sessions must survive, validate an explicitly session-preserving overlay or aggregation design, or application mobility mechanism. The label SD-WAN alone does not guarantee continuity. A stable cloud egress address can help but tunnel behavior, state, packet loss and application tolerance still need testing.

Part 4: Configuring Load Balancing

Common methods

Sticky sessions matter

Many websites and banking apps tie a login session to the client’s public IP. If one session’s requests come out of different WANs, the server sees the IP change and may log the user out. Use session persistence (keep a client’s connections on the same WAN for a period) for these cases.

Practical policy examples

• VoIP and video calls: pin to the lower-latency, more stable link, with the other as backup.
• Guest Wi-Fi: send out the cheaper or secondary link with bandwidth and firewall limits. Shared firewall, switches, AP airtime and a common failover link can still let guest load affect staff unless these resources are managed.
• Cloud backups and large uploads: send over the link with spare upload capacity, and rate-limit them.
• Site-to-site VPN: pin to one WAN, with automatic failover to the other.

Don’t forget upload

Offices often forget that asymmetric links have small upload speeds. Video calls and cloud backups are upload heavy, so size and balance for upload as well as download.

Part 5: The Hard Part, Inbound Services

Outbound failover is easy. Inbound is where most dual-ISP projects fall short, because each ISP gives you a different public IP. If your mail server, web server, VPN or camera system is reachable at 203.0.113.10 on ISP A, it is not automatically reachable on ISP B.

Options for inbound resilience

1. DNS-based failover

Use an authoritative DNS or traffic-management service that health-checks endpoints and returns healthy destinations. Choose a supported low TTL, such as 60–300 seconds where the provider allows it, and validate both paths before enabling failover. Plain round-robin with two A records is not failover. Clients may still receive and attempt the dead endpoint; behavior is not a guaranteed 50/50 split. Recovery also depends on health-check timing, existing cached answers, client retries and how the application resolves names; a low TTL is not an end-to-end recovery guarantee.

2. Move the service out of the office

Host public-facing services in the cloud or a data centre. The office link then affects only internal users.

3. Reverse proxy or tunnel service

A cloud-hosted proxy or outbound tunnel (the office device makes outbound connections over whichever WAN works) gives users a single stable address, and an outbound tunnel can work without an office public IP. A conventional reverse proxy reaching the office directly still needs a reachable origin. Check protocol support, identity controls, traffic limits and the cloud dependency.

4. BGP with your own ASN and provider-independent IP space

This is an advanced routing option for suitably sized organisations. Your own IP block is advertised through both ISPs, and traffic follows whichever path is alive. It requires an ASN, an IP allocation, ISP cooperation and BGP skills, so it is rarely worth it for a small office.

5. SD-WAN or aggregation service

Some aggregation or overlay services carry traffic through a remote gateway with a stable egress address. Other SD-WAN deployments only choose a local WAN and still change the public address. Confirm the actual product capability, licensing and failure behavior.

Email and reputation

If the office sends mail directly, outbound email will come from a different IP after failover. This can break:

• SPF: include both ISPs’ public IPs, or relay through a fixed smarthost.
• Reverse DNS (PTR): most mail receivers check it. A backup ISP with a generic PTR can get your mail flagged.

An authenticated mail provider or relay can give mail a stable sending identity, while the office still needs working connectivity and permission to reach that service over the backup path.

VPNs

• Site-to-site VPNs: configure the remote peer with both of your WAN IPs (primary and secondary peer), or use dynamic DNS names with health-checked failover. Enable dead peer detection so the tunnel rebuilds quickly.
• Remote-access VPN: publish a hostname (not an IP) and use health-checked DNS, or terminate the VPN in the cloud.

The CGNAT trap

Many 4G/5G and some cable or fibre providers use CGNAT: the WAN address is private, shared with other customers. Outbound traffic works fine, so it can serve as an outbound backup, but ordinary unsolicited inbound IPv4 connections will not reach your firewall through local port forwarding alone. An outbound tunnel, a provider-supported mapping service, or suitable public IPv6 may offer different options; assess them separately. Ask the ISP whether you can get a public static IP (often an extra charge).

Part 6: Supporting Details

Power

A shared power strip, UPS, circuit or core device remains a common failure point even with two ISPs. Put both ISP devices, the firewall and the core switch on a UPS, and consider separate circuits. Ask each provider about upstream power resilience and record what has actually been confirmed; a local UPS does not protect a street cabinet or a mobile tower.

DNS

Configure DHCP to hand out DNS servers that are reachable via either link. If clients use only the primary ISP’s DNS servers, internal users will see “no internet” on failover even though routing works. Use an approved DNS design that remains reachable over either WAN. Preserve internal domains, directory-service resolution and split DNS; replacing corporate DNS with public resolvers can break those services. Test the firewall’s own DNS and client DNS separately.

QoS and bandwidth during failover

If the backup link is slower (or capped, like 5G), the office may not be able to run everything on it. Prepare a degraded-mode policy:

• Prioritise VoIP, video conferencing, ERP, and payment systems.
• Throttle or block backups, large updates, streaming and guest traffic.
• Apply the policy automatically when the backup becomes active.

Metered links

If the backup is a data-capped mobile link, alert on usage and block heavy background traffic (OS updates, cloud sync) while it is in use.

Security

A second link is a second attack surface. Apply the same firewall policies, management restrictions, and logging to both WANs. Don’t expose management interfaces on either one.

Part 7: Testing, Do Not Skip This

Untested failover is a hope, not a design. Many offices discover on the day of a real outage that failover never worked. Test before going live, after relevant changes, and on a business-approved schedule. A quarterly cycle is an example planning choice, not a universal requirement.

Prepare

• Schedule a maintenance window and tell staff.
• Document the current configuration and take a backup.
• Have console or out-of-band access to the firewall in case you lock yourself out.
• Prepare tools: a laptop, a continuous ping, a speed test, a way to see the public IP, and a test VoIP call.

Test scenarios

Application-level checks during each failover

• A continuous ping to an external address: how many packets are lost?
• A VoIP call: does it drop, and how soon can a new call connect?
• VPN tunnel: does it re-establish, and how long does it take?
• Cloud apps (email, file sharing, ERP): do users need to re-login?
• Inbound services: can you reach them from outside through the backup path (or through DNS failover)?
• Public IP check: confirm the source IP switches to the other ISP.
• Email: send a test message and check SPF and headers.
• Load balancing: run several simultaneous downloads and confirm traffic appears on both WANs in the firewall’s interface graphs.

Measure and record

Write down for each test:

• Detection time: how long until the outage was recognised.
• Recovery time: how long until traffic flowed again.
• Packets lost and sessions dropped.
• Failback behaviour.

Compare these with business expectations. If the office needs failover in under 10 seconds and yours takes 45, tune the timers or consider SD-WAN.

Example results log (hypothetical, not APYS measurements)

Part 8: Monitoring and Alerting

A failover that happens silently can run on the backup for weeks, until the backup fails too. Set up:

• Alerts on WAN status changes (email, SMS or chat).
• Latency, jitter and packet loss graphs per link (SNMP, NetFlow or the vendor dashboard).
• Bandwidth utilisation per WAN, to spot saturation and verify balancing.
• Metered-data alerts for 4G/5G backups.
• External monitoring (a probe from outside) so you know when each public IP is unreachable.
• Log retention for failover events, which helps in ISP disputes and SLA claims.

Common Mistakes

1. Both ISPs sharing the same physical path or upstream. Redundant on paper only.

2. Relying on link state only. The modem light stays on while the internet is dead.

3. Probing only the ISP gateway. The gateway answers while the rest of the path is broken.

4. Aggressive timers. Constant flapping creates more disruption than the outage.

5. Forgetting inbound services. Outbound works, but the web server, VPN or mail goes dark.

6. Double NAT from ISP routers left in router mode.

7. No UPS, or both modems on one power strip.

8. Backup link too slow for essentials, and no degraded-mode policy.

9. Using per-packet balancing without an aggregation service.

10. Never testing, or testing only once at install.

11. Ignoring CGNAT on the backup link.

12. No alerts, so the backup runs unnoticed.

Quick Decision Guide

Deployment Checklist

• [ ] ISPs chosen for physical and upstream diversity
• [ ] Dual-WAN capable firewall sized for throughput with security features on
• [ ] ISP handoff and bridge/passthrough/NAT behavior documented
• [ ] CGNAT status checked for each link
• [ ] Per-WAN source NAT configured
• [ ] Health checks use multiple external targets, not just the gateway
• [ ] Timers tuned (interval, failure, recovery, failback delay)
• [ ] Load-balancing method and weights chosen, with session persistence
• [ ] VoIP and critical traffic policies defined
• [ ] Inbound services handled (DNS failover, cloud, proxy, or BGP)
• [ ] VPN peers configured for both WANs with dead peer detection
• [ ] SPF/PTR checked for email, or mail relayed via fixed smarthost
• [ ] DNS reachable from both links
• [ ] Degraded-mode QoS ready for the backup link
• [ ] All ISP and network equipment on UPS
• [ ] Full test plan executed and results recorded
• [ ] Monitoring and alerts live
• [ ] Documentation updated, with a retest schedule

Conclusion

A dual ISP setup protects an office from one of the most common and costly failures, but only when three things line up: genuinely independent links, health checks that detect real outages, and a tested plan for the things that change when the public IP changes, such as VPNs, inbound services and email.

Start by deciding what you actually need: simple failover, balanced bandwidth, or session-preserving resilience. Build the design around that, then test it by breaking it on purpose. The best time to discover a flaw in your failover is during a planned Saturday maintenance window, not during a real outage on a Monday morning.

IPv6 Needs Its Own Failover Design

Do not assume IPv4 NAT failover automatically covers IPv6. Each provider may delegate a different prefix. Clients can keep addresses and DNS records associated with the failed path. Plan router advertisements, prefix lifetimes, source-address selection, firewall policy and DNS behavior, then test IPv4-only, IPv6-only and dual-stack applications. A working IPv4 speed test does not prove IPv6 resilience.

Worked Example: Choosing the Degraded Mode

Assume a primary connection has 300 Mbps download and 100 Mbps upload, while measured busy-hour backup performance is 50/10 Mbps. The office cannot treat the backup as an equivalent replacement. Estimate concurrent conferencing and business application needs from actual vendor guidance and observations. Reserve capacity for essential traffic, pause scheduled backups and software downloads, and limit guest access. Set shaping below the measured bottleneck where needed to control queueing. These figures are illustrative, not a guaranteed mobile service rate or an APYS measurement.

Separate Detection From Application Recovery

A 3-second probe interval with four failed checks suggests a detection window near 12 seconds, but probe timeouts, scheduling and quorum logic change the result. Gateway removal, NAT-state cleanup, DNS lookup, application retries and VPN negotiation add further time. Define acceptance per application: recognition time, a new HTTPS request, a new call, restored VPN traffic and inbound availability. Record session losses separately; a fast WAN status change does not prove business recovery.

Worked backup bandwidth and data-budget example

Suppose the agreed busy-hour backup measurement is 50 Mbps down and 10 Mbps up. For this invented planning example, reserve only 8 Mbps of the measured upload for scheduled application demand, leaving 2 Mbps uncommitted. This 80% planning choice is not a universal QoS setting; actual shaping and queue design must follow repeated measurements and platform guidance.

The decision is to pause or explicitly limit the backup job during failover, not to assume “priority” creates bandwidth. The per-application rates above are assumptions for demonstrating arithmetic; replace them with current vendor guidance and observations for the chosen codecs, meeting modes and concurrency. Check download, packet rate, latency under load, firewall inspection and WiFi capacity separately. A mobile link may fall below the measurement later.

Metered-link calculation: a sustained aggregate 8 Mbps transfer for two hours is 8 × 7200 ÷ 8 = 7200 MB, or 7.2 decimal GB. This is a payload-rate planning calculation; billable totals may include additional traffic and protocol overhead. A 20 GB allowance would cover about 5.56 hours at that constant rate before those additions, not an assured working-day runtime. Configure usage alerts and an agreed cap policy; do not estimate mobile-data cost from a one-minute speed test.

Example recovery record: distinguish route recovery from a usable service

The following event times are invented to demonstrate the method, not APYS test results:

If the agreed application recovery target is 20 seconds, this hypothetical VPN result fails by 12 seconds even though outbound HTTPS passed earlier. Record the disposition, configuration change and retest. Keep existing-call survival, new-call setup and new-web-request success as different acceptance criteria.

Job-sheet fields and rollback gate

Before a maintenance-window test, save the approved configuration and record the restoration method and local/console access. Record ISP identifiers and verified diversity, handoff/NAT/public-IP status, IPv4 and IPv6 behavior, firewall firmware and licences, probe target/protocol/interface, gateway policy, source NAT, DNS mode, application priorities, backup cap, expected failure behavior, test owner and rollback condition. Keep credentials out of the public report.

For each scenario record T0, detection, new-flow recovery, application transaction recovery, existing-session losses, observed public egress, logs, failback outcome and pass/fail against the agreed requirement. A failed test remains open until corrected and repeated. Alert delivery must also be tested over the surviving path; merely configuring an email address does not prove delivery during an outage.

Editorial review: 28 October 2026. Numerical schedules and result logs are illustrative. Vendor-specific configuration and real-site acceptance require the actual platform and recorded tests.

Related planning: PoE power budgets, structured cabling, and scope an APYS network assessment.

Vendor Documentation

• Netgate multi-WAN concepts: https://docs.netgate.com/pfsense/en/latest/multiwan/concepts.html
• Netgate load balancing and failover: https://docs.netgate.com/pfsense/en/latest/multiwan/load-balance-and-failover.html
• Netgate IPsec in multi-WAN environments: https://docs.netgate.com/pfsense/en/latest/multiwan/ipsec.html
• Netgate interface and DNS configuration: https://docs.netgate.com/pfsense/en/latest/multiwan/interfaces-and-dns.html

Need a Dual ISP Assessment?

APYS Projects supports office networking, firewall configuration, WiFi, structured cabling and documented network handover. Share your ISP handoff details, firewall model, required applications and acceptable recovery times for a scoped assessment. Request a quotation: Contact APYS Projects