pfSense

Just a fix to this section:

What actions I did to fix the issue ?

Changed Firewall State Policy from Interface Bound States to Floating States.
This fixed the issue.

Hello Marcos, thanks for answering.

I'll try to simulate that in my lab, I'll install a new NIC in my server to map that with libvirt.
But I can't do it right now, too busy lately unfortunately.

As soon as I have some free time, I'll test and update here.

Thanks.

Hello, my ticket #16716 has been closed as a duplicate of this one. It seems this is indeed the same problem, except I haven't meddled with this "Firewall State Policy" setting for now.

Considering this problem is still happening on pfSense Plus 25.11.1, I think you can change this ticket back as not resolved.

Of course if you need to do some tests, I can do that.

Can you test that on 26.03-BETA? I set the default IPv4 gateway to a gateway group of WAN1 (tier 1) and WAN2 (tier 2) then configured a DDNS entry that uses WAN2 as the interface. After clicking "Save & Force Update" the IP address of WAN2 was used for the update.

I'm not a fan of running the Beta version of an OS on my hardware, but fine... I am now running pfSense Plus 26.03.b.20260219.2016 on a Netgate 8200.

I did some tests and discovered that the type of the interface matters! Something I didn't checked in my previous tests and probably caused a lot of confusion. I was just using any WAN that is not the default one, so I'm not sure of my previous results anymore, as I don't know if the bug affected any interface in the previous version, or if I simply kept selecting an interface of the 'wrong' type.

• When monitoring the WAN interface (SFP+ port), the DynDNS correctly updated with the IP address of WAN
• When monitoring the WAN2 interface (RJ45 port), the DynDNS correctly updated with the IP address of WAN2
• When monitoring the WAN_VPN interface (Wireguard client), the DynDNS FAILED the update by using the default WAN (I checked by using WAN as default and then WAN2, and got consistent results in both cases)

I think the DynDNS service mistakenly don't send the IP check on a tunnel interface, but on the underlaying interface that supports the tunnel.

Also the logging problem is back on the Beta, I have enabled verbose logging but all I get in the logs is "check_reload_status / Syncing firewall", except when there is an error. When the server of the update URL doesn't respond (because I forgot to launch it one time), the DynDNS service logged an error after an insanely long timeout of 75000ms! This default value is WAY too high and should definitely be lowered and/or made customizable.

Regarding the logging in 26.03, you'll need to increase the default log level to at least "Info" under Status > System Logs > Settings to show informational messages. I'll add a note about that for the future.

Edit: I've just tested this (Dynamic DNS, not RFC 2136) with both OpenVPN and WireGuard and in both cases the A record was updated to the VPN's public address. This would indicate there's likely a misconfiguration on the system where it's failing. A quick way to test that the traffic would take the correct route is to start a packet capture on the WireGuard interface then run a ping from the WireGuard interface's address. For example: ping -S 10.1.1.1 198.51.100.1. Alternatively contact TAC (if you have it) or follow up on the forum for assistance.