pfsync interface and security

pfsync is a FreeBSD protocol designed for direct, trusted communication between two peer firewalls. It is not designed to defend against malicious input.

This lesson spells out the security model and what happens when it is violated.

What is on the wire

A pfsync packet carries:

• A state insert message: tuple (src, dst, sport, dport, protocol), state flags, expiry, creator.
• A state update message: changed fields.
• A state delete message: the tuple to remove.

There is no cryptographic signature, no authentication header, no sequence number that would let the receiver reject replay. A peer that receives a pfsync packet trusts it.

What an attacker can do

An attacker who can transmit on the pfsync interface can:

1. Manufacture states. Send a crafted pfsync insert message claiming a TCP connection from any source IP to any destination IP. The peer applies it. The peer now allows traffic matching that tuple.
2. Delete states. Send a pfsync delete for a legitimate connection. The peer’s state table loses the entry. The next packet from the connection is matched as a new flow and rejected (because no rule permits it).
3. Reset state flags. Send a pfsync update that turns an established connection into a closed state. The peer tears down the connection.

None of this requires authentication. None of this leaves a log entry by default. The attack is silent.

The isolation requirement

The only protection is isolation. The pfsync interface must live on a network segment that no other host can transmit on. Practical implementations:

• A direct crossover cable between the two firewalls.
• A separate VLAN on a managed switch, with the VLAN configured to allow only the two sync ports (no other ports).
• A private subnet on a virtual switch (Proxmox, VMware) with no other VMs attached.

A shared broadcast domain — even one that has firewall rules restricting it — is not isolated. A misconfigured switch, a compromised host on the same VLAN, or a Layer 2 attack can inject pfsync packets.

The audit

The audit for pfsync isolation is a single check:

“Can any host that is not one of the two firewalls send traffic on the pfsync interface?”

If the answer is “yes, in theory”, the deployment has a vulnerability. The fix is immediate reconfiguration to a truly isolated segment.

What about TLS for pfsync?

OPNsense and FreeBSD do not support TLS for pfsync. The security model is the isolation of the sync interface. If you need a cryptographically secure HA protocol, the options are limited:

• A separate IPsec tunnel between the two firewalls, with pfsync running inside it.
• A direct physical link that is physically secure.

The first option requires running a control-plane IPsec tunnel between the two firewalls. This is supported but operationally more complex. The second option is the standard pattern.