Segregating DNS for local-only and Internet clients
-
I have some clients that I want to block from Internet access. I use only unmanaged switches, and thus cannot leverage VLANs.
It is pretty clear how to block IP access from certain clients using firewall rules.
However, clients are all querying the same pfSense unbound DNS server, which is currently configured with all the local clients reservation hostnames, but also to resolve and cache public Internet DNS names.
This means that even clients that I block from Internet access using firewall rules can still resolve public DNS names. It leads to unpredictable situations, as vendors don't test their devices this way - even when they want to support private networks, if they are able to resolve public hostnames, but not connect to them, it creates connection timeouts and headaches; whereas not resolving the public DNS names at all is handled more gracefully.
So, my question is, how can I stop select clients from being able to resolve DNS names ? I still want all clients to be able to resolve the local reservation hostnames.
It seems to me that this would require 2 separate DNS server instances, and point some clients at one or the other. I don't see any way in the GUI to instantiate two Unbound. It might be possible to instantiate one DNS forwarder (dnsmasq, presumably) and one Unbound.
Has anyone done this, and if so, how ? I would like to try to stick to a method that is saved in the standard pfSense+ XML file, rather than some manual changes through command-line, which would not be easily restorable.
-
@madbrain They would both listen in port 53 which is impossible.
Unbound has a “view” feature which might help. I’ve used it to block specific domains but maybe all .com or something might work.
-
@madbrain You are correct, it will require 2 DNS servers. pfSense can only be 1 server, there is no facility to have it behave one way on interface 1 and and 2nd way on interface 2. PiHole might be a good solution for the 2nd DNS server.
-
@madbrain how many local resources do you want them to be able to resolve? if its not 1000s or 100s you could do it with views. Where you have a view that lists what they can resolve via local entries, and this view has no ability to resolve anything else.
If I get some time tmrw I will do a walk through.. But it be a manual process.
For sure it would be much easier to just run a something like pihole.. Might be able to do it where bind or dnsmasq listens on a vip? Since you say you can not run vlans. Let me look into that.
edit:
Ok quick hack for you.. I haven't tested extensively, seems to do what you want.. I tested it with my local dhcp reservations which I use for all my local resources.
So first thing is make sure unbound is not listening on all, set the specific interface - guessing just lan for your network without any vlans.
Create an alias on this network. So for example my pfsense lan address is 192.168.9.253/24, I created an alias of 192.168.9.252/24
Then setup dnsmasq (forwarder) to only bind to this vip.
You prob want to set a local-ttl, or will use 1 second.
Now you see I can resolve local stuff when I query this IP, but external stuff all comes back refused
Not sure if you use register dhcp, that may work - and you could just create local host overrides that should work.
Again have not tested all kinds of scenarios here - just quick and dirty hack to do what you want.
Now if I query my normal unbound (resolver) listening on .253 - I can resolve external
-
@SteveITS it would be possible if assigning multiple LAN IP addresses to pfSense, and binding selectively. Then, clients could be pointed to different DNS IPs in pfSense.
-
@madbrain ahaha - see my edit ;)
-
@johnpoz still having dinner. Will reread your reply. But I currently have 355 local hosts, using a /22 .
-
@madbrain you could try it with dhcp then if they register their names.. I don't currently do that, and all my stuff gets a reservation. I could fire a client to test that. But this seems to do what your asking for, resolve local stuff, not external
-
@madbrain possibly a variation of https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html with a NAT source.
-
@SteveITS there is not need to do any sort of nat anything or redirect of dns, if you point your clients at the vip IP. This could be handed out via dhcp reservations. But sure a redirect of dns to your vip for the clients you want to prevent from doing external dns could work sure.
-
@madbrain FWIW, old-school ISC BIND can do this sort of thing trivially using views. I am not familiar with unbound so I'm not sure if its view feature is equivalent, but that's what I'd look at first.
You should also look into disabling recursion in the views for the restricted clients, to be sure that the server will not return anything except locally-defined names.
-
@SteveITS Blocking all .com wouldn't be good enough. The goal is block all hostname resolution, except the hosts in the local domain, currently .localdomain, but only for a subset of local-only clients. All clients would still need to be able to resolve *.localdomain . The .localdomain hosts come from DHCP reservations.
-
@AndyRH I don't think PiHole, or any DNS server not running on the pfSense router box, would be viable. In case of power outage, the 2 DNS servers will not come up simultaneously at the right time. The system running the secondary DNS would need to first get a DHCP reservation and IP from pfSense, before it can start listening for DNS requests. But all clients are going to make their DHCP requests at roughly the same time. That means that one subset of clients would have DNS access immediately after the DHCP response. Some devices might misbehave in this situation. My preference is hence for the 2 DNS servers to run on the same pfSense box.
-
@madbrain said in Segregating DNS for local-only and Internet clients:
The system running the secondary DNS would need to first get a DHCP reservation and IP from pfSense, before it can start listening for DNS requests.
That statement makes no sense to me. Whatever systems you have offering DNS service must have fixed, manually assigned IP addresses, else the clients cannot find them.
I'm a little skeptical of your concern about both DNS services coming up at the same time --- isn't any one client going to be told to contact only one of them? But in any case, if you can implement it as two views served by one DNS server, that will happen for free.
-
@johnpoz Thank you very much for all this. Sorry I could only get to this today, I have been dealing with health issues.
I tried to follow your process. You said to create an alias. I went to Firewall / Aliases and tried to create one, but it did not show up as an interface for the DNS service. I think you actually meant a virtual IP. I was able to create one through Firewall / Virtual IPs.
I then made sure Unbound, the DNS resolver, only binds to the LAN and VPN interfaces, not the local DNS IP.
Then, I tried to enable the DNS forwarder. The configuration screen looks different from yours. Perhaps we are running a different version of pfSense. I'm using pfSense+ 25.07 .
I tried to bind it only to the specific virtual IP, and use strict binding. Unfortunately, pfSense+ isn't letting me enable it. It claims port 53 conflicts with the DNS resolver, Unbound. They should be listening on distinct IPs, so this conflict should not occur.
I believe it may be possible to get around this with firewall rules, by making the DNS forwarder listen on another port, say, 5353, and forwarding port localIP:53 to localIP:5353 for a subset of clients. However, it appears you did not run into the GUI warning, so I'm curious what you did differently from me.
I'm indeed using DHCP, specifically, KEA DHCP server. Here is the main config :
I then have DHCP reservations, all with hostnames, from 192.168.100.2 through 192.168.101.120 .
A sample DHCP reservation is here :
It currently has the DNS server field blank, which means it uses the default DNS of 192.168.100.1 .
The idea would be to change the DNS server field for some clients to the new local DNS VIP , 192.168.103.254 . And the IP reservations for these clients would also be changed to a dedicated range for local-only clients, with additional firewall rules to prevent public Internet IP routing.
-
@tgl I agree that the IP of the host running the secondary DNS cannot change. That can either be configured manually on that host, or through a DHCP reservation in pfSense for that host. The manual static method would be faster. However, the timing issue will remain. The secondary DNS host still might boot up later than pfSense, before the other local-only clients, which are pointing to the secondary DNS. These clients would temporarily be unable to resolve anything, until the secondary DNS host is fully up. IOT clients such as smart bulbs boot extremely fast, in a matter of seconds, so this is not a theoretical concern. The two DNS servers need to be up and ready by the time the pfSense DHCP server is up.
-
@madbrain said in Segregating DNS for local-only and Internet clients:
@tgl I agree that the IP of the host running the secondary DNS cannot change. That can either be configured manually on that host, or through a DHCP reservation in pfSense for that host. The manual static method would be faster.
I think you failed to grasp my point. It's not about speed, it's about reliability. Machines offering core network services should avoid depending on other machines to offer those services. Otherwise, when anything goes wrong you have cascading failures and/or a nasty debugging problem to find the root cause. IMO, a DNS server that does not have its IP address statically assigned on-device is verging on admin malpractice.
I'd also worry a bit about the single-point-of-failure hazard inherent in putting all these services on your router. In my own small home network I have two DNS servers, neither of which is the DHCP server, and all of the critical network infrastructure has manually assigned IP addresses. So I can reboot any one of those three machines and not risk losing connectivity.
-
@tgl Most of the network already falls apart while pfSense reboots. It is already a single point of failure. Many devices monitor the gateway IP, and any number of bad things happen if pfSense goes away for too long. For example, Unifi mesh APs going offline, causing hundreds of Wifi clients to disconnect or roam tot he wired APs. If I wanted to increase reliability, I would look into the possibility of failover for pfSense itself, to prevent this situation. I'm not sure if that's possible or how - I have not looked into it, and this is a whole different can of worms. For now, I accept this single pfSense point of failure.
IMO, offloading a secondary DNS server to an external system would be an additional point of failure, and decrease reliability in my network.
I use KEA DHCP server with Unbound on pfSense, so that the hosts for the 355 DHCP reservations are automatically registered in the DNS. It would be additional work to export them to an external DNS. I have not considered the possibility of running both DHCP and DNS servers externally. This complicates the network, IMO. If I make major changes to the pfSense configuration, for example, the LAN subnet, I would have to make corresponding changes on the secondary host. This is also not theoretical - I have changed the subnet before from /24 to /22, and plan to do it again and go to /20.
I'm looking for something I can easily backup & restore atomically with a pfSense backup, without external dependencies. This implies that my DNS server must run on pfSense, either through using a view, or two separate DNS server instances (Resolver + Forwarder).
-
@madbrain Certainly, if your router is down then a lot of stuff is going to be unhappy, since internet connectivity is so fundamental to modern tech. The question I'm trying to get you to think about is "if things go pear-shaped, am I going to be able to log into the pfSense box to diagnose/repair it?".
I don't know the details of your setup, but in my case I'd be wanting if possible to connect to pfSense from my laptop, which implies the laptop, the UniFi AP it connects to, and the intervening switch(es) have to stay up, and ideally my local DNS service should still work so that I don't have to recall the router's IP address. Since the pfSense box is my DHCP server, that implies that the laptop, AP, and switches all need statically-assigned IP addresses, which they have, as do the not-on-the-pfSense-box DNS servers. I don't do meshed wifi, either. So I'm pretty confident that if the pfSense box stopped offering service, I'd still be able to connect to it if it's alive at all. While I haven't had to put that to the test in total-failure situations, I have had to debug broken-DHCP situations, and I was darn glad that I'd taken these precautions.
-
@madbrain said in Segregating DNS for local-only and Internet clients:
The system running the secondary DNS would need to first get a DHCP reservation and IP from pfSense, before it can start listening for DNS requests.
My PiHole running on a Pi3b boots much faster than my pfSense.
My PiHoles have static addresses, they are not waiting on anything.
Clients in your case would point to 1 DNS, if it is not up then no response. They will try again.
Why would you restart all computers at the same time after an outage? Network stuff then client stuff.
If DHCP is not up when a computer starts, it will use the last address given provided the lease has not expired. It will also try again.I was aiming for simple. Aim for complex if that is your way.
