Authenticating Users with Google Cloud Identity
-
As mentioned by @stephenw10 proxing your captive portal clients is ..... let me paraphrase this :
You just bought a car, and you're somewhat manage to actually drive without touching other object and people. Great.
Now you want to join the F1 in Monaco to try to beat Verstappen because 'why not' as you think you can drive ....@leonida368 said in Authenticating Users with Google Cloud Identity:
what I don't understand is why Netgate is deprecating Squid
If squid was a process with some libraries and some basic 'ethernet' needs, it would be easy : write a GUI part that takes care of the process's settings files, and some process control code and done.
This isn't the case with squid. Squid is as big and complex as pfSense, probably more.
A proxy isn't a firewall, it isn't a router, it needs to access the actual data stream.
But, as you already know, you can not 'crack' TLS. If you could, everybody could, and security world wide would fail .... Worlds economic would fail. School will be over. Issue solved.
To really answer this question, you have to know what squid is, how it works, how how to admin it.A proxy would have to intercept a TLS communication. To do this, the device that is used by the client has to be 'modified' so it uses a proxy, not an open Internet connection.
You've probably se this option in a browser or OS setting without giving it to much though.
This situation is the contrary of a captive portal, as you do not admin the devices the visitors use : you even don't know who they are, what devices they use. When they connect.
You couldn't really create a captive portal login page where you state :Please go to the local administrator (== you) on the first floor so the administrator can modify your device so it uses our proxy from now on. En when you leave the premises, please visit me again so I undo these modifications again.
Added to that, there are many sites, every day more and more, that do not work when you (your portal clients) are using a proxy. So you have to mange a list with 'exceptions'.
There is a reasonable "plan B" : most sites that offer content that you don't want to make avaible for your portal visitors are part of lists, full with IP addresses or host names (DNSBL).
That why pfBlockerng exists. It will block the resolving of the host name p#ornhub.com and/or block the access to certain known IPs.@leonida368 said in Authenticating Users with Google Cloud Identity:
Do you think that in another school there are saw the postal police arrive.
Plan C : route all captive portal traffic out over a VPN connection. Get in VPN endpoint outside of Europe. Local (or European) law keepers won't bother you anymore ^^ because VPN == TLS and 'they' can't break it neither.
-
@leonida368 said in Authenticating Users with Google Cloud Identity:
ok I'll study this solution and then implement it. In the meantime I wanted to use the Idle timeout (Minutes) field set to 2min, then asking the teacher on duty who finishes his lesson to disable the wifi otherwise even if no one is surfing on the device, in Status / Captive Portal the Last Activity field increases always even if the PC is not used (probably for a series of background processes that require connectivity), so there must be a total lack of connectivity.
I tried with my device: I log in to the portal, then I deactivate the wifi and continuously refresh the Status / Captive Portal page. Well, an unpleasant surprise! the Last Activity field always increments, so the user on my device will never log out! How is it possible? How can I solve it?
Thank youplease can you answer this too?
-
You mean :
goes up and up without even a cable connected to the pfSense captive portal interface ? Or Wifi radio shut down ?
Look here : Diagnostics> Limiter Info
There is a limiter / scheduler for every individual connected portal user. It's these pipes that are also used to count send / received bytes.
These pipes are MAC/IP based, so another IP/MAC can not 'pollute' your pipe.
When I connect my phone : user 'x' :
and right after connection I switch to another Wifi, the Last activity will stay at "09:10:32" as my device isn't part of the portal network anymore.
I'm not sure how to solve this issue, as it isn't an issue for me.
@leonida368 said in Authenticating Users with Google Cloud Identity:
(probably for a series of background processes that require connectivity)
Oh, you didn't know that ? If you power on a PC, even before you can enter a password, it has already communicated with 'other devices', Internet included, a lot.
edit at 09h37 :
still 09:10:32 ....
-
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.
