
Configure High Availability on a SonicWall Pair
Before you run this
This guide pairs two identical SonicWall appliances into an Active/Standby High Availability cluster: the Primary handles all traffic, the Secondary sits synchronized and idle, and if the Primary fails the Secondary takes over the firewall's identity and keeps traffic flowing. That is the whole purpose — surviving a hardware failure without hand-rebuilding a box.
A few things to understand before you touch anything:
- You need full administrator access to the firewall's web management (SonicOS) GUI, and you need access to the MySonicWall account the units are registered under to associate them as an HA pair for licensing.
- This is a production-changing operation. When you enable HA and sync, the Secondary's configuration is overwritten by the Primary's — the Secondary becomes a clone. Do not put a firewall you care about into the Secondary slot expecting to keep its config.
- Keep an out-of-band path open. Have a laptop on the console/serial port of the Primary, or a management session on an interface you are not about to change. A wrong monitoring IP or a cabling mistake on the HA link can leave you unable to reach management while production traffic is also disrupted.
- Back up the running config first. In SonicOS 7 go to DEVICE | Settings > Firmware and Settings and export a settings backup (and take a system backup / snapshot) of the Primary before you begin. That export is your rollback.
- Do this in a maintenance window. Enabling HA can cause a brief interruption, and the first full sync reboots/reloads the Secondary.
- Test the failover before you trust it — force a failover once (covered at the end) so you know it actually works, rather than discovering it during a real outage.
- To roll back, set HA Mode to None on the Primary (covered at the end) and restore the settings backup if needed.
I am writing this for SonicOS 7.x on two appliances of the same model and same firmware version (for example two NSa 2700s or two TZ570s). HA will refuse to form or behave unpredictably if the models or firmware differ. If you are on the older SonicOS 6.5 GUI the concepts are identical but the menu layout differs — check the 6.5 admin guide for the exact paths.
Prerequisites
Get these right first; most failed HA builds are a prerequisite problem, not a settings problem.
- Two identical units, identical firmware. Update both to the same SonicOS build before pairing.
- Licensing association. HA itself is a licensed feature on the pair. Log into mysonicwall.com, and under the Primary unit's product page use the Associate option to add the Secondary as an HA Secondary. This lets the Secondary share the Primary's security licenses. If you skip this the pair can form but the Secondary won't inherit services correctly.
- The HA link. SonicWall uses a control/heartbeat connection between the two units.
- Some models have a dedicated HA port; on those you cable HA port to HA port directly.
- On models without one, you dedicate a data interface as the HA Control interface.
- Consult your model's page in the SonicOS 7 High Availability administration guide for which interface your specific model uses — do not guess this, because designating the wrong interface will drop it from data use.
- Matching cabling. Every interface used on the Primary must be cabled the same way on the Secondary. The Secondary's X1 must reach the same WAN, X0 the same LAN, and so on. HA fails over the logic, not the wiring.
- Two spare management IPs. For monitored interfaces you'll assign a per-unit management IP to the Primary and the Secondary so you can manage each individually while the shared (virtual) IP floats.
Configure HA on the Primary
Do all of this on the Primary only. The Secondary is configured by sync, not by hand.
- Log into the Primary's SonicOS GUI.
- Go to DEVICE | High Availability > Settings.
- Set the HA Mode to Active/Standby. (The dropdown also offers Active/Active DPI and clustering modes — Active/Standby is the standard, mainstream failover setup and what this guide covers.)
- If you want session/state to survive failover so existing connections don't drop, enable Stateful Synchronization (labelled as a stateful HA option on this page). Leave it off for a simpler, connection-resetting failover.
- In the HA Devices / serial number fields, confirm the Primary Serial Number is filled (your current unit) and enter the Secondary Serial Number — the exact serial printed on the Secondary appliance.
- Set the HA Control (and Data, if your model uses a separate one) interface to the port you cabled between the two units, per your model's guide.
That is the core. There are additional timing and behaviour settings (heartbeat interval, probe interval, election delay, and Preempt Mode, which makes the Primary reclaim the active role after it recovers). The defaults are sane for most deployments — leave them unless you have a reason. If you enable Preempt Mode, understand it will cause a second failover when the Primary comes back, so only enable it in a maintenance window or when a second brief interruption is acceptable. For the exact field names and default values, see the Settings section of the SonicOS 7 High Availability admin guide rather than trusting a number from memory.
Set per-unit management (Monitoring)
So you can still reach each box individually:
- Go to DEVICE | High Availability > Monitoring.
- For each interface you want to monitor and manage (typically LAN/X0 and WAN/X1), set:
- the Primary IP Address — a management IP unique to the Primary,
- the Secondary IP Address — a management IP unique to the Secondary,
- and enable management on those IPs.
- Enable logical/physical monitoring on the interfaces whose link loss should trigger a failover (for example the WAN uplink). Don't monitor an interface that legitimately flaps or you'll cause needless failovers.
Save. The Primary will begin syncing to the Secondary. The Secondary reboots into standby and pulls the Primary's configuration.
Verify it worked
- On DEVICE | High Availability > Settings (or the dashboard status), confirm the pair shows Primary — Active and Secondary — Standby, and that the status reads synchronized / ready. A Secondary stuck in "Not Ready" usually means the HA link or serial number is wrong.
- Browse to the Secondary's per-unit management IP — you should reach it and see it identify as the Standby.
- Check the log (MONITOR | Logs) for HA state messages confirming synchronization completed.
Now prove failover, in your maintenance window:
- Trigger a controlled failover. SonicOS provides a manual failover / force active control on the High Availability status area — use that, or physically pull the Primary's power. Watch the Secondary transition to Active and confirm production traffic continues (ping through, an active session, or a test HTTP request).
- Restore the Primary. If Preempt is off, the Secondary stays active (this is fine); if on, the Primary reclaims active after it's back and synced.
Undo / roll back
To dismantle HA cleanly:
- On the currently Active unit, go to DEVICE | High Availability > Settings and set HA Mode back to None.
- Save. The units become independent again.
- If anything is inconsistent, restore the settings backup you exported at the start via DEVICE | Settings > Firmware and Settings.
If you'd previously associated the units in MySonicWall and want to fully separate them, remove the HA association there as well.
That's the standard, boring, reliable Active/Standby build. Get the prerequisites and cabling right, test one real failover, and it will do its job the day the Primary dies.
Runs enterprise networks and security for a living, and writes Shore Up to turn two decades of hands-on Linux, Windows and mail-server work into guides you can actually use.
More about the author →Was this article helpful?
Tap a star — no sign-in needed.
Be the first to rate this article.
