I’ve noticed a problem with the DNS Firewall. Is it working? Let me explain. I’ve selected the “Pornography” category, but it lets me access all the porn sites. Does this happen to you too? I have the 203 Development Build: master/9b7ed567
I had version 203 Development Build: master/e9a5fbb3, and to rule out any problems, I lowered the MIME type to 202 and updated again.
Now I’m on version 203 Development Build: master/9b7ed567, but I’m still having the same problem.
You have restricted the access zone to only be for the Green network. If you are using the web proxy then your traffic to the dns system will not be coming from green but from IPFire itself and therefore will not be blocked.
This is covered in the IPFire documentation. See at the bottom of the List restriction section.
The simplest situation for most users is to use the default settings and not edit the access settings.
If you want to stay with your Green access selected then disable the use of the web proxy via the browsers.
If you want to be covered by the DNS Firewall irrespective of if the browser is using the web proxy or not then disable all the Network Zones.
In your case press Ctrl + click the mouse button on the Green selection and it will be deselected.
I’m sorry to say I followed your instructions and it’s still not working. I even cleared the Squid cache, like the browser’s F5, Ctrl+F5, and Ctrl+R, and it still accesses without problems. I seem to recall that it worked with version 202.
For me it also is working with CU203, the same as CU202, the only difference being that is uses knot-resolver in place of unbound.
I would have suggested clearing the caches but it looks like you have done that.
Just to confirm, when you say that you cleared the squid cache, you mean that you pressed the Clear Cache button at the bottom of the Web Proxy WUI page.
You don’t have to go searching through the messages file you can go to Logs - System Logs and select Domain Name System from the drop down box and it will show you both the unbound and knot-resolver logs for the rpz.
In there you can choose a date back when you had CU202 in place and you should be able to find those entries, as well as seeing of there is anything from the current period.
To simplify the test you could set your browser to use the system proxy or no proxy and then it guarantees that the traffic will go directly to the DNS system.
I just tested it out on my CU203 system (Development Build: master/e9a5fbb3)
and selected the same categories as you did and then tried to access pornhub.com with the browser setup with using system proxy
16:01:48 supervisord: captured stdio output from kresd0[1825]: Called for pornhub.com.localdomain.com. (1)
16:01:48 kresd[1825]: [rules ] => local data applied, user: 192.168.200.10, name: pornhub.com.
You should also be able to find the successful startup of knot in that log. It should look similar to the following
15:54:51 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
15:54:51 supervisord: spawned: 'policy-loader' with pid 1822
15:54:51 knot_resolver.controller.supervi: Supervisord is already running, we will just update its config...
15:54:51 knot_resolver.controller: Selected controller 'supervisord'
15:54:51 knot_resolver.controller: Available subprocess controllers are ('supervisord',)
15:54:51 knot_resolver.controller: Starting service manager auto-selection...
15:54:51 knot_resolver.manager.logger: Changing logging level to 'INFO'
15:54:51 knot_resolver.manager.server: Loading configuration from '/etc/knot-resolver/config.yaml' file.
15:54:51 supervisord: spawned: 'manager' with pid 1819
15:54:50 supervisord: notify: injected $NOTIFY_SOCKET into event loop
15:54:50 supervisord: supervisord started with pid 1776
15:54:50 supervisord: Server 'unix_http_server' running without any HTTP authentication checking
15:54:50 supervisord: RPC interface 'fast' initialized
15:54:50 supervisord: RPC interface 'supervisor' initialized
15:54:50 supervisord: RPC interface 'sd_notify' initialized
15:54:50 supervisord: RPC interface 'manager_integration' initialized
15:54:50 supervisord: RPC interface 'patch_logger' initialized
15:54:49 knot_resolver.manager.server: Exec requested with arguments: ['/usr/bin/supervisord', 'supervisord', '--configuration', '/run/knot-resolver/supervisord.conf']
15:54:49 knot_resolver.controller.supervi: We want supervisord to restart us when needed, we will therefore exec() it and let it start us again.
15:54:49 knot_resolver.controller: Selected controller 'supervisord'
15:54:49 knot_resolver.controller: Available subprocess controllers are ('supervisord',)
15:54:49 knot_resolver.controller: Starting service manager auto-selection...
15:54:49 knot_resolver.manager.logger: Changing logging level to 'INFO'
15:54:49 knot_resolver.manager.server: Loading configuration from '/etc/knot-resolver/config.yaml' file.
If you don’t see anything like that then you need to show what log messages you do see when knot has been started.
I’ve disabled Squid. I’ve removed the proxy from the Windows 10 settings. I’ve assigned a static IP address to Windows 10 using IPFire DNS. I’ve cleared the Firefox cache. I can still access it.
The dig query from IPFire itself isn’t filtered, in my opinion. The query should be run from a host, e.g., from the green network. My question is, what does the DNS configuration look like on IPFire?
What could be happening? I’m telling you, with version 202 there were no problems, and when I updated to 203, without changing anything, it stopped working.
@alexand, I’m going to try what you suggested. With this configuration:
