pfSense, Unbound & Netflix = No go...

wardex

After you switch to resolver mode I would check to see if there are any residual states that still point to 8.8.8.8 and delete them. The Netflix app does make direct connections to 8.8.8.8 with a very short TTL. Those states may still be active from before your config changes.

SteveITS

@furom If using forwarding disable DNSSEC. Per Quad9 it can cause false failures. I noticed no issues in multiple routers in 22.05 and earlier.
https://support.quad9.net/hc/en-us/articles/4433380601229-Setup-pfSense-and-DNS-over-TLS

furom

@johnpoz said in pfSense, Unbound & Netflix = No go...:

but don't your clients just point to pfsense for dns?

They should, yes, good point. Thanks :) I guess a rule like this should do it, right?

johnpoz

@furom yup that is valid rule to allow clients on one of your network to talk to that networks pfsense IP and use dns.

Just need to make sure its in your rule list before something blocks or redirects it.

johnpoz

@furom now just because I don't have any issues with resolving all the stuff needed for netflix to work correctly, and I do quite a bit of dns filtering.. But nothing that I recall for netflix specific, but I do a lot of telemetry blocking of my rokus attempts..

Might be good troubleshooting step to load netflix in your browser - do you have any issues with that working? With a browser you can normally get a listing of all the stuff trying to be loaded, like the developers tools in firefox..

To see what exactly is not resolving, what is not loading, etc.

you could enable more detailed logging of your dns queries and responses with

server:
log-queries: yes
log-replies: yes

In unbound custom options box - this might give you some insight to what is failing, and once you know that you can look to why.. Maybe your having a hard time talking to a specific network where some of the NS for a specific domain involved in some aspect of using netflix sit.. It is prob way more than just www.netflix.com ;)

I know for sure that at least at some point in the past, not sure if currently happens.. But if you were using HE tunnel for your IPv6 netflix wouldn't work.. HE can be used as a way to circumvent geo location, so netflix had blocked it.. There was a few discussions of that around here, and ways stop unbound from returning any AAAA for the netflix required domains.

While I use HE, the network my rokus sit that I use netflix on has no IPv6 enabled at all - so be it they got a AAAA for something doesn't matter since the clients don't have an IPv6 to try and talk to netflix via HE anyway.

furom

@johnpoz said in pfSense, Unbound & Netflix = No go...:

@furom yup that is valid rule to allow clients on one of your network to talk to that networks pfsense IP and use dns.

Just need to make sure its in your rule list before something blocks or redirects it.

Great. It works fine for most stuff I tried, but Netflix still won't like this... I get black icons for much content for some reason. I did reload filters, reset states and then restarted Netflix/player...

furom

@wardex said in pfSense, Unbound & Netflix = No go...:

After you switch to resolver mode I would check to see if there are any residual states that still point to 8.8.8.8 and delete them. The Netflix app does make direct connections to 8.8.8.8 with a very short TTL. Those states may still be active from before your config changes.

Thanks! This is a good one, have started to do this more regularly now after a change. :)

furom

@johnpoz said in pfSense, Unbound & Netflix = No go...:

Might be good troubleshooting step to load netflix in your browser

Just tried Netflix in firefox, and well, works flawlessly, but my player on another network still refuses partly, identical DNS rules, on top of all else so should behave the same... But the DNS-rule on netflix network creates no states...

furom

@furom Found what made the difference... :(
My player does not like this to be on;

And yes, it says quite clear that it may break a lot, but worked fine with Quad9 so why suspect it...

So... Would this indicate something is not working or how should I interpret it?

johnpoz

@furom said in pfSense, Unbound & Netflix = No go...:

But the DNS-rule on netflix network creates no states...

The one to pfsense IP? That would point to devices not using pfsense for dns.. Maybe they using doh?

Even if they are redirecting you should see a state..

furom

@johnpoz said in pfSense, Unbound & Netflix = No go...:

Even if they are redirecting you should see a state..

After unchecking the option above it works great again... :) Time fo celebrate with an episode of something I suppose. :)

Would be grand to know if this option should work with Unbound, or is it my player that has a problem with it? It does use the pfSense DNS btw, or at least states that it does...

johnpoz

@furom said in pfSense, Unbound & Netflix = No go...:

And yes, it says quite clear that it may break a lot, but worked fine with Quad9 so why suspect it...

Why would you think that would work when you forward.. That is a resolver option.. Forwarding isn't going to use min name - how would that work?

