@bendida I have the same problem after upgrading to pfSense 2.7

@guntery said in CP using IP address for radius session not username:

nothing to do with radius or auth.

I agree.

@guntery said in CP using IP address for radius session not username:

it disregards mac and username

It looks like that portal_allow() returns with the $sessonid. Portal firewall rules are not modified, so, while the IP is the same, the MAC will be different. No login page is presented, and no "Internet access" : that's your issue ?

That is, I could not create a situation with my setup where another device (another MAC) was using an IP that had already a session.
Typically, for my usage, Idle timeout (Minutes) is set to 360 and Hard timeout (Minutes) is set to 720 or 12 hours. The latter will remove sessions.
My DHCP leases on my captive portal are set to 86400 sec or 24 hours.

@serginho said in CP using IP address for radius session not username:

for the developer to recognize and correct this error

Feel free to enumerate.
And as you walked through the code, you should be able to add lots of details.

@Chooks said in Captive Portal not redirected after successful login:

I'm using the latest version.

23.05.1 ?

This :

3c06064e-e679-421e-b8ef-8ae0286e7c88-image.png

looks like the OS - or program - knows or suspects that the device hasn't a direct Internet connection.
It's part of the portal detection.
Normally, the GET (www.example.tld)/connecttest.txt should return a 'page' like this one that shows the word (for example) "Success.".
If it doesn't, because another page came back : the pfsene captive portal login page, the OS should pop up a message, notification, or even a browser directly in front of the user.
If it doesn't do that ... well ...

After successful portal login :

d7c6be7a-64af-4e2d-88fd-3c4917acbd46-image.png

192.168.2.6 - - [07/Jul/2023:08:19:56 +0200] "POST /index.php?zone=cpzone1 HTTP/2.0" 302 0 "https://portal.brit-hotel-fumel.net:8003/index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html" "Mozilla/5.0 (iPhone; CPU iPhone OS 16_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148"

302 = Redirect.
You can also see the URL parameter "?zonecpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html" see the "http://captive.apple.com/hotspot-detect.html" :

b8693d06-cfb9-4078-b69a-94e313943dd0-image.png

Because I've set :

9582e267-23f6-4b26-a378-ec51189fede9-image.png

I was take to https://www.google.com/
If my "After authentication Redirection URL" was empty, I would see the

fd83eba8-4ed9-4cab-ab1f-c7778b48ea29-image.png

and that's a bit stupid.
But correct my iPhone wanted to go to that page (that page because it uses it to detect the prence of a captive portal). When the captive portal authentification was done, it will show the page. My phone is now happy : the device has a working "Internet connection".

Look at /usr/local/captiveportal/index.php - that is the page PHP that shows the login page. But it does more then that. See /etc/inc/captiveportal.inc tells the whole (rather complex) story.

@susobaco
I answered you in your post. Please create a bug yourself - maybe you can better convey to the developers with your words that it is a regression of this current firmware.
Then note the device key under "AutoConfigBackup" and reinstall to 2.6.0 and restore a config from 2.6.0 with the device key. Then we'll be right back.
Let's hope that the developers will adjust the firmware and get the captive portal up and running again.

@dochy

Ah.
Your using an ancient version.

5ae2a4b1-a046-4732-8a2e-edc2aded1058-image.png

That's ok of course, but I can't recall what I did 'yesterday'. And before yesterday, I was using 23.05, and before that 23.01 and before that ... 22.0x and before that 2.6.0.
2.7.0 isn't ok for you ?

I suggest you use the use the "forum search", as I'm pretty sure some one has writing about mysql in the past.

Double check the PHP version pfSense 2.6.0 uses.

@mhmd said in How can I allow the subdomains of one hostname in Captive Portal?:

My exact problem is that the domain IP is different from the subdomains it has.

And what is these 2 fqdn exactly?

https://docs.netgate.com/pfsense/en/latest/captiveportal/allowed-hostnames.html#allowed-hostnames

A daemon periodically resolves the hostnames to IP address(es) and allows them through the portal without authentication in this zone.

