A dual-machine WAF pair fails in two very different ways: the system log warns about a VRRP heartbeat that's actually a configuration mismatch, not a dead peer -- and a single protected site goes dark while every other site on the same pair keeps working fine. Here's how to read both correctly, the HA checklist that prevents them, and the exact fix for each.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
One looks like a network problem and isn't; the other looks isolated to one site and is actually an addressing conflict that spans several.
Dual-machine hot standby on a WAF is supposed to be boring -- one active node, one standby, a virtual IP that doesn't care which physical box answers it. In practice, two faults account for most of the tickets: a system log entry that says the VRRP heartbeat between the pair is abnormal, which reads like a network or cabling problem but is almost always a protected-site configuration mismatch instead; and a single reverse-proxy site going unreachable while its neighbors on the same pair are fine, which traces back to a link-address overlap rather than anything wrong with HA itself.
What follows is how to read each of these correctly, the HA configuration checklist worth running before either one shows up, the gotchas that account for most of what's actually wrong, and field-sourced FAQ answers.
Transparent-proxy HA and reverse-proxy HA don't even negotiate over the same interface -- mixing them up wastes the first ten minutes of any investigation.
Both deployment modes share a virtual IP and an active/standby role, but the heartbeat path underneath is different: transparent-proxy pairs negotiate over a directly-connected HA port on the panel, while reverse-proxy pairs negotiate over the management port instead -- which has to sit in the same subnet as its peer and be routable. Getting this straight first tells you which interface is actually worth troubleshooting.
Diagram labels are kept in English for engineering clarity.
The second fault sits below the HA layer entirely: reverse-proxy protected sites each carry their own front-end and back-end link addresses, and when a new site's link address collides with another site's -- or with its own subnet's broadcast address -- the affected site goes dark while the HA pair itself reports nothing wrong at all, because nothing about the standby relationship actually broke.
Different symptom, different place to look -- the log message and the affected scope point you to the right one immediately.
In reverse-proxy mode this specific log line isn't a network alarm -- it's the WAF telling you the two nodes' protected-site configs don't match.
System log (reverse-proxy mode):
VRRP peer heartbeat abnormal
// this line fires when "Apply Changes" finds a protected-site mismatch
// with the peer -- it is a config-diff alarm, not a link-down alarm
Fix:
Configuration > Configuration Sync > Sync Config File
(run from the node with the complete / correct site configuration)When only one protected site is affected, it's an addressing conflict on that site's link, not an HA or forwarding-rule problem.
Config check: Configuration > Protected Sites
Site A front-end link: 10.10.0.11 back-end link: 10.10.1.11
Site B front-end link: 10.10.0.12 back-end link: 10.10.1.11 // <- collides with Site A
// overlapping back-end link address -> Site B silently unreachable, Site A unaffected
Packet capture interfaces:
Lo -> server-side address
site front-end interface -> link address (front-end)
site back-end interface -> link address (back-end)Once you know which of the two faults you're looking at, these account for most of what's actually wrong.
SYMPTOMSystem log: VRRP peer heartbeat abnormal, in reverse-proxy mode, with the HA link itself apparently fine.
CAUSEThe two nodes' protected-site configurations don't match. Clicking Apply Changes on one node triggers a check against the peer's configuration, and any difference logs this exact line -- it's a configuration-diff detector, not a liveness check on the peer.
FIXSync the complete configuration from the correct node via Configuration > Configuration Sync > Sync Config File, and make a habit of editing sites on one node only.
SYMPTOMOne specific reverse-proxy protected site is unreachable; every other site on the same pair works normally.
CAUSEReverse-proxy link addresses (front-end and back-end) have to be unique across every protected site on the box. A new site's link address colliding with an existing site's -- or landing on the subnet's own broadcast address -- causes silent misdirection with no error anywhere in the HA layer.
FIXAudit Configuration > Protected Sites for the affected site's link addresses against every other site's link addresses and their subnet broadcast address before looking anywhere else.
Site A back-end link: 10.10.1.11
Site B back-end link: 10.10.1.11 // duplicate -> Site B silently unreachableSYMPTOMReverse-proxy HA negotiation reports abnormal even though the two nodes' configs “look the same”.
CAUSEReverse-proxy dual-machine requires identical protected-site configuration on both nodes except for VRRP role. The field that actually breaks things is the virtual route ID, which has to be identical between the pair for the same site while the active/backup role differs -- a duplicate virtual route ID across different sites on the same device is a separate, silent failure mode.
FIXConfirm every protected site has VRRP enabled, that each device's active/backup role is consistent across all of its sites, and that no two sites on the same device share a virtual route ID.
SYMPTOMHA negotiation abnormal, and the interface being checked doesn't match the deployment mode.
CAUSETransparent-proxy dual-machine heartbeat negotiates over the directly-connected panel HA port. Reverse-proxy dual-machine heartbeat negotiates over the management port instead, which additionally has to sit in the same subnet as the peer's and be routable -- troubleshooting the wrong one of these wastes time on cabling or routing that was never the problem.
FIXConfirm the deployment mode first, then check the matching interface: HA port for transparent proxy, management port reachability for reverse proxy.
SYMPTOMTransparent-proxy HA negotiation abnormal, with both boxes individually configured and seemingly fine.
CAUSEOne device is set to dual-active mode while the other still expects a primary/backup relationship -- or the HA configuration's local-IP and peer-IP fields have been entered the wrong way round on one side.
FIXConfirm both devices select the same mode (both dual-active, or one primary plus one backup), and re-check the HA Configuration page's local-IP versus peer-IP assignment on both nodes.
Pulled from field cases -- the ones worth having a ready answer for.
Transparent-proxy dual-machine negotiates its heartbeat over a directly-connected HA port on the device panel. Reverse-proxy dual-machine negotiates over the management port instead, and that management port additionally has to be in the same subnet as the peer's and actually routable -- it's not interchangeable with the HA port used in transparent mode.
Not usually. In reverse-proxy mode this specific message fires when the node you applied changes on checks its protected-site configuration against the peer's and finds a mismatch -- it's a configuration-diff alarm dressed up as a heartbeat warning. Sync the configuration from the correct node via Configuration Sync before assuming there's a cabling or routing problem.
Almost always no -- check whether the new site's front-end or back-end link address overlaps an existing site's link address, or the broadcast address of its subnet. That collision causes exactly this pattern: one specific site goes dark while its neighbors, and the HA pair itself, look completely normal.
Check System Logs for any alarms first, then confirm the number and content of protected sites match between the pair and that configuration sync has actually completed. In Configuration > Protected Sites, confirm every site has VRRP support enabled, that each device's active/backup role is consistent across all its sites, and that virtual route IDs aren't duplicated.
Confirm both devices are set to the same mode -- either both dual-active, or one primary and one backup, not a mismatch between the two. Then check Configuration > HA Configuration on both nodes and confirm the interface IP fields are correct, specifically that local IP and peer IP haven't been entered backwards on either side.
This note is built around a Huawei WAF appliance's dual-machine hot-standby model -- its HA port / management-port heartbeat paths, its VRRP-based reverse-proxy failover, and the protected-site configuration model behind both field cases here. If your platform uses a different HA mechanism, the exact menu paths and log strings change, but the underlying pattern -- verify configuration sync before assuming a network fault, and check for addressing collisions before assuming an HA fault -- carries over directly. It doesn't cover geographically dispersed (cross-site) HA designs, or active-active clustering beyond the dual-active mode mentioned above.
Tell us the exact log message or which specific site is affected, plus whether you're in transparent or reverse-proxy mode, and we'll help you narrow it down.