What appears to be happening is dpinger binds to the interface IP via -B as expected. The problem is that pf's binat rule is intermittently firing for the ICMPv6 probe traffic, translating the source address before it leaves the interface:

tcpdump -i tun_wg0 -n ip6 ← broken gateway

PREFIX:0:2:0:2 > MONITOR_IP: ICMP6 echo request   ← source translated by binat
MONITOR_IP > PREFIX:0:2:0:2: ICMP6 echo reply      ← reply goes to NAT addr, not ::6

tcpdump -i tun_wg1 -n ip6 ← working gateway

PREFIX:0:2:0:a > MONITOR_IP: ICMP6 echo request   ← source intact, no translation
MONITOR_IP > PREFIX:0:2:0:a: ICMP6 echo reply      ← reply received correctly

The 1:1 NAT rules are identical on both interfaces. IPv4 binat is also loaded on both but doesn't fire for ICMP probes (which is the correct behavior). This seems specific to ICMPv6 and appears to be a transient pf state issue triggered during interface initialization.

Trigger conditions:
Reboot — one of the two IPv6 gateways is affected at random
Editing or restarting an assigned interface or IPv6 gateway — the gateway associated with that interface is affected

Workaround:
Restarting the WireGuard service immediately fixes it — no config changes needed:
VPN > WireGuard > (restart service). It stays fixed until one of the trigger conditions above happens again.

Has anyone seen this or found a more permanent fix?
Happy to provide additional captures or config details.

I’ll try to lay this out as concisely as I can, but I’m baffled by an odd issue (or a misunderstanding) with an IPsec setup I am working on in my lab.

The VPN is connected and working and I’ve done a ton of troubleshooting already with no luck. Below is the layout, then I’ll explain what’s not working.

• Site A

• Local subnet of 10.10.12.0/24 with a host at 10.10.12.10 which I am using for testing

• IPsec Phase 2 setup to connect to Site B

• Network NAT enabled on the Phase 2 to NAT to subnet 172.16.51.0/24

• Firewall rules on the 10.10.12.0/24 subnet to allow pinging to a 192.168.15.0/24 subnet at Site B

• Firewall rules on the IPsec tab to allow 192.168.15.0/24 to ping back to 10.10.12.0/24 (since NAT is processed first, as documentation talks about)

• Site B

• Local subnet of 192.168.15.0/24 with a host at 192.168.15.10 for testing

• IPsec Phase 2 setup back to Site A

• No NAT enabled

• Phase 2 is setup with the Remote Network as Site A’s NAT subnet

• Firewall rules on the 192.168.15.0/24 subnet to allow pinging back to 172.16.51.0/24

• Firewall rules on the IPsec tab to allow 172.16.51.0/24 to ping 192.168.15.0/24

The issue I am having is that 192.168.15.10 at Site B can not ping 172.16.51.10 (which translates to 10.10.12.10) at Site A. However, Site A’s 10.10.12.10 can ping 192.168.15.10 without issue. More importantly, if Site A pings Site B first, then Site B can ping back to Site A just fine.

As I understand it, this should be working according to documentation since each 4th Octet is NATed at a 1 to 1 ratio, so Site B should be able to initiate pings.

192.168.15.10’s traffic does pass firewall rules and does pass on both the IPsec tab (validated with a pcap) and on the “WAN” (quotes since this is a lab) based on the ESP packets I am seeing (no other VPN in use and the counts match).

The traffic gets to Site A as well, validated also by checking ESP packet counts. But it never shows up on the IPsec tab with a pcap. And the Security Associations on IPsec > Status don’t count bytes up, so as I understand it this is failing the SPD check.

But if I check the IPsec SPD tab, I can see a proper SPD entry for 192.168.15.0/24 > 172.16.51.0/24, so as I understand it, it should work. I can’t find info on it, but, isn’t the SPD checked before NAT would happen?

Regardless, I feel like this should be working and I’m pretty lost here.

I have a pfSense install, version 2.6.0-RELEASE, where I am experiencing unintended behavior that could possibly result in a security issue. I am trying to confirm whether or not this behavior is expected, and if it is not, if it has been patched in a later version of pfSense (I understand 2.6.0 is a tad old).

The issue is pretty simple. Say you have three interfaces, WAN, OPT1, and OPT2, and you have created NAT rules for OPT1 and OPT2, specifically port forwards. OPT1 and OPT2 are either OpenVPN or Wireguard tunnels. You decide you no longer need OPT2 and delete it from the interfaces page. Now, when you look at the NAT rules you had before, the OPT2 rules will have reverted to the WAN interface, as well as the correlating firewall rules allowing the traffic to pass. The problem is that this behavior is not communicated to the user and can lead to an unintended publishing of internal services to the WAN if any of the IPs or ports for the rule match up to a live service.

