Subcategories

• Cache/Proxy

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

  21k Posts

  L

  I am trying to use a rule to whitelist ips for a specific backend in my frontend.

  Basically use the X backend, if the host matches xxx.com and ip is whitelisted in a pfsense defined ip alias list.

  The problem is I am using the Cloudflare proxy and need to inspect the CF-Connecting-IP.

  And to do that I am using Custom ACL like this

  req.hdr(CF-Connecting-IP) -f /var/etc/haproxy/ipalias_Allowed_IPs.lst

  The Alias is defined in the firewall named Allowed_IPs.

  But this list does not get created unless I use something standard like "Source IP matches IP or IP Alias". Is there another way to refer to the created Aliases so that they are created properly?

  The workaround for this is to create a dummy acl with "Source IP matches IP or IP Alias" that does nothing but it is not a good solution.

  Edit: One more thing, I noticed is, when the alias list is updated, this does not get reflected to the HAProxy lists in /var/etc/haproxy/ until HAProxy is restarted.

• IDS/IPS

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

  16k Posts

  S

  oh ok. Thanks again

• Traffic Monitoring

  Discussions about packages that handle bandwidth and network traffic monitoring functions such as bandwidtd, ntopng, etc.
  571 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

  M

  Hello,
  I found this in the error log. Wondering how serious that is:

  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/1/25 20:00:24 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/2/25 20:00:24 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/3/25 20:00:24 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/4/25 20:00:24 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/5/25 20:00:03 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/6/25 20:00:10 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/7/25 20:00:04 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/8/25 20:00:04 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/9/25 20:00:05 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/10/25 20:00:04 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/12/25 08:00:05 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/13/25 08:00:05 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/14/25 08:00:05 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/15/25 08:00:04 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/16/25 08:00:04 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/17/25 08:00:08 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/18/25 08:00:04 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/19/25 08:00:04 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/20/25 08:00:05 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/21/25 08:00:05 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/22/25 08:00:04 ]
  [PFB_FILTER - 17] Failed or invalid Mime Type: [application/octet-stream|0] [ 06/23/25 08:00:05 ]

  UPDATE:
  as per suggestion from a previous post with a different but similar error, I added
  'application/octet-stream',
  to the file /usr/local/pkg/pfblockerng/pfblockerng.inc

  Hope this helps.

• UPS Tools

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

  2k Posts

  J

  So far everything is stable without me changing anything else. Who knows why....

• ACME

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

  3k Posts

  I

  @Gertjan Thank you for the directions. I will have a look this evening and post some logs. I tried it using my current PAT Token for my domain. The cert is for a website, not for a VPN-Server. :-)

