Authenticating Users with Google Cloud Identity
-
Hi @Gertjan
well I'm sure you're right but keep in mind that when I tried to install stunnel from 2.60 the system told me that it was necessary to upgrade Pfsense and in fact I updated it to 2.70 and in fact after doing this upgrade of PfSense I was It is possible to install Stunnel, but with all the problems you see.
You won't believe it, but before reading your post I went to System / Update again and found 2.7.2 and I said to myself: "But why not try?".Well I did that upgrade and...... STunnel WORKS!!!
-
Great
Now you know what 'golden' is in that rule. -
@Gertjan sure sure I understood hahaha. Thanks and thanks also to
@stephenw10. Now I move forward with the implementation of the captive portal. Tomorrow I will be at the customer's site so... let's hope for the best!
If I have other problems, can I bother you again? Thank you -
Nice! Yup it pulled in the STunnel pkg from 2.7.2 and that won't run in 2.7.0.
Got there in the end.
-
So, here I am again bothering you.
I solved the Google authentication problem with Stunnel and it finally works. At this point I moved on to configuring the captive portal, as the director of the client school wants a captive portal to appear on all the school's PCs when they try to go out on the Internet. I carried out the following steps:-
I set the pf dhcp so that the clients have the pfsense IP as their primary DNS
-
I have checked the filtering rules so that outgoing DNS traffic is not blocked
-
In System / General setup I have set the external DNS to which Pfsense will forward queries via the DNS resolver
-
I created a CA and a related certificate
-
I have enabled and configured the DNS resolver
Enable SSL/TLS Service: I have NOT enabled "Respond to incoming SSL/TLS queries from local clients"
I left all fields as they are and made sure that:
SSL/TLS Certificate: I have given the certificate created above
System Domain Local Zone Type: Transparent
DNS Query Forwarding I checked "Enable Forwarding Mode"
host overraides: I entered the pfsense server data -
I have enabled and configured the captive portal
services /Captive portal/ add / enter Zone name / Save & Continue / tick Enable Captive Portal
in Interfaces I chose the interface on which the captive portal should appear
I set the following 2 timeouts
Idle timeout (Minutes)
Hard timeout (Minutes)
I checked "Enable logout popup window"
In the Authentication section for the Authentication Method field I chose "Use an Authentication backend" and for Authentication Server I chose "ServerGogoel Workspace" configured previously
I checked "Enable HTTPS login" so that the captive portal appears even with https traffic
in HTTPS server name I gave "pfsense server name". "domain" as inserted in the common name (CN) of the CA and the certificate created
SSL/TLS Certificate: I gave the created certificate
The problem is that when the client tries to connect to the Internet the message "Connect to the Wi-Fi network" initially appears but then when I click on Connect the error appears:
pfsense.localdomain has redirected you too many times
ERR_TOO_MANY_REDIRECTSHow can I solve it? Thank you
-
-
@leonida368 said in Authenticating Users with Google Cloud Identity:
host overraides: I entered the pfsense server data
What did you enter there? Why did you add that?
I would start out by just enabling the default captive portal values and make sure that works as expected.
Then add the external auth, check that works.
Then add further settings and check those.
-
@stephenw10 I deleted the pfsense data from Host Overrides and the DNS resolver still works anyway.
I created a captive portal giving the default values and it works, but it only works on http which is absolutely not needed -
It redirects to an http login?
-
yes
-
And just enabling https login causes an error?
-
@stephenw10 said in Authenticating Users with Google Cloud Identity:
And just enabling https login causes an error?
Reply
yes
-
Same redirect error?
Anything logged?
-
@leonida368 said in Authenticating Users with Google Cloud Identity:
Enable SSL/TLS Service: I have NOT enabled "Respond to incoming SSL/TLS queries from local clients"
That option is only usable if you control every LAN client, so you can set up each client to use DNS over TLS on port 853. That wasn't even possible with Windows devices nort so long ago.
This option is not usable for a captive portal, where you do not control the connecting devices.@leonida368 said in Authenticating Users with Google Cloud Identity:
I checked "Enable logout popup window"
You don't need it.
Must users, yourself included, have already disabled those nasty popup windows ages ago.
So that windows never (or very rarely) pops up.@leonida368 said in Authenticating Users with Google Cloud Identity:
I checked "Enable HTTPS login" so that the captive portal appears even with https traffic
in HTTPS server name I gave "pfsense server name". "domain" as inserted in the common name (CN) of the CA and the certificate created
SSL/TLS Certificate: I gave the created certificate"https" login is mandatory if you want a portal that isn't flagged as suspicious (or worse) on every client connecting to the portal. Classic "http" is pretty much gone these days.
To have "every" browser trust your certificate, you can't make your own. Nobody trusts you ^^
You to get a certificate from a known trusted Certificate Authority.
That's why where the pfSense package ACME comes in handy : it will 'arrange' a trusted certificate for you. The certificate will be free of charge, will get renewed every xx days, with you doing nothing.
And here it comes : Before Lets-encrypt creates and signs a certificate for you, you have to proof that you own (actually : rent) the domain name.
Maybe your school already has its own domain name ?
And maybe the registrar used support one of the "DNS API" methods that acme offers ?
If so : declare (example) this domain : "portal.your-school-domain-name.tld" and set up acme to it will ask a cert for this sub domain. Use this domain like this :
Or maybe they already have a wildcard certificate for the your-school-domain-name.tld domain ? You can use that also, as that will work for pfsense.your-school-domain-name.tld and portal.your-school-domain-name.tld and printer.your-school-domain-name.tld etc etc .
"Nico" is the name of the acme account where I've set up the cert request for "portal.your-school-domain-name.tld".
Place also a domain override under the Resolver, at the bottom :
and now you have done everything that is needed to create a https web server, as that is what the captive portal login page server actually is (should be).
Btw : you can also buy a cert from a cert signing company, as we did all before. Upload the cert into the pfSense cert manager, and select it on the captive portal's settings page.
Now the clients will connect to the login page web server with a valid, trusted certificate, and everything will work without any issues.
Btw : this step isn't much different as building your own web server.
In the past, you started a web server, threw in a bunch of html files, later on PHP and whatever, but these days you have to get your hands on a valid certificate, and place it in the web serer config files. Without a cert : no https .....
Not a big issue, as a web server on the Internet means : you have a domain name already. So arranging a cert is just another admin job.
A captive portal isn't a public web server, but you still need to own a domain name or sub domain name. -
This post is deleted! -
I can't reply, I always go to spam
-
Try again, I upvoted 6 of your posts, so you're above 5, so the anti spam won't bother you less.
-
I meant: so I have to generate a certificate from letsencrypt.org using an ACME client. Is the certbot client ok?
This school's domain was generated using Google Workspace. To prove that you own the domain name, is it sufficient to have the administrator credentials of that school's Google Workspace console? -
@leonida368 said in Authenticating Users with Google Cloud Identity:
Is the certbot client ok?
Noop, as that's to hard.
There is no 'certbot' package for pfSense.@leonida368 said in Authenticating Users with Google Cloud Identity:
To prove that you own the domain name
Like certbot, ascme, or actually, none of the two, its Letencrypt that check if you own a domain.
-
@Gertjan said in Authenticating Users with Google Cloud Identity:
Noop, as that's to hard.
There is no 'certbot' package for pfSense.If the certbot client is too difficult, what do you recommend?
-
I see that among the PfSense packages there is Acme Certificates. Should I use this?
