DNS Puzzle

johnpoz

Pihole IP not found in Status/Infra.

Well then its not pfsense (if all you have setup in dns is to talk to loopback) or anything asking unbound for dns that is causing it. So its something else that somehow is using the mac of your bridge you setup. Or something else running on pfsense talking to it directly.. Because the infra cache would show you all the NS that unbound has talked too.. if possible I would check that cache as soon after you see a mass query, they can fall off or if you have restarted unbound the infra cache would get flushed.

But if your not seeing it listed in the infra cache - then unbound didn't talk to it.

So you have tracked to a smart TV? Why would it be seen as your bridge mac? It is a wireless client and when pfsense bridges this traffic to your lan, its putting it on the wire as coming from the bridge mac?

Proxy Arp could do that, and have seen that in the past with like wireless extenders - but normally you should see the actual mac if on the same layer 2, even through a bridge.. Unless pfsense was routing that traffic - then your pihole could see traffic from some remote IP as the mac of the pfsense interface that sent the traffic too it.

But you should see the remote IP, just the mac of pfsense interface that routed it.. Unless pfsense was also natting the traffic.

provels

@johnpoz said in DNS Puzzle:

But if you're not seeing it listed in the infra cache - then unbound didn't talk to it.

Understood, agreed

So you have tracked to a smart TV?

Only from Googling the target hostname.
d1oxlq5h9kq8q5.cloudfront.net
All seem to ref Samsung TVs.

Why would it be seen as your bridge mac? It is a wireless client and when pfsense bridges this traffic to your lan, its putting it on the wire as coming from the bridge mac?

Yeah, no clue. But it is a wired client. I just cleared the log and will watch for it again. Thanks for all you input. I'll reply back when I see it again.

johnpoz

@provels wired client - wow that makes it weirder even - wireless ok something odd with the bridge and the wireless card in pfsense.

So the TV is on 1 side of the bridge and the pihole is on the other side? I mean if they are on the same side - then how would pfsense even be involved in the conversation, so there would be no way for your pihole to see the mac from the bridge. Is the pihole wired as well? And they are on different sides of the bridge?

Hmmm - wonder if mask could be wrong, and traffic is being sent to pfsense because TV thinks the IP its pointing to is on different network. I mean possible the TV could be trying to talk to say googledns or something - but you said you have no redirections or anything setup so even if it asked 8.8.8.8 pfsense wouldn't be sending that to the pihole. But if pfsense is seeing traffic to it with destination of IP of the pihole, could it maybe send that on, but from the mac of the bridge?

If you believes its the TV generating the dns queries - I would packet capture to validate that and see exactly what is going on, where is the traffic being sent, what IP and mac coming off the TV.

provels

@johnpoz

then how would pfsense even be involved in the conversation

Good question! TV and Pi are on the same flat net behind the bridge. Pi runs as a VM on a Windows server. Mask is right , TV gets DHCP. But would anyone be surprised if Google DNS was hard coded into the TV? After all, they try to make these things as stupid-proof as possible. I do attempt to block DoH in pfB. And I force all normal 53 DNS to the FW. But still, pfS shouldn't even know there is another DNS server on the net. As far as pfS knows, Pi is just another client. I'll watch it and post back if I have any revelations. Thanks again.

Bob.Dig

@provels said in DNS Puzzle:

And I force all normal 53 DNS to the FW

I think you have said you don't. So what do you do exactly.

@provels said in DNS Puzzle:

@Bob-Dig I only have one port forward, for OpenVPN, and that's not enabled unless I'm out of town.

I also would argue that this is not a port forward, just an open port.

johnpoz

@provels said in DNS Puzzle:

And I force all normal 53 DNS to the FW.

Yeah with @Bob-Dig here - you stated here that you don't do any redirection.

My net is quite simple, it's like 1998... No DNS redirection, NAT reflection.

If you redirect dns, and your TV is trying to talk to say 8.8.8.8 - where are you redirecting it too.. If the pihole than that explains your flood. If you were forwarding it to unbound, which resolves then it doesn't.. Even if redirected unbound would never ask pihole for anything unless you setup a domain override pointing to pihole, and you showed that is not happening when you stated you don't see the pihole IP in your infra cache. I haven't actually validated such a override would be in the infra cache - but I would think it would be.

Many iot devices these days hard code dns entries - I think it's horrible for them to do that, but yeah lots of them do.. The only way to try and stop that is with redirection, or just a block - and many of them will scream and holler and fail to move forward in a setup if they can't talk to their overlords via dns query to the outside.. Shoot some of them have started doing doh, which you can't really redirect and pita to block via whack-a-mole lists of known doh servers, even if you could like with the case with dot on its own port of 853, any sane client would be able to tell its been redirected because the cert being served wouldn't validate.

Good question! TV and Pi are on the same flat net behind the bridge.

Ok on the same side - because one side of your bridge is the wireless, and only 1 wired interface in the bridge.. So yeah same side makes sense - doh ;)

If that is the case then there is no freaking way pihole could ever see the mac of your bridge - unless you are actually redirecting traffic on pfsense and the TV is talking to something that would need to go through its gateway via the bridge connection on pfsense and your redirecting it to the pihole.

