@nourgaser said in FreeRadius Idle-Timeout not honored by pfSense radius client:

Hope the clears up my issue a bit.

A lot.
I'll get back to you soon.

Here : a tool I use to inspect the captive portal 'internal, SQLITE3 "database :

#!/usr/local/bin/php -q <?php require_once("/etc/inc/util.inc"); require_once("/etc/inc/functions.inc"); require_once("/etc/inc/captiveportal.inc"); /* Read in captive portal db */ /* Determine number of logged in users for all zones */ $count_cpusers = 0; /* Is portal activated ? */ if (is_array($config['captiveportal'])) /* For every zone, do */ foreach ($config['captiveportal'] as $cpkey => $cp) /* Sanity check */ if (is_array($config['captiveportal'][$cpkey])) /* Is zone enabled ? */ if (array_key_exists('enable', $config['captiveportal'][$cpkey])) { $cpzone = $cpkey; /* Zone selected -> count users and add */ $cpdb = captiveportal_read_db(); foreach ($cpdb as $cpent) { print_r($cpent); echo date("m/d/Y H:i:s\n", $cpent[0]); echo "---------------\n"; } } ?>

If an "Idle_Timeout" comes back from the radius server, like this (your example) :

... Idle-Timeout = {idle_timeout_from_my_db_in_seconds} ....

it's stored in the record of the connected portal user :

[8] => [idle_timeout] =>

I saw it when I was testing - see above.

The portal prune process (every 60 seconds) will use this value to throw of the client when [idle_timeout] is exceeded.
That is : it should work like that. I saw an IDLE DISCONNECT in the portal log when testing this morning.

edit :
If you called the file /root/cap.php :
Use the 'tool' like this :
SSH (or console), option 8.

php -q cap.php

When I log into the captive portal with my 'test user account', where I've set

f9931ea1-b854-49e8-a47d-52f364fa6c45-image.png

I see this :

.... Array ( [0] => 1701419243 [allow_time] => 1701419243 [1] => 2014 [pipeno] => 2014 [2] => 192.168.2.6 [ip] => 192.168.2.6 [3] => e0:92:5c:d9:6c:fe [mac] => e0:92:5c:d9:6c:fe [4] => x [username] => x [5] => b70ed7483d25b0c9 [sessionid] => b70ed7483d25b0c9 [6] => eA== [bpassword] => eA== [7] => [session_timeout] => [8] => 5 [idle_timeout] => 5 [9] => [session_terminate_time] => [10] => 600 [interim_interval] => 600 [11] => [traffic_quota] => [12] => 1000 [bw_up] => 1000 [13] => 2000 [bw_down] => 2000 [14] => radius [authmethod] => radius [15] => first [context] => first )

Your looking at the dump of the pfSense captive portal logged in users.
It's a small PHP SQLITE database. For every logged in user, all variables are dumped.

For example : "[idle_timeout] => 5" has been set accrding to what came back from the Radius server.

While typing here, 5 minutes are passed, so :

05f04bde-5116-43e7-847e-1e4a315f876b-image.png

@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.

@susobaco

As showed in the other thread I linked above, the "2.7.0" portal works just fine.

Some thoughts though :
if this gets involved :

@sanrzn said in Problem Captive Portal pfSense 2.7 with allowed ip addresses:

haproxy (0.63_1)
Others: DHCP, DNS (with forward to firewall) on domain controller

then the setup will need more attention.

I'm pretty sure that if the classic setup was used : pfSense is the DNS, and handles the DHCP, the portal works.
Now, step by step : remove DHCP, have it being handled by another DHCP server : and test (!) : it can be done. It's a question of the correct 'settings' and all devices/systems involved.
Next step : pfSense isn't handling the DNS anymore on the portal : that can be arranged also.
Another step "domain controller" : ok, why not. Things are getting way more complicated as even more things have to be checked. I never did this myself, but I presume it is possible.

@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, thanks again.

sockstat -4 | grep '8002'
6838ab8a-9fee-453e-a0db-a21d15e3703d-image.png

The VLAN_50_GUEST / 24
826b2413-ada4-45f4-96b1-3720b3665dc1-image.png

DHCP / 24
61fe1007-33b7-4c12-b523-5a2b5bef067f-image.png

pfSense Rule VLAN_50_Guest
I changed to accept all the trafic, from all the interfaces. Continious the same error.
I deleted and recreate the rule.
3f59471d-0bc2-451a-a928-5fd2086ddaa1-image.png

DEFAULT NETGATE LOGIN PAGE
When I remove the custom loggin page, I have the same error.
dcfa8ed2-d910-457d-8938-6dc95d91fc14-image.png

