@jrey turns out i also had to update , i feel so silly thx for the troubleshoot

@Gertjan Belated thank you. He'd probably just VPN around it anyway. Sigh...

@milonic

Running processes, like syslog, don't keep their own time. The use a system call to get the exact time when needed.
That time, you can see it on the command line, just type

date

That is the "time stamp" syslog uses when it writes a log line.

The time is normally counted by a real time clock on the system motherboard. This chip, or the power (remember the famous BIOS RAM battery - it's the same ?)
Added to that, pfSense processes a ntp = a real time service, so even if the local real time facilities is bad or worse, the system will will get synced every minute or so so it compensates for the loss ( normally less then some nano seconds )

You have the ntp service activated, right ? By default, it is.
Just checking : Status > NTP :

3ac5ce55-f1a7-491f-b828-6768ee125630-image.png

The NTP is normally configured with host or pool name - I use

a9428efe-3b28-4b96-b6b7-8493eeaf70b3-image.png

and this host name points to a pool with mixed IPv4 and IPv6 IPs.
One is chosen, and the others are backups.

If you managed to find a pfBlockerng IP list that has these (time server) IPs on the list, and you use the list to block for outgoing connection, then yeah, you've aligned the nearly impossible :
Using a device with a bad real time clock - this happens more often nthen you thing, stuff just dies .... that's normal.
Adding extra software (pfBLockerng), and use it to block IP that you actually need : the time server your NTP has selected... now the system time will derail.

And yes, a good accurate time isn't that important for syslogging (that is, I would consider it a security issue), but becomes very important for simple DNS requests (DNSSEC)à ... or just TLS, also used by pfSense itself.

So : pfBlockerng : check your IP feeds you've chosen. You should always do this. Just think about it : what happens if you start to use that list that contains all the windows update IP's of Microsoft - and you use this list for blocking outbound connection ? Your PC will not receive any updates anymore, as it can't contact to 'Microsoft' anymore. That's ... dono, not great ?!
Or you got the list that contains all the IPs of the servers that contain the lists of all the other IP lists and DNSBL (yes, that has been done already) : pfBlocker can't download (update) the other lists anymore ... also great ...
So, to make a long story short, sorry to say, but do not trust anything that comes from the internet. Use it, and check it. If doubts, don't use it.

With pfBlockerng taken care of, your NTP server should now sync up your real time.

@Seeking-Sense said in Problem with update pfBlockerNG-devel 3.2.0_18 to 3.2.0_20:

if (is_array($dhcp['staticmap'])) {

Ok, thanks.

Still, for my own curiosity, I still cant see why it failed.

The line above states :

// Collect static DHCP hostnames/IPs foreach (config_get_path('dhcpd', []) as $dhcp) { if (is_array($dhcp['staticmap'])) {

The foreach asks for the list of array() in <dhcpd>
It should return a list with <staticmap> </staticmap>, as these are your static lease entries.

So, no need to test inside the foreach loop if arrays exist, as if there were none, the inner loop couldn't be reached in the first place.

My question : do you have an invalid entry somewhere inside the <dhcpd> .. </dhcpd> section ?

This is what I have ( I removed some info ) :

<dhcpd> <lan> <range> <from>192.168.1.70</from> <to>192.168.1.200</to> </range> <defaultleasetime>21600</defaultleasetime> ..... babla <numberoptions></numberoptions> <staticmap> <mac>00:4e:01:ac:ca:9c</mac> <cid>bureau2</cid> <ipaddr>192.168.1.2</ipaddr> <hostname>bureau2</hostname> .... more blabla <uefihttpboot></uefihttpboot> <numberoptions></numberoptions> </staticmap> <staticmap> <mac>ac:15:a2:02:d0:0b</mac> <cid>TL-SG108E</cid> <ipaddr>192.168.1.3</ipaddr> <hostname>TL-SG108E</hostname> .... bla goes on <nextserver></nextserver> <filename32></filename32> <filename64></filename64> <filename32arm></filename32arm> <filename64arm></filename64arm> <uefihttpboot></uefihttpboot> <numberoptions></numberoptions> </staticmap> <mac_allow></mac_allow> <mac_deny></mac_deny> <nextserver></nextserver> <ddnsdomainprimary></ddnsdomainprimary> <ddnsdomainkeyname></ddnsdomainkeyname> .. more dhcp general setting <ddnsdomainsecondaryport></ddnsdomainsecondaryport> <dnsregpolicy>default</dnsregpolicy> <earlydnsregpolicy>default</earlydnsregpolicy> <ntpserver>192.168.1.1</ntpserver> </lan> <opt1> .... and here we go again, for the second interface (if it exists) ..... </opt1> <dhcpd>

Btw : I now also see that the original issue, some error in the dhcpd IPv4 list of static leases was not the same as I had.
My errors came from the <dhcpdv6> section, which comes just after line 5347.
The array list with static lease info was correct, but the indic=vidual IPv6 address were plain wrong, like "::c6" instead of a complete, real IPv6 : example

<staticmap> <duid>00:01:00:01:1e:6a:44:de:64:00:6a:8b:f1:b3</duid> <ipaddrv6>::c9</ipaddrv6> <hostname>bureau</hostname> <descr><![CDATA[Bureau]]></descr> <filename></filename> <rootpath></rootpath> </staticmap>

@jazzl0ver Thanks. That seemed to fix it for me as well.

Current System

2.7.2-RELEASE (amd64) built on Wed Dec 6 15:10:00 EST 2023 FreeBSD 14.0-CURRENT pfBlockerNG-devel 3.2.0_20

Wondering if this is error / issue in found when running pfBlockerNG?

I recently added the ISC_Miner list and looks like it may be dead too.

@publictoiletbowl said in allow fb messenger but:

but no luck. because in pihole it works

No luck because it works ? 😊 Isn't it the other way around ?
It works with pi-hole, so ... can you discover why it works for pi-hole ?

Btw : what is 'facebook' ?
You means their web site ?
Whatsapp ?
Messenger ?
Other ?
And also :
From a web browser ?
From an app on a pad or phone ?

The nasty thing about facebook : (and Google, Apple, Microsoft, Amazon and this list is very long)
They use (own) thousands of IP addresses. These addresses change all the time.
A fact is that a browser access will use destination port 443 as it is https only.
Apps can use any port they want.

The good news is ; they own their own networks, or AS and pfBlockerng can block these, but that means nothing will work anymore, not even the web browser access.

So, I'm curious, who does pi-hole does it ?

Hummm.

@Gertjan said in pfBlocker still not working even in 24.11 version:

Copy past the Log that will show up (it's text, so copy text please).

I missed that.
In that log there can be info related to any issues. Issues you're looking for.

Also - probably not related :
b1d657a2-1801-4468-8747-b577b8cca361-image.png

so delete for the moment :

7819b6d2-a93d-464e-9ab8-4067b18b0cea-image.png

and then delete the error message with :

8b37e6df-6238-4480-a903-547af1730cdc-image.png

edit :

Did you conclude that you didn't loose any Internet access while reloading ?

@Gertjan
Looks like the issue is resolved. changing from "fall back to remote" to "ignore remote". I also made sure that there was NO other references for external DNS servers.

I've also been working on making sure that all of the downloads are working. I have found that some have changed policies or paths.

THANK YOU!

@reberhar SUCCESS

After the latest upgrade for pfBlocker I started to have the same problems all over again and none of my other methods fixed it.

I finally got onsite and have learned some useful things.

First I have 2 Netgear GS108PEs, and one worked properly in this situation and the other did not. After thinking about it I realized that the one that functioned had 802.1q VLAN enabled. So I enabled 802.1q VLAN on the one that was not functioning correctly and the problem disappeared. No I didn't make any VLANs on the second unit, although the first unit I mentioned does have them. I just enabled 802.1q VLAN.

I reasoned that perhaps multicast was somehow involved in this. (duh) So I worked through enabling multicast on my Ubiquiti 24 port smart switch that had failed with this challenge earlier. It actually involved the Cloud Key as well.

This I did just on the two ports I am using for HA, not the entire switch.

That worked too and is still working.

😊

Yes I know, multicast is mentioned in the HA diagnostics write up. I guess I was just not following through. Actually, I was just a little unsure how to proceed. I have other very smart switches that have been testy in this pfBlockerng / HA environment. I am excited to try this approach with them.

@Jabiru

Be aware that this exists : Update Frequency of GeoIP do you can't update their lists xx hours, you will be punished (== blocked). As most lists don't even change each week, a weekly update is more then enough.

Also, visit the https://www.maxmind.com/en/account/sign-in and check your account. Didn't they change something last year, so you had to 'redo' ( ? ) your registration (get new codes etc - can't recall )

edit : this :

@Jabiru said in pfBlocker configuration for MaxMind GeoIP:

401 Unauthorized

smells like a account problem.

@Gertjan This is Noted, and Thank you

@jrey Thank you for clarifying.

The asn is downloading (I did have to do the above shell command to force it first time), but the expectation was it would download immediately upon a first save or update that included asn.

Once primed, once per day more than enough. After all, how often do asn assignments actually get changed?

@JClayton
I'm having the same issue with pfsense 2.6 and the last pfblockerng package
did you find any solution?
thanks

@johnpoz Got it. Many thanks.

@Gertjan My main point is that 24.11 is not able to run the same setup that 24.3 had no issues with on an SG1100. I have rolled back to 24.3 and all is fine. 24.11 isn't able to run even a fraction of the feeds that 24.3 is able to. If you're on a small SG1100 I'd stay away from 24.11 for now.

@Gertjan Yeah, I'm aware.