Business continuity through resilient WAN design
FortiGate Internet Failover Solution in Dubai, UAE
When internet access carries cloud applications, payment traffic, voice, VPN sessions and everyday business communication, a single ISP path can become an avoidable point of operational disruption. A properly designed FortiGate failover setup can monitor more than one WAN path, identify when a preferred route is no longer usable, and move eligible traffic to an alternate connection according to defined routing or SD-WAN rules.
Direct answer: what is FortiGate internet failover?
FortiGate internet failover is a network design that uses two or more WAN connections and defined health, routing and policy logic so traffic can move away from a failed or unacceptable path. It is mainly used to reduce the business impact of an ISP outage, upstream routing problem or degraded circuit. Organisations that depend on SaaS, cloud ERP, payment systems, remote access, VoIP, site-to-site VPN or continuous branch connectivity should consider it. Before proceeding, a buyer should confirm the FortiGate model, FortiOS version, link types, public addressing, application priorities, inbound service requirements, VPN design and whether a secondary firewall is also needed for device-level resilience.
What the solution does
The practical job of the solution is to stop treating internet access as a single-path dependency. The FortiGate can use health monitoring to determine whether a WAN path is usable and routing logic to select an alternate member when required. In an SD-WAN design, Performance SLA checks can monitor path quality using criteria such as latency, jitter and packet loss as well as basic reachability. In a simpler primary-and-backup design, route distance, priority and link-monitor behaviour may be used to favour one circuit and withdraw or de-prioritise it when a health condition fails.
The design must be tailored to the actual traffic. Internet browsing may fail over cleanly while an existing session tied to a public IP can reset. Inbound NAT, externally published services, IPsec peers, voice platforms and provider-specific addressing can require additional planning. Failover should therefore be designed around applications and dependencies, not just around whether a cable is physically connected.
Who should consider it
The solution is appropriate for organisations where internet interruption creates measurable operational inconvenience or risk. A branch using cloud accounting, a clinic accessing hosted applications, a warehouse dependent on ERP, a retail site using central systems, a hotel relying on online services, or a professional office using Microsoft 365 and cloud telephony can all have different reasons for introducing a second WAN connection.
It is also useful for multi-site organisations that want consistent WAN behaviour across branches. However, it is not automatically justified for every office. A secondary circuit has recurring cost, and useful resilience depends on path diversity. Two links that share the same last-mile provider infrastructure may not provide the independence a buyer expects. The business should compare outage impact, link cost, required recovery behaviour and operational complexity before choosing the design.
Business problems a failover design helps address
Primary ISP interruption
A preferred circuit can fail because of local access problems, upstream faults, planned maintenance or provider routing issues. A secondary path gives the firewall another route to use when monitoring determines that the primary path is not healthy.
Degraded application experience
A circuit can remain technically up while latency, jitter or packet loss becomes unacceptable. SD-WAN health checks can provide a basis for steering selected traffic according to defined performance targets rather than link state alone.
Overdependence on one carrier
Using more than one provider or access technology can reduce dependence on a single service path. The real value depends on the physical and logical diversity of those connections, which should be discussed with the carriers.
Manual recovery effort
Without planned failover, staff may need to change gateways, reconnect equipment or wait for an engineer during an outage. Automated policy and routing decisions can reduce the number of manual steps when the failure matches the configured conditions.
Core capabilities that shape the solution
Service-fit matrix
| Business situation | Relevant assistance | Scope dependency |
|---|---|---|
| One FortiGate, two ISP circuits, primary/backup requirement | WAN interface review, health monitoring, routing or SD-WAN failover, testing | ISP handoff, gateway method, public IPs, existing policies |
| Critical voice or cloud apps need path-quality decisions | SD-WAN rules, Performance SLA targets, application prioritisation | Application identification, latency/jitter tolerance, bandwidth |
| Published server or inbound VPN must survive ISP change | Inbound dependency review, NAT/VIP design, DNS or peer planning | Provider IP ranges, remote peer control, DNS design |
| Firewall hardware itself must not be a single point of failure | Separate high-availability assessment | Matching appliances, interfaces, licensing, switching and cabling design |
| Existing configuration is complex or poorly documented | Discovery, backup, policy and routing review before change | Administrative access, maintenance window, network documentation |
Buyer information and service scope
This is a solution and configuration topic rather than a single FortiGate model. Hardware performance, ports, subscriptions and feature availability vary by appliance and FortiOS release. The table therefore describes the information FourTeck normally needs to assess the engagement instead of inventing a blended specification.
| Topic | FortiGate Internet Failover Solution |
|---|---|
| Main purpose | Maintain an alternate internet path when a preferred WAN connection becomes failed or unsuitable according to configured health criteria. |
| Suitable environments | Single offices, branches, retail sites, warehouses, clinics, hospitality, education and multi-site business networks where internet interruption has operational impact. |
| Typical WAN choices | Two or more business broadband, leased internet, Ethernet, broadband, 4G/5G or other supported WAN handoffs; exact compatibility is model and carrier dependent. |
| Failover methods | FortiGate SD-WAN with health checks or traditional route/link-monitor design, selected according to requirements and existing configuration. |
| Assessment support | Available as a quotation scope after current topology, FortiGate model, ISP circuits and business requirements are reviewed. |
| Configuration support | Scope may include interfaces, SD-WAN members, health checks, routing, firewall policy, NAT, DNS considerations, VPN review and controlled testing. |
| Licensing | Model, FortiOS and subscription dependent. Required FortiCare or FortiGuard service coverage should be confirmed for the selected appliance and support requirement. |
| Remote or on-site coordination | Requirement dependent. Access method, site conditions and change window should be agreed in the quotation. |
| Availability guidance | Contact FourTeck to confirm current UAE hardware availability, service scheduling and any vendor lead time. |
| Customer inputs required | FortiGate model, firmware version, topology, WAN settings, public IP information, critical applications, VPN details, preferred behaviour and maintenance constraints. |
| Important note | Dual-WAN resilience does not automatically provide FortiGate appliance redundancy. High availability should be assessed separately when firewall hardware failure must also be covered. |
Dependencies that should be resolved before configuration
Failover behaviour is configuration dependent. The firewall can make routing decisions only with the information and health criteria provided to it. A physical interface can remain up even when internet access beyond the provider gateway has failed, which is why a meaningful monitoring target matters. At the same time, an aggressive health check or poorly selected probe destination can cause unwanted path changes. The design should consider multiple stable targets where appropriate and choose thresholds that match the business requirement.
Public IP addressing is another major dependency. Outbound sessions normally use source NAT appropriate to the active WAN. If the public address changes during failover, existing sessions may reset and third-party services that whitelist the primary public IP may reject the backup path. Inbound services can be more complex because remote users and systems must know how to reach the alternate address. DNS, external load balancing, provider routing or peer-side configuration may be required depending on the application.
FortiOS menu names and available options can vary between releases. Existing production devices may also contain policy routes, virtual domains, IPsec tunnels, VIPs, dynamic routing or central-management dependencies that change the implementation method. For that reason, FourTeck should review the actual device configuration before any migration or major routing change is included in a final scope.
A practical engagement journey
Discover
Document current WAN circuits, firewall model, routing, public services, VPNs and applications whose interruption matters most.
Design
Choose SD-WAN or route-based failover, define health tests, priorities, application behaviour, NAT and recovery logic.
Prepare
Back up the device, agree a maintenance window, confirm access, notify application owners and define a rollback point.
Implement
Configure approved settings and verify normal traffic, security policy, DNS, VPN and management access before failover testing.
Test and hand over
Simulate approved failure conditions, confirm expected path changes, document limitations and save the post-change configuration.
Health checks must represent real reachability
One of the most important design decisions is what the FortiGate should consider a healthy internet link. Checking only local Ethernet state does not prove that traffic can reach the internet. A modem, ONT or provider edge can remain connected while routing beyond it is impaired. FortiGate health monitoring can probe remote destinations so routing decisions reflect end-to-end path health more closely.
The monitoring design should avoid a single fragile dependency. If one probe target is temporarily unavailable while the ISP is otherwise healthy, an unnecessary failover could occur. Multiple stable targets and sensible thresholds may reduce false decisions, but the exact implementation depends on FortiOS capability and the network objective. Probe frequency should also balance detection speed with stability.
For businesses running real-time applications, simple up/down status may be insufficient. SD-WAN Performance SLA can measure latency, jitter and packet loss, allowing rules to use a path that better meets application requirements. This is useful when a line is technically available but performing poorly. The thresholds should be based on application needs rather than copied from a generic template.
Failback needs as much thought as failover
A design that switches to a backup circuit quickly but repeatedly returns to an unstable primary link can create more disruption than a slower, controlled recovery. Failback behaviour should consider how long the primary path must remain healthy before it becomes preferred again and whether some applications should stay on their current sessions until naturally re-established.
Businesses should also decide whether the backup link is intended only for emergencies or can carry normal traffic. A metered 5G connection may need strict backup-only behaviour, while two business internet circuits of similar capacity may be used actively with traffic steering. Those are different designs even though both contain two WAN links.
Testing should include restoration, not only failure. The team should verify that the preferred route returns as expected, monitoring returns to a healthy state, critical services can establish new sessions, and no stale route or policy behaviour remains. A documented failback test is particularly valuable after firmware changes or ISP replacements.
SD-WAN or traditional primary-and-backup routing?
Both approaches can be valid. A traditional design may use two default routes with different distance or priority values together with link monitoring so the preferred route is removed when the monitored path fails. This can be appropriate for a straightforward environment where one link is primary and the other exists only as standby. The main advantage is conceptual simplicity, especially in an established configuration where changing to SD-WAN would create unnecessary scope.
SD-WAN becomes attractive when the business wants more granular decisions. Multiple WAN members can be grouped into an SD-WAN zone, health checks can measure path quality, and rules can select links according to source, destination, application or service requirements. A voice application may prefer a low-jitter path while general browsing can use a different rule. This can turn a failover project into a broader WAN optimisation exercise, so the design should remain proportionate to the operational need.
An existing FortiGate should not be migrated to SD-WAN merely because the feature is available. Existing static routes, policy routes, VPNs, virtual IPs, management systems and remote branches should be reviewed first. FourTeck can help determine whether the requested outcome is better served by a minimal failover change or by a structured SD-WAN redesign.
Application continuity is not identical to path continuity
When the active WAN changes, many users expect every open application session to continue without interruption. That expectation is not always realistic. A connection on the primary ISP may have been translated to the primary public IP. When traffic moves to the backup ISP, new packets can use a different source address. Remote services may regard that as a new session, and encrypted or stateful applications may need to reconnect. The firewall can restore a route to the internet, but it cannot force every external service to preserve an existing session across a public-address change.
For this reason, the business should classify applications before configuration. Web browsing and many SaaS applications recover quickly because clients retry automatically. Voice calls may drop even though the softphone reconnects seconds later. Site-to-site VPN tunnels may need to renegotiate. Banking portals, third-party APIs or partner systems can be restricted to known source IP addresses, which means the backup public IP must be approved in advance. Hosted services need their own inbound failover plan.
The most useful acceptance test is therefore application based. Instead of only checking that a route changed, test DNS, cloud login, email, payment workflow, voice registration, VPN connectivity and any critical business process agreed in scope. This produces a more meaningful result than a simple successful ping.
Internet failover and FortiGate HA solve different failures
Two ISP circuits connected to one FortiGate protect against some WAN failures, but the firewall itself remains a single device. A hardware fault, power issue, failed interface, software problem or maintenance event on that appliance can still interrupt connectivity. FortiGate high availability uses multiple compatible appliances and a separate cluster design to address device-level resilience.
Some organisations need both: diverse WAN paths and a firewall HA pair. Others accept one firewall but want protection against the more common inconvenience of an ISP outage. The right choice depends on recovery objectives, budget, network topology, rack and power design, model compatibility and licensing. FourTeck can scope WAN failover independently or include an HA assessment when the business continuity requirement extends beyond the internet circuits.
Diversity matters more than the number of cables
A backup circuit provides greater resilience when it avoids the same failure domain as the primary. Two services from different providers can still share building entry points, ducts, local exchanges, upstream infrastructure or power dependencies. Likewise, two logical services delivered over one physical handoff do not provide the same protection as independent access paths.
Buyers should ask their carriers about last-mile diversity, handoff equipment, power requirements and provider routing. For a site where terrestrial paths are difficult to diversify, a cellular backup may offer a different access method, although signal quality, data allowance, CGNAT, public IP availability and modem compatibility then become important. FourTeck can configure the firewall side once the carrier characteristics and handoffs are clear.
Ideal business environments and use cases
Cloud-dependent offices
Teams using Microsoft 365, hosted ERP, cloud file services, online CRM and remote collaboration can lose productivity when a single internet circuit fails. A secondary path can restore access for new sessions while the primary issue is investigated.
Retail and payment locations
Stores may depend on central inventory, payment gateways, digital signage and remote support. The design should confirm whether payment providers or head-office systems restrict traffic by public IP before assuming automatic continuity.
Warehouses and logistics
Warehouse management, shipping portals, scanners and central ERP often rely on continuous WAN access. A backup carrier can reduce disruption, while application testing confirms which workflows reconnect automatically.
Branch networks
Branches that maintain IPsec connectivity to head office or cloud environments may benefit from alternate internet paths. Tunnel design, remote peer configuration and route preference must be reviewed so failover works at both ends.
Voice and contact operations
Cloud telephony is sensitive to delay, jitter and packet loss. SD-WAN health criteria can help select a more suitable path, but active calls may still reset during a public-path change and should be tested.
Sites with limited IT staff
Automated recovery can reduce the need for manual cable changes or emergency routing adjustments. Clear documentation and remote management access remain important so the team can diagnose which path failed and why.
Integration and operational considerations
A WAN failover change touches more than interface settings. Firewall policies must reference the correct zones or interfaces, source NAT must behave correctly on each path, and administrative access should remain available during a failure without exposing unnecessary services. If FortiAnalyzer, FortiManager, cloud management or external monitoring is used, the management path should also be tested through the backup circuit.
DNS can become an overlooked dependency. Internal users may reach the internet through the backup link, but hosted records, split-DNS behaviour or provider-specific resolvers can still fail. Publicly hosted applications may require DNS failover or another external mechanism because the FortiGate cannot control how internet users resolve the organisation’s public service unless the wider design supports it.
IPsec VPN needs careful review when peers are configured with fixed addresses. A branch that fails to a different public IP may need dial-up style design, secondary peer definitions, dynamic DNS or changes on the remote gateway. The correct method depends on both ends of the tunnel. SSL or remote-access behaviour can also differ if users connect to a public hostname that resolves only to the primary ISP address.
Finally, logging and alerting should make failover visible. Automatic recovery is useful, but silent recurring circuit failures can hide a provider problem and leave the business permanently operating on a lower-capacity or metered backup link. Monitoring should help the team identify path state, repeated transitions and unusual utilisation.
Buyer questions to resolve before ordering or scheduling work
ISP outage, degraded quality, firewall failure and building power loss are different failure domains. The scope should identify which ones matter.
Compare bandwidth, latency, data limits, public addressing and carrier restrictions with the applications that must continue.
Public-IP changes can affect VPN, voice, partner portals and stateful sessions. Decide what temporary interruption is acceptable.
If the need is basic primary/backup connectivity, a minimal design may be preferable. Application-aware steering adds value only when there is a real use case.
Published servers, remote-access gateways, cameras or APIs can require additional public DNS, NAT and provider-side planning.
If a FortiGate device failure must not stop the site, assess a compatible HA design separately from WAN redundancy.
Procurement and evaluation checklist
How FourTeck can assist with planning and configuration
FourTeck can help turn a general request for “backup internet” into a defined technical scope. The starting point is requirement clarification: which FortiGate is installed, which WAN circuits are available, what applications are critical and what kind of failure should trigger a path change. From there, the configuration approach can be matched to the existing network rather than applying a generic dual-WAN template.
Support can include reviewing the present routing and policy design, identifying whether SD-WAN is appropriate, defining health-check targets, mapping NAT and VPN dependencies, planning a change window and documenting a test sequence. For a new deployment, FourTeck can also help select a FortiGate appliance based on internet bandwidth, inspected traffic, interfaces, VPN requirements and future growth. Hardware and subscriptions are quoted separately according to the selected model and current availability.
Businesses that need wider firewall assistance can review FourTeck firewall services or compare relevant options through the FortiGate product area. For a broader Fortinet firewall purchasing discussion, the Fortinet firewall Dubai resource can support model-selection planning before the failover work is finalised.
UAE availability and support guidance
Contact FourTeck to confirm current UAE availability for any FortiGate appliance, LTE/5G accessory, subscription or related component required by the failover design. Availability may depend on the selected model, license term, quantity, region and vendor lead time. If an existing supported FortiGate has suitable interfaces and capacity, the requirement may be primarily a configuration engagement rather than a new hardware purchase; this should be confirmed after review.
Delivery and project coordination can be discussed after the exact requirement is established. Installation or configuration work should be explicitly included in the quotation when needed. FourTeck can also help identify whether the project requires new WAN cabling, an ISP handoff change, a supported cellular modem, additional switching, a FortiGate HA pair or only policy and routing changes. No deployment date or service visit should be assumed until access, equipment, technical scope and site readiness are agreed.
Dubai, Abu Dhabi, Sharjah and Ajman coverage
FourTeck can discuss FortiGate internet failover requirements for businesses operating across Dubai, Abu Dhabi, Sharjah and Ajman in one coordinated UAE engagement. A head office may need two fixed internet circuits and detailed SD-WAN rules, while a smaller branch may use one fixed line and a cellular backup. Multi-site organisations can benefit from using a common assessment checklist so every location documents ISP handoffs, public IPs, critical applications, VPN peers, change windows and support contacts in the same way. Remote or on-site assistance depends on the project scope, device access and location. Where several branches are involved, FourTeck can help separate site-specific details from the standard configuration principles so the quotation remains clear and the implementation can be planned in phases rather than treating every site as identical.
GCC Availability
Businesses operating across the Gulf often want the same WAN resilience principles applied to offices in more than one country. FourTeck can assist with requirement review, FortiGate model or license selection, quotation coordination, configuration scope, installation planning and renewal guidance for projects that may involve the United Arab Emirates, Saudi Arabia, Kuwait, Qatar, Bahrain or Oman. The technical design should still be assessed location by location because carrier handoffs, public IP options, available bandwidth, cellular services and local site conditions can differ even within the same organisation.
Product availability, licensing, delivery schedules, service visits, vendor lead times and project scope can vary by country, model, quantity and requirement. A regional buyer should provide the destination country, exact FortiGate model if already selected, number and type of WAN circuits, quantity of appliances, subscription term, deployment location and expected project window. FourTeck can then coordinate a more accurate commercial and technical discussion. Customers with requirements involving Kuwait can also review FourTeck Kuwait resources as part of wider regional planning.
Africa Availability
Organisations with procurement teams in the UAE and operating sites in Africa may also need consistent FortiGate failover design across different connectivity markets. FourTeck can help evaluate firewall models, subscriptions, accessories, WAN interfaces, deployment requirements, configuration scope, support expectations and renewal planning for projects where the final destination is in Africa. The backup-link strategy may differ significantly between a city office with two fibre providers and a remote site where cellular or another access technology is the practical alternative.
Availability and fulfilment can depend on destination, model, quantity, license region, power requirements, shipping arrangements, vendor lead time, installation scope and local project conditions. Buyers should share the destination country, exact requirement, quantities, preferred deployment schedule and any installation or support expectations before requesting a final quotation. For regional context, FourTeck maintains resources for Africa technology projects, while organisations with East African operations can also review FourTeck Kenya guidance. These references support planning but do not imply local stock or fixed delivery commitments.
Related FourTeck options to consider
FortiGate appliance sizing
If the current firewall lacks spare WAN interfaces, capacity or support coverage, model sizing should be completed before designing the final failover configuration.
FortiGate configuration service
Existing firewalls may need routing, policy, NAT, VPN and health-monitor changes rather than replacement. A review can define the safe change scope.
Fortinet platform guidance
Multi-branch environments may also require FortiManager, FortiAnalyzer, VPN, switching or wireless integration depending on the wider network strategy.
Why businesses contact FourTeck for this requirement
The value of assistance is in requirement clarification rather than a promise that one template suits every FortiGate. FourTeck can help identify the actual failure scenario, collect the technical details that affect the design, determine whether the current appliance is suitable and separate essential configuration from optional enhancements. This is particularly useful when the customer knows they need a backup connection but has not yet decided whether the network should use simple primary/secondary routing, SD-WAN application steering or a wider high-availability architecture.
For procurement teams, FourTeck can translate the technical discussion into quotation items: hardware if required, subscriptions, configuration, installation coordination, testing and any supporting components. For IT teams, the engagement can focus on dependencies such as public IPs, VPN peers, policy routes, NAT, monitoring targets and change windows. For project owners, the result is a clearer distinction between what can be automated by the FortiGate and what still depends on the carriers or external applications.
The goal is to reduce mismatched purchasing and incomplete scope. A failover project should finish with an understood operating model: which link is preferred, what triggers a change, which applications are expected to recover, what may require reconnection, how the primary path returns, and who should be contacted when monitoring shows a recurring provider issue.
What buyers commonly need to understand before designing failover
A common starting question is whether adding a second internet line is enough. It is only one part of the design. The FortiGate must know both paths, must have routing or SD-WAN rules that define preference, and must have a meaningful way to determine when a path should no longer be used. The network team also needs to understand what changes when the public source address moves from one provider to another. For an office whose main requirement is web access and cloud applications, that change may be relatively easy to tolerate. For a site hosting services or maintaining fixed-peer VPNs, more planning is required.
A backup link can have lower capacity, but the business should know what must be restricted when it is active. Large software updates, guest Wi-Fi, cloud backup or video streaming may need different policies so limited bandwidth is preserved for critical applications.
4G or 5G can provide path diversity, but signal strength, antenna placement, data plans, carrier NAT, fixed public IP availability and compatible modem hardware must be checked. It should not be treated as interchangeable with a leased circuit.
Very aggressive probe intervals may detect a fault quickly but can also react to brief packet loss. Thresholds should balance business recovery expectations with the need to avoid unnecessary switching.
Another frequent question is whether FortiGate automatically balances two internet links. It can be configured to use multiple links, but the desired behaviour must be defined. Some businesses want the second line completely idle until the first fails. Others want both circuits active and prefer different application classes on each. Still others want traffic to use whichever path currently meets a quality threshold. These designs use the same underlying idea of multiple WAN members but have different rule sets, testing requirements and operational consequences.
Buyers also ask what happens to VPN during failover. The answer depends on the VPN topology. If the remote peer expects the primary public IP only, a tunnel cannot simply move to an unrelated backup address without support on the other side. A design may need secondary peer configuration, dynamic addressing methods, route changes or a separate tunnel. If the VPN carries branch-to-head-office traffic, both sides should be tested together. The FortiGate can choose a path, but the peer must also accept and correctly route the alternate path.
For companies publishing an internal server, camera platform, remote desktop gateway or other inbound service, the key issue is how external users locate the service after ISP failover. Outbound failover is controlled locally because the FortiGate chooses where to send traffic. Inbound failover involves internet-side name resolution and addressing. A second Virtual IP alone does not make remote clients automatically discover the new address. The architecture may require public DNS changes, external health-based DNS, application-layer services or provider routing depending on how quickly the service must recover.
There is also a practical purchasing question: do you need a new firewall? Not necessarily. An existing FortiGate may already have suitable ports and support the required configuration. The decision should consider traffic volume on both circuits, security inspection load, VPN use, number of interfaces, FortiOS support, future bandwidth and whether the device has current support coverage. If the firewall is already near capacity, adding a second link can be the right time to review hardware sizing rather than creating a configuration that leaves no operational headroom.
Finally, buyers should plan for evidence after implementation. A good handover should include an updated configuration backup, a simple topology showing primary and backup paths, the health-check destinations, the expected failover condition, the failback logic and a record of the tests completed. That information helps future support engineers understand why the network behaves as it does. It also gives procurement and management teams a clearer basis for discussing carrier improvements, secondary-link upgrades or a later transition to firewall high availability.
Decision questions that shape the final design
How quickly should the network react to a failed ISP?
The fastest possible reaction is not always the best objective. Health probes require thresholds, failure counts and recovery logic. A site running transactional cloud systems may want quick detection, while a branch on variable wireless access may need more tolerance for brief loss. The correct values depend on circuit behaviour and application sensitivity. FourTeck can define and test thresholds as part of the configuration scope rather than assuming one universal timer.
Should all traffic use the backup link?
Not necessarily. If the secondary circuit is slower or metered, critical traffic can be prioritised while non-essential use is limited. The policy may also distinguish guest networks, software updates, cloud backup or media traffic from core business systems. This makes the failover state a deliberate operating mode rather than a simple copy of normal routing.
Can one provider gateway be used as the only health target?
It may prove the local circuit reaches the provider edge, but it may not detect a wider internet routing problem. A remote, stable monitoring destination usually gives a better view of end-to-end reachability. Multiple checks can improve confidence when configured correctly. The selection should avoid fragile or rate-limited destinations that could create false failovers.
Will the same public IP remain available after failover?
Usually not when two independent ISPs provide unrelated address ranges. Keeping one public prefix across multiple carriers requires a different provider and routing architecture. If the application depends on a fixed source address, the backup IP may need to be whitelisted. If users connect inbound to a fixed hostname, DNS or external failover design may be necessary.
Can failover be tested without disconnecting production users?
Some elements can be validated with controlled routing tests, but an end-to-end proof often requires simulating the actual failure condition in an approved window. The test plan should state which circuit will be disabled, what applications will be checked, who will monitor the results, and how to restore normal service if behaviour differs from expectation.
What information makes a quotation more accurate?
Provide the FortiGate model, current FortiOS version, WAN types and speeds, IP addressing, a simple topology, critical applications, VPN details, number of sites, expected backup behaviour, whether hardware HA is required, and whether the engagement includes new equipment, remote configuration, on-site work or testing. These details reduce the chance of omitted dependencies and unnecessary quotation revisions.
Frequently asked questions
Does FortiGate support automatic internet failover?
Yes. FortiGate can be configured to move traffic away from an unhealthy WAN path using SD-WAN health checks or route/link-monitor methods. The exact configuration depends on the FortiOS release, WAN type and existing routing design.
Do I need SD-WAN for a simple primary and backup ISP setup?
Not always. A straightforward design can use route preference and link monitoring. SD-WAN is useful when the business needs application-aware steering, path-quality decisions or more flexible use of multiple links.
Will active internet sessions continue without interruption?
Not necessarily. Sessions that depend on the original public IP or path may reset when traffic changes ISP. New sessions can use the alternate link, but application behaviour should be tested.
Can site-to-site VPN also fail over to a second ISP?
It can be designed for alternate paths, but both VPN peers, public IPs, tunnel configuration and routing must support the change. A normal internet failover rule alone does not guarantee VPN continuity.
Is two-ISP failover the same as FortiGate high availability?
No. Dual ISP design protects against selected WAN-path failures. FortiGate HA uses multiple firewall appliances to address device-level resilience. Some environments need both.
Can a 4G or 5G connection be used as backup internet?
Potentially, if the FortiGate model and modem or interface design support it. Carrier NAT, public IP needs, signal strength, data allowance and application requirements should be checked first.
What does FourTeck need before configuring failover?
Share the FortiGate model, FortiOS version, current topology, both ISP details, IP addressing, critical applications, VPN information, desired failover behaviour and an approved change window.
Can FourTeck supply a FortiGate if the current firewall is unsuitable?
FourTeck can assist with model sizing and quotation. Current UAE availability, subscription options and vendor lead time should be confirmed for the exact appliance before ordering.
Is installation included automatically with the failover solution?
No. Remote configuration, on-site work, cabling, hardware supply, carrier coordination and testing should be defined in the quotation so the customer knows exactly what is included.
Plan the failover around your real applications and ISP paths
Share your FortiGate model, WAN circuit details, critical applications and preferred recovery behaviour. FourTeck can help define whether the requirement calls for simple primary/backup routing, Secure SD-WAN, VPN path redesign, a new FortiGate, hardware HA or a combination of these items.
Need broader firewall planning? Visit the FourTeck Firewall Dubai resource or contact FourTeck with your requirement.