Captive portal & external DNS Server - not redirecting

[sazanof]

Hello everyone!

Next rules:
x.x.144.1 - PF
x.x.144.10 - Win Srv (DC, DNS, DHCP roles)

Tell me, I set up captive portal (dhcp, dns resolver) on pf and enabled
Enable HTTPS login option.

I checked, everything works, opens the authorization page and it passes successfully.

I want to use a DNS server on DC (there is also DHCP sevice on it).

Well, I turn off the PfSense DHCP server, turn on DHCP on the domain controller, in the DCHP options I specify the DNS server PF (144.1) - it works well.

I changed the address of the DNS server to another one (144.10) in the DHCP parameters (which is raised on the domain controller) + I added this IP 144.10 in the portal's captive settings in allowed ips, then redirection does not work , sites open without authorization.
The authorization page opens manually (copy-paste).

How can I force captive portal to redirect if clients use another DNS server (on my DC)? I want to use one DNS server with 144.10 on DC instead of DNS PfSense.

Please, help!

In addition, I use DNSBL to perform a Safe Search

[Gertjan]

@sazanof

What about this one : on the DHCP server you use, tell it to send your 144.10 server as the DNS server.

Now, get a device, activate the wifi - or wire, and connect to the portal ntwork. Do not loggin.
Check on that device with ipconfig /all ( or equivalent) what IP, gateway and DNS it received.

The pf portal will, of course, block this 144.10 IP, so you have to add it to the "allowed IPs" list on the portal.

Now : without using the captive portal login page - no browser nothing, ; can you do a dig or nslookup on the device connected to the portal network ?
Does it use the 114.10 device ?
Can you see the DNS request coming in on that DNS 144.10 ? And the answer ?

[sazanof]

@Gertjan hello! Yes, of course I did all of this:

On my DHCP server option 006 is 144.10

ipconfig /all - shows DNS Server 144.10 on client

nslookup google.com - also shows DNS Server 144.10 on client

nslookup google.com
Tõ¨òõ¨:  UnKnown
Address:  192.168.128.10
google.com
Addresses:  2a00:1450:4010:c0e::66
          2a00:1450:4010:c0e::8a
          2a00:1450:4010:c0e::65
          2a00:1450:4010:c0e::8b
          142.250.150.101
          142.250.150.102
          142.250.150.113
          142.250.150.138
          142.250.150.139
          142.250.150.100

OR

nslookup lipsum.com
Tõ¨òõ¨:  UnKnown
Address:  192.168.128.10

Lü :     lipsum.com
Address:  34.85.243.109

In the diagnostics section "Packet Capture", I noticed that the packets go to port 53 of address 192.168.1.1 (???). But there is no such address in my test network.

I decided to look into the properties of the DNS server on windows server and the server 192.168.1.1 was listed in the forwarding server. I fixed it to 144.1 (pf).

So now, when client open for ex. lipsum.com or someone else - the portal page opens, but there is no redirection for a very long time (about 20 seconds). If you open an IP address with some kind of web interface in the browser, then redirection to the portal page occurs instantly. Why?

@Gertjan said in Captive portal & external DNS Server - not redirecting:

The pf portal will, of course, block this 144.10 IP, so you have to add it to the "allowed IPs" list on the portal.

Yes, I read the troubleshooting guide for the portal, and the first thing I did was register IP 144.10 in the portal settings "allowed IPs".
And if I do this, there is no redirection to the portal page, all sites open without requiring authorization. Why?

And I understand that most likely this is another topic, but nevertheless, it may be related: DNSBL on pfBlockerNG not work. There is no redirect on "access denied page". =(

The SafeSearch section and the rules in DNS Resolver for safe search work, but if I open blacklisted site in the browser, it will open without redirect to DNSBL error page. It's also unclear what went wrong.

[Gertjan]

@sazanof said in Captive portal & external DNS Server - not redirecting:

So now, when client open for ex. lipsum.com or someone else - the portal page opens, but there is no redirection for a very long time (about 20 seconds). If you open an IP address with some kind of web interface in the browser, then redirection to the portal page occurs instantly. Why ?

What a device, the OS actually, should have to do: as soon as DHCP negotiation finishes, it will send a http (not https !) request to a build in URL. For Apple device, this "http://captive.apple.com/hotspot-detect.html". If this does not return (click on the link to see the answer) "Success", then the OS knows there is no direct Internet connection. So, maybe a captive portal ? It will spin up a default web browser with the same URL again.
This "any IP destination, destination port 80 => redirect to IP of the portal interface, port 8002" action, a firewall rule, will produce not "Success" but our login page.

No why this does not happens on your device : ask your device ?

For instance, most browsers want to out smart us by totally ignoring system's DNS, and use their own DOH or whatever .... and yeah, that will hit the wall ... portal.

Keep in mind also that the portal is the server (web server) and you have the client.
The portal page isn't send or pusched to you.
You see it when you (the browser or the system) asks for it.

Why your device doesn't ask for it ? Dono.

Btw : when the portal login page opens, and you validate that page with a valid login, the IP & MAC of your device are added to the OK-table in the firewall. And then, as a result if the POST (to login) of your browser, it will receive a URL redirect to the original URL it wanted to visit initially.

What I do : I redirect the user to a well known site, that shows up fast, and proofs that the user is connected :

login-to-view

From there on, they will know what to do.

[sazanof]

@Gertjan

Yes, it turns out a whole trip to the theater.
Also, it turns out that the problem is solved, the solution (in my case) is found, published. Maybe it will help someone.

Thank you very much!

As for DNSBL - perhaps I will create a new topic.