Captive portal - what am i missing

stephenw10

Are you blocking http?

You should be able to hit the CP login page directly though if you're in the CP subnet.

michmoor

@stephenw10
I re-arranged the Reject rules to the bottom for now.

From the other CP zone you see a permit any/any rule.

michmoor

@stephenw10
Update. I am able to hit the CP site from an interface not behind a captive portal - a super trusted segment.
So the question is, why isnt pfSense redirecting properly?

stephenw10

Hmm, do you have IPv6 enabled there?
https://docs.netgate.com/pfsense/en/latest/troubleshooting/captiveportal.html#captive-portal-does-not-redirect

Is it listening on port 8003 in sockstat?

stephenw10

Ah can you hit it using https?

michmoor

@stephenw10
I can hit it via HTTPS plus i see open sockets for it.
This is just very strange behavior.

stephenw10

So it seems like it's just not redirecting at all?
Do you see states to port 8003?

Do you see the redircet rule in the ruleset? Like:

# Captive Portal
rdr on bridge0 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.221.1 port 8002

Is you test client in the CP table already so it's not being redirected?

michmoor

@stephenw10
This seems to be a failure in redirection. I see states. at least.

For good measure i rebooted my pfsense (this is my home) just to make sure there isnt any issues. This also means the boot env loaded is still 23.09.01 but the config it decided to load was where my portal IP is 192.168.11.1
Thats ok because it should work on that IP as well considering i have a permit any rule

 cat /tmp/rules.debug | grep cpzone
table <cpzoneid_2_cpips> { 192.168.17.1}
ether pass on { igc2.17  } tag "cpzoneid_2_rdr"
ether anchor "cpzoneid_2_auth/*" on { igc2.17  }
ether anchor "cpzoneid_2_passthrumac/*" on { igc2.17  }
ether anchor "cpzoneid_2_allowedhosts/*" on { igc2.17  }
rdr on igc2.17 inet proto tcp from any to ! <cpzoneid_2_cpips> port 443 tagged cpzoneid_2_rdr -> 192.168.17.1 port 8003
rdr on igc2.17 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.17.1 port 8002
pass in quick on igc2.17 proto tcp from any to <cpzoneid_2_cpips> port 8003 ridentifier 13001 keep state(sloppy)
pass in quick on igc2.17 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13003 keep state(sloppy)
block in quick on igc2.17 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13005

stephenw10

If you view that in Diag > States do you see the redirect happening?

michmoor

@stephenw10
Is this accurate? portal.example.com has a DNS entry of 192.168.11.1. But it seems i see CP grabbing the internet flows to the clients gateway (192.168.141.1) on port 8003

stephenw10

Yup. And on port 80. Yet you don't see the browser detect it's behind a portal? Hmm

michmoor

@stephenw10
Thats exactly right. On paper everything should work. DNS entry is good, States on the firewall are shown. We see redirection happening at least on the output above.

Yet the "Made with Love" Netgate page does not show up. This happens on any interface i enable CP on.
I honestly don't get it and i dont know a way to do more verbose output within PF to see whats going on.

The closest i can find to this behavior in the forums is here. https://forum.netgate.com/topic/178297/help-needed-captive-portal-not-working-no-login-page/15

No resolution sadly

stephenw10

Do you see any traffic from that client that isn't redirected? That just passes the firewall directly?

In that other thread the users test client was somehow still seeing successful responses to Apples CP test.

michmoor

@stephenw10
No internet connectivity is possible.
In fact i get SSL Warning messages in my browser. The cert given is a valid ACME certificate but of course the domain doesnt match up to the CN hence the warning.

michmoor

@stephenw10
Doesnt make sense. I have a valid ACME cert but redirections arent happening.

Here is my error on my phone.

Gertjan

@michmoor said in Captive portal - what am i missing:

portal.xxx.com is a IP Alias i made - 192.168.50.211

Ok, why not ....
But 'normally', a captive portal is assigned to a NIC dedicated for the portal, setup like 192168.x.1/24 where 192.168.x.1 is the pfSense captive portal IPv4. The 192.168.x.2 to 250 is part of the DHCP portal pool (I've reserved several IPs for my AP's outside of this range : 251,252,253,254)
An gateway in the middle of a IPv4 range is ... strange - for me.

You have setup this one ? :
Services > DNS Resolver > General Settings
under Host Overrides :

From now on, when the URL https://portal.xxxxxxxx.net is used, "portal.xxxxxxxx.net" will get resolved locally, by the resolver, and points to 192.168.2.1 and from there on, on port 8003, the TLS portal web server will answer, as the https version should be listening to 8003.
The http should listen on 8002.

Never assume ^^ : fact check :

[23.09.1-RELEASE][root@pfSense.xxxxxxl.net]/root: sockstat -4L | grep '800'
root     nginx      26853 5   tcp4   *:8003                *:*
root     nginx      26551 5   tcp4   *:8003                *:*
root     nginx      26322 5   tcp4   *:8003                *:*
root     nginx      26050 5   tcp4   *:8003                *:*
root     nginx      25832 5   tcp4   *:8003                *:*
root     nginx      25596 5   tcp4   *:8003                *:*
root     nginx      25587 5   tcp4   *:8003                *:*
root     nginx      25522 5   tcp4   *:8002                *:*
root     nginx      25274 5   tcp4   *:8002                *:*
root     nginx      24968 5   tcp4   *:8002                *:*
root     nginx      24825 5   tcp4   *:8002                *:*
root     nginx      24663 5   tcp4   *:8002                *:*
root     nginx      24610 5   tcp4   *:8002                *:*
root     nginx      24381 5   tcp4   *:8002                *:*
?        ?          ?     ?   tcp4   192.168.2.1:8002      192.168.2.215:36840
?        ?          ?     ?   tcp4   192.168.2.1:8002      192.168.2.215:43290

