Subcategories

• Cache/Proxy

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

  21k Posts

  O

  Hey that is familiar :

  [2.8.0-RELEASE][admin@fw1.man.mylocal]/root: squid -z
  ld-elf.so.1: /usr/local/sbin/squid: Undefined symbol "ZTVNSt3__117bad_function callE"

  Hopefully it is resolved soon!

• IDS/IPS

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

  16k Posts

  J

  @bmeeks your code is epic !!

• 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

  T

  Thanks, @BBcan177.

  Some clear confusion ITT re pfSense system version and pfBlockerNG package version numbers. For posterity:

  pfSense 2.7.2 CE - Database Sanity check issue not present, because pfBlockerNG and pfBlockerNG-devel packages are both on "RELENG_2_7_2" branch of pfSense / FreeBSD-Ports

  pfSense 2.8 CE - Database Sanity check regression, possibly because branch updated to "devel" for both packages?

  (RELENG_2_7_2 branch: pfBlockerNG/pfBlockerNG-devel)
  (devel branch: pfBlockerNG/pfBlockerNG-devel)

  I think that's what's happened. Maybe someone can give me a sanity check. 😜

  The package version numbers appear to have been realigned in pfSense 2.8 CE however. The last package versions of pfBlockerNG and pfBockerNG-devel on pfSense 2.7.2 CE were 3.2.8 and 3.2.0_20 respectively.

  But under 2.8 CE, both packages are now currently on version 3.2.8 (pfBlockerNG and pfBlockerNG-devel).

  Will both packages continue to be maintained separately and we should expect version numbers to potentially diverge again?

• UPS Tools

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

  2k Posts

  G

  @AngryAnt said in pfSense -> pfSense NUT connection issues:

  Surely the destination matching should be the pfSense LAN address (192.168.1.1) and then the NAT IP (where the package is redirected to) should be 127.0.0.1 where NUT listens by default?

  You saw it :

  a5ca1c2f-e6ad-47be-a16b-083fa05d1f8a-image.png

  @AngryAnt said in pfSense -> pfSense NUT connection issues:

  Only firewall log entry related to 3493 is from a port scan on WAN by known-bad actor according to https://www.abuseipdb.com

  Normally, you don't place any rules on WAN.
  The default firewall for every interface, including WAN is : "silently drop". This is not a pfSense behavior, every firewall on planet earth does this.
  Don't ( ^^ ) have this drop rule log, as you'll be smacked with firewall log notification.

  So, normally, un check this :

  41f6e255-ec55-479b-b536-6742094177ea-image.png

  @AngryAnt said in pfSense -> pfSense NUT connection issues:

  Also: Progress! I am unsure why my previous attempt at having LISTEN 192.168.1.1 in there was unsuccessful

  A service needs to listen on an interface, and a port, using UDP and/or TCP.
  and
  You need on that interface (LAN) a firewall rule that allows that traffic to enter.
  For your pfSense LAN, there is/was an install pass-all rule, so as soon as upsd was listening on 192.168.1.1, it would have worked.
  That is : you also need to set up user auth.

• 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.