@johnpoz said in Netflix and HE tunnel broker: No gua, no ula - not even a link-local, so why and the F would it ask for AAAA for?? Lazy freaking programing if you ask me. Good question. If there are no local IPv6 interfaces to talk to, I'm curious what the advantage is knowing that an AAAA exists for a host that will be contacted over A anyway. I've a possible reason in front of me, the one and only Firefix plugin I use : [image: 1773127237304-4cc14808-f093-4491-9b04-2d62263ab906-image.png] edit : the plugin is he.net powered. It shows me for every web site I visit what I'm using : A or AAAA, and it also shows what other sites are visited when the page was retrieved. [image: 1773127312570-36fdb069-8ff7-4888-a2ce-c2c8e65d6013-image.png] I can image that when this Firefox plugin is used, these AAAA requests are made. But if it isn't used ? @SteveITS said in Netflix and HE tunnel broker: Edit: also FWIW we found HE tunnels were rate limited. I mean they are free, so hard to complain, but bandwidth was about 1/3 of our IPv4 connection speed. Because the POPs have cost involved Some of them are marked as "can't add any new clients anymore" == they are 'full'. If they would throw hardware on it, tunnel.he.net would become a real, free VPN alternative **, which would need even more hardware. ** he.net uses a tunnel = IPv6 packets are encapsulated into a IPv4 packets = the GIF protocol, which is, afaik, not encrypted. Not a big deal as all traffic is TLS already anyway.

@JonathanLee said in IPv6 HE tunnel broker and Netflix quick fix idea: This fixed my issues 100% anyone else parse AAAA and A dns records like this? That issue is very old. Hit the search button - its just above : [image: 1721814205482-979fea0f-8b0a-4338-afa4-9be21a3aeefa-image.png] The issue has even a pfBlockerng solution made for it : [image: 1721814277228-99d7ab85-cb14-44e3-958e-e48648d7256f-image.png] Check the check box. Add all the host names that should not be resolved to AAAA. Done.

@gertjan Pfsense uses 127.0.0.1 as it's nameserver (it was displayed then using the pfSense dns lookup tool). I checked all settings on my win10 client and even captured the packets with wireshark: The packets were definitly sent to pfsense and were processed there (i saw the specific lookup request I made in the unbound logs). Good idea to check the resolution with the cli, thx. However in the meantime, it seems like it's working: I have noticed that I didn't upgrade my pfSense for more than 3 months. Therefore I checked for updates and saw that the version 2.6.0 was available. I installed it and as of know, the problems are gone. Don't know if this was a bug in the previous version or what, but it was definitly strange... @johnpoz @Gertjan @SteveITS Thanks for all the help :)

Your rules force all traffic out the gateway. [image: 1603285929397-rules.png] And the rules below that make no sense, because rules are evaluated top down, first rule to trigger wins, no other rules are evaluated. So your rule sending traffic out your gateway is any any.. When would there be traffic that does trigger that rules. When would there be traffic to ! private, that does not match the rule above it any any? If you want your clients to talk to pfsense IP.. Where do you allow that? You block talking to pfsense on 443, then your next rule says go out the vpn.. How does vpn have access to pfsense vlan30 interface for example?

Damn that’s encouraging