Redirecting Client DNS Requests Dosen't work
-
@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::200eAnd 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: SERVFAILAnd 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!
-
@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:~$ -
@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-logoI can't remember where i changed the DNS settings, and what do you suggest i change them to - 127.0.0.1?
Thanks again!
-
@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.
-
@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 -
@DjJoakim lets your rules.., You should allow it to go to that without redirecting it.-
-
@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
-
-
@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.
-
@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!
-
@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.
-
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)! :)
-
@DjJoakim yeah so stuff using other than your IP will be redirected, and stuff using the pfsense IP will be allowed.
