When trapping rogue DNS requests, logging looks strange

gniting

The (long) screenshot below show two things:

The NAT rule that I have to trap/reroute "rogue" DNS requests originating from clients on my network
The automatic firewall that is created when I made this NAT rule

Looking at the details of #2 above, it looks like that rule will capture all DNS requests and log them, which is what I am seeing. I am only interested in logging requests made to DNS servers that are not my preferred one.

When I use tcpdump to see the same info, I get what I am looking for, so it is working.

tcpdump -i igc1 -v 'udp port 53 or tcp port 53 and not host 192.168.7.1'

How do I fix the NAT+LAN rule to fix the logging?

Gertjan

@ibbetsion

You implemented this : Redirecting Client DNS Requests ?

Why NATting to 192.168.7.1 instead of 127.0.0.1 ?
( 192.168.7.1 might work ... )

viragomann

@ibbetsion said in When trapping rogue DNS requests, logging looks strange:

How do I fix the NAT+LAN rule to fix the logging?

The filter rule can only log, what it sees. The NAT happens in front of it, but it doesn't log anything.
If you want to log all DNS requests, which are not going to the stated server block them.

However, I'm wondering, why you're caring about.
I do also forwarding DNS requests to my pfSense, but I don't care about the origin requested address.

Gertjan

@viragomann said in When trapping rogue DNS requests, logging looks strange:

I'm wondering, why you're caring about.

He probably want to find the devices that misbehave ?

gniting

@viragomann said in When trapping rogue DNS requests, logging looks strange:

@ibbetsion said in When trapping rogue DNS requests, logging looks strange:

How do I fix the NAT+LAN rule to fix the logging?

The filter rule can only log, what it sees. The NAT happens in front of it, but it doesn't log anything.
If you want to log all DNS requests, which are not going to the stated server block them.

However, I'm wondering, why you're caring about.
I do also forwarding DNS requests to my pfSense, but I don't care about the origin requested address.

Curiosity mostly...

johnpoz

@ibbetsion what are you seeing in the log that you don't think you should be seeing exactly?

viragomann

@Gertjan said in When trapping rogue DNS requests, logging looks strange:

I'm wondering, why you're caring about.

He probably want to find the devices that misbehave ?

Yes, I got it. But what's the benefit of that.
The redirection works and all is good anyway, even if some clients keep on trying to access another name server.

gniting

@johnpoz said in When trapping rogue DNS requests, logging looks strange:

@ibbetsion what are you seeing in the log that you don't think you should be seeing exactly?

@johnpoz my expectation is that I will only see entries in the log that are being blocked. However, I am seeing all DNS queries.

I made the change suggested by @Gertjan and changed the NAT rule to use 127.0.0.1 vs 192.168.7.1 and doing that did result in the logs only capturing the denied DNS queries, but now I see the dreaded unexpected source error when using nslookup and forcing the use of an external DNS server.

❯ nslookup cloudflare.com @8.8.8.8
;; reply from unexpected source: 192.168.7.1#53, expected 72.52.178.23#53
;; reply from unexpected source: 192.168.7.1#53, expected 72.52.178.23#53
;; reply from unexpected source: 192.168.7.1#53, expected 72.52.178.23#53
;; connection timed out; no servers could be reached

Unsure what's going on.

johnpoz

@ibbetsion ah yeah - that is client error/warning - change redirect to loopback and you wan't see those.

Your saying your seeing that with looback as your redirect?

If you were directing to loopback, why would it be saying 192.168.7.1 - are you doing an outbound nat into your network?

Gertjan

@ibbetsion said in When trapping rogue DNS requests, logging looks strange:

but now I see the dreaded unexpected source error when using nslookup and forcing the use of an external DNS server.

nslookup is there to check things : you gave it the 'wrong' DNS, so it complains. That's perfect.
When you run nslookup on your PC, there won't be any errors, because :
Your LAN has 192.168.1.1/24 - your PC uses a 192.168.1.x/24, and got a DNS that is 192.168.1.1 - and a gateway that is 192.168.1.1.
So, when you start nslookup, it will use the default DNS, obtained by DHCP, which is 192.168.1.1, and you will see no complaints.
Devices that behave not the correctly, as they use for example 8.8.8.8 even when they got from DHCP '192.168.1.1", well, let them complain, they asked for it.

I tested all my network devices : NAS, printers, DVR's PCs and other stuff : they all respect my DNS : all devices use 192.168.1.1 (that is : they don't : they use the IPv6 equivalent, as IPv4 is less used these days)

