Captive portal blocks access to internet

DominikHoffmann

After many months of chewing on this problem, the culprit turned out to be the guest network’s captive portal. This is the configuration:

Captive Portal Configuration.png

For any other information regarding the setup of the guest interface, DHCP, etc., see my thread “Two VLANs set up alike, one does not get Internet.”

What is wrong with this configuration?

stephenw10

So what doesn't work? Clients never see the login page?

Are they using the pfSense interface address for DNS?

https://docs.netgate.com/pfsense/en/latest/troubleshooting/captiveportal.html

DominikHoffmann

@stephenw10 said in Captive portal blocks access to internet:

So what doesn't work? Clients never see the login page?

They do not.

Are they using the pfSense interface address for DNS?

Clients get an IP address in the correct subnet, with the correct subnet mask and gateway address.
list itemDNS points to the gateway address, which the firewall rules explicitly permit.

stephenw10

Ok and I assume that simply disabling the captive portal on the interface allows clients to connect as expected?

What are you testing with?

DominikHoffmann

@stephenw10 said in Captive portal blocks access to internet:

Ok and I assume that simply disabling the captive portal on the interface allows clients to connect as expected?

With the captive portal disabled, clients can connect to the internet.

What are you testing with?

A MacBook Pro, an iPhone and an iPad.

Your not so subtle hint to Read The Manual led me to believe that it is the firewall rules which have a Reject rule at the top for access to the gateway address on Ports 80, 443 and 22. I just learned from that troubleshooting link that the client must have access to the gateway address on Port 80.

I have changed the rules and will test it tomorrow afternoon, when I am back on site.

Gertjan

@DominikHoffmann said in Captive portal blocks access to internet:

I just learned from that troubleshooting link that the client must have access to the gateway address on Port 80.

Source ?

Just for the fun, I've added this first reject rule on my captive portal :
The rule rejects traffic going to = destination = "192.168.2.1" is the portal (pfSEnse) interface using destination port 80 = a web server port.

and then I took my phone (iphone) and connected to the Wifi Portal SSID.
Immediately I saw the portal's login page, I could login, and live was good.

I looked again at my portal firewall rule (actually : 20 minutes later) and I saw this :

This means what you think it means : the 'port 80' as a destination or http web server port on the pfSense portals interface (for me : 192.168.2.1) is never accessed.
This is because the web server that offers the login page isn't using = listening, on port 80 .... (neither port 443 = TLS/SSL or https).

@DominikHoffmann said in Captive portal blocks access to internet:

Clients get an IP address in the correct subnet, with the correct subnet mask and gateway address.

And you forgot to confirm the most important one :
This question :

@stephenw10 said in Captive portal blocks access to internet:

Clients never see the login page?

Are they using the pfSense interface address for DNS?

On your iphone (pad, mac), you should see this :

Remember : 192.168.2.1 is my portal's interface - and the portal's gateway.
If your DNS is pointed to somewhere else, consider your portal as 'broken'.
How to 'repair' ? Easy !
Go to the DHCP server that serves your portal's network, and make sure the DNS entry says :

So : enter nothing (do nothing) the default pfSense portal IP will be used - and done.

DNS has to work - the pfSense DNS has to be used to make the portal work.
Somewhat logic, as all other destinations are blocked.
You don't need to add rules for this on the portal's GUI firewall rule page.

Btw : make sure unbound - the resolver - actually listens on the portal's interface (UDP/TCP port 53) :

Just use the default Resolver's "Network Interface" settings :

and you'll be good.

Test :

[25.07-BETA][root@pfSense.bhf.tld]/root: sockstat -4 | grep 'unbound'
unbound  unbound    96151 5   udp4   *:53                  *:*
unbound  unbound    96151 6   tcp4   *:53                  *:*
unbound  unbound    96151 8   tcp4   *:853                 *:*
unbound  unbound    96151 9   tcp4   127.0.0.1:953         *:*

The first two lines means : unbound - the resolver) listens on all (!) my interfaces, and that's what the GUI was asking it to do, on the DNS port 53. It uses TCP and UDP.
Line 3 and 4 not important here.
"All interfaces" means : also my pfSense portal's interface = 192.168.2.1.
( even the WAN interface ^^ - but don't worry, you normally have no firewall rules on your WAN interface that let traffic into pfSense so no risk )

edit : My captive portal does block this :
(this is on of my many portal's firewall rules ) :

where "This firewall (self) stands for all pfSense interface, which includes "192.168.2.1".
The self made alias "ThisFirewallPorts" stand for "21, 22, 23, 80, 443" so my portal users, by definition (for me) "non trusted users" can not use SSH (on pfSense), neither accessing the pfSense GUI access on http or https : I don't want them to try to access my pfSense GUI.

stephenw10

Maybe you have 'https login' set?