@Christopher87

Even after reading this : Troubleshooting Captive Portal ?

@nourgaser

Uncheck ?
I've set it :

4b40d34c-6eef-4237-8df2-5548b292ee49-image.png

as this check box does this :

/etc/inc/captiveportal.inc :

70aeb364-b2f8-4b36-9177-814f1662c094-image.png

which means "$cpentry[7]" gets used, and that's the value obtained from Radius.
Note : "$cpentry[7]" == "/* hard timeout or session_timeout from radius if enabled */"
Not setting this checkbox it means it will use the captive portal 'master' hard timeout value :

a6f8d9cc-2732-4214-968b-bc746a354a23-image.png

IMHO : "$cpentry[7]" == is the radius equivalent of a hard (seesion) time out.
"$cpentry[8]" is the soft (idle) timeout.

@sceptre357

Yeah, that looks plausible.
Something typical that wasn't tested like that.

So : easy to remove the issue : switch "Use custom captive portal page" off.
Save !!
Now, remove everything under "Captive Portal Login Page", as it is visible now.
Save !!
Activate (check) "Use custom captive portal page", add the files, feautes and stuff you want.
Save.
Done.

Some one should redmine this (no me, as I have to do the tests to chow case the issue, Ive no time right now 😊 ).

@sambu Try running radsniff -x from the console, try and auth, might give you a few more hints.

@sceptre357 said in Missing "Last Activity" for portal users - Idle timeout not working:

Why does this happen? Is this a known bug?

Hummm.
Shouldn't happen.

Long story short :

[23.09-RELEASE][root@pfSense.bhf.tld]/root: ps ax | grep prunecaptiveportal 3852 - Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone1.pid /etc/rc.prunecaptiveportal cpzone1 4060 - I 0:00.86 minicron: helper /etc/rc.prunecaptiveportal cpzone1 (minicron) 97982 0 S+ 0:00.00 grep prunecaptiveportal

This says : the portal is 'pruned' every 60 seconds.

This is the prune function : captiveportal_prune_old()

Your situation is handled here : in this function. If traffic is 'not known' (zero) the "Last activity" (a time stamp) can't be determined. In that case, the "Session start" time/date is taken, the timeout value (soft time out or hard time out) is added, and that's the 'prune' time. If this prune time is smaller as the actual time, the user is disconnected.

Btw : what is the DHCP lease time for your captive portal ?
How many potienta portal devices ?
How big is the DHCP pool size ?
If a devices looses the lease, as it went away for the day, and came back the next day, and the lease (IP) was already assigned to another device at that moment, the portal starts to loose track of who is what when etc.

edit :

You don't see these "IDLE TIMEOUT" lines :

939affe0-3e4b-4d2c-abaf-1a0fdbbb9d0e-image.png

@sceptre357 said in Missing "Last Activity" for portal users - Idle timeout not working:

im using the "Idle Timeout" to clear

You've set the Idle timeout set to something like this :

c2495265-99e5-4faa-b18c-4bd669d76c66-image.png

What is the value you have set ?

@jarlel said in Captive Portal, MultiWAN and routing:

but unfortunately I don't see a way to assign different policys to different
accounts.

I'll see what I can find - gime a couple of days though, as this means some serious Googling.

@John-3 said in Captive Portal on 2.7 not redirecting to login page:

For starters DHCP Works fine and the client does get IP/Gateway and all the information from the DHCP Server.
I've already tested that dns answers my queries with pinging random addresses which of course doesn't reply to my pings because i haven't authenticated yet but resolves the addresses to Ip's and as i've mentioned if i enter the portal login page manually then everything works fine!

Ok. Good to know, and now this is out of the way, let's continue.

I'm using pfBlockerng, so I have a file I can use to test if DNS works :

If you haven't, switch the resolver to "Level 3" (query level) on the Services > DNS Resolver > Advanced Settings, and then Save + Apply.

I use

tail -f /var/unbound/var/log/pfblockerng/dns_reply.log

