Test pfSense WireGuard CARP maintenance separately from a powered-off node

A live former master can respond from a different address and influence the remote peer’s endpoint.

Source facts

Netgate warns that WireGuard address selection can behave unexpectedly with CARP. A node entering maintenance can stop owning the VIP yet continue replying from its interface address, causing the remote peer to keep contacting that node. Power-off and reboot differ because that node cannot send the unexpected reply. Letting the remote peer always initiate can work around documented initiation-source limitations.

Source: Netgate — WireGuard Limitations.

Applicability

This concerns the documented FreeBSD/pfSense WireGuard implementation with HA addressing.

DSE recommendation

DSE recommends recording the intended public endpoint and initiation direction alongside CARP ownership. Include planned maintenance, hard node loss, and restoration as separate acceptance scenarios. Avoid assuming an outbound NAT workaround makes initiation from a CARP VIP transferable between nodes; the source documents a state-ownership limitation. Coordinate tests with the remote VPN owner so endpoint changes can be observed rather than guessed from a local status indicator. Name maintenance, reboot, and power loss as separate HA acceptance cases. Retain the remote peer’s observed endpoint for each transition and compare it with the intended VIP. Do not use a successful power-off result to close an untested live-maintenance case.

Verification

Using an approved nonproduction peer, compare a CARP maintenance transition with a node shutdown. Inspect the observed source address and the peer’s learned endpoint after each event. Confirm which node carries application traffic and repeat restoration before declaring the design suitable for the required maintenance procedure.

Official reference

Netgate — WireGuard Limitations. Reviewed October 20, 2026.