PfSense - Cannot connect to Netflix and Hulu on Andriod devices / Smart TVs
-
I'd be more than happy to reproduce the results if wanted. Any insight I can provide, I will.
-
I agree, it's probably DNS. It's always DNS!
There's a lot of speculation that it's ECS but I don't see any actual proof of that in some brief searching. Yet.
-
@incith so again, ecs is not a thing with current unbound installed on pfsense
I just logged out of my netflix client on my android tablet.. I have a block to any other dns, and yup the stupid client is trying to use google pretty hard.. But its blocked, and the only dns it can use is my local dns.. Which just resolves.
And able to login to netflix just fine on the tablet, even though blocking google, and not sending any ecs..
While you very well could have a dns related problem, I highly doubt its a ecs problem - because well unbound isn't going to be sending any ecs info, since the module is not enabled in the one on pfsense. And you sure do not need to send that info to be able to login to netflix..
If you believe its a dns related problem - simple sniff of your clients dns traffic, see what it asks for, see what doesn't get answered.. Packet capture on pfsense for your clients IP on port 53.. Is there something its asking of dns that doesn't get answered?
Along with looking at dns, you could just capture all the clients traffic - is there something other than google dns its trying to talk to that doesn't get answered..
-
@stephenw10 said in PfSense - Cannot connect to Netflix and Hulu on Andriod devices / Smart TVs:
It's always DNS!
-
@johnpoz I'll do some more digging after work 🫡
-
@incith also curious why/how you would think ecs could fix the problem.. When you resolve clearly who you talk to knows what IP you did the query from..
ecs is for sending extra data when you want to send info about the client asking, that is different than who is doing the actual query..
EDNS Client Subnet (ECS) is an option in the Extension Mechanisms for DNS that allows a recursive DNS resolver to specify the subnetwork for the host or client on whose behalf it is making a DNS query. This is generally intended to help speed up the delivery of data from content delivery networks (CDN), by allowing better use of DNS-based load balancing to select a service address near the client when the client computer is not necessarily near the recursive resolver.
In what scenario would this help you, your client is behind your public IP.. So when you resolve, this would be the same as your IP the query is coming from.
ECS would make sense when say you had a corp network where you had central dns in your say chicago office, but you had clients in your LA office.. So you would want your chicago dns to send the info for the clients public IP range in LA, so when that client went to go talk to whatever resource on the public internet, it went to an IP close to LA and not chicago.. If the was such a resource in the CDN the resource is being served from.
ECS when all your queries are coming from from the same IP your clients would be using to talk to the internet with any doesn't make much sense.. Now sure it could very well help maybe in anycast sort of scenario where hey the dns your talking too is not the closest too you, and this remote NS should hand back a different IP then its region because well the client is in a different region, and only reason the query ended up on this remote NS was anycast. But then again the IP of the ns doing the query would be known anyway.. And that IP is no different than your client, etc.
I am just trying to come up with a scenario where ecs would or could solve your issue, and I am not seeing how it could be a problem to be honest. Now if you were routing your dns through some vpn - and the endpoint was far away from where your actually at, sure you might want to send your pubic subnet range in the query, so the actual NS that is going to answer for the query, knows hey use the best answer for the client subnet, and not the IP of the NS actually asking for it.. As you saw in when I queried 8.8.8.8 TXT directly.. But my client sent no extra info for that info to be available..
So you see any info in this query about the clients subnet or IP?
edit:
To be honest this would of been handy 20 years ago when company at worked for used central dns ;) and local internet access.. And some issues of connectivity could of be better if got an answer back based on the clients location vs where the query came from..I will do some googling on android and netflix and ecs, but I really don't see how that could be an issue..
-
@incith if you think its a dns related problem with unbound/pfsense - why not just have these android clients use 8.8.8.8 directly for everything, not just some specific forward for netflix.com
Do they work then? That would else for sure point the issue with something going on with dns on your end.
-
@johnpoz I feel like I've already said that works.
I don't want to go in circles.
I will further post my findings later.
Why not force my phone to use Google? Because I don't want to. That's a bandaid, not an understanding of the problem.
I don't think posting anymore "I don't see how..." will resolve anything.
In a nutshell, it's simple: with DNS caching on, I cannot login to Netflix on my phone. With DNS caching off (forward all requests), it works. Every. Single. Time. If I tell DHCP to specify my dns servers as public, it also works. If I revert that change and go back to caching DNS (even after restarting unbound and flushing the cache in status page), it will not login again.
You must clear data on your android between every attempt on the Netflix app.
I'm glad it's working for you!
That still doesn't mean it's not a DNS issue, as it clearly is, for me.
Even when I change my upstream DNS servers on pfSense, it made no difference. Ok?
This is absolutely something with unbound. Whether it's ECS or not.
-
@incith said in PfSense - Cannot connect to Netflix and Hulu on Andriod devices / Smart TVs:
This is absolutely something with unbound
Your not doing any filtering, no pfblocker lists? That could cause problems, but if that was the case it wouldn't work when you forward vs resolve either.
To get to the problem of what is not working when resolving, you need to know exactly what is failing, then you can troubleshoot why that is happening.
I had a weird issue the other day, where I was having trouble talking to the NS for .tv this was causing my app.plex.tv to fail.. This was something upstream of me..
;; ADDITIONAL SECTION: a.nic.tv. 172800 IN A 37.209.192.6 b.nic.tv. 172800 IN A 37.209.194.6 c.nic.tv. 172800 IN A 37.209.196.6 d.nic.tv. 172800 IN A 37.209.198.6I couldn't reliably talk to any of these NSers.. I found that by doing a dig with +trace for the app.plex.tv what was failing.. It was either something on their end, or something in my isp or just the internet that was not allowing me to talk to them. Prob something with my isp connection, because if I tried it from the one of my vps boxes no issue. Google wasn't having any issues, for a temp work around I setup forward for plex.tv to google, kind of like how your doing.. Then the next day the issue was gone..
If you sniff your clients IP for all dns its doing and find the one(s) that are failing you could do a +trace with dig to figure out what is failing in the resolve process. You might also want to look at your resolver status, look for domains that have high RTT or RTO or issues with timeouts.
When I was having the problem the other day, these number clearly showed major issue talking to those servers..
-
@johnpoz No, again, as I had mentioned previously, I disabled pfblocker and suricata.
I feel like I need that Chris Tucker gif "DO YOU UNDERSTAND THE WORDS THAT ARE COMING OUT OF MY MOUTH?"
Like...I'm out. This conversation is frustrating me now.
️ -
@incith said in PfSense - Cannot connect to Netflix and Hulu on Andriod devices / Smart TVs:
I disabled pfblocker and suricata.
Did you read my post, where did I say it was pfblocker or suricata?? I just stated if was pfblocker it wouldn't work be it you forward in unbound or resolve - so clearly its not that, etc.
You can not troubleshoot the problem if you do not know what is failing - period.
So did you even look at the status of the resolver, do you see any high RTT or RTO domains? Timeouts?
sniff your clients IP when you try and go to netflix or hulu to login - what is failing in the dns queries it sends out? You will see the queries, and pretty easy to tell in the sniff what did and didn't get an answer.. Once you see something that doesn't get an answer, you can look to why your not getting an answer... But until you know that, you can not figure out what the problem is.. If your not going to do that, then you might as well just have unbound forward vs resolve..
My example above was showing how I determined what the problem was, there was as specific fqdn I couldn't resolve - so via a +trace with dig I could tell where it was failing in the resolve process, it wasn't a "unbound" issue.. It was a problem outside of my control in the resolve process.
First step is to know what exactly is failing.. Which you do not - you just know netflix isn't logging in..
-
This post is deleted!
