Authenticating Users with Google Cloud Identity
-
where?
-
In Diag > States. Filter by the IP address of the CP client.
-
after almost 10 minutes of inactivity:
-
Now you force us to go over all the states ....
And you didn't list them all, so, our works would be non conclusive.This means :
@stephenw10 said in Authenticating Users with Google Cloud Identity:
Filter by the IP address of the CP client.
that you could do this :
("PORTAL" is my captive portal interface)
Th IP is the IP you showed above :
so you would have found right away :
(omg : Facebook )
I call that "States"
But ... I can't explain why this clients isn't disconnected right away, respecting the Idle time out setting.
Further more, I'm not using the pfSense Users manager, but Freeradius (because : why do it simple and easy as I can do it way more complicated ? ^^ ). Anyway, pfSense user manger portal users, or freeradius, the pruning process is almost identical.The pruning of the portal is done every 60 seconds.
This is what executed : https://github.com/pfsense/pfsense/blob/74ad34bcc782e0846897af0b15a12c45a7149eb9/src/etc/inc/captiveportal.inc#L560.To make this long function short : if the time is up, the client is removed from and "connected clients database" and the related firewall rule are removed.
There is, IMHO, no such thing as "are there states still open ?".Also : again : why setting a idle time that low ?
If the device is shut down / wifi disconnected / whatever, it could, for some minutes, still 'communicate'.
But : as I just said : the device is shut down / wifi disconnected / whatever !! so there can't be any communication. So, the authorization for that unique device won't be used anymore. There can't be any traffic, the connection is idle (no more packets flow through) and the idle time counter kicks in. -
Hi @Gertjan,
15.10 I disable the wifi
idle timeout= 5min
this is the situation at 15.20
THIS AT 15.24
THIS AT 15.30
-
Look at the bottom of System > Advanced > Firewall & NAT : Closed states will stay there for 900 seconds ...
Difference with your states, and mine (my Phone used 192.168.2.6) is that as soon as I switch to another SSID, all states are passed to "Closed". Only some TCP states to port 443 and 80 (web servers) will remain.
But I don't care ^^
When Idle time is over (normally set to 120 minutes or so) the devices get disconnected. -
@Gertjan I implemented the captive portal at the client and it's fine. Unfortunately this anomaly regarding the disconnection time is affecting everything a bit
-
Good morning, in the end I thought I had solved it by enabling the logout popup on the customer's PCs and devices (there are around 50 of them and they are always the same ones for which this job was done only once). Unfortunately, however, the logout button suddenly no longer works, it remains to think for a while and then an error page appears and the session remains in the status of the Captive portal. How can I solve it?
-
@leonida368 said in Authenticating Users with Google Cloud Identity:
he logout button suddenly no longer works
A html button is nothing more as a 'link' or URL. What is this URL ?
@leonida368 said in Authenticating Users with Google Cloud Identity:
then an error page appears
Error ? That doesn't say me much. What error ?
-
Unable to reach the pfs.istitutodonvitale.edu.it site
ERR_CONNECTON_TIMED_OUT
Furthermore, the bar at the top of this window reads:
pfs.istitutodonvitale.edu.it:8003The good thing is that last week it worked!
-
This one :
@leonida368 said in Authenticating Users with Google Cloud Identity:
pfs.Istitutodonvitale.edu.it
should resolve to the IP of the pfSense captive portal interface.
Even when you are not connected to the portal, you, the device you use, is a member of the network of the captive portal network == it should have lease with a correct IP, gateway, DNS.
The DNS (should be the interface of pfSense) is the one being used to resolve pfs.Istitutodonvitale.edu.it to it's IP address.
When that done, and the browser has the IP, it actually starts to wortk : it used the IP and connects to port 8003.
That fails. Looks like the captive portal web doesn't answer.Also : only with this :
pfs.Istitutodonvitale.edu.it:8003it will fail.
There is more info needed.For reference : see what the Disconnect button does/is : look at /usr/local/captiveportal/index.php line 135
Transmitted is :
"logout_id" - this one will be hidden
but there should be a 'zone' parameter ! Without it, the URL will fail. -
@Gertjan said in Authenticating Users with Google Cloud Identity:
pfs.Istitutodonvitale.edu.it
should resolve to the IP of the pfSense captive portal interface.
Even when you are not connected to the portal, you, the device you use, is a member of the network of the captive portal network == it should have lease with a correct IP, gateway, DNS.
The DNS (should be the interface of pfSense) is the one being used to resolve pfs.Istitutodonvitale.edu.it to it's IP address.
When that done, and the browser has the IP, it actually starts to wortk : it used the IP and connects to port 8003.
That fails. Looks like the captive portal web doesn't answer.This thing certainly works, pfs acts as a DNS resolver for the devices on the network and in fact from each one I regularly ping the host pfs.Istitutodonvitale.edu.it
As for the second thing, I'll let you know, but I wonder how information can be missing from a command sent via a button on a page developed by Pfs without any modification/customization on my part and which was working until last week.
Thank you -
@leonida368 said in Authenticating Users with Google Cloud Identity:
but I wonder how information can be missing from a command sent via a button on a page developed by Pfs without any modification/customization on my part and which was working until last week
I agree with you : the button URL is build by the same 'index.php' web server page, so it should be correct.
I just tried myself to use my url liek this :
https://portal.br***********.tlf:8003so : without the needed "?zone=cpzone1" parameter.
I got a time out.
cpzone1 is my zone name.
My https server port is also 8003. -
@Gertjan but does it give you the same problem?
-
No, can't don't have this problem.
See here : https://forum.netgate.com/topic/188255/authenticating-users-with-google-cloud-identity/44?_=1718687961544 :
I don't make use of the the portal logout popup window, everybody (you and me included ^^) have "allow popups" in your browser de activated - so the issue is gone.
Popups is something of the past.
If users are somewhat educated and do what "they do at home", they will disconnect the wifi, or just leave the premises which will has the same result : no more activity on their portal session, and the soft time out (60 minutes for me) will take care of things. During this 60 minutes there were no bytes transferred, so "user still connected" or user "not connected" is the same thing.
After 60 minutes : pfSense, the portal, will destroy the session. "Don't ask to an ignorant user what you can do yourself way better ^^"Btw, the newer, RFC defined portal detection mechanism, as discussed elsewhere (the captive portal sub form !) is way better, and solves many issues. AFAIK, it's only supported by the big OSs for the moment (Apple and Microsoft)
-
G Gertjan referenced this topic on
-
Hi, I also wanted to abandon the popups, but since at my client the teachers alternate within the class in a few minutes, the Idle timeout parameter had to be set for a few minutes (2min max 5min). But if you remember (we saw it together just go back in this discussion) this thing doesn't work at all. How can I solve it one way or another?
-
@leonida368 said in Authenticating Users with Google Cloud Identity:
but since at my client the teachers alternate within the class in a few minutes
Give the teachers the 'rights' to use this button :
With one click : all users disconnected.
Check also here : Diagnostics > Limiter Info
The entries (pipes actually) still shown are the devices you've listed under :
@leonida368 said in Authenticating Users with Google Cloud Identity:
(we saw it together just go back in this discussion)
I remember. I can't reproduce that. My "Idle timeout (Minutes)" seems to work fine.
-
Hi @Gertjan, thank you for the idea, but thinking that a teacher can connect to Pfs go to Status / Captive Portal and carry out operations is truly as unfeasible as possible.
Furthermore, the user must log out only himself, not everyone together, because everyone has different end times for the lesson.
Since we have now enabled popups on the customer's devices, couldn't we try to make the logout popup work? Or find another way for the user to log out? Thank you -
@leonida368 said in Authenticating Users with Google Cloud Identity:
thank you for the idea, but thinking that a teacher can connect to Pfs go to Status / Captive Portal and carry out operations is truly as unfeasible as possible.
Can't trust teachers ? Woow. There are some strange places these days.
But I wasn't saying you had to give the teacher the admin account. It's very possible to create another pfSense user and give this 'teacher' user only limited access, like the captive portal status page, where he can log them all out, or just some.@leonida368 said in Authenticating Users with Google Cloud Identity:
Since we have now enabled popups on the customer's devices, couldn't we try to make the logout popup work?
Work or not, most hand hold devices (phones etc) don't use the default browser as the browser to login to a captive portal. For example, the browser the iPhones use, is a subnet browser of safari, not the system user default browser, so no cookies, no session keeping. And this browser doesn't allow popups.
Other devices, like ordinary windows based PCs and laptop behave fine.And even if the popup was dismissed (close), visiting again the portal login URL :
https://portal.your-domaine.tld:8003/index.php?zone=CPZONEwill not show the login page, as the user is already logged in, but the logout page, with a logout button.
@leonida368 said in Authenticating Users with Google Cloud Identity:
couldn't we try to make the logout popup work?
It isn't broken.
The fact that your Idle timout isn't working 'very well' is already strange. It's a core pf functionality, and isn't pfSense, but actually build into kernel FreeBSD.
As soon as you you what's wrong, you've solved your issue.@leonida368 said in Authenticating Users with Google Cloud Identity:
Or find another way for the user to log out?
All possible ways are already mentioned.
I haven't found any other ways in the manual (the source code).Recently, a new method was created.
Look on the forum (captive portal) for the "DHCP 114" method.
It's an upcoming RFC draft. Apple (and Microsoft and the original Samsung OS phones - clone OSes : no yet).
I have no, under the SSID properties a link to a portal "Status page". The URL I gave the the status page is the logout URL. So no need to type it the URL mentioned above.
To use this "DHCP 114" method, no need to edit any pfSense file.
There is just one PHP file to upload.
You have to use ISC DHCP, not KEA, as you have to add a DHCP option. Number 114.The value of the option, type is String, must be :
"https://portal.your-domaine.tld:8003/rfc8910.php?zone=cpzone1"
Where 'portal.your-domaine.tld' is the HTTPS server name of the portal.
8003 is the TLS port used.
'rfc8910.php' is the name of the file you've uploaded.
'cpzone1' is the name of the SSID zone.
