@viragomann Just following up, this works perfectly. I have had no DNS leaks since this was implemented and the VPN is working as intended. Thank you very much sir.

@gblenn I guess this thread should really continue over here...
https://forum.netgate.com/topic/178472/will-we-ever-get-upnp-to-work-behind-private-network-ip

Google STUN server seems to be working and UPnP accepts requests to open ports. But it still isn't working. In fact it stops working and some games, like MW2 (2009) can't even connect to IW servers. Turning off UPnP gives me better results using manual port forwards...

However, the only way I have been able to get Open NAT across the board is faking a public WAN IP...

It seems as if it was the USB adapter. We changed it to Realtek and it seems to be working.

@dominikhoffmann said in Why does pfSense not use BIND by default?:

Why does pfSense not use BIND by default?

Do you use bind ?
bind is ... huge.
It's a project that went the same way as OpenVPN : it was 'opensource' and everybody added what he wanted. And worse, everything is split out over dozens of configuration files.
It can forward - resolve, be authoritative, does DNSSEC, does dynamic updating, can be a master, hidden master, slave can handle interfaces that "go down" and "come back" without a reload needed.
It's the (IMHO) typical program that can not (like no way) be mastered with a GUI.
bind works well, but it's a command line only program.
You'll be needing

a text editor, know how to work with all the testing tools, have a solid knowledge of what DNS is. There is no place for 'presuming' anymore - with bind, it's the real thing.

The real reason is : no one integrates bind as a package or system and then offers it to the public for 'free' like pfSense 2.6.0. User going to ask for support.
Nobody want to 'support' bind for some one else.
If Netgate decides to use bind , they will, for sure, stop giving pfSense for free.
bind is like a Boeing 737 MAX : buying one doesn't mean you can fly one.
You'll be needing 'some' training. It will be the old fashioned 'learn' thing. The good news is : it's free !! (although, you will need some time).
There will be a big advantage at the end : you will know now what DNS is, thus basically understanding what 'Internet' is.

Again : this is my opinion.
I'm using bind for decades on my own dedicated servers for all my domain names. Played with all the tricks and options.
In the beginning, it was 'hard', 'scary' and 'frustrating'. The smallest errors meant : mail down and web sites down (my company).
And I went to school to play with system(back then) like a Prime, VAX, and messed around with a PDP11. Looking back now : things were so easy actually back then, and we didn't know shit ....

@dominikhoffmann said in Why does pfSense not use BIND by default?:

Would there be an advantage to installing the BIND package and running that?

It's possible to stop unbound and use another process that does the same job.
You can already chose between unbound, the resolver, and the forwarder (dnsmasq).
But you can only use one on a system, as the DNS process needs to bind to port '53' and you can't have tow process listing to the same port.
The same thing goes for mail processes, web servers etc.

Using bind on pfSense makes things harder.
You have to deal with bind.
And
The awkward way how it is totally incomplete "hidden" behind a GUI.

It's hard, and painfull, to admin bind like that.
I chose for nano.

edit :
https://en.wikipedia.org/wiki/Comparison_of_DNS_server_software

Netgate needed a resolver, as pfSense is a device that does not need host a domain name server, or a mail server, or a public web server.
Our ISP's, in the past, forced us to sue their DNS (ISP) servers, so a simple forwarder was great - pfSense used dnsmasq before. It was small, fast, and fitted for the job.
These times are over now.
The world has been devices in two parts :
The ones that uses DNS as it is meant to be used by what Internet actually is : they use the root servers.
And the others, who want to hand over their DNS traffic to some third party source. They could have chosen their ISP DNS (they still exist), but no .........

@rmac1813 said in DHCP reservation inside existing pool:

the range must stay in tact as it is. there are active client leases, preventing the range from changing.

Not sure where you got that idea from to be honest.. This has never been a thing..

Lets say I had a pool of .100 - 200

And clients have say .100, .101, .103, etc.. Then I change the pool to be .150-250..

Clients that try and renew their .100 address will not get a renew, they would either than do a discover and get a new IP, or when their lease actually expires they would do discover and get an IP from the new pool.

The advantage of dhcp is this, I can change up the pool, I could even change the whole network from say 192.168.1.0/24 to 192.168.2.0/24 and automagically devices would move to the new range, etc.. I could set a vip on the old 192.168.1. address so that stuff continues to work with the old range until they are all moved over, etc..

You can for sure split your pool into 2 pools, leaving IPs out of the new pools to assign specific devices to those IPs via reservations.

@jonathanlee has anyone ever used served option 252 over https?

@aiden21c Good! I still think that some good came out of this whole situation, though.

For one, even if your current setup works well, the ideal setup for your whole company network is still with VLANs The order of the firewall rules needs to be held in mind (PfSense processes firewall packet rules from top to bottom):
1c9cfaf5-771e-4d8c-959e-e798596807bd-image.png
Rule 3 catches all traffic filtered by rules 4, 5, 6. It needs to be last. Rules 5 and 6 have destination address "Any" instead of "LAN Address". A way that helps (me personally) to keep fw rules tidy is to add 4 separators, the top one named "GENERAL BLOCK" (for entire protocols, for example, no need to allow GRE, ESP, AH, OSFP... on a LAN with interconnected servers if there is no explicit need), a second separator named "INCOMING", a third separator named "LOCAL TO FW" and a fourth one named "OUTGOING". I also add separators named "PASS" and "BLOCK", with that order, under each main separator. Even if no further network changes seem necessary, it is best to avoid NAT. In the future, in order to reduce latencies or enable certain UDP services that cannot be NATed, you can check if the Cisco Router can do PPPoE passthrough for PfSense. Because PPPoE is a separate interface in PfSense, you can have both a PfSense-to-Cisco connection (OFFICE - 192.168.20.40/24, not as a Gateway) and a PPPoE adapter as a direct PfSense Gateway (because PPPoE is a Layer 2 protocol, doesn't use IPs, that is why its Point-To-Point, so it doesn't interfere with the 192.168.20.0/24 subnet at all) with a public IPv4 for PfSense. At some point, instead of having separate rules for each gateway and traffic type, you might want to implement Multi-WAN Load Balancing and Traffic Shaping to control which traffic type uses what Gateway. It is best to set static IPs for LAN through the DHCP server (without a dynamic address pool) and set your private IPs as Static Mappings. That way, you can use Host Overrides on Unbound, which would allow you to use hostnames (and no IPs) in your setups, and avoid unnecessary config nightmares in case, say, you want to put everything in Docker. You can just change the IPs in the Static Mappings of PfSense Unbound, add a BIND container to Docker (just to handle the inter-container IPs using the same hostnames) and be done with it.

@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 😂
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/