which means that nginx, the one used for the captive portal and not the pfSense GUI, has 7 instances for http (8002) and 7 for https (8003)

@michmoor said in Captive portal - what am i missing:

"Your connection is not private"

Is that the message show below the SSID name of the wifi network ?
That's might be alarming for the portal user.
Captive portals networks are normally not WPA2 - or something else - protected, but 'open' wifi networks.

The login page will be https (TLS) protected - so no one can sniff your user and password, and as soon as you are logged in, all traffic, these days, is TLS - nobody gets his mails over non TLS connections anymore, neither will they using http (port 80) sites as these don't exists anymore.
One thing will be fowing over the Wifi in clear : the DNS traffic.

You could of course activate WPA2 (or something like that) on your Wifi network. In that case you have to publish your WPA2 SSID password and the captive portal credentials.

So, in short : the "Your connection is not private" is probably a scary thing for the "don't no nothing about anything use", and they might decide not to use the network.
On the other side, the one that knows, doesn't bother, as, as soon as the portal is open, they will kick in their client VPN so everything (the TLS traffic, DNS, whatever) gets hidden in another TLS tunnel (their VPN).
This means that I, as a pfSEnse admin, can't see any clear portal user traffic at all. This is one of the reasons I don't even bother using pfNlockerng on the portal.

Btw :
I use a network domain , and asked acme.sh to get a wild card certicate.
So it is valid, and can be sued for the pfSense GUI itself, and the captive portal.
https://pfsense.xxxxxxxx.net (on 192.168.1.1 - my LAN) and https://portal.xxxxxxxx.net (192.168.2.1- my portal network)

For testing the portal : this one :

is perfect.
When the portal work == the login page opens as soon as the user selects the portal Wifi SSID, you cn start adding rules to lock down what is possible, and not.

These are important :

The very first one is part of a NAT rule, where I redirect all DNS traffic to the local resolver.
Keep in mind that there are a lot of people out there that feel the need to direct traffic to a public resolver, bypassing the local (pfSense) resolver, and thus their device can't resolve the local portal.xxxxxx.net URL, thus the device can't find the login page.
Normally, the device uses (have to) DHCP so it will obtain a gateway, network and DNS, which should be the IP of the portal NIC of pfSense. If the device uses some other DNS, this will braek the portal access, as it won't be able to resolve portal.xxxxxx.net (that points to an RFC1918 - so public resolver won't resolve that request).

Unbound, the resolver, should listen on this IP. Btw : is unbound actually listening on your "192.168.50.211" ??

There are more portal 'pf' rules : these two are also very important :

# Captive Portal
rdr on igc1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 443 tagged cpzoneid_2_rdr -> 192.168.2.1 port 8003
rdr on igc1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.2.1 port 8002

As you can see, the http (TCP port 80) [which does not go the the portal IP] will get redirected to port 8002, the non TLS nginx captive portal.
This nginx port 8002 (non TLS) will then - if you use the https login page, redirect the 8002 traffic to the 8003 (TLS) nginx server : and there you have your https portal login page.
Remember : a non TLS (https) can get redirect to TLS (https), not the other way around.

When a device activates a network, for example it connects to a SSID, your portal and then it fires up a DHCP client to get a lease.
Right after that, the device will execute a "portal detection" test - this is build in all modern OSes these
days.
You can see the 'polling' of the device on the Status > System Logs > System > GUI Service page.

Example : Just found a new one :

The test URL is http://mobilesecuritycore-detection.norton.com/msc-detections/all/network/success.html - click to see what the test should return ^^

If the return text was not "Success" then the device concludes that a portal might be present.
It will open a browser, pointing to the same URL.
What will show up : the portal login page.

So, there will be a http (not https !!) request to a known exiting URL - that is the test that every device makes.

stephenw10

@michmoor said in Captive portal - what am i missing:

No internet connectivity is possible.

But do you see any connections from that client passing the firewall? And states that are not redirected?

The only way the client should try to connect without detecting the CP is if the test connection is being passed.
Do you have anything in the bypass captive portal list?

michmoor

@stephenw10
I see NO connections passing through the firewall. Once i attempt to connect to the network with CP enabled, i see the states redirected to the gateway and thats it. Clients do not get the portal sign in page at all.

Below you see the redirects to 8002/8003. NGINX (pfSense process) isnt serving the page. Normally on an iphone the portal page loads up and i enter credentials. Works without issues. Im half way tempted to load up 22.05 in my boot environment and test this out because i did have this working on multiple interfaces without issues. Then again this could be my fault entirely. I just dont see how it is right now.

michmoor

@stephenw10
https://docs.netgate.com/pfsense/en/latest/troubleshooting/captiveportal.html#captive-portal-does-not-redirect

I have triple checked this piece of documentation. DNS does work. I remove CP off the interface and normal web browsing can function again. When i re-enable CP on the interface thats when things stop.
I even have a DNS Redirect rule just in case....

stephenw10

I assume if you try to visit an http site you get correctly redirected to the portal in the traditional manner?

I just can't see how the portal detection in the browser/OS wouldn't be triggered unless the test site was being passed.