pfBlockerNG showing unknown in Reports
-
I just installed and configured the pfBlockerNG-devel package (v3.1.0_9) on a Netgate 2100 appliance. I have both IP blocking and DNSBL enabled. Since this is a new install, I'm dipping my toe in the water by using minimal feeds for IP blocking and DNS blackholing. It seems to be working as a number of scanner sites are being blocked and about 15% of DNS queries are getting blocked (no ads on Yahoo).
However, there is an issue with GeoIP lookup on the Report tab where it is showing "UNK" for every external address. Despite having a properly configured license key and the update log shows the Maxmind database was updated properly, it still isn't resolving a GeoIP location. BTW - I am not doing any GeoIP filtering at this time.
🔒 Log in to view
Figure 1 - Screenshot of "Unk" in Reports tab of pfBlockerNG GUI screen🔒 Log in to view
Figure 2 - Screenshot of proof Maxmind database is successfully updating.So, after doing some Googling on this situation, I came across the following command and got the following error that suggests there is a problem. I'm at a dead-end and looking for help from the community. Thank you!
🔒 Log in to view
Figure 3 - SSH session showing a manual update of the Maxmind database. -
-
-
Hi @johan333
I have the same issue and followed steps from the link in your post, but the reports still showing Unk. Some of the requests has a country listed, but most of them are showing unknown.
Using the command
/usr/local/bin/mmdblookup -v -f /usr/local/share/GeoIP/GeoLite2-Country.mmdb -i 89.248.165.195 country iso_code
from the shell will works and return the good country, but still shows Unknown in the GUI:Database metadata Node count: 924578 Record size: 24 bits IP version: IPv6 Binary format: 2.0 Build epoch: 1672939859 (2023-01-05 17:30:59 UTC) Type: GeoLite2-Country Languages: de en es fr ja pt-BR ru zh-CN Description: en: GeoLite2 Country database Record prefix length: 120 "NL" <utf8_string>
So I'm confused here. I did reboot the pfsense, but still having the issue.
Regards!
Yanick -
I visited "www.recyber.net" :
Result :
I've got 172.67.181.221 as an IP, based in the 'US' (according to geoip).
The SOA request has an 'unknown' as did the IPv6 request (didn't have one), both is normal.
Btw : using pfBlockerNG-devel package (v3.1.0_9)
Also: I saw what @serbus wrote about the geoip tar not being untarred, but I did not see that issue :
[22.05-RELEASE][admin@pfSense.local.net]/var/db: php -f /usr/local/www/pfblockerng/pfblockerng.php dc Download Process Starting [ 01/9/23 09:58:12 ] /usr/local/share/GeoIP/GeoLite2-Country.tar.gz 200 OK /usr/local/share/GeoIP/GeoLite2-Country-CSV.zip 200 OK Download Process Ended [ 01/9/23 09:58:17 ] Country code update Start Processing ISO IPv4 Continent/Country Data Processing ISO IPv6 Continent/Country Data [ 01/9/23 09:58:47 ] Creating pfBlockerNG Continent PHP files IPv4 Africa [ 01/9/23 09:59:02 ] IPv6 Africa [ 01/9/23 09:59:03 ] IPv4 Antarctica IPv6 Antarctica IPv4 Asia IPv6 Asia [ 01/9/23 09:59:07 ] IPv4 Europe [ 01/9/23 09:59:08 ] IPv6 Europe [ 01/9/23 09:59:19 ] IPv4 North America [ 01/9/23 09:59:22 ] IPv6 North America [ 01/9/23 09:59:31 ] IPv4 Oceania [ 01/9/23 09:59:37 ] IPv6 Oceania [ 01/9/23 09:59:38 ] IPv4 South America IPv6 South America [ 01/9/23 09:59:39 ] IPv4 Proxy and Satellite [ 01/9/23 09:59:40 ] IPv6 Proxy and Satellite IPv4 Top Spammers IPv6 Top Spammers pfBlockerNG Reputation Tab Country Code Update Ended
- 14 days later
-
@gertjan I also have found this issue. While GeoIP is working, I have aliases defined and it is blocking by country, I have the Unk in the reports in all IP filtered traffic.
In this line the IP is recognized originating from Asias/India and blocked. IN-V4 rule.
So why does it show Unk??Also in the stats:
🔒 Log in to viewSeems more like to be a bug in the reports.
-
@manilx I did run the commands from the above referenced post:
cd /usr/local/share/GeoIP /usr/bin/tar -xzf GeoLite2-Country.tar.gz --strip=1
Fixed this for the time being. As I'm running the latest .11 pfblockerng update I do think that this issues has been fixed. The only thing was that installing the update didn't also run the command, which I think it should.