@LadiesMan217

https://docs.netgate.com/pfsense/en/latest/captiveportal/allowed-hostnames.html#allowed-hostnames

@Gertjan
It is exactly like that
When I first started CP, we had a virtual machine that everyone called Remote Desktop and used it for Internet-related matters, and when one of the users authenticated, the rest of the users also authenticated in CP without needing to authenticate. CP was passing and it was very funny.

Thank you very much for this detailed answer. I appreciated very much your explanation of the redirecting technique.

@Gertjan said in Captive Portal redirect does not work for a few clients:

First things first : you have this package installed, and activated the patches :

05481e7a-0815-410a-93dd-d28cd13e58ed-image.png

Btw : you might want to use 2.7.0-beta, is close to release.

This package indeed needs an update. Will do so this evening.

We won't use a beta version in this production environment. But we have a Dev cluster and will check this on that.

The solution is always the same : Delete the wifi profile on the phone - it doesn't contain any user settings as a password (portal networks don't use password - they use a TLS connection to authentify against the portal web server, and from then on all connection are TLS anyway[ok, except DNS]) - and re connect.
It always works for me.

Yes, this also worked for our test client!

You mean pfSense can't see the MAC addresses of the connected captive portal users ?

Exactly

You didn't mention the most important criteria of a portal : DNS.
A connecting device should obtain an IP, network, gateway and DNS.
Then it throws out a hidden http request (see above) and for that to work, DNS should work.
Not some "8.8.8.8" DNS, as all non local DNS are not accessible at this moment. By default, the DNS will work on the pfSense portal interface.
Did you test that ?

Yes, DNS works good on the inside interface of the pfsense, with host override for the portal page redirect.

In the past, this page Troubleshooting Captive Portal was mandatory.
It still is, but these days it talk about the new firewall 'pf', as Netgate made 'pf' MAC aware.
2.6.0. uses ipfw, which was ditched after 2.6.0.

I am aware of this page, thank you. The problem is also with troubleshooting in the Prod environment. I cannot change some settings just to test if it works. There would be the risk to interrupt the connectivity of the 300-400 working clients. I have to do non-invasive things like packet capture and log examination.
If this issue remains or even spreads to more clients or the "Wifi forget" on the phone won't help anymore we would need to reproduce the setting in a testing environment.

Again thank you
R.

@darnoldvcs said in Captive Portal Pass-through MAC Auto Entry is registering unauthenticated users:

I have tested this on 22.05 & 23.01.

What is / Is there a reason not to test de the current version - 23.05 ?

For good manners : I use 23.05, as it removes issues present in 23.01 ;)

With only this option checked :

@darnoldvcs said in Captive Portal Pass-through MAC Auto Entry is registering unauthenticated users:

Pass-through MAC Auto Entry: Checked/Enabled

I had to identify with valid credentials, and then the MAC was added to the MACs table.

These two :

54a7c9c3-d164-4e80-b6eb-4253f72705bb-image.png

I have never tested these .
But setting them to "1" both does expose what you've mentioned above.
I still don't know what "Pass-through credits per MAC address" actually is. 1 hour ? or 1 "something" ?

But, I've seen the same thing : with these to set to "1", the MAC address of my device was added right away in the MAC table, granting me indefinite access from that moment.
That behavior doesn't match with the description

When enabled, a MAC passthrough entry is automatically added after the user has successfully authenticated.

edit :

I've been looking around in the documentation.

In the captive portal /usr/local/captiveportal/index.php file, around line 192 :

8bf8f900-5314-4f43-ad58-f51ce72ea634-image.png

The function "portal_consume_passthrough_credit($clientmac)" return 'true' if these 2 :
54a7c9c3-d164-4e80-b6eb-4253f72705bb-image.png

are set (bigger then 0).

The if statement is true, so a log line is add to the captive portal log :

captiveportal_logportalauth("unauthenticated", $clientmac, $clientip, "ACCEPT");

which means a user with MAC '$clientmac' and "unauthenticated" is added.
Like :
08c5ad14-4c20-4d73-bcd5-26b19c42f723-image.png