you can also use (I didn't test but sur ethat DNS requests will show up - do not forget to undo this "Level 3" setting as it will produce a huge log file) :

tail -f /var/log/resolver.log

As soon as I connect my 'iPhone' to the portal, before a browser pops up on my phone, showing the login page, I saw a lot of (20+) DNS requests flying by.
This is what I just saw :

...... DNS-reply,Nov 22 11:52:03,reply,A,CNAME,30,captive.apple.com,192.168.2.35,17.253.109.202,FR .....

This was the the OS of my phone that emitted a http (not https !!) request to a known web server (from Apple of course) and my device does this because it wants to test (all devices do this these days) if it can reach a 'test' site available on the internet.
Click to see the test.

This was my iPhone 'calling home' 😊
Androids don't call to apple, they use some other site.
Same thing for Microsoft device, they use a xxxx.microsoft.com http site.

If the resulting page contains the word (in my Apple case) 'Success' then the device knows it has a direct (non portal !) connection to the Internet. This is by far the most common case.
If it doesn't, (something else came back) then the device knows that a captive portal might be present.
It will fire up a 'browser', and repeat the same request.
On the pfSense side of things, a http request "with destination port 80 (http)" will get redirected by a captive portal firewall rule. To something like http://a.b.c.d:8002/xxxxxxx

Now, welcome that nice feeling : you start to understand how a portal works, that a 'captive portal' isn't actually a pfSense thing, but a BJOD device thing.
pfSense uses a rather simple firewall rule - and a web server to show a web (login) page if requested. Most of the heavy lifting is done by your device.

@Gertjan

Now is more clear for me : have to set the direction

thank you !

Direction
The direction to allow traffic matching this IP address.

From
Allow traffic sourced from this IP address through the portal, such as a local client IP address attempting to reach the Internet, or the IP address of a management client that must reach hosts on the portal network.

To
Allow traffic with this IP address as a destination, such as a local web server IP address that must be reached via port forward, or a remote web server IP address which clients must always reach.

Both
Allow traffic both to and from this IP address.

@ratcrow said in Captive portal login page not served:

because the pfSense DNS Resolver did not seem to be working (is this a clue?).

Yes, it the most common failure, see Troubleshooting Captive Portal.

Typically, you include in the DHCP lease (server side !) the IP of the captive portal interface of pfSense.
This is the case by default.
Two conditions must be true :
You have to allow traffic 'to port 53, protocol TCP and UDP where the IP is the IP of the captive ortal network.
This is the case by default (see my firewall line below).
Unbound has to listen to this interface.
This is the case by default.

@ratcrow said in Captive portal login page not served:

I assume that there is a default captive portal page that will just come up and that I don't have to create a custom page to make this work.

Exact.

@ratcrow said in Captive portal login page not served:

My firewall rules are about as simple as can be. It is possible that some other part of my configuration is to blame, but I don't know where to look

This is the 'simple one' : only the last yellow line :

95cf4987-eefa-4051-a76b-59ede42c6400-image.png

Afterwards you can add new, more specific 'block' rules above this line.

@Gertjan ok, then it seems things changed and i need to update all MAC settings.

Thank You.

@dochy said in Windows RADIUS Server:

we are still waiting for that manual please

Like these : microsoft nps ?

You'll find the Documentation under Additional resources.
Remember : this isn't open source and a Microsoft product. Manuals are most probably copyrighted.

@extranjero
A pfSense device that doesn't have access to the net ?
That means : no dns.

You saw the Troubleshooting Captive Portal : the very first "DNS resolution not functioning" will stop you right there.

Device connecting to a (wifi) network will trow out a 'hidden' http request, right after the DHCP negotiation. This can be any host name (most are know, though), so DNS needs to work.
But you have no WAN .....

So no auto captive portal login page opening.

The user could still know that it is connected to a gateway/router, so they could enter http://a.b.c.d (where a.b.c.d) is the IP of the pfSense interface IP.
That wouldn't make the portal login page showing up neither, as needed parameters are missing.

Using a laptop for such experiments is making your live hard on yourself. Any sub 50 $ old PC, with at least 2 network interfaces will do the job. Throw in an AP, and your good.
You can always add some rules on the portal interface that block traffic to the outside world (except DNS, right ?!)

@yogendraaa said in Captive portal making WAN gateway losses in 2.7.0:

Please help

I'd love to, as soon as I found out how to simulate what '5000' users can do when they discover that they need to logging again, and they all hit the pfSense captive portal web serer to login at the same time 😊

Your portal setup is not a, @home version, I tend to say : industrial ?
So, good to know you use a Xeon and boat loads of memory, please share more info.
For example :
Here : /var/etc/ : look for the two files starting with "nginx-", these are the captive portal web server config files.
The default worker_processes is "6". The number of max connections is "1000".
With these numbers I suspect that their will be some "pushing-at-the-gates" and not everybody will make it.
A less scientific approach of 5000 users number : not every device is fully "portal" aware, and will hammer the portal web server without doing an actual login ...... (less aware users makes things only worse ).
Add to this : for every established connection, the portal login page wilml get spewed out, and this happens when nginx piped the request to PHP-(fpm), and got the parsed result back.
PHP is a lot, but managing a stressed PHPP interpreter is ... a world apart.

Take note : I'm not an nginx expert.

When that login storm is over, and the firewall tables are all filled up with 5000 IP and 5000 MAC addresses, then these 5000 will generate 1 Mbits / sec per second ? That's already 5 gig ....
Don't worry, I get it, even if 5000 portal users are realty connected, far from 5000 are actually active.

@yogendraaa said in Captive portal making WAN gateway losses in 2.7.0:

WAN gateway showing losses

This doesn't say much. Losses = the gateway (WAN) monitoring tool sends a ping every 500 ms and checks if it gets back. If pings get lost, no big deal.
If other, 'user' traffic gets lost, that indeed not good. But dpinger (the monitoring tool) can not know that.

What does the Status > Monitoring (WAN) show you ?

And sorry, I just gave you more questions, not really solutions.

Update:
I tried to use NPS on server 2016 as RADIUS server just now, it works.
Pfsense version is 2.7.0, RADIUS MS-CHAPv2 .

@Gertjan Thank you, I did as you said, it works in 2.7.0 too!

Yes, you can use LDAPS authentication.
You need to add LDAP authentication server in System / User manager / Authentication servers, select "SSL/TLS encrypted" in Transport option.
You may test it using Diagnostics / Authentication.
Then select the LDAP server you added in your captive portal settings (Authentication Server).

As I recall, if I use Domain\Username or Username@Domain as user in CP login page, it will fail, but use only "Username" will be OK.

@johnpoz said in Secure Wireless Hotspot rule with IPv6:

You could put in a redmine..

https://redmine.pfsense.org/issues/14948

Hope I done it right.

@MiguelGon17

Can it be done with the pfSense GUI, filling in some fields and done : No.
pfSense by default doesn't use or include MySQM (maraidb) support.
Although, as soon as you install (no need to use it) the pfSense Freeradius package, PHP MySQL client support will be loaded.

Your question is known already, and there are answers, even solutions, just use the search button (look above) and search in the Captive portal forum the word MySQL.

It all boils down to : make your own captive portal login page, and upload it into pfSense.
Edit/modify the pfSense support 'code', PHP scripts actually, most probably /usr/local/captiveportal/index.php and /etc/inc/captiveportal.inc so you can 'get' to the records entered by the portal visitor, and do with them what you want, like : sending them to a mysql database.

This :

Collecting Users Data for Marketing (Email, Phone Number, Name)

is of course forbidden in most civilized countries ;)
Most users that are willing to enter some information, will use fake names, phone numbers, mail address etc.
You could say : ok,; I'll send a sms with a random 6 digit code to the phone number, and the user has to use this code to validate the info. And the same thing for the entered email address, but at that moment, the user can't access his mail account as the portal isn't open yet.

So, yes, of course, it can be done.
The question will change very soon : are you willing to do this ? Support this ?

@bokikay

Can you tell something about the circumstances ?

@Gertjan To update! I restarted the system and it worked. Thanks for all the support.