If I enable the IPFire DBL-Rulesets on the DNS-Firewall, is it obsolete to add these to the IPS Ruleset or to the URL-Filter?
Is there a log for the DNS-Firewall?
Btw so far no problems with Build master/7f0ed6b7
1 Like
Hello Tofficap,
all of these 3 filtering methods are using the same database. All of them have their advantages and disadvantages but in fact doing the same.
For example, when already using the web proxy and the clients are configured to pass their traffic to it, you probably will not benefit much from enabling the DNS firewall.
The same matches for the IPS, when using the DBL at this place, the benefit of adding DBL to the URL-filter or DNS-firewall again is very small.
When your clients are forced to use yout IPFire for DNS name resolution, the easiest way would be to enable DBL herr, but…
I think you got the idea.
When using the DNS-firewall, the blocked domains and clients can be found in the System→Logs→DNS(unbound) section.
Best regards,
-Stefan
4 Likes
When enabling the various DNS rulesets, it looks like you have to enter them manually and also enable them per interface. Meaning, the interfaces aren’t selected by default. Is that the case?
The default is to enable them on green and blue (if available). Orange never gets filtered, because the IPFire does not offer name resolution for that zone because of security reasons.
The customize section can be used to limit a category to a sinhle zone or certain host/subnet…
So in most cases there is no need for modifying the policy - just enable the desired filtering categories and enjoy. (Proper configured clients required, of course…)
Best regards,
-Stefan
2 Likes
OK, but in my case – having Green and Orange – both are unselected by default in the Edit screen. That makes little sense, ui-wise, if Green is always selected anyway and Orange should never be selected.
I use IPFire as a secondary DNS resolver. My primary DNS server is Technitium.
The IPFire DBL lists work perfectly there.
I asked just for my understanding, thx.
I just now tried setting up DNS Firewall. I ticked a couple of categories and then selected my green zone for each. It seems there’s a bit of an issue. I see in the log entries:
unbound: .. error: *.rpz.ipfire.org failing lookup, cannot probe to master primary.dbl.ipfire.org
for each of the enabled categories
[Edit} more log info: text-to-pdf-20260312-1203.pdf (1.4 KB)
Note: I have no problem pinging primary.dbl.ipfire.org
@cbrown, could you please trace this with tcpdump or something?
I see these logs at boot on a system with wireless red client. The logs come out 2 seconds after getting the ip address for red0. If I restart unbound, I do not get the logs. However, It doesn’t look like the dbl rpz files are ever getting loaded.
If you don’t touch the system, is unbound eventually able to load the zones itself?
Of course it needs to have internet connectivity and when the system boots up that might not have been available immediately.
1 Like
The absence of blocking behavior would indicate the zones are not getting loaded. Is there a way to re-initiate the loading. I have done unboundctrl restart – did not see the error indication – but doesn’t seem to do the expected blocking.. I’ve been testing against sites that get blocked nicely via UrlFilter on my main cu200 system
The current Testing build is master/61b0ac40
Would be worth doing an update of testing
https://www.ipfire.org/docs/configuration/ipfire/pakfire/testing#update-testing
2 Likes
If Unbound has no chance to load the list it obviously cannot block anything. Once it has at least downloaded the list for a first time it will cache it and at least use a slightly older version if it isn’t able to pull the updates.
You can trigger a refresh like so:
unbound-control auth_zone_transfer ads.rpz.ipfire.org
Obviously you will have to change ads if you want to test another zone.
1 Like
I use DNS over TLS, and upgrading to 201 and activating the DNS blacklist (including DNS-over-HTTPS blocking) immediately borked all DNS (“Status: Broken” on DNS page). Restarting Ipfire fixed it. The problem returned later at night without me touching the system, doing a /etc/rc.d/init.d/unbound stop and then start fixed it but then I removed DNS-over-HTTPS blocking and it has worked since then. We’ll see.
1 Like
A lot of the systems that are offering DoH also offer DoT on the same hostname. Enabling this on the DNS Firewall should not cause any problems like this because Unbound will directly use the configured IP address instead of the hostnames. But if you enable it on the IPS and have the TLS filtering enabled, it will of course be blocked.
1 Like
The unbound-control commands all responded “ok” for each zone. Is there something else needed to get the blocking to function?
Hello,
the unbound-control command will only tell Unbound to run the task. It won’t check if the task was actually successful so you will have to check the logs.
So what’s in there?
I didn’t see any unbound logs in /var/log/messages as I executed the unbound-control commands. Is there some place else I should be looking?
I am finding a similar situation.
I enabled the URL Filter with gambling and porn enabled.
Then I tried to access two gambling sites and a porn site. All were blocked with a message similar to this one.
Firefox can’t establish a connection to the server at welkom.hollandcasino.nl.
Error code: 503 Service Unavailable
I then disabled the URL Filter and enabled the DNS Firewall for gambling and porn and then set the Green Network as the Network Zone.
I then accessed the same three tabs, still open in the browser with the blocked message and all three sites opened up.
I checked the unbound cache directory and it had the zone files in there and they contained the domain for the sites I was trying to access.
The URL Filter logs show the blocking of the urls.
In the DNS: Unbound system logs there was no entry for the porn site that was accessed but for the two gambling sites the following lines were present.
15:15:28 unbound: [1821:0] info: rpz: applied [gambling.rpz.ipfire.org] *.onecasino.com. rpz-nxdomain 192.168.200.11@47602 nl.onecasino.com. A IN
15:15:21 unbound: [1821:0] info: rpz: applied [gambling.rpz.ipfire.org] *.hollandcasino.nl. rpz-nxdomain 192.168.200.11@48039 welkom.hollandcasino.nl. A IN
So it looks like it saw those but did not actually block them but the porn site didn’t trigger anything.
A separate but interesting find is that with gambling enabled then accessing postcodeloterij.nl is not stopped for either DNS Firewall or URL Filter.
postcodeloterij is in 5 of the 9 lists in the gambling category so I would have expected it to trigger something.
I will report that into the IPFire DBL reporting process. Changed my mind on that as the url is in the lists. The problem is that for some reason it is being ignored in the url filter. So need to try and identify why that is happening.
EDIT:
I found that the reason is that postcodeloterij.nl is not ending up in the gambling domains file that is downloaded, although it is in 5 of the lists in the gambling category.
So I have reported it into the reporting system.
3 Likes
I’ve also noticed this problem.
If you disable URL Filter, unbound displays the logs info: rpz: applied but the pages remain accessible.
You have to stop and restart the proxy for them to be blocked by rpz filter again.
Edit: I think it’s Squid that keeps the address and bypasses the DNS Firewall