Subcategories

• Cache/Proxy

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

  21k Posts

  K

  I also have this issue (tried upgrading this morning and had to roll back). No idea if this works as I can't try again until tomorrow.

  https://dannyda.com/2025/05/30/how-to-fix-pfsense-community-edition-pfsense-ce-2-8-0-squid-issue/

• IDS/IPS

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

  16k Posts

  B

  Looks like Suricata's binary part will have the same issue as Snort. It is missing a match for the LINKTYPE_PPP_ETHER link type as well --

  The relevant code is within src/decode.h starting at line 1122,

  static inline void DecodeLinkLayer(ThreadVars *tv, DecodeThreadVars *dtv, const int datalink, Packet *p, const uint8_t *data, const uint32_t len) { /* call the decoder */ switch (datalink) { case LINKTYPE_ETHERNET: DecodeEthernet(tv, dtv, p, data, len); break; case LINKTYPE_LINUX_SLL: DecodeSll(tv, dtv, p, data, len); break; case LINKTYPE_PPP: DecodePPP(tv, dtv, p, data, len); break; case LINKTYPE_RAW: case LINKTYPE_GRE_OVER_IP: DecodeRaw(tv, dtv, p, data, len); break; case LINKTYPE_NULL: DecodeNull(tv, dtv, p, data, len); break; case LINKTYPE_CISCO_HDLC: DecodeCHDLC(tv, dtv, p, data, len); break; default: SCLogError("datalink type " "%" PRId32 " not yet supported", datalink); break; } }

  An edit like the one below will probably work (again, as with Snort, if the raw PPP data is the same in the two link types) --

  static inline void DecodeLinkLayer(ThreadVars *tv, DecodeThreadVars *dtv, const int datalink, Packet *p, const uint8_t *data, const uint32_t len) { /* call the decoder */ switch (datalink) { case LINKTYPE_ETHERNET: DecodeEthernet(tv, dtv, p, data, len); break; case LINKTYPE_LINUX_SLL: DecodeSll(tv, dtv, p, data, len); break; case LINKTYPE_PPP: case LINKTYPE_PPP_ETHER: DecodePPP(tv, dtv, p, data, len); break; case LINKTYPE_RAW: case LINKTYPE_GRE_OVER_IP: DecodeRaw(tv, dtv, p, data, len); break; case LINKTYPE_NULL: DecodeNull(tv, dtv, p, data, len); break; case LINKTYPE_CISCO_HDLC: DecodeCHDLC(tv, dtv, p, data, len); break; default: SCLogError("datalink type " "%" PRId32 " not yet supported", datalink); break; } }
• Traffic Monitoring

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

  3k Posts

  K

  @pulsartiger
  The database name is vnstat.db and its location is under /var/db/vnstat.
  With "Backup Files/Dir" we are able to do backup or also with a cron.

• pfBlockerNG

  Discussions about the pfBlockerNG package
  3k Topics

  20k Posts

  S

  I thought I'd link this thread here since you're all probably in the same boat:
  https://forum.netgate.com/topic/197685/config-history-not-pruning-on-ha-pair-has-3400-files/

  Basically, it's a bug in 24.03/24.11 where the pfSense config history files are not automatically deleted. I mention here because our backup router generates 2-3 files every 6 hours apparently from the pfBlocker sync (and cron job on the backup). Which at least for a while has been without the workaround/fix above. Plus any other changes we make, so it contained over 3400 files when I found it yesterday.

  Temp fix is to open the config history page in the web GUI, which will likely time/error out if you have that many.

  (the file pruning bug is not specific to HA or pfBlocker, but those amplify it)

• UPS Tools

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

  2k Posts

  J

  Hello all. Just pulled the trigger and updated to 2.8.0. Everything went smoothly except for NUT. I'm getting this in the logs:

  Jun 5 03:51:09 upsmon 36111 Poll UPS [ups@localhost] failed - Driver not connected Jun 5 03:51:09 upsmon 36111 Poll UPS [ups] failed - Driver not connected Jun 5 03:51:04 upsmon 36111 UPS ups@localhost is unavailable Jun 5 03:51:04 upsmon 36111 Poll UPS [ups@localhost] failed - Driver not connected Jun 5 03:51:04 upsmon 36111 Poll UPS [ups] failed - Driver not connected Jun 5 03:50:59 upsmon 36111 Communications with UPS ups@localhost lost Jun 5 03:50:59 upsmon 36111 Poll UPS [ups@localhost] failed - Driver not connected Jun 5 03:50:59 upsmon 36111 UPS ups is unavailable

  It's a CyperPower unit. I found this previous post from 2.7.0 (https://www.reddit.com/r/PFSENSE/comments/14tebia/nut_issues_on_270/) that stated to put interuptonly in the extra arguments but that doesn't seem to have fixed the issue. Funny part is I had no issues on 2.7.0 using the usbhid driver.

  Thanks in advance!

• ACME

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

  3k Posts

  J

  Let's Encrypt is removing the TLS Client Authentication EKU from certificates they sign in the near future:

  https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/

  This shouldn't affect many, if any, users of ACME on pfSense as it isn't used as a client certificate, only as a server certificate in various context (e.g. GUI, Captive Portal, HAProxy)

  In the past we have discouraged using Let's Encrypt certificates in certain contexts (like for clients) since it wasn't typically a secure practice. For example, if you use a Let's Encrypt certificate for OpenVPN, it would trust any certificate signed by Let's Encrypt, which makes it useless as an authentication factor.

  So while this is something to be aware of and check, it's unlikely to be a problem for most people.

• FRR

  Discussions about the FRR Dynamic Routing package on pfSense
  291 Topics

  1k Posts

  F

  After further troubleshooting, I discovered that, for some reason, the file /var/etc/frr/frr.conf is missing the line "ip ospf area 0.0.0.0" on every interface.

  However, whenever I restart the FRR services, the file is rewritten and the "ip ospf area 0.0.0.0" line is correctly added to every interface.

  I’m not sure if this is the root cause of the problem or just a symptom. The fact is, when I reboot my HA PFSense box, /var/etc/frr/frr.conf is missing the "ip ospf area 0.0.0.0" statements, and only after restarting the FRR service does the file get updated.

  In practical terms, I observe that no OSPF hello packets are sent until this is fixed—that is, until the services are restarted.

  EDIT:

  /usr/local/pkg/frr/inc/frr_ospf.inc

  line 215, remove:

  if (empty($interface_ip)) { continue; }

  This fixes the problem.

• Tailscale

  Discussions about the Tailscale package
  86 Topics

  552 Posts

  J

  Looks like Tailscale updated their Oauth to include client ID and client secret. Currently, I cannot login with client secret only.

• WireGuard

  Discussions about WireGuard
  681 Topics

  4k Posts

  R

  @Ryu945 I never figured out how to get it working in self DNS mode like I could with OpenVPN. I had to put the DNS Resolver in forwarding mode to get it to work.

  I also figured out that both the client and server need wireguard rules saying both client LAN to server LAN and server LAN to client LAN.