link text

@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 ?

@goldsoft To change the URL, you can follow these steps:

Access your router settings. Look for the configuration related to the URL or redirection. Replace "http://192.168.1.1" with "http://pfsense" in the configuration. Save the changes.

This should update the URL as you want. If you need more detailed instructions, please specify your router model for further assistance. Also, consider using the essay writing service at for academic help.

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

@Gertjan

Yes, it turns out a whole trip to the theater.😊
Also, it turns out that the problem is solved, the solution (in my case) is found, published. Maybe it will help someone.

Thank you very much!

As for DNSBL - perhaps I will create a new topic.

@owenv said in Image URL in captive portal not showing:

I’ve added the domain name AWS bucket as a host name but even with this the image won’t show

Connect to the portal without identification.

Can you use / visit / see the AWS rule now ?
Keep in mind : a firewall doesn't use URLs or host names for that matter : it only understands "IPs" so if you use a host name, it should be present listed in the allowed host names and now you have to hope that the IP (only one IP !!) it resolved to is the correct one (AWS is typical for using a lot of IP addresses, not just "one").

See here : Allowed Hostnames - the first Note.

@des000 said in Captive portal and subnet:

want to transform dd-wrt into an ap

4760f5b0-081a-40eb-a817-de3b34fc97bb-image.png

Disable WAN.
Give it a static IP, like 192.168.2.2 / 24
Gateway and DNS is 192.168.2.1 - my captive portal pfSense interface.
Shut down the DHCP server.
You might even assign the WAN port as anther LAN port, if needed.

I've 4 of these (192.168.2.2 -> 192.168.2.6)

Btw : Wifi network security :

3f2fe97d-3986-4a01-9b39-7a742a913f73-image.png

Pretty rock solid.

https://forum.netgate.com/topic/183222/how-to-use-the-pfsense-name-instead-of-the-ip-address-in-http

The same purpose

Thank you for this feedback.

Correct me if I'm wrong but the normal process for the captive portal is as follows (on Windows 10 22H2) :

step 1: action of connection to public wifi

step 2: the PC obtains an IP address from DHCP

step 3: the Windows system attempts to connect to a url "www.msftconnecttest.com" with the LNASvc service (NCSI probe)

step 4a: the captive portal "captures" the previous HTTP connection attempt and opens the default browser. The captive portal login page opens.

step 4b: launch the browser by entering an HTTP URL and the captive portal page is displayed

My problem is that step 4a is not done. The default browser does not open. Unlike I can successfully perform step 4b.

The fact that the browser does not open is a problem for BYOD.
We cannot configure user devices...

I don't know if this is a problem related to PfSense...but in other establishments, it works with the same configuration...

@wendel_gt

2.6.0 is something of the past. It had its issues. For example, it had an issue with UDP, which was solved a couple of day later.

"But who uses 2.6.0 these days ?"

Take a look at the rule I showed above : if you are connected (authenticated if needed) to the portal, then pfSense isn't blocking you.

If you have non-default settings or a non common setup, please detail them.

@stevencavanagh

Try these settings :

Use pfSense using default settings : nothing altered or added by you.
Your device ; use default settings, so nothing altered or add by you.

Example : You could set up your device to use a DNS like 8.8.8.8 instaed of the DNS you got from pfSense.
That great, your choice.
But now the portal doesn't work anymore, as their is no DNS available until the portal gets unlocked (and for that to happen DNS need to work) : chicken and egg problem.

Another example : You've set up your browser to use DoH.
That great, your choice. Free world and so.
But now the portal doesn't work anymore, as their is no DNS available until the portal gets unlocked (and for that to happen DNS need to work) : chicken and egg problem.

Etc.

@Gertjan I've implemented pfSense on VmWare VM, with one nic(lan) on WiFi VLAN to provide captive portal for wifi client, and the other nic(WAN) on my lan network.

@goldsoft said in I am using a self-signed certificate. HTTP is working fine, but HTTPS is not.:

My certificate is the one that comes with PFSENSE

If you had a web site with a self signed certificate, yo would see the same issue : the browser would complain, as the certificate was signed by 'some one' that isn't on his 'trusted signer list'.
When you visit pfSense GUI using the build in auto generated certicate, you saw the same thing.
Easy solution : import the cert into your web browser cert store, and now its trusted.

The thing is : a captive portal, typically, is used for visitors, and you want them to be able to use your wifi.
With a self signed certificate, they should accept your unsigned cert first, or they have to import the cert .... and this is way to impractical.
If you want to use https : get a domain name, and use that domain name to get a trusted certificate with the help of the pfSense package "acme".

