DNS Puzzle

[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..