Redirecting Client DNS Requests Dosen't work

johnpoz

@DjJoakim I don't see that rule ever being evaluated. See the 0/0

Easy way to validate your redirection is working is just query direct say to 1.2.3.4, if you get an answer than yeah your dns is redirected, either by pfsense or upstream.. because 1.2.3.4 doesn't answer dns..

DjJoakim

@johnpoz

Yeah i noticed that too, but can't figure out why it dosen't work... it's like my pfsense is avoiding the rules and being a teenager.
I will look into how to do that, for the meantime i use dnsleaktest to check if it's working...

johnpoz

@DjJoakim lets see your port forward rules..

Not just the one rule - lets see the order of them. Keep in mind if there is an existing state your redirect will not work..

For example if your client is talking to 8.8.8.8 and there is state already in the state table.. That redirect will not take effect until a new state is created. Ie that existing state times out, or you kill it, etc.

DjJoakim

@johnpoz The rules on the pic above is the only rules i have - this is a fresh installation. Or, ok.. the 2 rules not listed are in WAN, that's blocking the private network (default rules).

I have tried Reset state after every change i have done, seems like it dosen't matter. When i try to change my DNS servers on the computer on LAN, it pops up - google, cloudflare etc.. whatever i change it to.

Should you suggest using Kea or ISC, can that affect in any way?

johnpoz

@DjJoakim your dhcp server has nothing to do with it.. You sure your clients not using doh, that would be over port 443 and your redirection would not work..

Just do a direct query via your fav tool, nslookup, dig, host, doggo, dnslookup, etc

Here I redirected my dns for a test..

Notice got answer when asking 1.2.3.4, and how would google or quad9 know anything about my local nas.home.arpa so clearly that was redirected. Also notice my rule now shows evaluations, and a current state even.

Gertjan

@DjJoakim

As Johnpoz, another demo, using the same setup :

The NAT rule - the second rule :

My captive portal firewall rules start with :

The rules "IGMP" rule isn't related to the subject.
The second rule is the actual NAT DNS firewall rule, related to the NAT rule. Very few hits actually.
The third rule is a classic "accept TCP/UDP DNS" traffic rule - this one receives the most hits - I guess this rule is important.
The fourth rule is a bock all other DNS traffic rule. It never got any hits, which means all DNS traffic was handled at this point.

I have to use this DNS setup on a captive portal, as visiting device have to, use the DNS of pfSense, not some other DNS server, as the portal operation mode depends on this.

DjJoakim

@johnpoz @Gertjan

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.