BLOG ARTICLE • 9 OCTOBER 2026 • SUGGESTED READING TIME: 7–9 MINUTES
A branch office has two internet connections. One comes from the primary internet service provider (ISP). The other acts as a backup.
It sounds reliable. But when the main connection fails, employees may still lose access to cloud applications, email, video meetings and business systems.
The problem is not always the internet connection itself. The backup may be configured incorrectly, the firewall may not detect the failure, or traffic may not switch to the working link.
This guide explains how to troubleshoot dual ISP failover, identify common configuration problems and test whether your branch office can stay online when one internet link fails.
Quick Answer: Why Does Internet Failover Sometimes Fail?
A backup internet connection may not work as expected because of:
- Incorrect firewall or router settings.
- A health check that does not detect the actual failure.
- Incorrect routing or gateway settings.
- An inactive backup link or expired ISP service.
- VPN tunnels that do not reconnect.
- DNS problems or blocked traffic.
- Incorrect public IP or NAT settings.
- A failover setup that has never been tested.
The right approach is to check the failure, confirm the device detects it, and verify that traffic moves to the backup connection.
1. Two Internet Connections Do Not Guarantee Continuity
Consider a branch office with 80 employees. Its primary ISP provides a fibre connection, while the secondary ISP provides another broadband or fibre connection.
Both links appear active during normal working hours. Employees can browse websites, access Microsoft 365 and join online meetings.
One morning, the primary connection fails.
The firewall still shows the physical interface as active. However, the ISP has a problem farther along its network. The firewall continues sending traffic through the failed path, and employees lose access to business applications.
This happens because an active interface does not always mean the internet is reachable.
A reliable setup needs to check more than whether a cable is connected. It must confirm that the chosen internet path can carry traffic to the required destination.
2. Check Whether Both ISP Links Are Working
Start by checking the primary and backup connections separately.
Confirm that each ISP service is active and that the router or firewall receives the expected IP address and gateway.
Review the interface status, connection logs and error counters. Where available, check packet loss and latency to a reliable external destination.
Use this checklist:
- Confirm that both ISP services are active.
- Check the IP address and gateway on each WAN interface.
- Look for interface errors or repeated disconnections.
- Verify that the backup connection can access the internet.
- Confirm that the firewall’s monitoring system can reach its test destination.
Do not assume the backup works simply because its interface status shows up.
If the secondary link has not been tested independently, it may have a service issue of its own.
3. Review the Failover and Routing Settings
The firewall or router needs a clear rule for choosing the internet path.
In many networks, the primary ISP has a higher routing preference. The secondary ISP takes over when the primary path becomes unavailable.
The device must know when to stop using the main path and when to restore it.
Review the default configuration and compare it with the intended design. Check the default route, route priority, health-check settings and rules that select the active WAN connection.
Look for these common issues:
- The backup route has the wrong priority.
- Both routes are active when only one should be preferred.
- The default route remains pointed at the failed gateway.
- The firewall detects an interface failure but not an upstream outage.
- A recent configuration change has altered route selection.
A configuration can look correct at first glance but still fail during a real outage.
Document the intended routing behaviour so the team knows which ISP should carry traffic under normal conditions and which one should take over during a failure.
4. Use Health Checks to Detect Real Failures
A firewall needs a way to determine whether an ISP path is usable.
Some devices monitor the physical interface. More complete setups can also test connectivity to an external IP address or another reliable destination.
For example, a WAN port may remain active even when the ISP has lost upstream connectivity. A basic interface check may not detect this problem.
The health check should test a destination that helps confirm the internet path is working. Where supported, use more than one suitable target to reduce the risk of treating a single destination failure as a complete ISP outage.
Review:
- The destination used for monitoring.
- The monitoring interval and failure threshold.
- The recovery threshold before switching back.
- Whether the test uses the correct WAN connection.
- Logs showing when the device declares a link failed or restored.
Avoid setting health checks so aggressively that brief packet loss causes repeated switching. Also avoid thresholds so relaxed that users remain offline for too long.
5. When Should You Use IP SLA?
IP SLA is a Cisco technology that can measure network performance and check reachability. It can help a router detect when a route is no longer usable.
For example, a Cisco router may use an IP SLA operation to test an external destination through the primary ISP. If the test fails and the tracking configuration responds to that failure, the router can remove or change the preferred route and use the backup path.
A typical design may include:
- An IP SLA probe that checks a reachable destination.
- A tracking object that monitors the probe result.
- A route linked to that tracking object.
- A backup route that becomes the preferred available path when the primary route is withdrawn.
The exact configuration depends on the router model, software version and network design.
IP SLA is not a universal requirement. Other firewalls and routers have their own WAN health-check and failover features.
The important point is that the routing decision should reflect actual path availability, not just the status of a physical port.
6. Check NAT, Public IP Addresses and VPN Connections
Internet access may return after failover, but some applications may still fail.
This can happen when the two ISPs use different public IP addresses. Existing sessions may depend on the address assigned to the primary link. When traffic moves to the backup, those sessions may break.
Check the following areas:
NAT and firewall policies: Confirm that outbound traffic can use the secondary ISP and that the required rules apply to that WAN interface.
Public IP dependencies: Review services that allow access only from a fixed public IP address. The backup ISP may use a different address that the remote service does not recognise.
Site-to-site VPNs: Confirm that VPN tunnels can establish over the secondary connection. Check peer addresses, tunnel monitoring and route changes.
Remote access: Verify whether employees who connect through a VPN can still reach internal systems after failover.
DNS: Check whether devices can resolve domain names. A working internet route does not guarantee that DNS requests will succeed.
Do not treat a successful website test as proof that every business application has recovered. Test the services employees actually use.
7. Confirm That the Backup Link Has Enough Capacity
A backup ISP may keep the office online but still provide a poor experience.
For example, the primary link may provide 300 Mbps while the secondary offers only 50 Mbps. If many employees switch to the backup at once, cloud applications and video calls may slow down.
Check the backup link’s capacity against essential business needs.
Prioritise critical services if the network design supports it. These might include business applications, voice calls, remote access and essential cloud services.
Also review any traffic limits, fair-use policies or restrictions attached to the backup service.
For related troubleshooting, see our guide on why cloud applications can be slow even when speed tests look good.
8. Test Failover Before an Emergency
A failover setup is not proven until the team tests it.
Plan a controlled test during an approved maintenance window. Notify affected users and confirm that the team can restore the original configuration if something goes wrong.
Use this checklist:
- Record the current routing and firewall settings.
- Confirm that both ISP links work independently.
- Start continuous monitoring of important destinations.
- Simulate the agreed failure using a safe, approved method.
- Check whether the device detects the outage.
- Confirm that traffic moves to the backup ISP.
- Test websites, DNS, VPNs and key business applications.
- Measure how long recovery takes.
- Restore the primary path and confirm that normal routing returns.
- Record the results and any changes required.
Do not disconnect cables or change live routing without approval. Follow the device manufacturer’s procedure and your organisation’s change-management process.
A successful test should confirm more than a route change. It should show that users can access the services they need.
9. Document the Network and Review Changes
Small, undocumented changes can create major problems during an outage.
A new firewall rule, a changed route priority or an expired ISP service can affect failover behaviour.
Keep a simple record of:
- ISP names, service details and support contacts.
- WAN addresses and gateways.
- Primary and backup route preferences.
- Health-check destinations and thresholds.
- NAT, firewall and VPN dependencies.
- Failover test dates and results.
- Recent configuration changes.
If the office also experiences slow wireless access or intermittent local network issues, review our guides to diagnosing slow office Wi-Fi and random office network problems involving DHCP and IP conflicts.
Good records help IT teams find the cause faster and reduce the risk of repeating the same fault.
10. When Should You Request a Network Assessment?
Consider a structured assessment if the backup link repeatedly fails, users lose VPN access during failover, or the team cannot explain why traffic stays on a failed route.
An assessment should review the ISP links, routing design, firewall policies, health checks, VPN dependencies and recovery process.
It should also establish how quickly the office needs to recover and which services must remain available.
FineITServ helps businesses review network infrastructure, investigate connection problems and identify practical improvements. Recommendations should follow the evidence rather than assume that another internet connection or a hardware upgrade is always necessary.
Learn more about our professional IT services in Bangalore.
Frequently Asked Questions
What is dual ISP failover?
Dual ISP failover uses two internet service providers or internet connections. When the preferred connection becomes unavailable, a router or firewall switches traffic to the backup path according to its configuration.
Why does the backup ISP not take over automatically?
The device may not detect the failure, the backup route may be incorrect, or the health check may monitor only the physical interface. Routing, firewall or NAT settings can also prevent traffic from switching successfully.
What is the difference between load balancing and failover?
Failover moves traffic to another available connection when the preferred path fails. Load balancing distributes traffic across multiple connections according to the device’s rules. Some networks support both, but they require different configuration and testing.
Does IP SLA work with every firewall?
No. IP SLA is associated with Cisco networking equipment. Other vendors provide their own monitoring and failover tools. Always check the capabilities of the specific device.
How often should a business test failover?
Test it after major network changes and at regular intervals based on business needs. The schedule should account for how critical the connection is and how quickly the office must recover.
Will failover keep every application connected?
Not necessarily. Existing sessions may break when the public IP address changes. VPNs, remote services and applications with fixed-IP restrictions may need additional configuration. Test critical applications during a controlled failover exercise.
Final Thoughts
Two ISP connections provide a useful backup only when the network can detect failures and move traffic correctly.
Check the health-monitoring rules, routing, firewall policies, NAT and VPN behaviour. Then test the full recovery process under controlled conditions.
If your branch office keeps losing internet access even with two ISP links, contact FineITServ for a practical network assessment. A structured review can help identify the cause and define the next steps.