A good firewall high availability design pairs two identical firewalls so that either one can carry the whole site on its own, synchronises configuration and session state between them, and sits on a network with no other single point of failure. For most UK organisations the right starting point is an active/passive pair, each unit sized for full peak load, with a dedicated failover path and monitored, tested failover.
This guide covers the decisions that matter: the HA mode, capacity sizing, link design, timers, and the resilience around the pair. It is written for IT directors and network managers in schools, universities, manufacturing, logistics, hospitality, shared workspaces and property development.
TL;DR
- Use two identical firewalls, with the same model, licences and software, so state and configuration can be synchronised reliably.
- Active/passive is the simpler default. Active/active adds design and troubleshooting complexity and should be chosen for a specific reason.
- Size each unit for the full peak load of the site. Never count on two units adding up during a failure.
- Give the failover and state synchronisation traffic dedicated links on busy networks.
- A firewall pair does not make a network highly available by itself: circuits, switching, routing and power need the same treatment.
Table of Contents
- What firewall high availability actually does
- Choosing the mode: active/passive or active/active
- Size for failure, not for the sum of two boxes
- Link design: failover, state and data paths
- Timers, identical hardware and software
- Resilience beyond the firewall pair
- Sector considerations
- Our perspective
- How we can help
- A design review checklist
- FAQ
- Sources
What firewall high availability actually does
High availability (HA) groups firewalls so that configuration and session state are shared and no single device is a point of failure. Vendor documentation describes the result as a deployment where, if one unit fails, its peer takes over and user connections can be preserved through state synchronisation.
The mechanics are similar across platforms. In Cisco’s Secure Firewall Threat Defense, for example, a failover pair needs two identical devices joined by a dedicated failover link and, optionally, a state link. The units use the failover link to check each other’s health and replicate configuration. The state link passes connection information to the standby unit so that sessions survive a switchover.
Two points follow from that:
- HA protects against device failure. It does not protect against a bad rule, a misconfigured policy or an upstream outage, because the configuration is replicated to both units.
- HA is only as good as the standby unit’s readiness. A pair whose members drift apart in software version or licensing is a pair that fails to fail over.
Choosing the mode: active/passive or active/active
There are two main modes, and the choice shapes everything else in the design.
| Criterion | Active/passive | Active/active |
|---|---|---|
| Traffic handling | One unit forwards, the other stands by | Both units forward traffic |
| Failover speed | Fast, with state synchronised | Typically faster, as the peer is already forwarding |
| Design complexity | Low | Higher: routing, NAT and session ownership need planning |
| Troubleshooting | Single traffic path to follow | Traffic can traverse either unit |
| Capacity planning | Each unit sized for the full load | Each unit must still be sized for the full load |
In an active/passive pair one firewall manages traffic while the other is synchronised and ready to take over. In active/active, both process traffic, which offers load sharing and potentially quicker failover, at the price of more complex configuration. That complexity shows up in practice as replicated NAT pools, separate routing instances and the need to keep track of which unit owns which session, all of which make incident response harder.
Our recommendation for most sites is active/passive. It is easier to document, easier for a service desk to reason about at 2am, and easier to test. Choose active/active only when you have a clear requirement that active/passive cannot meet, such as asymmetric routing already present in the design, and when your team or managed service provider can support it.
Size for failure, not for the sum of two boxes
The most common design error is capacity. Organisations see two firewalls and assume they have double the performance. In a failure, they have exactly one firewall’s worth.
GOV.UK guidance on network infrastructure in shared buildings tells installers to connect two highly available firewalls to the internet link to prevent a single point of failure. The same principle applies to capacity: each unit must handle the entire peak load of the site by itself, so that a failover causes no bottleneck at the busiest time of day.
A sizing method
- Measure the real peak. Take peak, not average, throughput across all WAN bearers and internal segments that cross the firewall. Term-time mornings, shift changes and event nights are the usual peaks.
- Measure with the security features on. Vendor datasheet throughput is usually quoted for simple firewalling. Intrusion prevention, TLS inspection and application control reduce it. Use the figure for the features you will actually enable.
- Add growth. Allow for new users, new IoT and building systems, and bandwidth upgrades over the hardware’s life.
- Check the single unit against the result. If one unit cannot carry it, the design has no real resilience.
Clustering changes the arithmetic further. Cisco’s reference architecture for individual interface mode clusters indicates that cluster throughput is typically about 80% of the combined throughput of the nodes, once CPU and memory overhead and cluster control link traffic are accounted for. If you are planning a cluster for scale, budget for that overhead rather than for the headline sum.
Link design: failover, state and data paths
The links between the pair are easy to under-specify.
- Failover link. Carries health checks, unit state and configuration synchronisation. Use a dedicated interface, ideally a direct connection between the units or a dedicated VLAN on separate switching.
- State link. Carries connection state. Sharing one interface for both failover and state is a valid way to conserve ports, but on high-traffic networks we advise a physically separate interface for state synchronisation, so heavy session churn cannot delay it.
- Data interfaces. Connect each unit to redundant switches, so that a single switch or cable fault does not look like a firewall fault and trigger an unnecessary failover.
- Link monitoring. Decide which interfaces trigger failover when they go down, and test that the choice matches your intent. Monitoring too many interfaces causes needless switchovers. Too few lets a dead path go unnoticed.
Avoid running failover traffic through the same switch stack that the firewalls protect. If that stack fails, both units lose sight of each other and you risk both believing they are the active unit.
Timers, identical hardware and software
Failover time is set by how often the units check each other and how many missed checks they tolerate. Cisco’s firewall and IPS design guide is the reference we use for the principle that both units must be identical models with the same feature licences and software. On many platforms the poll interval can be tuned to somewhere between 0.5 and 5 seconds, but pushing timers below the vendor’s recommended thresholds can cause false failovers, especially on appliances that are close to their capacity limits.
A practical approach:
- Start with vendor defaults.
- Tighten only if a measured business requirement demands it, such as voice or industrial control traffic that cannot tolerate a pause.
- Retest under load, since a unit at 90% CPU may miss health checks it would pass at idle.
- Upgrade pairs in a documented order, and confirm both units run the same version afterwards.
Software upgrades are where many HA pairs lose their value. A pair that has never been tested through an upgrade is a risk, so rehearse it in a maintenance window before you depend on it.
Resilience beyond the firewall pair
A redundant firewall pair behind a single internet circuit, a single core switch or a single power feed is a redundant box in a fragile network. Real availability targets, such as the 99.99% sometimes cited in enterprise designs, depend on the whole path. Cisco’s reference architecture material shows resilient designs combining HA firewalls with diverse fibre routes, stacked or redundant core switching and power protection.
Work through this checklist:
- Circuits: two internet or WAN bearers from different providers, on physically diverse routes where the site allows it. Our SD-WAN failover design playbook covers how to steer traffic when a bearer fails.
- Switching: redundant core and distribution switches, with each firewall dual-homed.
- Power: UPS capacity sized for the time it takes generators to start or for a clean shutdown, and separate power feeds for each firewall where possible.
- Routing: dynamic routing that converges quickly and does not depend on the failed unit.
- Management and logging: out-of-band access, so you can reach the pair when the production path is down.
- Monitoring: alerts on a failover event, not just a failure. A silent failover leaves you running without redundancy until the second fault. Our guide to monitoring network health sets out what to track.
A data centre example shows the principle at work: see how a media company built a resilient data centre with failure of individual components in mind.
Sector considerations
Schools, colleges and universities
Education networks combine staff systems, student devices, guest access and safeguarding controls. Segmentation matters as much as redundancy, and the firewall pair enforces it. Device policy is part of this: for a view on the policy side, see these BYOD practices for schools, which is published in Greek. Plan HA around term-time peaks, exam periods and online assessment, when an outage does the most damage.
Shared workspaces and multi-tenant buildings
Tenants expect separation from each other and a connection that stays up. The GOV.UK guidance also covers using virtual systems to separate services and applying a final deny-all rule after permitting only the minimum required. Our network security guide for shared spaces goes into the tenant model in more detail.
Manufacturing and logistics
Production lines and warehouse scanners often cannot tolerate even a short pause. Here, a tuned failover time and a clean separation between IT and operational technology are the priorities. See our guide to OT network segmentation.
Hospitality and property developers
Hotels depend on guest Wi-Fi, booking and payment systems, while developers specifying connectivity for new builds need resilience designed in before cabling is installed. Our connectivity planning guide for new builds covers the early decisions.
Our perspective
We have worked with Cisco networks for over 35 years, and the pattern we see most often is not a missing second firewall. It is a second firewall nobody has tested. The pair was installed, the project closed, and two years later nobody can say what happens if the primary fails at 9am on a Monday.
Our view is plain. Choose active/passive unless you can name the requirement that justifies active/active. Size one unit for the whole site. Keep the failover and state links away from the traffic they protect. Then test, on a schedule, with the business informed, and record the results. A design that has been proved in a maintenance window is worth more than one that looks better on a diagram.
We also encourage a firewall review before any HA project. Rule bases that have grown for years are replicated faithfully to the standby unit, along with every weakness in them. Our firewall audit checklist is a good place to begin.
— Jacob
How we can help
Re-Solution designs, builds and supports Cisco network and security infrastructure for complex, multi-site organisations. If you want an independent view of an existing pair, our network audits examine design, capacity and configuration. If you would rather not run the firewalls yourself, our managed services cover monitoring and support, and our Network as a Service option provides the network on a subscription basis. For design and deployment work, see our professional services. You can also read how managed firewalls fit into network security, or look at our Cisco next-generation firewall and Meraki security offering.
A design review checklist
Before you sign off a firewall HA design, check each item:
- Both units are the same model, with matching licences and software versions.
- One unit alone can carry the measured peak load with all security features enabled.
- Failover and state links are dedicated and do not depend on the protected switching.
- Each firewall connects to two switches, and monitored interfaces are chosen deliberately.
- Timers are at vendor defaults or tuned with evidence, and tested under load.
- Internet and WAN circuits are diverse, and power is protected.
- A failover generates an alert, and someone owns the response.
- A failover test and an upgrade rehearsal have been run and documented.
- The rule base was reviewed before it was replicated.
FAQ
What is a firewall in HA mode?
It is one of a group of firewalls, usually two, configured to share configuration and session state so that one can take over if the other fails. In active/passive mode one unit forwards traffic and the other waits. In active/active mode both forward traffic.
Is active/active better than active/passive?
Not by default. Active/active can offer load sharing and faster failover, but it brings more complex routing, NAT and session handling. Each unit still has to be sized for the full load, so it does not remove the need for capacity headroom. Most sites are better served by the simpler active/passive design.
Does high availability stop all firewall downtime?
No. It protects against failure of one device. Configuration errors replicate to both units, and outages in circuits, switching or power can still take the site down. A resilient design treats the whole path.
Do both firewalls need to be identical?
Yes, in practice. Vendors require matching models, feature licences and software configuration for a pair to synchronise and fail over correctly. Check the specific requirements for your platform before purchasing.
Sources
- GOV.UK: How to install network infrastructure in shared buildings
- Cisco: Firewall and IPS Technology Design Guide
- Cisco: Secure Firewall Device Manager Configuration Guide 7.6, High Availability
- Cisco: Secure Firewall Reference Architecture for Individual Interface Mode Clusters
- Palo Alto Networks: High Availability overview
- Palo Alto Networks: HA Modes
Recommended
- Secure network architecture: a practical guide for IT leaders
- Explaining firewall policies: a practical guide for IT teams
- Understanding firewall security: a 2026 guide
- Role of firewalls in business: 2026 guide for IT teams
