Subcategories

• Cache/Proxy

  Discussions about packages which handle caching and proxy functions such as squid, lightsquid, squidGuard, etc.
  4k Topics

  21k Posts

  J

  @tinfoilmatt like this acl doh_rfc8484 urlpath_regex -i ^/dns-query acl doh_rfc8484 urlpath_regex -i dns= acl doh_rfc8484 urlpath_regex -i ^/resolve urlpath_regex "urlpath_regex: URL-path regular expression pattern matching, leaves out the protocol and hostname"
• IDS/IPS

  Discussions about packages whose functions are Intrusion Detection and Intrusion Prevention such as snort, suricata, etc.
  2k Topics

  16k Posts

  S

  @pvanderlaat https://forum.netgate.com/post/1242504
• Traffic Monitoring

  Discussions about packages that handle bandwidth and network traffic monitoring functions such as bandwidtd, ntopng, etc.
  582 Topics

  3k Posts

  M

  Disclaimer: AI wrote the bulk of this as it theoretically understands the crash dumps better than I do. Hopefully it's accurate information that can help us get this fixed. Hey all, I've been experiencing recurring kernel panics on my pfSense Plus 26.03 install and wanted to share my findings in case others are hitting the same thing. I've filed a bug report on Redmine with full technical details, but posting here to see if anyone else can reproduce this. Setup: pfSense Plus 26.03 (RELENG_26_03, built March 20, 2026) ASRock Rack board, Xeon D-1521 Onboard Intel I210 (igb), PCIe Intel 82599ES 10GbE SFP+ (ixgbe) Suricata running on the physical ix1 interface and two VLAN sub-interfaces (ix1.40 and ix1.70) What's happening: The firewall is crashing roughly every 1–4 days with a kernel panic. I've collected 8+ crash dumps over about 3 weeks, all with the same panic string: page fault, all hitting the exact same kernel instruction — bpf_mtap+0x86. The crashes happen via two different code paths: On packet receive: iflib_rxeof → ether_input → bpf_mtap On packet forward: ip_tryforward → vlan_transmit → bpf_mtap Both paths fault at the same address with a null pointer dereference at offset 0x30, which strongly suggests a use-after-free or uninitialized BPF descriptor in the kernel's BPF tap code when Suricata has active listeners on ix1 VLAN interfaces. What I've ruled out: Not a NIC driver issue (igb or ixgbe) — the fault is in the kernel BPF layer, not the drivers Consistent across 3+ weeks with no pfSense updates applied, so it's not a regression from a recent patch Suspected cause: Suricata attaches BPF taps to the ix1 parent interface and both VLAN sub-interfaces. Something in pfSense Plus 26.03 on FreeBSD 16.0-CURRENT appears to leave a stale or freed BPF descriptor that gets dereferenced during normal packet processing. Workaround: Disabling Suricata on the affected interfaces appears to be the only current mitigation, which I really don't want to do as open ports that get poked at on a regular basis. No System Patches are available yet to address this. If you're running Suricata on VLAN sub-interfaces of an ixgbe (82599ES/X520/X550) card on 26.03 and seeing unexpected reboots, please chime in — especially if your crash reporter shows a page fault. The more people who can confirm this, the faster it's likely to get addressed. Full technical details, crash backtraces, and register dumps are in the Redmine ticket: https://redmine.pfsense.org/issues/16828
• pfBlockerNG

  Discussions about the pfBlockerNG package
  3k Topics

  21k Posts

  J

  Welp this was a nice deep rabbit hole..... But i think i found it, on reddit surprisingly: https://www.reddit.com/r/pfBlockerNG/comments/1jb5rtc/ipv6_woes_wrong_vip/ "According to https://redmine.lighttpd.net/projects/lighttpd/wiki/Server_use-ipv6Details, using server.use-ipv6 = "enable" will bind to ALL ipv6 addresses, i.e. wildcard." So i commented out "server.use-ipv6" in the config, lighttpd now listens on the correct addresses.......
