Force port 53/853 to local pfSense DNS resovler

rtfmoz

Using an ERPoe-5 and the goal is to capture any outbound traffic from the LAN (192.168.0/24) on port 53/853 that's not from my DNS server (.170) and forward it to the DNS server. The server is a pfSense DNS resolver running pfBlockerNG-devel for DNSBL to block groups of sites. I have the following configuration setup and I am wondering if there is a better way to achieve this.

viragomann

@rtfmoz
Don't see the sense of the rule for DNS exclusions sources, since the translation is the same as for any source.

It might be more reliable to put the DNS server into a separate network segment than doing masquerading on the whole traffic. But when forwarding from LAN to LAN this will be necessary.

johnpoz

Redirection of dot is almost never going to work - because the client should be validating the cert. And your dns is not going to pass that validation.

AndyRH

I did something similar using PiHole as the DNS servers. It works well and silently forces hard coded systems (Roku) to use my DNS. I posted the instructions to use PiHole.

https://forum.netgate.com/topic/156453/pfsense-dns-redirect-to-local-dns-server?_=1627566532678

johnpoz

Redirecting normal dns on 53 is quite simple.. But trying to redirect dot (dns using tls over port 853) is not.. Because the client should validate the cert is for the fqdn of the dot server wanting to talk to, and that its a trusted cert.

This is not going to be the case with redirection of this traffic your local dns. While mitm is possible with dot, its more involved than simple redirection.

rtfmoz

This post is deleted!

rtfmoz

@viragomann said in Force port 53/853 to local pfSense DNS resovler:

@rtfmoz
Don't see the sense of the rule for DNS exclusions sources, since the translation is the same as for any source.

Rules 3 and 4 have switch0 as the source and the DNS server is on the same LAN=switch0, so I dont want to create a port forward loop.

rtfmoz

@johnpoz said in Force port 53/853 to local pfSense DNS resovler:

Redirecting normal dns on 53 is quite simple.. But trying to redirect dot (dns using tls over port 853) is not.. Because the client should validate the cert is for the fqdn of the dot server wanting to talk to, and that its a trusted cert.

This is not going to be the case with redirection of this traffic your local dns. While mitm is possible with dot, its more involved than simple redirection.

Yes I understand the problem is I need to read the DNS packet to determine that and I cannot open up a TLS connection. So all I have left is the IP address. This means I need to add the anycast IP of the root servers to a group and exclude them from the redirection. Would that solve the issue you think?

rtfmoz

Oh wait... when you say dot, do you mean "." or are you are referring to dns over tls?

johnpoz

what I mean by dot is (dns over tls) if you think you can just redirect that.. You need to do a bit more research on what that is that is for sure..

Redirecting port 853 dns is not really a thing.

rtfmoz

This post is deleted!

johnpoz

You would go about it by setting whatever the fqdn the client is trying to use to point to the IP of the dns that is hosting the dot dns.. Or by redirecting an IP it has hard coded to your IP, etc.

Now if you have a cert with that cn, or san that matches that fqdn, and the client will trust the CA you created that cert from - there you go mitm.

Depending on the client you might not be able to edit what CAs it trusts - so it could prove to be almost impossible, etc.

If you have all that understanding of how TLS works, why would you think you could just redirect dot then?

rtfmoz

I initially thought you were just referring the root domain server list aka “.” so I just didn’t redirect them. When it comes to SSL certs validation rules always apply.

But if you saying the CN is not tied to the domain of the DNS lookup then mitm is no problem with a trusted CA deployment. I just got that impression from what you said above