Redirecting all DNS Requests to pfSense?
-
Yes. That firewall rule is allowing explicit access to DNS running on the firewall.
-
Should I read it like this: the NAT rule ensures all DNS is 'catched' and sent to 127.0.0.1:53, and this firewall rule is allowing that DNS traffic.?
Thank you.
-
Yes. The NAT defines the redirection, and the firewall rule permits the traffic to flow.
-
@snore said in Redirecting all DNS Requests to pfSense?:
Should I read it like this: the NAT rule ensures all DNS is 'catched' and sent to 127.0.0.1:53, and this firewall rule is allowing that DNS traffic.?
Thank you.
If so, suppose you have a VPN-client (say to PIA). For this particular VPN-client-traffic you want to use PIA's DNS-servers, would that mean you can not use the NAT-technique, since then all traffic goes via the firewall's DNS, including thus the VPN-client-traffic you don't want to go through there?
-
Yes, I believe so. In that case, you don't want to transparently redirect all DNS to pfSense.
-
Thank you.
So if I understand correctly in that case it would be best to:
- Have the above allow rule;
- Have a block rule after that for all DNS requests to something else than the firewall.
Of course, if you have devices that have hard coded DNS servers in them (that will ignore the DNS servers that are issued to them via the firewall DHCP), that then will fail. But then again, that was the purpose: disallowing any other DNS than the firewall's DNS.
-
Reviving this old thread in hopes of getting some clarification about few questions I have on this topic:
-
The link:
https://docs.netgate.com/pfsense/en/latest/dns/redirecting-all-dns-requests-to-pfsense.html
talks about how to accomplish redirecting all DNS requests via NAT port forwarding but it doesn’t say on whether to also add a firewall rule about it or not (located below the NAT redirection option). So is a firewall rule important to add to your firewallrules for LAN and each VLAN you have created after you configure the NAT forwarding for each of those interfaces? -
The link: https://docs.netgate.com/pfsense/en/latest/recipes/dns-block-external.html#dns-block-external
talks about the other option of redirecting DNS inquiries which is via blocking of external client DNS inquiries in firewall rules and also states that although this method works, the NAT forwarding option maybe able to more gracefully get this task accomplished.
Would it hurt to implement both NAT port forwarding AND firewall rules to get all DNS inquiries forwarded to pfSense? Or is one option sufficient? Do you have preference which one to go with if it is only one?
-
If you need to redirect DoT requests, do you follow the same steps on either NAT port forwarding option or the external client blocking option (under firewall rules) as explained in the links mentions above?
-
What about redirecting DoH requests ? How do you achieve that? Via pfBlocker blocking of DoH providers or do you have a better way?
Appreciate any assistance with this and any screenshots of your configuration(s) to illustrate that.
Thanks so much in advance!
Marin
-
-
@MarinSNB said in Redirecting all DNS Requests to pfSense?:
- So is a firewall rule important to add to your firewallrules for LAN and each VLAN you have created after you configure the NAT forwarding for each of those interfaces?
In most cases, NAT rule and firewall rule is a belt-and-suspenders approach. If a packet destined for port 53 ingresses an interface with the NAT rule applied, then there's no way for that packet to circumvent the NAT rule-only.
(If one is already performing outbound filtering, destination port 53 may already be blocked in that interface's firewall ruleset, too.)
- Would it hurt to implement both NAT port forwarding AND firewall rules to get all DNS inquiries forwarded to pfSense? Or is one option sufficient? Do you have preference which one to go with if it is only one?
The NAT option is preferable since it redirects the packet to an operational DNS resolver that can actually respond to the query (regardless of whether or not the client respects the answer)—as opposed to a firewall rule which simply drops the packet with or without notifying the client.
But a firewall rule can also be added, and in some cases is necessary, without affecting the 'graceful' operation of the NAT rule.
Two scenarios:
1.) You're redirecting to the DNS Resolver listening on the same interface, and therefore the packet never egresses said interface and never even 'hits' the firewall ruleset; or
2.) If performing outbound filtering on an interface and forwarding to a different interface, you need a firewall rule since the packet will need to egress the interface it ingressed and therefore be assessed against the firewall ruleset.
- Lastly, if you need to redirect DoT requests, do you follow the same steps on either NAT port forwarding option or the external client blocking (under firewall rules) as explained in the links mentions above?
Yes, same steps. Just substitute destination port 853 for port 53 in any/all rules you create, NAT or firewall.
- What about DoH blocking? How do you achieve that? Via pfBlocker blocking of DoH providers or don’t out have a better way?
Correct. pfBlockerNG with known DoH-provider DNS and IP blocklists.
-
Dot is 'harder' to redirect.
Is TLS after all.
Let's take https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-tls/ for example. If the client device has set up DoT "according the rules", he would be using opening a connection to .1.1.1 and at the beginning of the transaction, the certificates are negotiated, and the certificate from "1.1.1.1" is checked against "does this certificate mention "1.1.1.1" or "one.one.one.one" ?"After all, when a browser connects to Microsoft over TLS ( == https) then, when connected, the certificate from the Microsoft server comes back, and should contain *.microsoft.com". If not, the browser sound all the alarm bells.
So, redirect DoT will probably make the DNS transaction fail. Normally, the device will fall back to a known DNS server, most probably the one with the DHCP lease.
DoH : even worse.
So this will be traffic that 'looks like' ordinary https traffic going to the default 443 TCP port.
pfblocker has a list with known DoH servers, and knows how to block them. -
@tinfoilmatt Thank you so much for your thought!
-
@Gertjan Thank you so much!