How to combine interface isolation and External Client DNS Queries
-
Hi Guys,
After setting up DNS over TLS...
https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.htmlthen isolating interfaces with the following guide...
https://docs.netgate.com/pfsense/en/latest/solutions/xg-7100/opt-lan.html
I'd like to apply the following external client DNS queries rules...
https://docs.netgate.com/pfsense/en/latest/recipes/dns-block-external.html
Unfortunately, the guides treat DNS differently.
Firstly, is the external client DNS block rules relevant...
Secondly, does the interface isolation rules achieve the First...
Thirdly, do I need to combine the two rule sets together and if so, how?Thanks.
-
@ASGR71 they are different thingsā¦the first prevents OPT from accessing devices on LAN. The example allows DNS so the devices on OPT can resolve hostnames.
The second prevents connecting to DNS servers on the Internet. You would need those rules on LAN and OPT if you want both restricted.
As for combining, rules on an interface are processed in order top down.
-
@ASGR71 putting a block rule to 53 just below the rule you allow 53 to pfsense IP would be a valid solution if you want to block clients on that network from talking to any normal dns on the internet.
If you are having issues with clients using dns other than pfsense. While that rule would block normal dns, it doesn't prevent clients from using doh (dns over https) or dot (dns over tls).. while dot should be easy to prevent since the standard part is 853.. And clients don't normally use dot. A forwarder would use dot to forward to some other resolver via tls.
Blocking clients from using their own dns to circumvent local dns has become an uphill battle.. Browsers deciding to use doh on their own without explicit opt-in by the user is a problem.
Blocking doh is becoming a challenge. Since it uses standard 443 port of https traffic - which is pretty much everything on the internet these days. Blocking this has come down to using lists of known doh servers and blocking the IPs.. Which can turn into a wack-a-mole game..
But if you just want to prevent some client talking to say 8.8.8.8 or quad9 or 1.1.1.1 on 53, etc.. then yeah that 2nd rule accomplishes that.