DDNS updates wrong IP after CARP failover (system traffic uses node WAN IP instead of CARP VIP)

Chebec

Hi all,

I’m seeing a DDNS issue in a CARP HA setup where the DDNS client ends up updating the record with the physical WAN IP of the active node instead of the CARP VIP.

Environment

pfSense: 2.8.1 (HA pair)
Topology: 2-node CARP cluster (Master/Backup working as expected)
WANs:
- WAN1: single public IP + gateway
- WAN2: public subnet with multiple usable public IPs (8 total)
WAN2 addressing:
- Node A (current Master): WAN2 = x.x.x.2
- Node B (Slave): WAN2 = x.x.x.3
- CARP VIP (WAN2) = x.x.x.4 (VHID/advskew OK; VIP moves correctly)
DDNS:
- DDNS record is intended to always point to WAN active.
- DDNS entry is configured accordingly (interface/VIP), and NAT rules are built around the VIP

What works

Inbound/outbound traffic works correctly through WAN2 VIP:

With Node A as Master: inbound NAT hits VIP x.x.x.4 and works
After failover to Node B: inbound NAT still works once VIP moves to Node B

So CARP and NAT are fine for normal traffic and VIP movement.

Problem / symptom

During certain failover sequences (WAN failover to WAN1 and then return to WAN2), DDNS updates with the node WAN2 address instead of the CARP VIP.

From logs, the firewall performs an IP check (“check IP” / IP checker) before updating the provider DDNS.
However, the system-originated traffic for that IP check appears to egress using the node’s real WAN2 IP (x.x.x.2 or x.x.x.3) rather than sourcing from the CARP VIP x.x.x.4.
As a result:

IP checker detects the node’s WAN2 IP
DDNS update uses that detected IP
Provider record gets updated to x.x.x.2 or x.x.x.3
Inbound traffic breaks because our NAT/port forwards expect the public to hit the CARP VIP (x.x.x.4) only

Expected behavior

When DDNS is configured to update the WAN2 CARP VIP, the IP check and update should use/reflect the VIP (x.x.x.4), not the node interface address.

Questions

Is this a known behavior/bug in 2.8.1 where the DDNS “check IP” does not bind to the CARP VIP source address?
Is there a supported way to force the DDNS check/update traffic to source from the WAN2 CARP VIP?
Are there recommended settings (routing, gateways, “source address”, or NAT for firewall-originated traffic) to ensure DDNS always updates with the VIP?

Thanks in advance.

SteveITS

@Chebec I think that's the issue fixed in https://docs.netgate.com/pfsense/en/latest/releases/25-11.html#dynamic-dns and per the redmine TBD in 2.9.0?

Chebec

@SteveITS said in DDNS updates wrong IP after CARP failover (system traffic uses node WAN IP instead of CARP VIP):

@Chebec I think that's the issue fixed in https://docs.netgate.com/pfsense/en/latest/releases/25-11.html#dynamic-dns and per the redmine TBD in 2.9.0?

It would seem so, however, I'm forced to wait for pfSense CE 2.9.0 (not available at this time).
I also tried searching for patch 16326 under System > Patches (as indicated at https://redmine.pfsense.org/issues/16326 ), but it doesn't appear in pfSense CE 2.8.1.

SteveITS

@Chebec It doesn't look like they added it to the package yet. Try adding a new patch using "691852a2b79e60d06313538cb3910e98725034dd" as the commit ID.

Chebec

@SteveITS
I have never installed a patch this way before.
Is this procedure safe to use in a production environment?
If any issues arise, is it possible to roll it back?

SteveITS

@Chebec Have a read through:
https://docs.netgate.com/pfsense/en/latest/development/patches/custom.html
and the rest of the topic.

If you add a patch, it should detect whether it can be Applied and will or will not show the Apply button, as I recall. There is also a Debug button to test. Normally a patch can be reverted via that button, yes, unless the target file is later changed. (after updating pfSense you would not want to revert a patch and reintroduce a bug, just delete the custom patch)

Note there's a later patch ID in that redmine: 8544b85f8c32d0f180c09a4d0986ac819919bd2b

As long as patches are from Netgate developers I would have no issue installing them. For random patches in the forum I'd be a bit more cautious. In either case you can see the code being changed, in the patch details.

Edit: Marcos M in the redmine is a Negate dev.