Authenticating Users with Google Cloud Identity
-
Does it start correctly if you don't set a cert at all?
Otherwise check if you have something else listening on port 1636 already for some reason.
-
hi, the Certificate field cannot remain empty
-
Up until last year I used Packetfence to do this. Even if it is a different product (it is a nac not a firewall) for better or worse the authentication with Google Workspace worked, but this involved the simultaneous presence of Packetfence for authentication and PFSense as a firewall and furthermore Packetfence registers a device with the user who authenticates and then the captive portal no longer appears on that device. Instead I would have liked to do everything with PFsense but I find it hard....
-
@leonida368 said in Authenticating Users with Google Cloud Identity:
the Certificate field cannot remain empty
It throws an error when you try?
You have to have a client cert for Google Auth to accept it but Stunnel should start OK without a cert defined there. If it does then we know the problem is with the certificate.
-
Like:
-
it's a box where you have to choose something but if I choose Default I have a view like yours i.e. the Certificate field is empty. However, even in this way the service does not start
-
Ok so not a certificate issue.
Do you have other STunnel entries that might have misconfig?
Do you have some other service already listening on port 1636?
What happens if you just try to run the command at the CLI:
[24.03-RELEASE][admin@4200.stevew.lan]/root: stunnel [ ] Initializing inetd mode configuration [ ] Clients allowed=54725 [.] stunnel 5.71 on amd64-portbld-freebsd15.0 platform [.] Compiled/running with OpenSSL 3.0.13 24 Oct 2023 [.] Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,OCSP,PSK,SNI [ ] errno: (* __error()) [ ] Initializing inetd mode configuration [.] Reading configuration from file /usr/local/etc/stunnel/stunnel.conf [.] UTF-8 byte order mark not detected [ ] Compression disabled [ ] No PRNG seeding was required [ ] Initializing service [Google Auth Test] [ ] Initializing context [Google Auth Test] [ ] stunnel default security level set: 2 [ ] Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK [ ] TLSv1.3 ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 [ ] TLS options: 0x2100000 (+0x0, -0x0) [ ] Session resumption enabled [ ] Loading certificate from file: /usr/local/etc/stunnel/stunnel.pem [ ] Certificate loaded from file: /usr/local/etc/stunnel/stunnel.pem [ ] Loading private key from file: /usr/local/etc/stunnel/stunnel.pem [ ] Private key loaded from file: /usr/local/etc/stunnel/stunnel.pem [ ] Private key check succeeded [ ] No trusted certificates found [:] Service [Google Auth Test] needs authentication to prevent MITM attacks [ ] OCSP: Client OCSP stapling enabled [ ] DH initialization skipped: client section [ ] ECDH initialization [ ] ECDH initialized with curves X25519:P-256:X448:P-521:P-384 [.] Configuration successful [ ] Deallocating deployed section defaults [ ] Cleaning up context [stunnel] [ ] Binding service [Google Auth Test] [ ] Listening file descriptor created (FD=9) [ ] Setting accept socket options (FD=9) [ ] Option SO_REUSEADDR set on accept socket [.] Binding service [Google Auth Test] to 127.0.0.1:1636: Address already in use (48) [!] Binding service [Google Auth Test] failed [ ] Unbinding service [Google Auth Test] [ ] Service [Google Auth Test] closed [ ] Deallocating deployed section defaults [ ] Cleaning up context [stunnel] [ ] Deallocating section [Google Auth Test] [ ] Cleaning up context [Google Auth Test] [ ] Initializing inetd mode configuration
There you see it fails to start for me because it's already running.
-
Hi @stephenw10
I changed the Listen on Port field from 1636 to 1696 but nothing changed. I ran the stunnel command from the shell and the following error came out:
-
You probably broke the golden rule.
You've installed package(s) that depend on other packages like OpenSSL.
When installing "stunnel", the latest and greatest was put in place. But .... your pfSense 'core' (kernel, system libraries) in not recent or up to date : now you've entered "DDL" or library conflict hell.The golden rules says : before installing and or updating packages, first upgrade pfSense.
The current version is 2.7.2. -
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