Btw : the https login page is only protecting the login page. As soon as the user is logged in, every site he'll visit on the internet is using https anyway. Mail comes in also over TLS.

I'm using https for my captive portal (a hotel) because its more serious to show
"https://portal.hotel-brand.tld" with a nice padlock an no browser complaints, as a login URL as is "http://192.168.2.1/...."
( Yes, I won (rented) "hotel-brand.tld")

You could do this.

@aminbaik

Captive portal, or not, you should know who connects to your network.
Portal users : you gave the login credentials, right 😊

Next time : when give them the login, ask them to give you their device's MAC address.
With the MAC, you can set up a "static DHCP Lease" and from that moment, when a user (person) connects, you == actually : pfSense, will know who it is.

=> or observe the pfSense log Status > System Logs > Authentication > Captive Portal Auth and yo can see what 'login' uses what MAC (and IP) addresses.
=> Or look at the Captive Portal Status Dashboard widget.

With the IP you (== pfSense) can do what is called policy routing.

Captive portals make often use of policy routing, as you do not want the un trusted portal users using your WAN IP. Image these users use infected devices, you'll be having troubles. See this example.

I'm using the captive portal for a hotel, and I should (as I'm actually not doing it right now) route my captive portal users over to a "VPN ISP".
Using a VPN for them can gibe issues, as, for example, Netflix usage could be impossible.
The choice is up to you.

@mra said in Captive portal issue:

My problem is that when connected to wifi1's wifi, the user who needs to log in to wifi2 will also be able to log in to wifi1. In this way, I want to create a user group for wifi1 and connect only to wifi1 captive portal.

I think I have a solution for you.
No radius needed, just pfSense.

Locate Line 263 of the main portal /usr/local/captiveportal/index.php file.
It's an empty line, just before the function

$auth_result = captiveportal_authenticate_user($user, $passwd, $clientmac, $clientip, $pipeno, $context)

where a user name and password are used to check if a user is authorized.

These are your 'zone' names :
zone1: "localzone"
zone2: "wifi1zone"
zone3: "wifi2zone"

Add this single line line :

$user = $cpzone.$user;

83d222f4-9aef-4828-8e72-4032dad7700a-image.png

Now, goto the pfSense User manager.

Example :
Let's presume you have a user called "001" that is allowed to visit your "localzone" captive portal.
Make the user info look like this :

fa0a71c4-6ec4-4059-937d-69e0b99e8fb3-image.png

If user "001" also needs to be able to visit the "wifi1zone" portal zone add another user like this :

2d5831ad-c7db-4e93-a13b-ce20cf95a3a6-image.png

@dochy said in Captive Portal Bandwidth-Max-Up Down Radius:

have you used captive portal RADIUS pfSense-Bandwidth-Max-Up and pfSense-Bandwidth-Max-Down attributes with any authentication system?

Yes.

This captive portal setting is not used :

7f74b54b-516d-4294-bfa4-f057ae5b90ca-image.png

I've a test user, login 'x' and password 'x' set up in FreeRadius.
No bandwidth limiting.

ed13397e-0f07-489b-9708-f6c085e822b0-image.png

When I use this 'x' account, I get what is available. Right now, the real limit is around 45 Mbytes / sec up and down. That limit is imposed by my very old access points.

Now, I add a up and down limit for this user 'x' :

1b91a13f-beea-483d-b9f6-d054e7b2a3f6-image.png

and test again.
Sure enough, I disconnected the actual 'x' connection first, and re connected using user login 'x'.
Result :

e76b9f63-ba97-4d63-8a13-31394d9171fd-Capture d_ecran . 2023-09-21 a 12.45.09.png

I consider this a "it works".
Other captive portal users are not impacted.

@dochy said in Captive Portal Bandwidth-Max-Up Down Radius:

have many users in Active Directory service and i should control bandwith of each user by groups or something like that.

This is what I would do if I needed to figure this out :
pfSense has a build in authentication system, the default build in User manager.
This one is fine for very basic "login + password" checking.

FreeRadius offers more, as you already can see in the in te captive portal settings page :

e1d3242e-f36e-4f3a-82d1-708d6d6b86b4-image.png

So, an initial identification is done, and further more, every minutes 'accounting' is done.
This accounting is : the user id, and also, MAC address, consumed traffic and much more. All this info is send to FreeRadius, who compares in its own 'tables' (files and/or database) the allowed (max) values.
FreeRadius sends back with a 'granted' or 'refused' answer.