provels

@Bob-Dig I do, but the only client pfS's DNS should see is the Pihole.

i turned on the TV at 06:06 local and then saw this.

OK, so it looks like the TV is trying to go out the gateway and being bounced back to Pi. .74 is the TV, .01 is the pfS. Think that's it?

provels

@Bob-Dig said in DNS Puzzle:

I also would argue that this is not a port forward, just an open port.

I guess technically it is, since it's a random high port forwarded to 1194?

johnpoz

@provels that sure looks like the TV tried to directly talk to pihole, but then when it didn't get what it wanted seems like it says ok I will ask xyz out on the internet, which you then redirected.

Where exactly do you have that !pi_hole rule? source of ! pihole would be any IP that is not the pihole.. But that shows zero triggers with that 0/0 B -- but any other rule could allow that traffic.. What is your port forward - that looks like just a firewall rule that says hey any IP other than what IP is in the pihole allias going to the pihole alias ip(s) on dns_ports alias allow it.. As you can see with 0/0 there that rule has never triggered.. Which I don't see why it ever would since anything on your flat network wanting to talk to the pihole IP would never go through pfsense in the first place. What ports would you have in the dns_ports alias? Like I said you can not realistically redirect doh or dot (443 and 853) so creating an alias doesn't make a lot of sense.

Example here is a dns port forward redirection

Notice there is no 0/0 column - only a firewall rule would have that column..

johnpoz

@provels said in DNS Puzzle:

I guess technically it is, since it's a random high port forwarded to 1194?

Huh? A firewall rule that allows access to port 1194 on your wan interface isn't a port forward.. A port forward would be traffic hitting port X and being sent to port X or Y on different or same IP, etc.

What random high port are you talking about - the source port of some client wanting to talk to your vpn on 1194.. Yeah that is almost always going to be some random high port.. That you have no control over or ability to even know what it might be, etc.

provels

This is too much like work!!!

@johnpoz Yeah wrong rule. Here's the NAT rule. This was something I setup years ago and haven't had the need to look at since. I followed some recipe here on the forum.

Again, it's that Cloudfront host causing the flood and originates from the TV. Maybe best to just whitelist it. .74 def the TV.

@Bob-Dig Well, I thought I was port forwarding from the high port to 1194, but I guess I'm just passing the high port through. The OVPN server is disabled at present. Been a long time since I set this up, too!
Probably should have just left it at 1194 and NAT'd it at the FW if that's what I wanted.

johnpoz

@provels You have a few options.. Just block it talking to anything outbound for dns, doh is harder but not impossible, dot is easy with just a single port. Don't redirect it.

You can redirect it, and increase your flood number, or whitelist some of the stuff its looking for.. Problem with lots of these iot devices if they want to lookup xyz, and they don't get the answer they want or expect they can flood - like hey didn't get an answer, maybe if I just keep asking over and over again like every second maybe I will get an answer <rolleyes>. Maybe if I just ask faster will get an answer like 100 times in a second ;)

You could change the answer they get for what they are looking for, vs sending them nx or 0.0.0.0 - try sending them back loopback 127.0.0.1.. Also look to sending back different ttl vs what the default 2 seconds.. So if they do happen to have their own local cache - many iot devices don't.. Maybe if you give them some answer like loopback or all zeros with a ttl of an hour vs 2 seconds - they will only ask every hour vs every 2 seconds, etc.

Do some looking into what they are looking for - maybe some you might allow and not block, depends on what your wanting to stop?

Other option is just don't use internet on devices that flood like that - are you using the built in apps on the TV, or is this really some media stick.. Not all media sticks are as chatty and or easier to block specific ad fqdn, etc. that don't cause them to explode into a dns asking frenzy..

You could also just turn off the warnings of some of those rate limiting warnings in pihole - so sure it doesn't change what is going on, but it doesn't bother you warning you about something that you understand is going on..

provels

@johnpoz I do run a "Smart TV Blocklist" that's pretty aggressive; I have had to WL a few things to get the built-in app to work. I think the Pi default was 1000 hits before throttling, I dropped it to 250, thought I'd want to know if something went wild (and it did). I think I'll go ahead and WL that domain and leave it be. It's probably Samsung just wanting to know everything I've looked at today so they can squeeze their advertisers some more. Thanks again for all your input!

provels

@johnpoz I'm baaaaack! But no emergency, just FYI.
I created a rule to log all traffic from the TV and found hundreds of these entries in the FW log. Must be hard-coded in the Samsung firmware. Try to use its own DNS out the gateway, pfS redirects it back to Pihole.
Only posting in case someone else is similarly afflicted. Thanks again.

johnpoz

@provels yeah many of the iot devices these days are hard coding doh servers.. Like I said they are harder to block - and they way they can look up who they want to pull ads from or send telemetry, etc..

The prices of these products are so low quite often because the device itself is not really the product, they just want some device to get your info that they sell.

But yeah you start blocking stuff they want to look up, and you can find your NS getting hammered..