My iPad, iPhones : same thing : if they got an DNS from my DHCP server (pfSense), they will respect that DNS, and (oh, lol : how can this be true :) they will not use 8.8.8.8 or some other DNS harvester. I guess : phone apps can't do their own DNS, this is not allowed.
Note to myself : I'll have to try that ones : if (local) DNS doesn't work, will they start to resolve ? Or just bail out ?

I use the "Redirecting Client DNS Requests" rule set on my captive portal, as there are many 'other brand' wifi devices behaves differently, even when they got 'DNS is 192.168.1.1' they still insist in using 8.8.8.8 for everything (because they have to call home, I guess) and this will break the captive portal : they can't login.
They can't even contact 8.8.8.8 (or 1.1.1.1 or who ever) because the portal will not allow this.

Devices that use a network should respect that network's gateway (if not : no internet) and that network's DNS - if not, also ok, let them find the conclusion : go connect some where else.
They will auto comply ^^

gniting

@ibbetsion said in When trapping rogue DNS requests, logging looks strange:

@johnpoz said in When trapping rogue DNS requests, logging looks strange:

@ibbetsion what are you seeing in the log that you don't think you should be seeing exactly?

@johnpoz my expectation is that I will only see entries in the log that are being blocked. However, I am seeing all DNS queries.

I made the change suggested by @Gertjan and changed the NAT rule to use 127.0.0.1 vs 192.168.7.1 and doing that did result in the logs only capturing the denied DNS queries, but now I see the dreaded unexpected source error when using nslookup and forcing the use of an external DNS server.
❯ nslookup cloudflare.com @8.8.8.8
;; reply from unexpected source: 192.168.7.1#53, expected 72.52.178.23#53
;; reply from unexpected source: 192.168.7.1#53, expected 72.52.178.23#53
;; reply from unexpected source: 192.168.7.1#53, expected 72.52.178.23#53
;; connection timed out; no servers could be reached
Unsure what's going on.

@johnpoz here's a screenshot with the rule configuration and a new outbound NAT rule that I created to deal with the "unexpected source" error. Unfortunately, the error still persists.

@Gertjan while I understand your sentiment, I don't want to take away DNS resolution from the "rogue" device because it may render is useless. That means family will scream at me for X device not working :)

johnpoz

@ibbetsion said in When trapping rogue DNS requests, logging looks strange:

hat I created to deal with the "unexpected source" error.

Huh - no there should be no outbound nat rule - that could be causing you and issue.. If you forward to loopback your client would not know it not talking to 8.8.8.8

So this normally happens when you forward to some other NS on the same network as the client..

So for example..

I just duplicated it again

;; reply from unexpected source: 192.168.3.10#53, expected 8.8.8.8#53
;; reply from unexpected source: 192.168.3.10#53, expected 8.8.8.8#53
;; reply from unexpected source: 192.168.3.10#53, expected 8.8.8.8#53

if I setup a redirect on my 192.168.3.0/24 network and send traffic to pihole I run on this network at 192.168.3.10, and do a query from my client at 192.168.3.32 to 8.8.8.8

This has been gone over a few times - here is an old thread.

https://forum.netgate.com/post/920206

What is this 192.168.7.1 your trying to redirect too.. The problem is when your client tries to talk to say 8.8.8.8 and sends traffic to your router to get sent there, and your router sends it to something else on the same network, and it directly answers the client - the client will say hey wait a minute I was trying to talk to 8.8.8.8 via my gateway, why is this IP sending me an answer.. That is not where I sent it.

So you can either redirect to something on a different network, or loopback, etc. Or sure even an IP on pfsense should work. But if your going to redirect to something on the clients network - and it answers directly then yeah more than likely your going to have issues with the client not liking that he gets answer from something else than where he thought he was sending it.

gniting

@johnpoz said in When trapping rogue DNS requests, logging looks strange:

What is this 192.168.7.1 your trying to redirect too.

192.168.7.1 is the pfsense router. I want all DNS queries to go through the DNS server running on this system.

I deleted the outbound NAT rule. It was useless.
With the setup now, I do get what I want, which is that all rogue DNS queries are routed to my desired DNS server. But, the missing part is that I still can't log these. Since NAT rules are executed before other rules, the redirect happens before any logging can take place and NAT rules themselves don't allow for any logging.

Am I just overthinking this?

johnpoz

@ibbetsion Yes nat is before rule - but the rule would still log since the firewall has to allow the forward.

Gertjan

Just this one :

@ibbetsion said in When trapping rogue DNS requests, logging looks strange:

That means family will scream at me for X device not working

That's the ever ongoing discussion between "you and the others".
You : want to protect the entire network, and also from the others hurting themselves and/or your LAN. You don't want them to shoot in their own foots. Everybody knows all about security and that they should be careful .... and then they tap on the "Install tiktok" button.
Life is hard, .... but we keep on smiling.