This handling, I want to see this in the code or scripts.
FreeRadius is already a complex animal, but I said ones myself : it can't be that hard, as nearly every ISP, phone company and whatever other access that is metered on earth is using Radius already.
So, it can be done. But this aspect is very little discussed on the Internet.
You want to know how to build a web server ? That's easy, as the day you can read (5 years ?) you can find the info on the net - a zillion times.
A mail server ? Same thing - a bit more complex, as everybody can send mail, but actually very few know what really happens, what is needed.
A domain name server (aka : DNS server) : It's actually very easy, as it is ancient technology from the seventies last century, and didn't really evolve since. Take note that DNS is the biggest subject where people think they know what it is, and are fully wrong.
Radius or an authentication server : ? That's a secret. Just look at the config file (sorry : the entire config folder with xxx files in it) of a Radius server. A mess.
Of course, FreeRadius is open source. Still, you need to understand what you read .... what is needed to be done.
I understand that using the source code as a manual isn't really possible for everybody. But for me it's the only sure way to find out how things are done. It can't fail, lie, can't be wrong, is easy to find.
( and better : if you think it's wrong : don't complain, change it ^^ )

Anyway : I can't tell you what pfSense actually exchanges with the type LDAP server - if pfSense sends the "pfSense-Bandwidth-Max-Up and pfSense-Bandwidth-Max-Down attributes" to the LDAP, then you could see that on the LDAP side : just check (as always !) the log.
Does it interact on it ? => Does it send a 'granted' or 'refused' back to pfSense ones the "pfSense-Bandwidth-Max-Up and pfSense-Bandwidth-Max-Down values go over the set limit ?

I use FreeRadius for one simple (stupid) reason : I wanted to know what the 'Radius' thing was.
My needs, a captive portal so I can handle Free Wifi access for a hotel, works just fine if I was using the build in pfSense user manager.
I don't need to 'bandwidth' user or portal clients, as my 5 hotel APs are actually already limiting each user. The main WAN pipe is a 1 Gbits/sec up and down, so there is enough for everybody.
There are at the most 20 hotel clients connected at any time, as it isn't strictly needed any more these days, I've also 4G / 5G coverage.

Sorry for telling you much, and probably nothing.

@BENROFU Perfect, with wifi calling 👍

@oldschoolrouterjockey

Yeah, accepting DNS is a must have. DNS is mostly UDP btw, and rarely TCP.

@oldschoolrouterjockey said in Captive portal Help:

and also 8002

Don't need to do that.
The device will do the "http" (port 80) request initially. There is no need that the portal user needs to know that "port 8002" is used on the pfSense side.
Initial user port 80 traffic gets redirected at the firewall level to port 8002. The portal user's browser will never know it was talking to the server over this port. Or port 8003 when https is used.

# Captive Portal rdr on igc1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.2.1 port 8002

where igc1 is the portal interface, and "cpzoneid_2" is the portal zone ID, 192.168.2.1 is the portal IPv4.
A second portal instance will use, probably, port 8004 and another ID.

http portal mode is ok to "make it work".
Go to the https version, as most browsers will bark, showing warnings that will be errors in the near future, when not-TLS is used for any http traffic.
Also, the RFC1918 Portal IP won't show up anymore, the local pfSense portal host name is now used, because that's what certificates is all about.
Ones "https portal authentication" is set up, your done done with it installation. It will work well from then on.

There is a price tag, as you will need to rent a domain name. Annual fee : less then 5$ / year ?
Before you chose a registrar, make sure that it will work with "Lets encrypt", the pfSense package that will handle the automatic certificate renewal.

Advantage is : portal login goes over https, so there is no need anymore use any SSID security, the traffic is already encrypted. As soon as the user is logged in, all subsequent traffic is also using TLS : all mail, web and whatever uses TLS these days.
And as said above : portal users that want to add their own security : that's where VPN ISPs come in handy. : even you as the pfSense admin can 'see' their traffic anymore, you will have to trust your portal user ( ! ), which is actually a strange situation because portal users are actually 'untrusted' as they can do what they want with YOUR internet connection.

edit :

Purely optional :

If you have the NTP deamon running on pfSense, have it also listening on the portal interface.
Add this :
a555fc6f-40df-4909-b012-516cf32552fe-image.png
to the portal DHCP server (192.168.2.1 is my portal interface IP).
Add a rule like this :

2b7ce0ff-e511-460e-a7c2-805bd12a5826-image.png

to the portal firewall so portal users can use the pfSense NTP if they want to.

Update: I downgraded to 2.6.0 which works perfectly for us. Maybe I find the option to create an issue somewhere so it gets fixed at some point in the future.