Authenticating Users with Google Cloud Identity
-
hi @Gertjan, basically what I mean is that if for example I set the Idle timeout (Minutes) field to 1min, even if I disable wifi on the device, the user session disconnects at least after 10min if not more. I think this is a problem.
-
I've set my "Idle timeout (Minutes)" to 1 minute.
<166>1 2024-05-28T12:42:34.743231+02:00 pfSense.brit-hotel-fumel.net logportalauth 70503 - - Zone: cpzone1 - ACCEPT: x, e0:92:5c:d9:6c:fe, 192.168.2.6 <166>1 2024-05-28T12:44:21.624258+02:00 pfSense.brit-hotel-fumel.net logportalauth 88950 - - Zone: cpzone1 - IDLE TIMEOUT: x, e0:92:5c:d9:6c:fe, 192.168.2.612:44:21 - 12:42:34 = 107 seconds or 1 minutes 47 seconds.
The portal prune task executes every 60 seconds :
[24.03-RELEASE][root@pfSense.bhf.tld]/var/log: ps ax | grep 'prune' 5641 - Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone1.pid /etc/rc.prunecaptiveportal cpzone1so 1:47 could be right.
"Idle timeout (Minutes)" set to "1 minute" is, IMHO, not a useful setting. Something like 60 minutes, or more, seems far more seasonable to me.
-
Hi @Gertjan, with my device I authenticated on the PFS captive portal (Idle timeout=5min) at 1.41 pm and on it I disabled the wifi at 1.43 pm.
As you can see the user's session was dropped at 2.06pm. A good 23 minutes have passed instead of 5.
How do you explain it? Soon I reported the status, settings and logs.
Thanks
-
Check the states. The client could have opened something outbound that was still seeing active replies.
-
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?