Steps to reproduce:

• Create a new interface. Name it whatever. For this exercise we'll use OPT2. Enable it.
• Add a port forward NAT rule tied to OPT2. Use whatever ports and IP you like. Commit the changes.
• Now delete OPT2 from the interfaces page entirely and head back to the NAT port forwards page.
• You should see that the port forward rule has now reverted to WAN without a message or even a change commit / reload required.
• Now go to the firewall page and observe the rule that was created for the port forward. It should also now be pointed to WAN, meaning it will actually work and forward traffic.

Is anyone else able to replicate this behavior? Does it happen on 2.7.0+? And is this expected? I worry that this could really bite someone in the behind if they have no idea it is happening. Either a confirmation or message to the user if port forwards are detected tied to an interface pending deletion, or a way to preserve the original deleted interface on the orphaned rules, would suffice to fix this.

-7666

NAT+Proxy mode for NAT Reflection on port forwards targeting port 443 no longer functions in pfSense 25.07. The root cause appears to be the webConfigurator's nginx instance binding to *:443 (all interfaces), which prevents xinetd from establishing the proxy listener for NAT reflection.

Environment

• pfSense Version: 25.07.1
• Hardware: Intel-based (Wildcat Point-LP)
• Relevant packages: Nexus, pfBlockerNG-devel, ACME, Avahi, OpenVPN-client-export

Symptoms

• External access (WAN) to port-forwarded services works correctly
• Internal access (LAN hairpin/reflection) fails when NAT Reflection is set to "Enable (NAT + Proxy)"
• TCP connections are accepted but TLS handshake hangs indefinitely
• Switching to "Enable (Pure NAT)" immediately resolves the issue

Diagnostic Evidence

nginx (webConfigurator) is listening on all interfaces for port 443:

# sockstat -l4 | grep 443
root     nginx      40955 5   tcp4   *:443                 *:*
root     nginx      40662 5   tcp4   *:443                 *:*
root     nginx      40551 5   tcp4   *:443                 *:*

nginx configuration confirms binding to all interfaces:

# cat /var/etc/nginx-webConfigurator.conf | grep listen
        listen 443 ssl;
        listen [::]:443 ssl;
        listen 80;
        listen [::]:80;

xinetd logs show services being killed during reconfiguration:

Dec 10 02:30:39 pfs xinetd[34103]: Sending signal 9 to 19009-tcp server 39244
Dec 10 02:30:39 pfs xinetd[34103]: Sending signal 9 to 19009-tcp server 49600
Dec 10 02:30:39 pfs xinetd[34103]: service 19009-tcp deactivated
Dec 10 02:30:39 pfs xinetd[34103]: service 19010-tcp deactivated
Dec 10 02:30:39 pfs xinetd[34103]: Reconfigured: new=0 old=9 dropped=2 (services)

Steps to Reproduce

1. Configure a port forward: WAN 443 → internal host port 1443
2. Set NAT Reflection to "Enable (NAT + Proxy)" on the rule
3. From a LAN client, attempt to access the service via the WAN IP or external domain
4. Connection will hang after TCP handshake

Expected Behavior

NAT+Proxy reflection should work as it did in previous pfSense versions, allowing LAN clients to access port-forwarded services via the public IP.

Actual Behavior

xinetd cannot bind to port 443 for the reflection proxy because nginx (webConfigurator) already occupies *:443 on all interfaces. TCP connections are accepted by nginx but fail because nginx doesn't know how to handle the traffic.

Workaround

Use "Enable (Pure NAT)" instead of "Enable (NAT + Proxy)" for NAT Reflection. This works correctly and is arguably the better solution anyway, but the NAT+Proxy option should either work or be documented as incompatible with the default webConfigurator configuration.

Suggested Fix Options

1. Bind nginx/webConfigurator to specific interfaces (e.g., LAN only) rather than *:443
2. Add a GUI option under System → Advanced → Admin Access to configure webConfigurator interface binding
3. Document this limitation in the NAT+Proxy mode description
4. Have xinetd use alternative ports for reflection when 443 is occupied

Additional Notes

This appears to be a regression from the switch to nginx for the webConfigurator in pfSense 25.x. Previous versions using lighttpd may have had different binding behavior. The lack of a "Listen on interfaces" option in Admin Access settings means users cannot resolve this conflict without changing the webGUI port or using Pure NAT mode.