• FRR

  Discussions about the FRR Dynamic Routing package on pfSense
  294 Topics

  1k Posts

  B

  Hi,

  We are running 25.03-BETA and running into the issue of FRR and BGP processes disconnecting at the control level. It mitigates itself in BGP being stuck in the active state from the GUI and FRR point of view (even vtysh thinks so), while the BGP process is actively keeping the connection in the background. No routes are being populated into the routing table, but these are being announced as confirmed by our peer:

  Nothing in routing, BGP neighbor is active, so no routes should be in.

  10.206.238.225 4 65228 0 2309 0 0 0 never Active 0 Odido BGP via

  So far it looks good, but the session is already established:

  >>> tcpdump -i ipsec2 07:23:11.642870 IP 10.206.238.225.bgp > 10.206.238.226.49408: Flags [P.], seq 2440502671:2440502690, ack 2016892785, win 11, options [nop,nop,md5 shared secret not supplied with -M, can't check - 2ed14f304978416f8007afca427f988d], length 19: BGP 07:23:11.642939 IP 10.206.238.226.49408 > 10.206.238.225.bgp: Flags [.], ack 19, win 131, options [nop,nop,md5 shared secret not supplied with -M, can't check - 078b7005ba698e2b636e70eb2c37e234], length 0 >>> USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS ... frr bgpd 76872 22 tcp4 10.206.238.226:49408 10.206.238.225:179 The FRR restart doesn't help: /usr/local/etc/rc.d/frr restart Stopping watchfrr. Waiting for PIDS: 2357. Starting watchfrr. [58970|mgmtd] sending configuration Waiting for children to finish applying config... [59017|zebra] sending configuration [59963|bgpd] sending configuration [61500|staticd] sending configuration [61157|watchfrr] sending configuration [59017|zebra] done [58970|mgmtd] done [61157|watchfrr] done [61500|staticd] done [59963|bgpd] done

  The BGP process ID 59963 is different from 76872!!!

  >>>> ps -ax | grep 76872 76872 - Ss 0:02.09 /usr/local/sbin/bgpd -A 127.0.0.1 -F traditional -d 62041 0 S+ 0:00.00 grep 76872 >>>> sockstat -4 USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS ... frr bgpd 76872 22 tcp4 10.206.238.226:49408 10.206.238.225:179

  After killing the process, restarting the FRR, and checkign for the traffic and routes:

  >>> kill -KILL 76872 >>> ps -ax | grep 76872 21650 0 S+ 0:00.00 grep 76872 >>> /usr/local/etc/rc.d/frr restart Stopping watchfrr. Waiting for PIDS: 88383. Starting watchfrr. [27380|mgmtd] sending configuration [27540|zebra] sending configuration [28677|bgpd] sending configuration Waiting for children to finish applying config... [27380|mgmtd] done [30560|staticd] sending configuration [30405|watchfrr] sending configuration [27540|zebra] done [28677|bgpd] done [30560|staticd] done [30405|watchfrr] done >>> ps -ax | grep bgp 11708 - Ss 0:05.87 /usr/local/sbin/bgpd -A 127.0.0.1 -F traditional -d 31648 0 S+ 0:00.00 grep bgp >>> tcpdump -i ipsec2 07:31:08.709787 IP 10.206.238.225.bgp > 10.206.238.226.26294: Flags [P.], seq 1180140056:1180140117, ack 3799507337, win 11, options [nop,nop,md5 shared secret not supplied with -M, can't check - d6b2c0bac2ebb8cf1058d365224d4c5c], length 61: BGP 07:31:08.709850 IP 10.206.238.226.26294 > 10.206.238.225.bgp: Flags [.], ack 61, win 131, options [nop,nop,md5 shared secret not supplied with -M, can't check - 9dec3ac243f71d5f90e285627b2cd9e5], length 0 >>> show bgp summary Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc 10.206.238.225 4 65228 3 494 5 0 0 00:00:48 4 5 Odido BGP via >>> show bgp ipv4 unicast Network Next Hop Metric LocPrf Weight Path *> 10.204.50.4/32 10.206.238.225 0 65228 ? *> 10.204.50.12/32 10.206.238.225 0 65228 ? *> 10.204.52.4/32 10.206.238.225 0 65228 ? *> 10.206.238.192/27 0.0.0.0 0 32768 ? *> 172.27.0.0/16 10.206.238.225 0 65228 ? >>> netstat -rn ... B>* 10.204.50.4/32 [20/0] via 10.206.238.225, ipsec2, weight 1, 03:42:44 B>* 10.204.50.12/32 [20/0] via 10.206.238.225, ipsec2, weight 1, 03:42:44 B>* 10.204.52.4/32 [20/0] via 10.206.238.225, ipsec2, weight 1, 03:42:44 B>* 172.27.0.0/16 [20/0] via 10.206.238.225, ipsec2, weight 1, 03:42:44

  Did anyone see anything like it? We could've lived with the BGP down and no routes, but it is announcing, and the traffic is being expected on the wrong interface in the destination FW.

  Regards

• Tailscale

  Discussions about the Tailscale package
  86 Topics

  558 Posts

  C

  @yobyot said in "Tailscale is not online" problem:

  I'm late to the party but unless I misunderstand this thread it's not about Tailscale not starting up but instead about the auth key expiring.

  Auth keys are good for a maximum of 90 days. If you reboot pfSense on day 91, Tailscale will not come up and the "API" error will be generated (it's actually an auth key expired error).

  Thus, unless you never reboot pfSense, starting with the 91st day, you must re-generate an auth key and input it to Tailscale even if you have key expiry disabled.

  What makes this worse, IMHO, is that the longer you go between reboots, the more obscure the problem. So, Tailscale is not a reliable service because it cannot survive a reboot after 90 days.

  This occurs on both CE 2.7.2 in a Protectli Vault Proxmox VM and on a real SG-1100 running Plus 24.11 (packages as distributed with those releases).

  I wish TS would introduce a new feature "a la Acme update" so that this would be done automatically.

• WireGuard

  Discussions about WireGuard
  684 Topics

  4k Posts

  M

  Hi,

  I have the following setup:

  device c --> 5G (CGNAT) --> internet <--> pppoe fiber <--> device F

  device F: using pppoe fiber internet, changes public IP's once every week, has a dynamic dns name registered device C: using a 5G connection, behind CGNAT, has no DNS name registered

  These are 2 pfsense installs with a site-to-site link in between.
  Peer config representing device C in device F is configured as dynamic (IP not known / behind CGNAT).
  To handle public IP address changes of device F, I am running a watchdog script on device C that restarts the wireguard service in pfsense on device C when the IP of device F changes (using periodic DNS lookups to detect a change in IP).

  I have noticed though that in some cases, after the wireguard service restart on device C the endpoint address shown for device F is its not the new IP, but its previous IP address.
  In this case, I even tried doing wg set tun_wg0 peer <key> endpoint <newip>:port, which is briefly reflected in the output of wg show but then the peer's IP switches back to the previous (now not valid) IP in the wg show output.
  Obvisouly, in this state, the link is not operable. As expected, neither end shows any recent handshakes.
  Curiously though, on device C, both the sent and received (!!!) size keeps increasing.

  Looks almost like if the wireguard client on device C continued to receive valid wireguard traffic from the old IP address and updated the peer endpoint address automagically.

  No matter if I restart the wireguard service on either end, does not help. The only remedy seems to be restarting the 5G modem itself - possibly triggering some CGNAT state resets.

  Anyone experienced similar behavior? Seems like a broken CGNAT implementation? T-Mobile HU is the carrier.