Captive portal only works on mobile or Chromebook not yet logged in

[MathiasMa]

Hello

I have set-up a Captive Portal and checked the troubleshooting page.
I have set-up these rules, I think the first one isn't really necesary. But it won't hurt either.

The point is, it works: On my Android device, the CP is shown and I can connect. When I do the same on my Chromebook (when on the login page), it also works.

But when I try it on a Windows device, or on the Chromebook when logged it, the browser is launched and the corresponding test url tries to load (e.g. on Chromebook: http://connectivitycheck.gstatic.com/generate_204) but never loads. Odd, because I have a rule that should pass this traffic, and I guess the same page is loaded in the background on the Android device and the Chromebook pre login?

Thanks for any guidance or tips on how to solve this!

[MathiasMa]

Edit: I noticed I forgot to allow TCP traffic in the DNS rule, so I changed that, but it doesn't make a difference.
Edit2: Just for the sake of it, I added an allow all rule, but no difference. The connectiviycheck.gstatic.com/generate_204 page is not loading, so no redirect if performed.

[Gertjan]

@MathiasMa

What if : Windows devices do also a ping == protocol "ICMP" to check for network connectivity ?
You don't allow 'ping' ^^

Rule 1 : not needed. And keep in mind that a UDP web server (port) '80' hasn't been invented yet.

When you start with the captive portal, use this 'one and only' rule to test :

Afterwards, if you want, you can add more restrictive rules. As soon as stuff start to break, you'll know where the issue is ^^

On the windows device, as soon as you are connected == received a DHCP lease, you should be able to do a

nslookup gstatic.com

or a

nslookup connectivitycheck.gstatic.com

This should return a :

C:\Users\Gauche>nslookup connectivitycheck.gstatic.com
........
Addresses:  2a00:1450:4007:81a::2003
          142.250.201.163

As soon as the PC gets this IP resolved from the 'test' URL, it will connect to it, using port TCP 80.
This (a typical http browser) request and will get intercepted by the portal firewall, and redirected to the web server running on pfSense that shows a "login page".

Most important rule : pfSense should do the DNS resolving for the portal clients.
This is normally always the case, as clients have to use the mandatory DHCP to get access to the portal network.