If you are resolving - yeah strict is going to break quite a bit of shit that can tell you for sure..

I don't see how that could work if you were forwarding at all to be honest.. I have never tested what exactly would happen when forwarding.. Well because it would be pointless to try and do qname minimization if you were forwarding..

But I might see what unbound actually does with qname on and forwarding.. I don't see how that is a valid configuration to be honest.

furom

@johnpoz said in pfSense, Unbound & Netflix = No go...:

Why would you think that would work when you forward.

I thought I used the Resolver? I only said I fell back on forwarding as I didn't get Unbound Resolving to work initially. Sorry if it was confusing. It has been a bit for for me, but finally works now

furom

@johnpoz said in pfSense, Unbound & Netflix = No go...:

I don't see how that could work if you were forwarding at all to be honest..

I wouldn't be surprised if it just "tolerated" it then. I have once set it and then changed to forward-mode after that I suppose, it never complained :)

johnpoz

@furom said in pfSense, Unbound & Netflix = No go...:

have once set it and then changed to forward-mode after that I suppose

yeah I would think it forwarder mode it would be ignored.. But moving back to resolver mode it would use it, but strict is going to fail on all kinds of stuff that is for sure.. There is blog about it on cloudflare I think.

If I get a chance later today document what happens when you use when resolving, non strict and then see what it does if switch over to forwarder mode.. Does it send a shit ton of extra queries or just ignore it?

MoonKnight

@johnpoz
Hi,

I belive this is the right way to do DNS redirect?

johnpoz

@moonknight sure - but what is the 853 for... Did you have your clients using dot to talk to unbound? I don't see any point to that on your local network that is for sure.

And the redirect of dot isn't going to work.. Not with any client that actually validates who they are talking to for dot, because that is like one of the important aspects of dot or doh, validation of who your getting your dns from.

Also clients don't really do dot they do doh, so no port 853.

MoonKnight

@johnpoz
yeah you are right. I probably don't need the DoT (853) rule, since the unbound is handling DoT.

I'm blocking DoH anyways from floating rule.

Thanks, then i can remove the 853 rules from my local networks :)

johnpoz

@moonknight said in pfSense, Unbound & Netflix = No go...:

then i can remove the 853 rules from my local networks :)

Sure - while sure you could setup some client on your network to use dot to talk to unbound.. I just don't see the point/value of such a setup.. I mean it is your network, who would be hostile on your network sniffing for your dns traffic? ;)

Now if this unbound was out on the net somewhere, and you wanted to forward your local dns to it via dot then that could make sense.

But redirection of dot would be designed to fail redirection. Because the dot client should validate the cert is for the fqdn or IP the client is setup to talk to.. So for example if suppose to be talking to quad9.dns.net or whatever your unbound sure would not be able to return a cert for that that the client trusted as you being quad9.dns.net..

Now you could actually do that - but how do you know what your client might be wanting to talk to - you would have to be able to generate the correct cert on the fly, and then your client would also have to trust your CA you were signing the cert with, etc.

MoonKnight

@johnpoz said in pfSense, Unbound & Netflix = No go...:

@moonknight said in pfSense, Unbound & Netflix = No go...:

then i can remove the 853 rules from my local networks :)

Sure - while sure you could setup some client on your network to use dot to talk to unbound.. I just don't see the point/value of such a setup.. I mean it is your network, who would be hostile on your network sniffing for your dns traffic? ;)

Well, maybe my wife or kids

Now if this unbound was out on the net somewhere, and you wanted to forward your local dns to it via dot then that could make sense.

But redirection of dot would be designed to fail redirection. Because the dot client should validate the cert is for the fqdn or IP the client is setup to talk to.. So for example if suppose to be talking to quad9.dns.net or whatever your unbound sure would not be able to return a cert for that that the client trusted as you being quad9.dns.net..

Now you could actually do that - but how do you know what your client might be wanting to talk to - you would have to be able to generate the correct cert on the fly, and then your client would also have to trust your CA you were signing the cert with, etc.

I do use Quad9 DNS servers. I just like to have little bit more control of all the DNS traffics leaving my pfsense.
There is so many devices that have hardcoded DNS, you know, smart thigs, SmartTV, browsers, cell phones etc. I don't see the point why they use hardcoded DNS or DNS over HTTPS... It's my fu...... network

Thanks again for your Informations @johnpoz