Conntrack sync#

The third tab of High availability, at /ha?tab=conntrack. It owns the service conntrack-sync subtree.

A VRRP failover moves an address. It does not move the connection-tracking table, so every established flow through the old master is unknown to the new one, and the new master drops the packets that belong to them. Connection-tracking sync fixes that: the two routers exchange conntrack state over a dedicated link, and the one that becomes master already knows every connection.

Where the data comes from#

The tab reads GET /api/vrrp — the same call the VRRP tab makes — and uses two parts of it: conntrack_sync, which is the service conntrack-sync configuration subtree, and the VRRP sync groups, which the editor's picker offers. The interface picker comes from GET /api/interfaces/detail, minus lo — agent/gaps.go, ui/src/pages/Ha.tsx.

When it is configured#

The left panel is a read-out of five values:

Field	Node
Sync interface	`interface`
Failover mechanism	the keys under `failover-mechanism`
VRRP sync group	`failover-mechanism vrrp sync-group`
Accepted protocols	`accept-protocol`, or all when unset
Listen address	`listen-address`, or multicast when unset

Remove conntrack sync stages one operation:

delete service conntrack-sync

When it is not#

The panel explains what the feature is for and gives the three commands that turn it on, and a second panel appears beside it with the editor. Once it is configured, the editor panel disappears — this is a create-or-delete screen, not an editor. To change the sync interface you remove it and add it again, or edit the subtree from the CLI.

The editor#

Field	Command	Required
Sync interface	`set service conntrack-sync interface <if>`	yes — nothing is staged without it
VRRP sync group	`set service conntrack-sync failover-mechanism vrrp sync-group <name>`	no, but see below
Protocols	`set service conntrack-sync accept-protocol <p>` per protocol	tcp, udp and icmp are ticked by default

A complete result:

set service conntrack-sync interface eth3
set service conntrack-sync failover-mechanism vrrp sync-group HA
set service conntrack-sync accept-protocol tcp
set service conntrack-sync accept-protocol udp
set service conntrack-sync accept-protocol icmp

The sync-group picker only lists groups that already exist under high-availability vrrp sync-group. When there are none the hint says so: create a sync group on the VRRP tab first. You can stage the sync without a group, but then nothing tells conntrackd when a hand-over has happened, which is the point of the mechanism.

The sync interface#

The field's hint is the requirement: a dedicated link to the partner router.

Dedicated. Conntrack sync traffic is a running commentary on every flow through the router. On a busy box it is not a trivial amount of traffic, and it is unencrypted and unauthenticated. It belongs on a cable between the two routers, or at least a VLAN that carries nothing else.
Not a VLAN sub-interface, from this picker. The list is built from GET /api/interfaces/detail, which does not enumerate vif children — see what the Interfaces table does not show. A VLAN sync link is a CLI command.
Both routers. Each end needs its own service conntrack-sync interface pointing at its side of the same link.

What it does not do#

It does not synchronise anything else. Not NAT bindings beyond what conntrack itself carries, not IPsec state, not DHCP leases, not the configuration. The second router's configuration is your job — the CLI tab renders the whole HA configuration as commands for exactly that.
It does not report. There is no status, no counter of synchronised entries and no peer-reachability indicator on this tab. The tile on the VRRP tab says configured or off, which is a configuration read.
It does not help a single router. Without VRRP there is nothing to fail over to.

What breaks if you get it wrong#

No sync group. Failover happens, the tables are broadly in step, and there is no event telling conntrackd to commit the external cache at the moment of hand-over.
Sync over the LAN. It works, and now every flow record is on the segment your users are on.
Only TCP accepted. Long-lived UDP flows — VPN tunnels, VoIP calls — drop at the failover even though the TCP ones survive.
Asymmetric configuration. One router syncing and the other not means failover works in one direction only, and it will be the direction you did not test.

Verifying it#

There is nothing on this page to check against, so check the connection-tracking table itself. On the master it fills as usual; on the backup it should fill too, with the master's flows, once sync is working. GET /api/sessions reads that table on whichever router the agent is pointed at, and the connection-tracking pressure tab on Diagnostics reads its per-CPU statistics — see Diagnostics → Health.