A high-availability firewall pair can keep traffic moving when one member fails, but the label alone does not establish that every existing connection will survive. Evaluate three outcomes separately: whether another firewall takes over, whether active application sessions continue, and whether the required security controls remain in force.
For IT directors and MSP technical leaders, the useful acceptance question is specific: what will users experience during a defined failure, under the intended security policy and traffic load?
A replacement gateway needs more than the same rules
A firewall rule describes permitted traffic. A stateful firewall also tracks information about connections already in progress. NIST SP 800-41 Revision 1 explains that connection tables can include addresses, ports, connection state, and network address translation information. Having matching policy therefore does not, by itself, demonstrate that a second device has the information needed for an existing flow.
Ask which connection types and inspection functions the proposed platform can preserve, what information it synchronizes, and which exceptions require reconnection. Treat the answer as specific to the software version, deployment mode, and enabled features. A general promise of “stateful failover” needs that supporting detail.
Router redundancy addresses another part of the problem. The IETF's RFC 9568 defines how VRRP transfers responsibility for forwarding through a virtual router. That is useful gateway availability, but the standard does not establish application-session continuity or firewall inspection-state synchronization. Do not treat support for a routing protocol as proof of those separate outcomes.
Define the failure before accepting the design
Consider a hypothetical office with two firewalls connected through one upstream switch and one internet circuit. The second firewall may help when the first appliance fails. It cannot provide an alternate path around the office's only failed upstream switch or circuit. This is a topology example, not a customer incident.
Mark shared dependencies on the design: power, switches, carrier handoffs, and any services required to establish access. For each failure the business wants to tolerate, identify the surviving path and who operates it. Buying a second appliance and buying an independent internet path solve different parts of that design.
The NCSC's network security fundamentals recommends incorporating security and resilience into network architecture from the start. Our practical application is to review the complete remaining path, including its capacity and protection, before approving the redundancy plan.
Compare what users and security operators observe
We recommend agreeing acceptance evidence with both the application owner and the network operator. Use representative workflows already running before the transition, then start new connections after it. These observations answer different questions:
| Observation | What it helps establish |
|---|---|
| A new application connection succeeds after takeover | The replacement path can accept that new flow; an earlier session may still have been lost. |
| An existing call, transfer, or authenticated session continues | That tested workflow tolerated the transition under the recorded conditions. |
| A harmless test of an agreed blocked flow remains blocked | The relevant access restriction still applies on the replacement path. |
| Expected security events reach monitoring | Operators retain the tested visibility after the device role changes. |
Record interruption duration, required user actions, traffic load, enabled inspection, and any difference between expected and observed behavior. A successful idle-network demonstration leaves busy-period capacity unanswered. A browser that silently reconnects may also hide an interruption that matters to another application.
Plan any disruptive test with the responsible operators, an agreed maintenance window, stop conditions, and a way to restore service. The test should demonstrate the intended production policy; temporarily removing inspection changes the question being tested.
Include the return to normal operation
The recovered device's return deserves its own acceptance criteria. RFC 9568 recognizes that switching back to a preferred router can cause disruption and provides control over that behavior. For a firewall deployment, establish whether return is automatic or operator-controlled and verify the platform's actual behavior.
NIST also identifies paired-device logging and policy-change coordination as HA management concerns. Confirm which device supplies configuration, how synchronization is checked, and how operators recognize events from either member. These are operating responsibilities that continue after installation.
Network Box USA's Managed Unified Threat Management service combines gateway security with management and monitoring. Its design guidance calls for documenting high availability, capacity, and maintenance requirements. Confirm the proposed resilience scope and acceptance evidence for your environment. If you are planning a gateway replacement, contact our team to discuss the security and continuity requirements together.