DNSBL Category (Downloading Blacklist Database(s) [ ut1 (~8.5MB) ] ... Please wait ... Failed UT1 ... Failed)
-
Is there a work around for this?
Downloading Blacklist Database(s) [ ut1 (~8.5MB) ] ... Please wait ...
Failed UT1 ... Failed
These sites have been down for a while - what have you done too fix?
-
This post is deleted! -
The package utilizes the FTP source to download the feed, and therefore the domain "
ftp.ut-capitole.fr
" must be whitelisted if it's otherwise blocked.See relevant code here: https://raw.githubusercontent.com/pfsense/FreeBSD-ports/refs/heads/devel/net/pfSense-pkg-pfBlockerNG-devel/files/usr/local/pkg/pfblockerng/ut1_global_usage
@smolka_J said in DNSBL Category (Downloading Blacklist Database(s) [ ut1 (~8.5MB) ] ... Please wait ... Failed UT1 ... Failed):
For some reason the UT1 feed url occasionally varies between versions
This is not true. The domain "
dsi.ut-capitole.fr
" hosts the feed via HTTP, which the package does not utilize as its feed source by default.See "How to download" at the bottom of the page here: https://dsi.ut-capitole.fr/blacklists/index_en.php
(Additionally, the path to the system configuration file depends on the version of pfSense. In Plus that's
/conf/config.xml
. But in CE it's/cf/conf/config.xml
. I would be hesitant to manually modify either except for the most extenuating of circumstances which, in my opinion, these are not.) -
This post is deleted! -
@smolka_J said in DNSBL Category (Downloading Blacklist Database(s) [ ut1 (~8.5MB) ] ... Please wait ... Failed UT1 ... Failed):
both directories /cf/conf/ and /conf/ are both present in both version, they are symbolically linked
You're right about this, and all my previous comments about the XML config file storage location are incorrect. I was looking at my SSH file browser in that moment, which apparently doesn't display the
/conf
symlink. Shows you how familiar I am with the file!(Output of
ls -l
for a given filesystem location displays any/all symlinks.)OP's issue with the UT1 feed (and possibly yours too) is almost certainly with either DNSBL or IP filtering. Although in your case, Suricata might've been the more likely culprit. Was your instance in fact running on the WAN interface? And you might've disabled it but did the instance actually stop? You might've ensured it did by rebooting the box, but still—lots of variables there.
You should set your
config.xml
file back and try troubleshooting whatever the issue is further. -
@tinfoilmatt I deleted my other posts to avoid confusion. It may have added to things, Suricata I only run on LAN, VLAN and VPN interfaces but have the same whitelist configured in an alias for it. Currently, the FTP site loads perfectly fine in a ftp or file manager also whether Suricata is disabled or enabled. Reading from why others changed their URL in the past also was due to the FTP link being intermittent at times, changing the feed URL in config.xml when FTP feed is down does allow the file to download and clear the download error itself. After further looking into though, doing this causes the processing of it to stop there and not update the UT1 orig files or populate them if they didn't already previously before changing the feed URL. Having pfBlocker enabled while disabling DNSBL followed with a reboot, re-enable DNSBL, reload restored my "ftp://ftp.ut-capitole.fr/pub/reseau/cache/squidguard_contrib/blacklists.tar.gz" feed URL into my config.xml without needing to manually edit it back, downloaded and fully processed updates.
Lesson learned, if and when UT1's ftp goes down temporarily, leave things as is, it will come back up. More would have to be re-wrote to completely change over to a different URL feed by default but FTP maybe is preferred. Thank you for guiding me to dig further, thought I fixed one issue but led myself to turning it into another
-
@smolka_J
Side note re: Suricata, because of how it runs the instance in the native interface will see the VLAN packets i.e. it ignores the VLAN tags. So no need/point running a second instance on the VLAN interface if it’s on the parent. -
@smolka_J Gracias, will keep that in mind as I test n tune re-mapping. Just acquired a set of Grandstream APs to first start endulging down that path, still have a few more fiber optic and POE drops to get in place first to LAGG each AP at 5Gb onto 10G backplane, moving through rafters of the attic is a little slow on medical leave
-
@spinner I am having the same issue... have you been able to resolve this?
-
@Yoe777 #1, the FTP site does have its time periods of downtime which might fall in line with your current CRON update schedule.
#2 If you had upgraded in the past from a previous version of pfSense and/or with a config.xml imported/restored from a previous installlation, you may have an invalid or non-compatible UT1 feed link that isn't loading properly, pfBlockerNG is programmed in multiple areas to parse only "ftp://ftp.ut-capitole.fr/pub/reseau/cache/squidguard_contrib/blacklists.tar.gz", if that feed URL is different for any reason like mine was from me previously trying to mitigate fixing my concern with FTP failing randomly, I had changed it to the https url which did download but did not parse into the files needed.
Steps that fixed my UT1 feed URL to the correct one in my config and restored full parsing/download:- Make sure pfBlockerNG is enabled on the general tab.
- Go to the DNSBL tab and disable onle DNSBL, save
- Reboot pfSense
- Go back to the DNSBL tab and re-enable DNSBL
- Run a Force Update>Reload>All