A pair of FortiGate appliances can remove one point of failure while leaving several others untouched. Both units may depend on the same switch, power distribution, provider equipment or authentication service. The cluster can change its active member exactly as designed while staff still lose access to the applications they need.
A useful FortiGate failover drill tests the service around the pair. It examines which failures the design is meant to tolerate, how applications behave during recovery and whether the support team can recognise the event. The aim is to produce an honest recovery record, including remaining dependencies and manual actions.
Draw the service path beyond the appliances
Start at a representative user and follow the path to an essential application. Include access switches, wireless infrastructure where relevant, internal routing, the FortiGate pair, provider equipment and remote services. Add DNS and identity dependencies even if they are not on the obvious traffic path.
Mark shared components. Two firewall units connected to one upstream switch still share that switch. Two power supplies connected to the same dependent source may not provide the independence expected by the business. Ask qualified facilities specialists to confirm power arrangements rather than inferring them from the number of cables.
Use the diagram to define the intended protection. State which single failures the design should tolerate and which remain outside scope. This makes the drill reviewable and prevents the term “high availability” from being interpreted as protection against every possible outage.
Confirm the exact HA design before testing
Record the appliance models, FortiOS version, HA arrangement, monitored interfaces and relevant session settings. Have the implementation team review health and synchronisation using the supported methods for that release. An unresolved cluster issue should be understood before a deliberate failure is introduced.
Fortinet’s FortiOS 7.4.7 session-pickup documentation describes synchronising TCP session information and explicitly notes that resumption is not guaranteed under all conditions. It also distinguishes connectionless-session handling. That version-specific guidance supports a practical rule: test your actual applications rather than promising that every session will survive.
Do not change HA settings casually to make a drill pass. A proposed change needs its own compatibility review, approval and rollback route. Preserve the initial configuration and record the final state. The test report should explain what was tested, not merely show that a cluster appeared healthy at the end.
Select workflows with different recovery behaviour
Choose a small set of important activities. A customer call, an authenticated web session, a file upload and a transaction submission can react differently to the same interruption. Include remote access or site-to-site dependencies if they are part of the business requirement and within the approved scope.
Assign a business observer to each workflow. Ask them to note the last successful action, the visible interruption, any error message and the first successful completion after recovery. Technical timestamps are useful, but they should be connected to the actual user experience.
Use non-sensitive test data and identify how application state will be checked. If a submission is interrupted, confirm whether it completed before retrying. The drill should teach staff a safe recovery action, not encourage repeated clicking that may create duplicate records or inconsistent work.
Agree boundaries and a stop decision
Schedule the exercise with the affected service owners. Define the maximum acceptable disruption, the person authorised to stop and the recovery action for each scenario. Ensure that the required people, configuration records and access routes are available during the window.
Confirm a management path that does not depend entirely on the service being tested. If the team loses access at the moment of failover, recovery may become unnecessarily difficult. Document local assistance where it is needed and verify that the person on site knows which labelled component is involved.
Avoid improvising destructive actions. Use a vendor-supported or otherwise approved method appropriate to the scenario, supervised by qualified personnel where power or physical infrastructure is involved. The objective is controlled evidence, not the largest possible outage. Stop if the observed condition moves beyond the agreed scope.
Establish the healthy baseline
Run the selected workflows before any failure. Record cluster status, relevant path information and application results. Confirm that alerts reach the intended recipients and that clocks are sufficiently aligned to correlate events. This baseline helps separate a pre-existing problem from the effect of the drill.
Check the state of both members and the surrounding network. If one uplink is already impaired or a provider circuit is under maintenance, the drill may no longer represent the agreed single-failure scenario. Either correct the condition or document and approve the changed scope before proceeding.
Keep background activity visible. A quiet maintenance window may be appropriate for the first controlled exercise, but it does not prove behaviour under peak demand. State that limitation and decide whether a later representative-load test is required. The report should distinguish demonstrated outcomes from assumptions.
Test appliance failover as one scenario
Begin with the approved member-failure or controlled switchover scenario. Observe the role change, network reachability and each application independently. Record whether sessions continue, reconnect automatically or require user action. Do not reduce the result to a single ping measurement.
Have the support observer identify the event through the normal monitoring route. Did the alert arrive, describe the affected equipment and reach someone who could act? A successful technical transition accompanied by confusing alerts can still create operational uncertainty during a real incident.
After the event, verify that the remaining member carries the intended workload and that the environment is stable. Check the agreed security and routing state as appropriate for the deployment. Do not rush into the next failure while the system is still recovering or while the first result remains unexplained.
Test the dependencies the pair cannot replace
Next, consider separately approved scenarios involving an upstream path, a downstream connection or another shared dependency. Select only those that the design claims to tolerate and that can be tested safely. Each scenario should have a distinct expected result and restoration step.
For example, a hypothetical branch may have a resilient firewall pair but a single access switch serving every workstation. The drill need not deliberately disable that switch to recognise the dependency. The diagram and configuration review can establish the limitation, while a separate approved test examines any resilience actually provided around it.
Provider diversity also needs evidence. Two circuits can share building entry points, local infrastructure or upstream dependencies. Record what is known and what the provider has confirmed. Do not describe paths as independent merely because they have different labels in the firewall configuration.
Treat power scenarios as facilities work too
Map each appliance and supporting device to its power source. Include switches, provider handoff equipment and any management access needed during recovery. A firewall with an alternate supply cannot maintain service if the only connected switch loses power.
Have qualified personnel determine suitable testing methods and safe boundaries. The IT team should specify the business service being validated and the evidence required; it should not improvise electrical isolation. Coordinate the test with facilities and any other systems affected by the same supply.
Record the result at the application level. If the approved power scenario causes an expected interruption elsewhere, make that dependency explicit. The business can then decide whether to accept it, change the design or adopt a manual continuity procedure. The exercise is valuable when it exposes a decision that can be acted on.
Verify restoration and return to the intended state
Recovery is not complete when traffic first resumes. Restore the failed component through the approved process, verify health and confirm the desired operating state. If failback behaviour is part of the design, observe it separately and record any second application interruption.
Check that no temporary troubleshooting configuration remains. Review interfaces, routing, monitoring and management access affected by the exercise. Preserve the final configuration reference and note any changes that require a later maintenance window rather than making them impulsively during the drill.
Ask application owners to confirm that their test records are consistent and that normal work can resume. Close any synthetic transactions or test accounts according to the agreed process. This final business check prevents a technically recovered network from leaving unfinished work or misleading records behind.
Turn observations into a recovery runbook
Write the runbook around symptoms and actions. Explain how staff recognise a member failure, who checks cluster health, who contacts a provider and when users should retry an application. Include the limits demonstrated by the exercise and the conditions that require escalation.
Assign corrective actions to owners and repeat the relevant test after changes. A finding that both firewalls rely on one unprotected switch should become a design decision, not remain an interesting note in a report. Retain the evidence so future budget and maintenance discussions are grounded in the observed service impact.
Maxicon’s network infrastructure services provide a relevant starting point for reviewing the dependencies around an HA deployment. Contact Maxicon with the topology and essential workflows to define a bounded failover exercise and practical acceptance record.
Frequently asked questions
Does a FortiGate HA pair guarantee uninterrupted applications?
No universal guarantee should be inferred from the presence of two appliances. Session behaviour depends on the configuration, software, protocol and application, while surrounding infrastructure can still fail. Test representative workflows and document whether they continue, reconnect or require manual action. Use the exact product documentation to interpret the result.
Should the first drill include every possible failure?
Begin with a bounded scenario that the team can restore confidently, then expand the programme based on the design and business need. Test one failure at a time unless a combined scenario is explicitly planned. Record limitations honestly. A controlled, well-observed exercise is more useful than a broad test whose results cannot be explained.
Why are application observers needed if engineers monitor the cluster?
Cluster events do not show whether a user transaction completed or a call recovered acceptably. Application observers connect technical events to business consequences. They also help define safe retry instructions and verify test data after interruption. Both technical and operational evidence are needed for a meaningful acceptance decision.
Can power resilience be checked by unplugging equipment?
Do not improvise electrical tests. Have qualified personnel assess the arrangement and approve a safe method with clear boundaries. Include the supporting switches and provider equipment in the dependency review. The test should demonstrate the intended service outcome while protecting people, equipment and unrelated operations.
When should a failover drill be repeated?
Repeat relevant tests after material topology, software, policy or provider changes, and at an interval appropriate to the service’s importance. Also revisit the runbook when support responsibilities change. The useful question is whether the current system and current team can still reproduce the accepted recovery outcome.
Related technology support
For an additional service perspective related to this guide, explore Trubyte’s Fortinet and managed security services.
Discuss your requirements with Maxicon
Tell us about your business, current environment and the support you need.
