Forum Netgate

HAProxy -> Backend -> Advanced Setting -> Transparent ClientIP According to warning: "WARNING Activating this option will load rules in IPFW" - but IPFW rule is not added and returning traffic is not processed back by HAProxy. Step to reproduce: Check "Use Client-IP to connect to backend servers.", pick the interface where backend is connected. Restart HAProxy Check ipfw show - it should list the rule for NATing the traffic.

For weeks, I've been trying to figure out why connections from my IoT VLAN (from specific "trusted hosts" contained in an IP alias) were getting blocked, when I specifically had a rule to allow that traffic through. I thought at first it was a timing issue where I was just coincidentally reloading the filter exactly when this traffic was hitting the firewall, but after weeks it was happening too often to be a coincidence. The logs showed it happening at 4am too. Today, I finally think I figured it out- turns out it's a sneaky bug that was reported (see redmine #16563 ) almost a year ago. The redmine has more details, but in a nutshell, this combo silently fails to set the tcp flags on the generated rule (proto=Any + Flags=any): I did some further testing and came up with a patch that so far seems to have solved this. Just wanted to bring some awareness since I doubt people peruse old redmines much the way I do.

@stephenw10 That is always possible but 2.8.1 was running since the update and had uptime of 230 days. and i dont have this hardware that long yet. i'll let it run and see what happens.

Just updated Nexus package and my hardware is now supported. I am using Sophos XG310 v2 and previous builds stated it was incompatible. Anyone on Caswell Portwell hardware which is Sophos, Check Point and a bunch of others, there's a good chance your hardware will be supported now. Thanks Netgate.

@shoulders said in How to check if TRIM is on: I thought only the paid version was on ZFS Plus exposes boot environments in the GUI and uses that for upgrades, though they technically exist via command line in CE I believe. ZFS has been the default for both, for several years. It is possible to install pfSense and not use ZFS (maybe, one doesn't want the write amplification). However recall looking at that once and finding out TRIM was not that easy to set up in pfSense/FreeBSD for ufs, and that router ended up using ZFS. The dashboard Disks widget will show the file system in use.

Hmm, not if the BE is no longer there. If the boot verification fails it should flag the BE as failed and then roll back. You should still see the BR present in the list and flagged like: [image: 1790350789303-screenshot-from-2026-09-25-16-38-47.png] You would also see an alert present after booting back into the old BE. Try manually creating a BE cloned from the current one and see if you can boot into that. If that also disappears you might have a failing drive.

Yeah don't remove the pkg but you don't yet need to enable it. pfSense will run fine with it disabled.

@stephenw10 said in Netgate-4200: after upgrade to 26.07 strange behavior: Ah you mean using the gui command prompt page? no! The webgui gives up working after clicking around 5 to 10 clicks. So I can't admin the box reliably. It's not related to a specific page IMO

@stephenw10 Done and done thanks for the help. Successfully updated to 26.07 with everything imported appropriately! Only issue was figuring out why dpinger was unhappy and not wanting to work and finding a stale VIP causing the issue. edit: and this hint.acpi_spmc.0.disabled=1 kernel panic I just fixed as well lol

I'm testing Nexus CoreDNS with Unbound as its only upstream, but CoreDNS appears to be converting Unbound's NXDOMAIN responses into SERVFAIL. Design Clients → CoreDNS:53 → Unbound 127.0.0.1:5353 → Quad9 and Cloudflare (DoT) System details pfSense Plus 26.07 pfSense-pkg-Nexus 26.07_3 Nexus build: 0fd1915da462e197aaa12820fc51ec2750b37226 All services are running and listening on the expected ports: CoreDNS (rexdns): 53 Unbound: 5353 Nexus: 8443 The active generated CoreDNS configuration is minimal: (rexdns) { rexdns { default 127.0.0.1:5353 } } . { bind [local interfaces] import rexdns } No blocklists are assigned to the active CoreDNS group, and ZTE and ThreatGate are both disabled. Reproduction Querying Unbound directly for a nonexistent name: dig @127.0.0.1 -p 5353 rexdns-negative-test-20260922-01.example A +dnssec +noall +comments status: NXDOMAIN flags: qr rd ra ad AUTHORITY: 6 The same query through CoreDNS: dig @ rexdns-negative-test-20260922-01.example A +dnssec +noall +comments status: SERVFAIL flags: qr rd WARNING: recursion requested but not available AUTHORITY: 0 This reproduces consistently with multiple distinct nonexistent names. Unbound's response includes the ra flag and six authority records, while the CoreDNS response has neither. This suggests CoreDNS is generating the SERVFAIL itself rather than passing Unbound's response through. Control tests (behaving as expected) For comparison, these queries through CoreDNS return the expected results, which confirms t

We'll get that fixed, thanks!

@dennypage Below is a wireshark capture of a packet containing the Hop-by-Hop option with alert type of MLD (0). Google's AI claims: A Neighbor Solicitation (NS) packet carrying an MLD (0) router alert is a completely normal, standard component of IPv6 core networking on Windows 11. When your firewall or router logs a packet with these terms, it is witnessing Windows 11 performing a mandatory routine called Duplicate Address Detection (DAD) to ensure its own local IP* address doesn't conflict with another device on the network.* Unfortunately, windows 11 appears to start sending these frequently when it doesn't get a response which floods the firewall log. I'm not sure what causes windows 11 to generate these since the PC was running and didn't just boot up or come up from sleep state. I don't believe anything changed on the network either. 534 2026-09-27 19:50:48.408517200 ICMPv6 94 Neighbor Solicitation for from 00:e0:4c:01:f4:0c Frame 534: Packet, 94 bytes on wire (752 bits), 94 bytes captured (752 bits) on interface \Device\NPF_{B898AED1-CA87-489E-ACCD-623745EE4B22}, id 0 Section number: 1 Interface id: 0 (\Device\NPF_{B898AED1-CA87-489E-ACCD-623745EE4B22}) Encapsulation type: Ethernet (1) Arrival Time: Sep 27, 2026 19:50:48.408517200 Eastern Daylight Time UTC Arrival Time: Sep 27, 2026 23:50:48.408517200 UTC Epoch Arrival Time: 1790553048.408517200 [Time shift for this packet: 0.000000000 seconds] [Time delta from previous captured frame: 4.962271000 seconds] [Time delta