DNS Puzzle

provels

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!