DNS Black Hole
-
1/ You cannot have two DNS servers listen on the same port. End of story. You have already 3 instanced of bind running, starting more of them won't exactly help until you make sure they can use port 53 which is already in use by unbound.
2/ Resolved from where? This needs to be tested from the clients, which need to point to pfSense for DNS.
3/ No idea what you mean by "loose access" -
1/ You cannot have two DNS servers listen on the same port. End of story. You have already 3 instanced of bind running, starting more of them won't exactly help until you make sure they can use port 53 which is already in use by unbound.
2/ Resolved from where? This needs to be tested from the clients, which need to point to pfSense for DNS.
3/ No idea what you mean by "loose access"3 sorry for the mistake, English is not my 1st language. I meant to say that after I disable DNS Resolver I can no longer access the web gui
2 I'm trying to resolve it from the terminal from the pfSense vm itself as it shows here (under Initial Testing): https://doc.pfsense.org/index.php/Creating_a_DNS_Black_Hole_for_Captive_Portal_Clients
1 I had too many instances of it because I was unsure if they where running or not. now i know and I only have one. -
How you cannot access the web GUI? Are you using FQDN that no longer resolves? Or you cannot access it using IP?
You cannot meaningfully test anything from pfSense itself unless you point it to 127.0.0.1 as DNS server – which is extremely stupid idea if all the DNS server does is a blackhole.
-
This is all moot anyway. No matter what you do with DNS if the client web browser is asking for an https connection and the captive portal gets in the middle, a certificate error must be displayed.
We, as IP networking professionals, should never, ever, EVER implement anything that, by design, will present certificate errors to users. Connections to https sites before captive portal is negotiated should simply hang. Don't like it? Don't use a captive portal.
