Configure Interface Monitoring and Failover Detection on a SonicWall HA Pair

By default a SonicWall HA pair fails over when the active unit dies outright — power loss, hardware fault, a crash that stops the heartbeat. What it does not do out of the box is fail over when a single data interface loses link or when the upstream next hop goes away but the appliance itself is fine. Interface monitoring closes that gap: you tell the cluster which interfaces matter, and optionally give it an upstream target to probe, so a dead WAN or a pulled LAN cable forces the standby to take over.

Before you run this

This is a GUI configuration change on a live firewall cluster, made from the SonicOS web management interface. There is no script and no shell — everything here is done in the SonicOS 7 admin GUI on the active unit, and it synchronises to the standby automatically.

• What this does: enables physical (link) and optional logical (probe) monitoring on selected interfaces of an existing HA pair, so loss of link or loss of upstream reachability triggers a failover to the standby unit.
• Privileges: you need a full administrator account on the appliance. There is no OS-level sudo here; the equivalent is logging in as the built-in admin (or an admin-role account) on the active unit. Config-only or read-only accounts cannot save these changes.
• This changes failover behaviour on a production security appliance. A mis-set probe target, or monitoring an interface that legitimately flaps, can cause repeated or unwanted failovers and drop production traffic. Treat it with that caution.
• Keep a second way in. Have a console (serial/CLI) connection open to at least one unit, or out-of-band management, before you touch anything. If a change makes the management interface unreachable, that console is how you recover.
• Back up first. Export the current settings before you change a thing: Device → Settings → Firmware and Settings, then create a local backup and also Export Configuration to a file you keep off-box. Rollback is: re-import that settings file, or boot the previously saved firmware/settings image from the same page.
• Do it in a maintenance window, and if you can, rehearse on a lab pair or a spare cluster first. The verification step deliberately triggers a real failover, which is disruptive.

Assumptions

I'm writing for SonicOS 7.0 / 7.1 on two identical appliances (same model and firmware) already configured and running as a Stateful HA Active/Standby pair: the HA control/data link is cabled, both units are licensed and associated, and the HA status page already shows one Active and one Standby unit. Menu labels below are from SonicOS 7; on SonicOS 6.5 the same settings live under Manage → High Availability and the field names are close but not identical.

If your pair isn't formed yet, stop — set up HA first (Device → High Availability → Settings), confirm it's healthy, and come back.

Step 1 — Confirm the cluster is healthy before you change it

Go to Device → High Availability → Status (some builds show this on the Settings page). Confirm:

• One unit is Active, one is Standby.
• The state is settled (not "Election" or a synchronising loop).
• Settings synchronisation shows success.

Never add monitoring to a pair that is already unstable — you'll just make diagnosis harder.

Step 2 — Enable interface monitoring

Navigate to Device → High Availability → Monitoring.

You'll see a table of interfaces. For each interface whose failure should trigger failover (typically your WAN and your primary LAN), edit the row (the pencil/configure icon). In that dialog you can:

• Enable physical / link interface monitoring for that interface. This is the simple case: if the port loses link, that unit is considered failed for election purposes.
• Set the per-unit management IP addresses for the interface — a Primary (active-unit) address and a Secondary/Backup (standby-unit) address on that subnet. These give each unit an always-reachable management address regardless of which one is active, and they're also used as the source for probing.

The exact checkbox and field labels ("Enable Physical Interface Monitoring", the Primary/Backup IP fields, and the "Override Virtual MAC" option) are described with screenshots in the SonicOS 7 Administration Guide, High Availability → Monitoring section. Confirm the wording against your firmware build rather than trusting a label from memory — SonicWall has moved these between point releases.

Assign the per-unit management IPs from addresses you actually own on that subnet. For example, if LAN is 192.168.10.0/24:

• Interface X0 Primary management IP: 192.168.10.2
• Interface X0 Backup management IP: 192.168.10.3

Replace those with real, unused addresses on your subnet.

Save the interface, and repeat for each interface you want monitored. Don't monitor an interface that is legitimately allowed to be down (an unused port, a WAN you expect to drop) — that will cause spurious failovers.

Step 3 — Add logical (probe) monitoring where link-up isn't enough

Physical monitoring only sees the local link. If your WAN port stays up but the ISP's gateway dies, link monitoring won't notice. Logical monitoring fixes that: the unit periodically probes a target IP through that interface, and treats "target unreachable" as a failure.

In the same interface dialog on the Monitoring page, set a Logical / Probe IP address — a reliable upstream host that answers ICMP (for a WAN, the ISP gateway or a stable public host you're allowed to ping; for LAN, a core switch SVI or a critical internal server). Enable probe monitoring for that interface.

Pick a target that is genuinely representative of "this path works." A host that goes down for its own reasons will drag your firewall into failover with it.

Step 4 — Review failover timers (only if you must)

Probe interval, probe count/threshold, and the HA heartbeat and election-delay timers live under Device → High Availability → Settings and its Advanced section. The defaults are sane — leave them unless you have a specific requirement (e.g. a slow WAN where the default probe timing false-positives).

I'm not going to quote specific default millisecond/second values here, because they vary by model and firmware and I won't have you paste a wrong number into production. If you need to tune them, read the exact field names and defaults in the SonicOS 7 Administration Guide, High Availability → Settings/Advanced section for your build, change one value at a time, and note the original so you can restore it.

Verify it worked

1. Check monitoring is active and healthy. Return to Device → High Availability → Monitoring / Status. Confirm the monitored interfaces show as up/OK on both units and that your per-unit management IPs respond:

ping 192.168.10.2   # active-unit management IP
ping 192.168.10.3   # standby-unit management IP

Both should answer regardless of which unit is currently active. Substitute your real addresses.

2. Test a controlled failover — in the maintenance window. Trigger the condition you configured for and confirm the standby takes over:

• For physical monitoring: unplug the monitored cable on the active unit (or shut the upstream switch port).
• For probe monitoring: block the probe target's reachability from the active path.

Then confirm on Device → High Availability → Status that the roles swapped (former standby is now Active) and that production traffic and management stay up. Reconnect and confirm the pair re-syncs to a clean Active/Standby state.

SonicOS also offers a manual/forced failover control on the HA pages for testing without pulling cables — check the Status/Settings page in your build for the exact button, and use it in place of physically disrupting a link if you'd rather.

Undo / rollback

• Undo one interface: edit that interface row on the Monitoring page and clear the physical- and probe-monitoring options (and remove the probe IP). Save.
• Undo everything: re-import the settings file you exported in "Before you run this" (Device → Settings → Firmware and Settings → Import Configuration), or boot the saved settings image from the same page. That reverts the whole configuration, so only use it if you want a full rollback.

After any rollback, revisit Device → High Availability → Status and confirm the pair is back to a settled Active/Standby state before you leave the maintenance window.