FortiGate Active Passive Cluster Setup in Dubai, UAE
An active-passive FortiGate cluster is designed to reduce the firewall itself as a single point of failure. The value comes from correct architecture: matching cluster members, resilient heartbeat connectivity, sensible failover triggers, synchronized configuration, appropriate session handling, redundant upstream and downstream paths, and a test plan that proves the secondary unit can assume service without creating a new network problem.
Direct answer: what is a FortiGate active-passive cluster?
A FortiGate active-passive cluster normally uses two compatible FortiGate units working under the FortiGate Clustering Protocol. One unit is primary and processes the production traffic; the other remains secondary and is prepared to take over when the cluster decides a failover condition has occurred. Businesses use this design when continuity of the firewall function is more important than relying on one appliance. Buyers should confirm exact FortiGate model compatibility, FortiOS build, hardware configuration, license position, heartbeat interfaces, connected switches, ISP or WAN design, monitored links, session-pickup requirements, management method, maintenance window, and the traffic that must be tested before the cluster is placed into production.
What the setup is intended to do
The project is intended to create a coordinated pair of FortiGate firewalls so the network does not depend entirely on one appliance remaining healthy. The cluster shares HA information, synchronizes configuration, monitors the health conditions selected by the administrator, and performs primary-unit election according to the HA settings and current member state.
The design should cover the network around the firewalls as well. A firewall pair connected to a single unmanaged switch, one power source, or one ISP circuit may still have major single points of failure. For that reason, FourTeck treats HA as a topology project rather than a single checkbox in FortiOS.
Who should consider active-passive HA
This architecture is relevant to organisations where the FortiGate protects an important business edge, server network, branch aggregation point, data-centre segment, internet gateway, VPN concentrator, or other location where an appliance failure could stop work for many users.
It is not automatically necessary for every small office. The decision should reflect the cost of downtime, the resilience of ISP and switching infrastructure, the availability of a matching second FortiGate, operational support skills, and whether the business can test failover regularly. A well-managed standalone unit may be more appropriate than an HA pair whose dependencies are poorly understood.
Business problems an active-passive design can help address
The objective is continuity of the firewall role, but the real business issues are wider. Each card below shows the problem and the design response that should be considered during the project.
Appliance failure
A standalone firewall creates a direct dependency on one chassis or VM. An HA peer can take over the primary role when the cluster detects a qualifying failure, provided surrounding network paths remain usable.
Maintenance risk
Firmware planning and hardware maintenance become easier to structure when redundancy exists, but the upgrade path, supported versions, backup, rollback, and failover sequence still require planning.
Link-dependent outages
Monitored interfaces can be included in HA failover logic so a member with an important failed path does not remain primary simply because the firewall itself is still powered on.
Unplanned configuration drift
The cluster synchronizes configuration between members. Operations still need disciplined change control, synchronization checks, and clear handling of settings that are intentionally member-specific.
Core capabilities that matter in the HA design
Primary and secondary role control
FGCP manages cluster membership and primary-unit selection. Priority, override behaviour, monitored links and cluster state must be understood so operations teams know which device should become primary and why.
Heartbeat communication
Dedicated or carefully selected heartbeat interfaces exchange HA control information. They can also carry synchronization traffic, so interface choice and resilience are important rather than cosmetic.
Session synchronization
When session pickup is enabled, TCP session information can be synchronized to other cluster members. The requirement should be evaluated against the traffic profile and heartbeat capacity rather than enabled without considering overhead.
Configuration synchronization
The operating configuration is maintained across the cluster so the secondary can assume the primary role with the expected policy, routing, VPN, object and security settings. Synchronization status should be verified before failover tests.
Service-fit matrix
| Business situation | Relevant assistance | Scope dependency |
|---|---|---|
| Existing standalone FortiGate carries critical traffic | Assess second-unit compatibility, firmware, topology and migration method | Exact model, build, hardware, licenses and maintenance window |
| New site requires firewall redundancy from day one | Design cluster, heartbeat, LAN/WAN switching, management and test plan | ISP handoff, switches, VLANs, routing and physical rack design |
| Business uses IPsec VPN or many long-lived sessions | Review session and tunnel continuity requirements during failover | Traffic type, FortiOS feature behaviour and peer-side configuration |
| Remote administration must reach each cluster member | Plan cluster management plus member-specific management access where suitable | Available interfaces, addressing, security policy and management network design |
Technical and service information
This is a service page rather than a model-specific appliance page. Values that depend on the exact FortiGate hardware, firmware, licensing or topology must be confirmed before implementation.
| Topic | FortiGate Active Passive Cluster Setup |
|---|---|
| Main purpose | High availability for the FortiGate firewall role using FGCP active-passive clustering |
| Cluster member requirement | Same model, same hardware configuration and compatible matching FortiOS build must be confirmed |
| Heartbeat interfaces | Required for cluster communication; exact ports and redundancy are model and topology dependent |
| Monitored interfaces | Selected according to the paths whose failure should influence cluster failover |
| Session pickup | Configuration dependent; should be evaluated against session continuity needs and heartbeat bandwidth |
| Licensing and subscriptions | License and subscription dependent; confirm the current entitlement design for both cluster members |
| Management | Cluster management plus optional member-specific management design where required and supported |
| Testing | Planned failover, monitored-link, traffic, VPN, application and recovery tests should match the production use case |
| UAE availability | Contact FourTeck to confirm current service scheduling, hardware availability, licensing and project scope |
Dependencies that must be settled before configuration
Active-passive HA cannot be designed correctly from firewall settings alone. The existing LAN and WAN architecture determines whether traffic can continue after a role change. The project should identify which switch ports connect to each FortiGate, whether VLAN trunks are identical, whether LACP or redundant interfaces are used, how the ISP handoff is presented, where static or dynamic routing decisions occur, and whether upstream devices cache or react to MAC and ARP changes in ways that affect recovery.
The two FortiGate units must also be checked as a pair. Model, hardware configuration, firmware build, licensing level, storage differences where relevant, interface naming, transceivers, power, rack layout and cable paths can all influence the final bill of materials. For virtual FortiGate deployments, cloud or hypervisor behaviour introduces additional dependencies, and the HA method may differ from a physical appliance design. FourTeck can review these inputs before a quotation is finalized so the engagement reflects the actual environment rather than an assumed topology.
How the engagement moves from assessment to handover
Discover
Collect model numbers, serial-independent hardware details, FortiOS build, licenses, topology, IP plan, ISP handoff, VLANs, routing, VPNs, critical applications and outage tolerance.
Design
Define HA mode, group settings, heartbeat ports, interface monitoring, primary-unit preference, session handling, management access, switch connections and rollback path.
Build
Prepare the secondary, align firmware and prerequisites, form the cluster, verify configuration synchronization and connect production paths according to the approved topology.
Prove
Run agreed failover scenarios, validate applications and VPNs, inspect synchronization status, confirm recovery behaviour, document findings and hand over operational steps.
Heartbeat architecture: the control path deserves its own design
Heartbeat interfaces are the communication path that allows cluster members to determine whether their peers are alive and to exchange HA information. In a production design, they should not be treated as spare ports chosen at the last minute. The selected interfaces must be available on both units and be connected in a way that is consistent with the FortiGate model and deployment. When multiple heartbeat interfaces are configured, the cluster can use their priorities and link state when choosing a communication path. This adds resilience to the HA control plane, but only when cabling, port state and network separation are understood.
Session synchronization can also consume heartbeat bandwidth. Environments with a large number of connections, high connection rates or long-lived sessions should therefore consider how much synchronization traffic the heartbeat design may carry. The right answer is not simply “use the fastest port”; it is to understand the platform, session profile, expected failover behaviour and which interfaces can be dedicated without compromising production connectivity.
If heartbeat traffic shares a network rather than a dedicated direct connection, the security and reliability of that path need extra attention. FortiOS provides options for heartbeat authentication and encryption in relevant designs, but these options can also affect performance. FourTeck can review whether direct links, switched heartbeat networks, redundant heartbeat paths or virtual-environment methods are appropriate for the specific deployment.
Failover logic: decide what should make the secondary take over
A firewall can remain powered on while an important upstream or downstream link has failed. If the cluster looks only at whether the chassis is alive, traffic may stay attached to a unit that no longer has a usable path. Interface monitoring lets selected link failures participate in HA failover decisions. The monitored list should therefore represent interfaces whose loss genuinely makes that cluster member unsuitable to remain primary.
Over-monitoring can be as troublesome as under-monitoring. If every noncritical interface triggers a failover, a local access-port issue could cause an unnecessary role change and increase operational instability. The design should distinguish business-critical transit interfaces from ports that can fail without requiring the whole firewall role to move. When SD-WAN, redundant interfaces, aggregates or remote health checks are involved, the failure logic should be tested against the intended routing behaviour rather than assumed from a simple cable pull.
The primary-unit selection policy also matters after recovery. Teams should understand whether they want a preferred member to reclaim the primary role or whether they prefer to avoid an additional failback unless needed. That choice affects maintenance procedures and the number of traffic transitions users may experience. FourTeck can document the selected behaviour so operators know what to expect during faults, maintenance and restoration.
Session continuity: what “failover” means to real applications
A successful role change does not automatically mean every application session continues without interruption. The user experience depends on the traffic type, the state information synchronized between cluster members, upstream and downstream network convergence, the application’s own reconnect behaviour, and any external system such as a VPN peer, load balancer, ISP router or cloud service. FortiGate session pickup is designed to synchronize eligible session state so the secondary has more information available when it becomes primary.
That capability should be enabled and evaluated in context. Session synchronization adds traffic to the HA communication path, and not every protocol or feature has identical failover behaviour. A buyer who says “we cannot lose sessions” should identify exactly which sessions matter: internet browsing, Microsoft 365, VoIP signalling, IPsec site-to-site tunnels, remote access, database flows, payment terminals, published services, long-lived TCP connections, or application-specific transactions. Each category can be tested separately.
FourTeck can help build a test sheet that records pre-failover state, the trigger used, observed interruption, recovery time from the application perspective, cluster status, and any manual action required. This turns HA from a configuration claim into an operationally understood system.
Where this service is commonly useful
Head office internet edge
Suitable when one firewall outage would interrupt cloud access, email, internet browsing, inbound services, remote connectivity or branch traffic for a large user population.
Data-centre or server perimeter
Useful where the FortiGate protects published applications, server VLANs, partner connections or east-west segments whose availability is important to business operations.
Multi-branch VPN hub
Relevant when many sites terminate IPsec tunnels on a central FortiGate and the organization wants to reduce dependence on one hub appliance.
Operational technology boundary
Can be considered for carefully managed industrial or facility networks where segmentation and availability are both important, subject to application testing and site-change controls.
Campus or education network
May fit environments with many users, wireless networks, labs, administrative systems and internet-dependent services where a single edge firewall outage has broad impact.
Retail, hospitality and distributed operations
Useful for central gateways supporting remote sites, guest services, cloud applications and operational systems, provided the rest of the network path is also designed for resilience.
Integration and operational considerations beyond the FortiGate pair
High availability should be mapped end to end. On the WAN side, identify whether the ISP provides one Ethernet handoff, two handoffs, a customer router, a provider-managed device, a static routed block or dynamic routing. On the LAN side, identify whether both FortiGates connect to one switch stack, two independent switches, a chassis pair, MLAG-capable switches or simple access switches. The firewall cluster can only use paths that the surrounding infrastructure makes available.
Routing requires the same level of attention. Static routes may be straightforward, but dynamic protocols, SD-WAN rules, policy routes, BGP neighbours and route health checks can influence how quickly traffic becomes useful after a firewall role change. If the FortiGate pair sits behind load balancers or in front of server clusters, those devices may have their own state and convergence behaviour. The failover test should include them.
Management access should also remain practical during incidents. Administrators need a secure method to reach the active cluster and, where appropriate, to diagnose the secondary member independently. Reserved management interfaces can provide member-specific access in supported designs. The final design should specify addressing, allowed administration protocols, source restrictions, authentication controls, logging, backup locations and who is authorized to perform HA operations.
Questions to resolve before ordering or scheduling the work
Provide exact model numbers and hardware details. Similar performance class is not enough for a standard FGCP pair.
The firmware plan affects cluster formation, migration, upgrade sequencing and feature behaviour.
List critical applications, VPNs, published services, voice, payment or operational traffic that requires explicit testing.
Identify WAN and LAN interfaces whose failure makes a member unsuitable to remain primary.
Firewall HA does not remove a single point of failure elsewhere in the path.
A live conversion needs a controlled window, rollback criteria, stakeholder communication and application owners available for testing.
Procurement and readiness checklist
Use this list when preparing a quotation request. The more complete the information, the easier it is to distinguish hardware procurement, licensing, professional services and customer-side prerequisites.
How FourTeck can assist with planning, configuration and validation
FourTeck can support a project from the initial network review through controlled HA testing. For a new cluster, the work may include reviewing the proposed bill of materials, verifying that the two FortiGate units are suitable cluster peers, confirming FortiOS alignment, selecting heartbeat links, mapping monitored interfaces, defining the management approach, and documenting the physical connections to WAN and LAN infrastructure. For an existing standalone firewall, the scope may also include a migration plan describing how the second appliance is introduced without confusing the live network.
Configuration work can include the HA group settings, role behaviour, heartbeat interfaces, monitoring, session handling, member naming, management options and checks that cluster synchronization is healthy. The final configuration is always dependent on the exact FortiOS release and device platform. The goal is to create an operational design that administrators can explain, not simply a pair of appliances that currently show “in sync.”
Testing can be tailored to the business risk. That may include an orderly primary-unit change, loss of a monitored interface, recovery of a failed path, validation of internet and internal routing, IPsec tunnel checks, remote-access verification where applicable, key application tests, logging review and confirmation that both members can be managed. Visit the FourTeck firewall product area when a matching second appliance or related hardware also needs to be sourced.
UAE availability and support guidance
FortiGate HA work in the UAE should be scoped around the actual environment. Contact FourTeck to confirm current service availability, the availability of any required matching FortiGate appliance, transceivers, cables, support or security subscriptions, and whether the engagement requires remote preparation, on-site work, after-hours change execution, documentation or post-change observation. Availability may depend on the model, firmware position, license term, quantity, supplier lead time and the engineering scope required.
An accurate quotation normally needs the site location, exact model numbers, current configuration summary, network diagram, internet handoff, switch topology, expected outage window and test requirements. Installation and configuration should be included explicitly in the quotation when required; they should not be assumed to be part of hardware supply. For broader Fortinet planning, see Fortinet firewall guidance from FourTeck.
Dubai, Abu Dhabi, Sharjah and Ajman project coordination
Businesses in Dubai, Abu Dhabi, Sharjah and Ajman can discuss FortiGate active-passive projects with FourTeck as one combined UAE requirement. The important inputs are the site design and operational constraints rather than the city name: whether the firewalls are in an office, warehouse, campus, data centre or branch hub; whether access to the rack requires approvals; whether the ISP handoff can be changed during the window; and who will test applications after failover. Delivery, visit scheduling and engineering scope should be confirmed after the exact requirement is reviewed. Where multiple UAE sites are involved, the project can also separate the central HA cluster work from branch VPN, SD-WAN or routing changes so each change has a clear owner and rollback plan.
GCC Availability
FourTeck can discuss FortiGate active-passive cluster requirements for organisations planning projects across GCC markets, including the United Arab Emirates, Saudi Arabia, Kuwait, Qatar, Bahrain and Oman. Regional work begins with the technical requirement: exact firewall model, number of cluster pairs, license position, destination, data-centre or office topology, installation scope and expected project window. Hardware availability, licensing, delivery schedules, vendor lead times, service visits and local implementation conditions can vary by country, quantity and model, so these details should be confirmed before procurement. For multi-site projects, FourTeck can help separate the bill of materials from the engineering scope and define which activities can be prepared remotely before on-site implementation. Customers should share the destination country, exact FortiGate model, quantity, subscription term, deployment location and target schedule so quotation and project coordination can be reviewed appropriately. For Kuwait-related enquiries, the FourTeck Kuwait site can also provide a regional contact path.
Africa Availability
Organisations planning FortiGate high-availability deployments in Africa can ask FourTeck to review the technical and procurement requirements before equipment is committed to a site. The exact destination affects fulfilment, power and rack considerations, shipping arrangements, license region, service coordination and the feasibility of remote or on-site assistance. Projects in East Africa, West Africa, Southern Africa or Central Africa may also differ in ISP architecture and local switching design, which directly influences an active-passive firewall topology. Buyers should provide the destination country, FortiGate model, quantity, FortiOS build, subscription or support requirements, planned deployment date, network diagram and any expectation for installation, failover testing or post-change support. Availability and lead time can depend on vendor and logistics conditions and should be confirmed for the specific request. FourTeck can assist with requirement review and coordination through its Africa business technology channel and related regional teams.
Related FourTeck options to consider
Matching FortiGate appliance
If only one FortiGate exists today, the second unit must be checked for model, hardware and firmware compatibility before it is purchased for FGCP HA.
FortiGate migration support
A standalone-to-cluster conversion may need config cleanup, firmware alignment, new cabling and a controlled cutover rather than simply adding a second unit.
SD-WAN and WAN resilience
Firewall HA protects the appliance role. Dual carriers, SD-WAN health checks and routing design can address separate WAN-path risks where the business requires them.
Firewall review and documentation
Rulebase quality, VPN inventory, object naming, backups and diagrams often deserve review before an HA migration so hidden legacy issues are not carried forward.
Why businesses contact FourTeck for HA projects
High availability is one of those projects where procurement, network design and operations have to agree. The procurement team may need a second FortiGate, subscriptions and accessories; the network team must confirm the switch, ISP and routing design; the security team needs policies and inspection behaviour to remain correct; and application owners need a meaningful test plan. FourTeck can help bring those inputs into one scope so the quotation reflects the technical requirement.
Practical assistance can include requirement clarification, matching-unit checks, bill-of-material guidance, firmware and compatibility review, HA configuration planning, cutover sequencing, testing, documentation and support coordination. The exact deliverables depend on the project and should be listed in the quotation. To discuss a live network or new design, use the FourTeck contact channel and share the model numbers, topology and expected timing.
Practical buying and deployment insights for FortiGate HA
People researching active-passive FortiGate clusters usually begin with a simple question: “How do I make two FortiGates fail over?” The better question is “What must remain available when one firewall, one link, or one maintenance event occurs?” That change in wording moves the project from device configuration to service continuity. A cluster can transfer the firewall role, but it cannot create a second ISP circuit, a redundant switch, a second power feed or application resilience that does not exist elsewhere. Buyers should therefore map the complete path from internet or WAN provider through the firewall pair, switching, routing and the destination application.
Do I need identical FortiGates?
For a conventional FGCP HA cluster, buyers should plan on matching FortiGate models and hardware configuration with aligned firmware. A “similar” appliance from the same product family is not a safe substitution. Confirm the exact model before ordering the second unit.
Will failover keep every connection alive?
Session pickup can improve continuity for eligible sessions, but application experience also depends on protocol behaviour, synchronized state, upstream and downstream convergence and external peers. Critical applications should be tested rather than treated as guaranteed.
Another common buying question is whether both units need subscriptions and support. The answer depends on the Fortinet licensing program, product bundle and current vendor policy for the selected model and services. The safest procurement method is to provide the serial-independent model and bundle requirement and ask for the licensing position of both cluster members to be confirmed in the quote. This avoids building an HA pair that is technically synchronized but commercially inconsistent.
Heartbeat design is another area where short online guides can be misleading because they often show two appliances connected with one convenient port and omit the surrounding network. In a production environment, administrators should decide whether one or more heartbeat interfaces are required, whether the ports are direct or switched, what bandwidth synchronization may consume, and how a heartbeat-link failure should be distinguished from a member failure. If the cluster uses busy heartbeat paths while session pickup is enabled, synchronization traffic should be considered in capacity planning.
Buyers also ask whether active-active is “better” because both appliances can process some traffic. It is not simply a higher-tier version of active-passive. The operational model and traffic distribution are different, so the choice should be based on requirements rather than the assumption that using both CPUs is automatically preferable. If the main objective is straightforward appliance redundancy with one primary firewall at a time, active-passive is often the clearer design to evaluate. Performance sizing must still assume that the surviving unit can handle the intended production load.
For existing standalone firewalls, the migration path deserves special attention. The new secondary should not be introduced casually into a live network with unknown firmware and interface state. A controlled plan should cover configuration backup, firmware alignment, cluster parameters, cable changes, the order in which devices are connected, verification that the configuration synchronizes, and a rollback point if traffic behaviour is not as expected. The maintenance window should include application owners, not just the firewall administrator.
Finally, quotation requests are more useful when they describe outcomes. Instead of asking only for “FortiGate HA configuration,” state whether the job includes supply of the second firewall, licenses, rack and cabling changes, switch configuration, ISP coordination, on-site installation, after-hours execution, VPN testing, application testing, documentation, training or a post-change support period. This allows FourTeck to separate optional tasks from required dependencies and reduces surprises when the project reaches the change window.
Questions buyers ask while deciding how to build the cluster
Should the two firewalls connect to the same switch or separate switches?
The answer depends on the required level of resilience and the capabilities of the switching environment. One switch may be operationally simpler but remains a single point of failure. Two switches can improve path resilience, but VLAN, trunk, loop prevention, aggregation and MAC behaviour must be designed correctly. Share the switch models and topology before the HA cabling plan is approved.
What should be monitored for automatic failover?
Monitor interfaces whose loss means the current primary no longer has a valid production path. That may include critical WAN, LAN or aggregate interfaces. Avoid using the monitor list as a generic “watch every port” feature. Unnecessary triggers can cause role changes for faults that do not justify moving the firewall function.
Do we need a dedicated management interface for each unit?
Not every environment requires it, but member-specific management can be valuable for troubleshooting and maintenance. Supported FortiOS designs can reserve management interfaces so each member has separate access. The decision depends on available ports, IP addressing, management-network security and the operational support model.
How do we know the cluster is really ready?
“In sync” is necessary but not sufficient. Confirm member health, synchronization, heartbeat links, monitored interfaces, routing, ARP or neighbour behaviour, VPN status, log visibility and management access. Then run controlled failover tests against the applications that matter to the business and record the results.
Can we create HA without changing the current network?
Sometimes the surrounding design already supports two firewalls, but often new switch ports, VLAN trunks, WAN presentation, rack space, power feeds or cabling are needed. The safest assumption is that the network diagram must be reviewed first. FourTeck can identify whether the HA change is firewall-only or a broader infrastructure change.
What information makes a quotation accurate?
Send both FortiGate model numbers, current FortiOS build, license details, topology, ISP and switch information, routing and VPN requirements, desired maintenance window, site location, and whether the job includes supply, installation, configuration, testing, documentation or ongoing support. That information turns a generic service estimate into a project scope.
Frequently asked questions
What is FortiGate active-passive HA?
It is an FGCP clustering mode in which one FortiGate is primary for production traffic while another member is secondary and prepared to take over when the cluster detects a qualifying failover condition.
Do both FortiGates need to be the same model?
For a standard FortiGate FGCP cluster, the members should be the same model with the same hardware configuration and aligned firmware. Confirm the exact platform before buying the second unit.
What are heartbeat interfaces used for?
Heartbeat interfaces carry HA communication used by the cluster to maintain membership and state. They can also carry synchronization traffic, so port choice and resilience matter.
Does session pickup keep sessions running during failover?
Session pickup synchronizes eligible TCP session information between members and can improve continuity, but the user experience still depends on protocol, feature, network convergence and application behaviour. Test critical traffic.
Which interfaces should be monitored for HA failover?
Select interfaces whose failure makes the current primary unable to provide the required production path. The correct list depends on the WAN, LAN, switching, routing and aggregate-interface design.
Can an existing standalone FortiGate be converted to an HA cluster?
Yes, subject to model, firmware, hardware and licensing compatibility. A live conversion should use a documented preparation, backup, cluster-formation, cabling, testing and rollback plan.
Does HA require two internet connections?
No. Firewall HA and WAN redundancy are separate design questions. If the ISP link is itself critical, discuss dual circuits, SD-WAN or other WAN-resilience options in addition to the firewall pair.
How should we test an active-passive cluster?
Use agreed scenarios such as a controlled role change and failure of a monitored path, then validate internet, routing, VPNs, applications, logging, synchronization, management and recovery according to the business test plan.
How can FourTeck quote FortiGate HA setup in Dubai?
Share the exact models, firmware, topology, site, licenses, switch and ISP design, critical traffic, maintenance window and required deliverables. FourTeck can then confirm the project scope and current UAE service availability.
Prepare the HA project before the maintenance window
Send FourTeck the FortiGate model, FortiOS build, network diagram, ISP handoff, switch topology, licensing position and the applications that must be tested. We can help identify prerequisites, define the implementation scope and prepare a quotation based on the real environment.