# 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.

- Canonical URL: https://update.dsesecurity.com/updates/test-pfsense-wireguard-carp-maintenance-separately-from-a-powered-off-node/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:16:28+00:00
- Modified: 2026-10-20T18:34:35+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

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

## Potentially affected

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.

## Article

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](https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/limitations.html).

## 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](https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/limitations.html). Reviewed October 20, 2026.

## Primary reference

- Name: Netgate — WireGuard Limitations
- Authority: docs.netgate.com
- URL: https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/limitations.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Test pfSense WireGuard CARP maintenance separately from a powered-off node,” DSE Security, https://update.dsesecurity.com/updates/test-pfsense-wireguard-carp-maintenance-separately-from-a-powered-off-node/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.