• UPS Tools

  Discussions about Network UPS Tools and APCUPSD packages for pfSense
  107 Topics

  3k Posts

  4

  @dennypage ah that’s probably the case then. Thank you!
• ACME

  Discussions about the ACME / Let’s Encrypt package for pfSense
  520 Topics

  3k Posts

  J

  Current versions of the ACME package let you define a profile to use when requesting a certificate. Let's Encrypt is changing the behavior of some of those profiles next week, though they've been sending out announcements about the changes for a while now. The changes are: Let’s Encrypt will be making three previously-announced changes in one week, on May 13, 2026: The tlsserver ACME profile will switch to 45-day certificates. This profile is opt-in, for use by early adopters. The full timeline of shortening our certificate’s lifetime to 45 days over the next two years can be found in our blog post, Decreasing Certificate Lifetimes to 45 Days The tlsclient ACME profile will only be available to ACME accounts which have previously requested a certificate from that profile. That profile will be available until July 8, 2026. For more details, see Ending TLS Client Authentication Certificate Support. The classic ACME profile will switch to using our new "Generation Y" intermediates. These intermediates chain to our existing X1 and X2 roots, so this change should not introduce compatibility issues. The default profile if you don't specify one when requesting a certificate is classic. So most users can expect to see some different intermediates coming in when renewing after the 13th. Eventually, Let's Encrypt is making the tlsserver profile the default instead, so if you use Let's Encrypt to protect public servers, now is probably a good time to start testing that profile in a staging environment. Honestly, most people won't notice a difference with it the way most services use TLS server certificates. It'll renew more often, but if it's automated, there's little cause for concern.
• FRR

  Discussions about the FRR Dynamic Routing package on pfSense
  299 Topics

  1k Posts

  N

  @Schannes said in PfSense UI Not Updating frr.conf: I had the same problem. I was able to solve the problem, with clearing the "SAVED frr.conf" field under Services --> FRR --> Global Settings --> Raw Config. After clearing the field, it was possible again, to use the GUI to configure frr. I really want to stress that this is the ONLY feasible way to get frr config and web gui to work again. And while we are at it I would like to request an addition to the frr ospf menu's [image: 1774758674881-714f8830-f68c-4cd7-bfdd-aed167173a54-image.png] What is needed is to produce the line in bold interface tun_wg0 ip ospf network point-to-multipoint non-broadcast ip ospf area 0 This is supported by frr (tested in 25.11.1 and 26.03rc) and is required for ospf over wireguard tunnels on a single spoke , for hub and spoke setups. You also need to specify the neighbor by ip. The reason is that ospf wants multicast, (and works if you add 224.0.0.0/4) on the hub, BUT it will only work for the last spoke, since this is how wireguard operates. The setting above solves it, but since it is not on the menu, you need to change it by hand , which then gets the configuration out of sync, and one have to do chores described above to get it to synce, and THEN change the line to ip ospf network point-to-multipoint non-broadcast Hell breaks loose.!! ps. I would opt for bgp instead of ospf for wireguard tunnels, but this will be another thread!
• Tailscale

  Discussions about the Tailscale package
  99 Topics

  761 Posts

  C

  said in How to update to the latest Tailscale version?: Updated to version 1.96.4_1, no issues, no errors. Updated to version 1.96.4_2 service tailscaled stop fetch https://pkg.freebsd.org/FreeBSD:16:amd64/latest/All/tailscale-1.96.4_2.pkg || exit 1 && pkg-static add -f tailscale-1.96.4_2.pkg && rm -f tailscale-1.96.4_2.pkg && service tailscaled start After upgrading pfSense+ to 26.03, I added advertised routes in the Tailscale web GUI, and there have been no issues with Tailscale updates or pfSense reboots since then.
• WireGuard

  Discussions about WireGuard
  740 Topics

  4k Posts

  3

  @netblues Yes!:Thanks to psp's testing.