yes, this is another sad trend in the industry. To some extend, I can understand vendors here, since DNS resolution can be broken pretty badly in some networks (we experienced that ourselves when we brought DNSSEC to our users), but in most cases, corporations are probably more interested in the data they can get from DNS requests.
Please have a look at this wiki page for information on how to force clients in your network to use the DNS resolver provided by your IPFire machine.
In addition, consider dropping any outgoing DNS traffic not emitted by your IPFire itself. Having the aforementioned enforcement in place, there is no legitimate reason anymore why any client should speak DNS directly to the internet.
By blocking destination port 853 (TCP), you can get rid of DNS over TLS (DoT) as well, since it typically uses this port. For privacy reasons, you might want to configure your IPFire to use DoT, so your ISP cannot snoop on your DNS traffic. In this case, only block port 853 for any forwarding traffic, not for outgoing one, which is generated by IPFire itself.
This leaves you with clients being able to use DNS over HTTPS (DoH) to query different DNS resolvers. An understandable effort in terms of privacy, it is quite a nightmare if you need to enforce a security/privacy policy on your infrastructure. By using the web proxy, you can at least block common FQDNs used by DoH service providers such as dns.google. There is no catch-all guarantee on that, but it’s better than nothing.
The FORWARDFW log hits you see do not come from actually dropped packets, but from logged packets. This is because you have the “log” checkbox ticked on the “redirect DNS” firewall rule, so every packet redirected by this gets logged as well.
For the record, the log prefix of actually dropped packets is DROP_FORWARD.
To ensure your redirecting firewall rule works correctly, you can create another one, dropping any DNS-related traffic (destination ports 53 UDP & TCP, port 853 TCP) to the internet, and enable logging for it. If you see any hits then in your logs, something indeed managed to bypass the redirection rule - otherwise, it would not get to the dropping rule in the first place.
By the way, in this screenshot of yours, the firewall rules 8 and 9 are unnecessary, since Google’s DNS resolver will never establish a connection on its own - it only responds to incoming connections. That way, you don’t need to create firewall rules for 8.8.8.8 and 8.8.4.4 as a source.
I think since I setup some of these rules things changed.
I will have to redo them to make sure,
Interestingly, I think this rule works the best, because since then I have seen a lot of Windows 10 devices, showing “No Internet” and maybe this could be why Avast can’t get uipdates sometimes.
Or it could be a coincidence, it could be one of the IPS rules "ET DNS Non-DNS or Non-Compliant DNS traffic on DNS port "
