Run two Korthveil firewalls as a pair: one is active and carries your internet and your gateway address; the other is on standby and takes over within seconds if the active one stops, then hands back when it returns. Your devices keep using the same gateway address and notice at most a second or two. The screenshots are from a test pair; the example addresses are a home network with a rack firewall (korthmain) as the main firewall and a NUC as the standby.
The example pair:
| korthmain (rack, 6 ports) | NUC (2 ports and Wi-Fi) | |
|---|---|---|
| Role | Primary (priority 200): active whenever it is up | Secondary (priority 100): standby |
| Own LAN address | 192.168.2.4 | 192.168.2.3 |
| Shared gateway (moves to the active one) | 192.168.2.1 | 192.168.2.1 |
| Internet port | enp1s0 | enp2s0 |
| LAN port | enp2s0 | enp1s0 |
What moves on a failover: the shared gateway address (192.168.2.1, and an IPv6 one), the internet port and its address from the ISP, the DHCP server and Gaming & apps (UPnP). Firewall rules, NAT, the DNS resolver and VPN servers run on both, so they are ready; open connections continue because the boxes copy their connection state.
When your ISP gives one address: most home connections give one public address, by DHCP, to one device. The pair handles this: both firewalls use the same MAC address on their internet port, and the port is up only on the active firewall. The ISP sees one device and gives it the same address, whichever firewall that is.
The ISP knows your current firewall by its internet port's MAC address. On both firewalls, Network › Interfaces › the internet port › Edit:
Then connect the second firewall's internet port to a free port on the modem (or a small switch between the modem and both firewalls). It stays down while the other firewall is active.
On each firewall: Network › High availability, turn the add-in on, and set:
This node: korthmain primary, priority 200; the NUC secondary, priority 100. Preemption on: the primary takes the active role back when it returns.
HA link: the port the firewalls use to talk to each other (the LAN port works; a direct cable between spare ports is better) and the peer's own address on it.
Virtual addresses: on the LAN port, VRID 1, IPv4 192.168.2.1/24, and an IPv6 address from your LAN prefix if your LAN uses IPv6. The same on both firewalls. From 1.1.21 an IPv4 address alone works too (1.1.20 needed an IPv6 one as well).
Each firewall has two IPv4 addresses on the LAN: its own (.4 on korthmain, .3 on the NUC), which never moves and is how you reach that firewall's web console, and the shared one (.1), which only the active firewall holds. The own address must differ from the shared one (Step 5 changes the current firewall's own address).
No fixed LAN gateway: leave the LAN port's gateway empty on both firewalls. The active one has the internet itself. The standby gets a route through the shared address only while it is standby, so it still reaches updates, SentinelOps and time servers. A gateway set to the shared address is removed by the sync, because the active firewall would route through itself.
The active firewall sends its configuration to the standby after every commit, so you configure one firewall and the other follows.
On each firewall, High availability › Peer pairing:
https://192.168.2.3.
Save and Commit on each firewall. What stays local to each firewall and is never overwritten: its hostname, its own addresses on the shared-address ports, its management port, its HA role and pairing, and its SentinelOps enrollment.
Pick a quiet moment: this step moves your gateway address.
The configuration sync copies the WireGuard tunnels to the standby firewall. From 1.1.30, the standby keeps every VPN client tunnel (a provider such as NordVPN or IPVanish, and every tunnel in a gateway group) idle: it does not connect to the provider. Only the active firewall does, so the provider never sees two connections of one account. When the standby becomes active, it connects its tunnels and the gateway groups start from tier 1. Remote-access tunnels (the firewall as WireGuard server) run on both.
Before 1.1.30, both firewalls connected the provider tunnels and the provider kept dropping one of them. If you added a rule that blocks the standby's UDP 51820 as a workaround, remove it after updating both firewalls.
Update one at a time, each with a live update (see Updating Korthveil): first the standby, then Force failover on the active one, update it, then Clear forced failover.
The pairing trusts one exact certificate of the other firewall, by its fingerprint. When that firewall gets a new web certificate (for example after it is reinstalled, renamed, or its certificate is replaced under System › Certificates), the active firewall stops sending it the configuration. Nothing else changes: the pair still fails over, and your internet keeps working. But changes you commit no longer reach the standby.
What you see: the top-bar light turns amber (Failover · Active). Hover over it: the last line says
Sync problem: the peer cannot be reached: … the peer's certificate is 4b63…, not the paired 8248…
The first fingerprint is the certificate the other firewall shows now; the second is the one paired.
Check that the new certificate is really the other firewall's. Sign in to the other firewall's own address (the NUC in the example: https://192.168.2.3), open Network › High availability › Peer pairing, and read This firewall's certificate fingerprint. It must be exactly the first fingerprint of the message. If it is not, do not trust it: another device is answering at that address.
Trust it on the active firewall (korthmain in the example):
The record: System › Audit log lists who did it, from which address, and when: the commit (with its note), and the configuration sent to the peer (ha.sync.push).
If the active firewall's own certificate changes instead, do the same the other way round: paste its new fingerprint on the standby, which then accepts the configuration again.
The pictures in this section are from the home pair (korthmain active, the NUC on standby), 2 November 2026, when the NUC had made itself a new certificate.
| You see | Meaning | What to do |
|---|---|---|
| Failover · Starting (amber) | The pair add-in has not reported a role yet | Wait a few seconds; check that the add-in is on and committed |
| Both firewalls active | They cannot hear each other on the HA link | Check the cable or switch between them; the standby refuses configuration while both are active |
| Last refusal: wrong pairing secret | The secrets differ | Enter the same secret on both and commit |
| Amber light; … not the paired … certificate | The other firewall has a new certificate | Check and trust it: see When the other firewall gets a new certificate above |
| The peer's ports … have no counterpart | The port map is incomplete | Map every peer port, or mark it not on this firewall |
| Standby gets no internet address after a takeover | The MACs differ | Both internet ports need the same cloned MAC |
| Commit refused: Sync group … has only 1 virtual router(s) | 1.1.20 with only an IPv4 shared address | Update to 1.1.21, or add an IPv6 shared address as well |
| High availability page: … interfaces is null | 1.1.20 stored a zone without ports after the sync | Update to 1.1.21 (both firewalls) |
| The standby cannot check for updates | 1.1.20 had no route on the standby | Update to 1.1.21: the standby routes through the shared address |