and then the mighty portal_allow( ....... ) is called.
This isn't a real login, an "unauthenticated", is more a "temporarily accepted auto login".
Nevertheless, because this is a new session, and "passthrumacadd" is set/checked (around line 2075 /etc/inc/captiveportal.inc) is now unconditionally added.

Easy way out : these options are somewhat 'mutually exclusive'.

The thing is : the captive portal logistics is ..... messy (I'm still looking for a better word) or somewhat what could be called as 'spaghetti code'.
The main settings page makes the portal admin think that all kind of option can me used together.
This is a typical case of : no way.

edit :

Change /etc/inc/captiveportal.inc : https://github.com/pfsense/pfsense/blob/5e92d678f642277642acb7f471cd430ed53aae16/src/etc/inc/captiveportal.inc#L2075

I tried to play with :

if (isset($config['captiveportal'][$cpzone]['passthrumacadd']) && empty($config['captiveportal'][$cpzone]['freelogins_count']) && empty($config['captiveportal'][$cpzone]['freelogins_resettimeout'])) {

which stands for
If ("passthrumacadd" == checked) and
both 'freelogins_count' and 'freelogins_resettimeout' are not set,
then do the MAC add passtrough.
But this was not a solution.

There need to be a test to see if the MAC in case is in the grace ( freelogins_resettimeout ) period.
This could be done by checking /var/db/captiveportal_usedmacs_cpzone1.db (cpzone1 is my captive portal zone name) ...

My first advise still stands : @darnoldvcs please keep it simple(r).
If possible, ditch the "passthrumacadd" option - and say sorry to your visitors : after a while (hard reset or IP change) : they have to login again.
If these people are really, or more or less trusted users : give them another, more trusted network that doesn't use the captive portal.

@darnoldvcs If pfSense have native saml support,the user can make the most of captive portal with other 2FA,such as casdoor and other SSO solution.
The pfSense can be the NAC.

@Gertjan Thank you for your response and effort, it all makes sense then.. I will try out the different DNS overrides and see how that will go.

@Gertjan Thanks

@johnpoz Thanks, I will do some more exploration today. I know that in the downloaded zip of the certs there is the:

cert1.pem
chain1.pem
fullchain1.pem
privkey1.pem

The import into I pfSense only asked for the cert and private key. When I import into other applications like Synolgoy they ask for private key, certificate, and intermediate key chain.

More fun on a Saturday...

Solved it. Needed to use "fullchain1.pem" for the certificate field. Problem went away. It was your detailed walk though example that lead me to think to this.

Thanks again @johnpoz

Hi,
After few days of tests, the firewall's solution works.
I'm still searching of to do that with FreeRadius and Groups.

Not exactly, I mean you connect using OpenVPN, so you did the first authentication user+password against a freeradius.
That is what I'm doing now, an external freeradius authenticates "password+OTP" with a freeradius perl module.
OpenVPN clients can connect to vpn server and when they are connected a captive portal asks for the second authentication factor.
The main problem is that the openvpn client won't asks for a second auth, it only accepts user+password, so the workaround is use a "password+OTP" string on the password field.
That can be done beause you know Google Auth OTP before the auth process, but with a SMS, email, ... sent you won't know that second "password" unless you did the first auth.

BTW, I managed to connect to a captive portal disabling MAC filtering.

@Gertjan said in Captive portal for OpenVPN clients to implement a MFA:

@elbuit

Isn't this a chicken and egg problem ?

If you want to connect to the captive portal, your VPN client has to connect first.
For the VPN client to be able to connect, you have to connect to the captive portal first.

OpenVPN : if you want several choices to identify, you could consider using Freeradius as an authentication service for the OpenVPN server.
Not the client btw. The OpenVPN client can only connect to a OpenVPN server.

See here : Authenticating OpenVPN Users with FreeRADIUS

LDAP can also be used.

@gertjan Thank you! That was the answer! I set the hard tie out to 30 minutes, 1 passthrough credit per mac address, and a 24 hour waiting period before they get another free credit.