@aligator638 Perhaps you could use a static address for one OS.

@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 [image: 1677527134909-71a73a3e-e039-4073-999c-c075b35f9c6e-image.png] Thanks again for your Informations @johnpoz

@johnpoz said in DNS & NTP best practice (vlans & IoT): There is way more too it than just a longer address ;) Yes, I'm aware of that, but not necessarily hard - pending on scope, just a different way of thinking (trying to stay positive about it)

I ended up deleting the interface and building it from scratch. It was mainly the effort of redoing the static DHCP leases. I had set up a dummy interface first and copied the rules over to that one, and then back to the redone interface. That fixed everything. It must have been some kind of corruption I could not shake in any other way.

@SteveITS that's perfect, thank you! No misunderstanding - I'm just new to networking so I sometimes miss the obvious.

A minor point - presumably it's also a bug in something that the error from nslookup is "recursion not available" rather than "connection refused".

I want to come back to this to post that I have solved this problem. My issue was that I had a bridge defined in Interfaces → Bridges. It bridged all my internal interfaces, except the guest and IoT interfaces. This allowed DCHP requests to leak through from one interface to the DHCP server running on another. Doh! I had done that, because I wanted to Bonjour-browse all my Apple devices, regardless of which subnet they were in. The Asahi package now accomplishes the same thing.

My first guess is the Firestick may use the hard-coded Google DNS IP to perform lookups over port 443 using the DoH (DNS over HTTPS) protocol. If that is correct, then attempts to bypass/redirect this will be unsuccessful since DoH traffic travels over the same port as regular HTTPS web traffic. Your firewall can't distinguish which packets are DoH versus which are HTTPS. Your only hope would be if you can override the DNS choices inside the device itself, but from what you say that is not working. Here is the official announcement from Google back in 2019: https://security.googleblog.com/2019/06/google-public-dns-over-https-doh.html. Actually, I have to tip my hat to the Firestick devs. I'm sure the Netflix folks are constantly urging the device manufacturers that deploy the Netflix app to help them fight attempts by users to get around geo-blocking. Forcing the use of the public Google DNS servers using DoH is pretty effective as the anycast nature of the Google DNS infrastructure makes identifying the general location of a DNS client pretty effective. The geographically nearest Google DNS server is likely to be the one that responds to you because closer to you means lower latency. Here is a brief tutorial from Cloudfare on anycast DNS: https://www.cloudflare.com/learning/dns/what-is-anycast-dns/.

I have the same issue (well, actually I also get this on my logs) the true issue is lack of IPv6 connectivity as I get an IPv6 address assigned by my ISP (Portugal, MEO/Altice) on the LAN interface (correctly). https://forum.netgate.com/topic/177981/no-ipv6-after-upgrade-to-23-01/

@moelassus Check the system log also. Could be something like Suricata update, WAN link down/up, etc.

I have tried resetting up an interface in the console that uses DHCP like I saw some on the forums talk about, that did not fix the issue for me

I've just updated to 23.01-RELEASE (arm) and the problem I threw into this lengthy debate appears to have gone away now.

Touch wood I think I have found my issue. It was the old RealTek network card driver in pfsense 2.6. Here a my basic notes on how to update Realtek Drivers Enable BSD repo /usr/local/etc/pkg/repos/pfSense.conf and changing the first line to: FreeBSD: { enabled: yes } Next, edit /usr/local/etc/pkg/repos/FreeBSD.conf and make the same change there: FreeBSD: { enabled: yes } It must be enabled in both places to function. Install new driver You can just use pkg add directly pkg update pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/realtek-re-kmod-198.00.pkg Edit /boot/loader.conf.local to load new driver. You can append those lines with echo echo 'if_re_load="YES"' >> /boot/loader.conf.local echo 'if_re_name="/boot/modules/if_re.ko"' >> /boot/loader.conf.local

Solved. It was Snort blocking the addresses.

Well that makes sense.. greatly appreciate your response!