Redirecting Client DNS Requests Dosen't work

DjJoakim

I performed an nslookup, and after doing that, I observed states on the LAN rule for DNS, so at least something seems to be working. However, I am not a DNS expert, which is why I'm reaching out for help. I have read a lot about how DNS works, and since nslookup seems to work, that's a good start. My goal, though, is to ensure that no one on the network can use their own custom DNS servers. I want everyone connected to the internet to only use the DNS servers on my PFsense, and if they don't, they should be redirected to do so.

Despite nslookup appearing to work, I get 0/0 on the states of the LAN rule when I try to "manipulate" the system by using my own DNS servers, such as Cloudflare and Google. What could be causing this issue?
See the attached image below. This is the opposite of what I want to achieve.

Thank you for your time and assistance.

Edit: I just saw that you mentioned DoH, and that could explain something. Is there a way I can look this up? And if so, is there anything I can do to redirect it? I guess not, since it's going over port 443...

alt text

johnpoz

@DjJoakim said in Redirecting Client DNS Requests Dosen't work:

is there anything I can do to redirect it?

No not really - all you can do is block all known doh servers.. Part of the plan of doh was/is to circumvent local dns by hiding in your normal 443 traffic that you can not really block - or you block the whole freaking internet.

But you can disable it in the browser.. for now.

Here is the thing - say you had a list of known doh servers, and you said ok if someone tries and talk to this known IP on 443 I will redirect them to my unbound doing doh.. Problem is how you going to get them to trust your doh cert, and look like your doh.google.dns or come or whatever.. The client "should" be sane enough to say hey wait a minute here this isn't

the doh server I wanted to talk to - this is someone else - the cert is wrong. Or the san on the cert might be right but I don't trust the CA that signed it etc..

Part of the whole point of doh is validation that your talking to the name server you said you wanted to talk too.. So if the doh client (your browser) isn't doing that - its a pos implementation that again just points to the real reason they came up with doh is wanting your dns queries.. They could give 2 shits about your privacy or security if you ask me..

if you have setup redirection and it works from your local dns client dig or nslookup or host or doggo, etc. then your redirection is working - but your browser is most likely doing doh.. The browsers like to turn that on by default of late.. There have been many a thread where user can't get something to work with dns just to come to find out the reason is their browser is doing doh..

DjJoakim

@johnpoz

Thank you so much for the explanation. I just don't want things to use their own DNS servers, but if they do over port 443, then I guess it's okay since it's hiding the local DNS, if I understand you correctly.

Just like you said, since it's working when I'm doing nslookup, it's redirecting the local DNS, and I am satisfied with that.

Thank you so much for taking the time to explain this to a newbie; I really appreciate it.

johnpoz

@DjJoakim you can just go into your browser and disable doh..

Here for example firefox.

You can turn if off in the other browsers as well.. But I am a firefox user so that was easiest to show.

DjJoakim

Hi again, sorry for bumping this thread, but I'm running into DNS redirect issues once more.

I'm trying to understand a DNS redirect behavior I've observed in my pfSense setup and hoping someone can clarify why it works in some cases but not others.

Scenario:

I have multiple VLANs/subnets configured, and I've set up NAT Port Forward rules to redirect all outbound DNS (port 53) to the pfSense resolver. According to the official Netgate guide, the redirect target IP should be 127.0.0.1.

This setup works perfectly in some subnets – clients are redirected and DNS resolution works as expected.

However, in one specific subnet, DNS fails completely when redirecting to 127.0.0.1. The only way to make it work there is by changing the NAT redirect target to the subnet’s gateway address (e.g., 10.x.x.1).

Firewall rules, NAT, DHCP – everything is configured identically across subnets.

My question:

Why does redirecting DNS to 127.0.0.1 work in some subnets but not others?

What factors determine whether 127.0.0.1 works as a redirect target?
Is it related to Unbound’s listen interfaces, loopback behavior, routing differences, or something else?

Any insights would be greatly appreciated – I'd love to fully understand the conditions that make this work (or break it).

Thanks in advance!

johnpoz

@DjJoakim it should work on all your subnets, off the top of my head I can not think of anything that would allow it to work if you redirect to an interface IP vs the loopback.

So when it set to forward to 127.0.0.1 - do you just time out, or do you get a response say nx or refused? when you query say 8.8.8.8

You can check this with your fav dns client, dig, nslookup, host, doggo, etc.

DjJoakim

@johnpoz
Thank you for the fast reply.

When i have the subnet gateway as NAT IP in the rule, i get this resoult using nslookup

unifi@unifi:~$ nslookup google.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.74.174
Name:   google.com
Address: 2a00:1450:400f:801::200e

And when looking at Packet Capture on WAN, port 53 - i can see that even when i try doing nslookup google.com 1.2.3.4 or 8.8.8.8, WAN IP always talks to the DNS server i have set on the interface - so it seems that the redirection is working.

But when i change the NAT IP to 127.0.0.1 and reset states, i get this;

unifi@unifi:~$ nslookup google.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.74.174
;; Got SERVFAIL reply from 127.0.0.53
** server can't find google.com: SERVFAIL

And i can ping 1.1.1.1, 8.8.8.8 but not google.com etc, so from my understanding the devices on that subnets get's "internet" but not DNS.

Thanks!

johnpoz

@DjJoakim said in Redirecting Client DNS Requests Dosen't work:

Server: 127.0.0.53

That is pointing to where? That is local caching instance running on your unifi box.

You should be able to see where it actually points too with

resolvectl status

Here for example is my unifi box ;) But I have renamed it to UC (unifi controller)

user@UC:~$ nslookup www.google.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   www.google.com
Address: 142.251.32.4
Name:   www.google.com
Address: 2607:f8b0:4009:81c::2004

user@UC:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (ens3)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.3.10
       DNS Servers: 192.168.3.10
        DNS Domain: home.arpa
user@UC:~$

You can see mine points to 192.168.3.10 which is my pihole.

I am currently running my controller on

user@UC:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.2 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo
user@UC:~$

DjJoakim

@johnpoz
Hmm, my "current DNS server" and "DNS Servers" are the gateway IP Adress of that subnet, so that explains why it's working when i change the NAT IP to the gateway adress..

I am running the same machine as you :)

unifi@unifi:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.2 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

I can't remember where i changed the DNS settings, and what do you suggest i change them to - 127.0.0.1?

Thanks again!

johnpoz

@DjJoakim why would not just point them to the IP address of pfsense on whatever network its on?

The only point of redirection is when some client is hard coded to use some external dns that you don't want it using. And you can't change it.

if you pointed it to 127.0.0.1 it wouldn't work, that is itself, just like 127.0.0.53 is.

DjJoakim

@johnpoz
Hmm, but it’s pointed to the subnet now - the device is on a vlan (10.30.0.1) with ip 10.30.0.100, and the dns servers are set to 10.30.0.1 - shouldn’t that work? Since DNS forwarder is listening to all subnets.. I can’t see why it’s working if I change the NAT ip to 10.30.0.1 and fails when I change it to 127.0.0.1

johnpoz

@DjJoakim lets your rules.., You should allow it to go to that without redirecting it.-

DjJoakim

@johnpoz
Here are the rules – ignore the fact that the gateway appears disabled in the screenshot.
And yes, I know you might think the last rule isn't necessary (based on a previous discussion)... but it's there anyway!

Since the descriptions are in Swedish, here's what the rules do:

NAT – Force DNS through pfSense
Reject all other DNS
Block connections between different subnets
Gateway rule
Block traffic that doesn't match the correct gateway

johnpoz

@DjJoakim put a rule above that first redirect rule that actually allows a client to talk to pfsense address on 53

what does your port forward look like?

your port forward is normally a ! rule, ie not to pfsense address, which wouldn't trigger if your going to pfsense address anyway. Or not to rfc1918, etc.

DjJoakim

@johnpoz
Yeah, I figured that I needed some sort of pass rule above everything else, but since it's working on every other subnet, I assumed the forwarder was handling it.

Here’s a screenshot of one of my other subnets – the one for my WiFi units – and it works just fine.
I’ve also included the NAT rules there so you can see them.

Another thing, since we're on the topic of DNS issues: as you can see in my WiFi subnet, I have a failover setup with dual WAN. I’ve noticed that when WAN1 goes down and it switches to WAN2, DNS stops working. I guess this might be related somehow?

In my "General Setup", I have one DNS server configured, and it's not assigned to any specific gateway ("none").
I know this is a bit off-topic, but since it's DNS-related, I figured I’d share it in case it helps clarify the overall picture.

Thanks!

johnpoz

@DjJoakim so example these rules

if you have a client on your wifi that is not using pfsense IP address on this network, then it would forward it to the loopback 127.0.0.1, and it would work.. But what if they are going to this pfsense wifi IP, then that rule wouldn't trigger.

so unless you had a rule that would allow the traffic on the interface to the pfsense wifi IP address - then dns wouldn't work for that client.

So I can see why your unifi isn't working - its trying to go to pfsense IP address, but your port forward says hey only forward if they are NOT going to pfsense unifi IP address. And you don't have any rules that allow it to talk to pfsense IP on dns.

When you change the forward to pfsense unifi IP, then the firewall rule changes to pfsense unifi IP vs 127.0.0.1 and your client is allowed to ask pfsense IP for dns on that network.

They might want to add a note to this

https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

That mentions something about having a rule that does allow access to pfsense IP for dns on the interface your wanting to redirect on.. Or yeah your going to have problems.. Unless you just made the port forward to any IP port 53.. vs the ! rule to the address.

You blocking all dns before say an any any is what is killing you.. So you could either remove that block, because your redirecting or put a rule above your redirection that allows access to pfsense IP on that network for dns, etc.

DjJoakim

@johnpoz

Thanks a lot for the detailed explanation – that actually makes perfect sense now!

To summarize what you said (and what I've realized):

Since my NAT redirect rule is set to "!Interface Address", traffic directly targeting the pfSense interface IP (e.g., 10.30.0.1) is not captured by the redirect.

Therefore, if a client is using the pfSense IP as its DNS server, the NAT rule doesn't apply.

In that case, I must have a firewall pass rule that explicitly allows DNS (TCP/UDP port 53) traffic to the pfSense IP on that interface.

If I don't have that pass rule, the client can't reach DNS, and resolution fails.

When I changed the NAT redirect target from 127.0.0.1 to the actual interface IP, things started working because the destination matched the pass rule and the firewall rules properly handled it.

So after adding the Pass rule as shown below, it started working.

Thank you so much for the explanation and your time – I will now look into why DNS fails when my failover kicks in.
Hopefully, once that's sorted, all my DNS issues will be resolved (at least for now)! :)

johnpoz

@DjJoakim yeah so stuff using other than your IP will be redirected, and stuff using the pfsense IP will be allowed.