@thomas-hohm said in Captive Portal with big number of passththrough MAC addresses is causing webgui gateway timeouts, Error 50x, and HA-sync XMLRPC Error - broken or quantity limitations?:

I reported it to redmine: https://redmine.pfsense.org/issues/15612

I too believe its a bug or an issue with how they are doing the limiters, at least for me I have moved away from auto addition of mac addresses to keep the list small.

@Gertjan

It's good

My error was:
On my NPS server, it was checked to allow all users without validation...

Thanks for your help

@marcos20

Same forum, a couple fo days ago :

b68b8911-bdb3-42cc-a0ea-c91b1b769092-image.png

somewhat the same question.

The very short story : pfSense is 'as is'.
Slightly longer story : If you want to make it better, or different, as it is 'open source', you are only limited by what you want and can do.

Go over this forum, you probably need to go deep down below, in the past, and you will find examples, valid for the pfSense which were used back then.
A lot has changed, but the basic principales are still the same.

Often, these kind of project don't exist very long time, as every time pfSense upgrades, your own 'patches and modification' have to be updated also.
People stop to upgrade, as this means more work for them, and thus introduce security issues.

@bishoptf said in Captive Portal Bandwidth issue:

some older devices even my linux laptop can be a pain

The concept of a captive portal is created and defined by pfSense or whatever router you use.
Most of the captive portal support is build into the OS of the device the user uses.
Our pfSense, and its captive portal, is nothing more as a firewall that block everything, except the DHCP protocol (UDP, ports 67 and 68) and DNS (port 53, UDP and TCP).
DHCP still works - has to work ! - on a portal, so the device will get the correct network info.
DNS has to work, because : on the visiting side, the device :
has to execute a "connection challenge" so check if, upon connecting to the wired or wireless network, a connection to the Internet is possible.
It does this with an OD based simple "http" (NOT https !) request.
For example, an iOS device will use this URL :

http://captive.apple.com/hotspot-detect.html

Before this request can be made, first, as always, the domain name has to be reolved to an IP.
So, a DNS request is made to resolve "captive.apple.com".
When the IP comes back, a request is made to 17.253.109.202 on port 80 - and the requested file will be "hotspot-detect.html".

On the pfSense, this request to 'somewhere' with destination port 80, protocol TCP, will get redirected to the Captive portal's web server, using some 800x port. result : The portal's login page comes back.
And that's not what the OS want .. it wants this answer back http://captive.apple.com/hotspot-detect.html (click on the link to se the answer).
So, now the OS launches a system's default browser, and repeats the request.
This time the end user can see the login page, and deal with it.

This gets me to my point : a captive portal is not only a pfSense thing. You, as a portal admin can't deal with every situation created by every possible device - "it's not your problem".

These days, captive portals are real, and are proposed by many companies, or every other nut that wants to share his connection. So every known OS today has the build in portal support these days.
Using old software on modern network (Internet is not going to wait for you ...) is indeed a pain.
But, hey, that's live.
You keep the old stuff and deal with it, every day a bit more.
Or you get the new stuff and deal with it, every day a bit more.
😊

@pablomichelin

I'm using myself a PHP script that does something with the Freeradius database :

<?php try { $link = new PDO('mysql:host=192.168.1.33;port=3307;dbname=radius', 'radius', 'xxxxxxx'); // Check connection if($link === false) { die("ERROR: Could not connect."); } // Attempt delete query execution $sql = "DELETE FROM `radacct` WHERE `acctstoptime` IS NULL and `acctstarttime` < (NOW() - INTERVAL 610 MINUTE)"; $stmt = $link->prepare($sql); $stmt->execute(); unset($stmt); } catch (PDOException $e) { print "Error!: " . $e->getMessage() . "<br/>"; die(); } ?>

So check if the needed PHP library "ext-20-pdo" is installed ( in /usr/local/etc/php ).
I can't recall anymore if I installed that one, or if it is there by default.
Because you have Freeradius installed, the MySQL client is already there.

There were, in the past, some exemples in this forum - just scroll down a lot ;) - and you'll find posts with example how to build PHP pages that collect user info and posts it into the needed "radius" database.

Be aware that you have to patch the freeradius PHP a little bit so it uses the database for the account info : right now, it uses a flat file, the one you find here : /usr/local/etc/raddb/mods-config/files/authorize

I've posted a while ago what needed to be changed so Freeradius uses the users created in the database, not the flat file.

@Gertjan
Please be informed that I am a beginner in this pfsense and first time I am using this support portal. I entered into this thread by the google search.
Net time I will keep in mind your points.

@vahidmoghadam said in Limit users in the number of login to the captiveportal:

Is there any way to have this option by making some changes to the CaptivePortal options or source code or even making changes to FreeRadius source codes or options?

Look at Redmines 13843, 13844, 14118 and 14119.

If freeRadius is on the same server as pfSense, your issues with multi logins to a single user account are handled well on the freeRadius end if you want a single account accumulation of data quota for multiple users as long a reauthenticate connected users every minute is "on" and you have a small number of users. Time is not handled properly though. In order to accommodate these issues, we:

Modified the "reauthenticate connected users every minute" to use the interim accounting value instead (default 10 minutes). This makes it possible to handle hundreds of connected users as with a built in one second "sleep" in the reauthenticate routine the current pfSense code is very limited in quantity of users reauthenticating through freeRadius. Removed the logout option from all custom login screens, the logout screen/popup is now a dashboard that relays time and quota remaining to the logged in user. This was done so that we could use a custom routine in captiveportal.inc that counts the number of currently connected users on a single account (ensure captive portal preserve connected users across reboot is checked). We can then cumulate the time for all users on that single account and terminate their session within the reauthenticate routine in captiveportal.inc based on the time quota assigned to the account. Terminating is done by simply looking up the max-octets file for that user, adding one octet to it and then writing that value to the used-octets file. The next reauthenticate check per login will now log out that user on that account (catching the rest within one "accounting interval"), as will their acutally reaching their data quota for that account as freeRadius is accumulating data usage correctly for multiple users on a single account. (Note freeRadius does not have a problem with 4096 GB quota limit, that is a pfSense issue so as long as no one reauthenticate session has exceeded that 4096 limit, it works fine) We do not limit the number of users per account but the logic used to count users/account for tracking time could likely be applied as per the tunnel attribute discussion below. The authentication routine is also within captiveportal.inc. As there is no GUI entry to set the number of users, we would implement that through a file on disk and a simple http screen to edit and change it. Otherwise you would have to hard code it.

We are currently processing up to 200 logins on accounts with multiple users per account using this method and it has been working without issues for almost 2 years. Accounts have up to 1TB data quotas and typically 31 day time quotas and managed to the nearest interim accounting value (10 minutes). The captiveportal.inc file is different for plus than CE and you have to re-do/check the custom code for every release so this is not a simple solution to administer. Unfortunately there is no evidence that the referenced Redmines will be addressed any time soon, if ever. The Redmines address more than multi-users per account, there is the failure to respect the Tunnel attribute which allows freeRadius accounts to log into the wrong captive portal if you have multiple portals authenticated by freeRadius on a single server. We use custom code to check the day/week/month/forever attribute and only permit one captive portal to match that attribute. We then force a fail if the user account is not associated with the correct attribute, i.e. captive portal. A kludge but it works for us.

You asked if it could be done and your answer yes with limitations, the rest is in the Redmines referenced above.

@vahidmoghadam said in Miss Logging on FreeRadius:

someone could help me

You already did help yourself 😊

After the /var/log/radius/radacct/... log notification, it also want to do something with SQL, probably logging into the radacct table.

But, IMHO, you saw the warning. It didn't find the query to do so.
Compare what you find here : /usr/local/etc/raddb/mods-config/sql/main/mysql/queries.conf with your Radius 'SQL' file.

@skveen said in The delay after enabling CP is very large:

Since client can't get internet using the DNS Resolver client, well, I tried using the default settings.

Several things.

A captive portal can be used on the main pfSense LAN network, true.
I'm using it on a separate 'OPT1' interface, because a captive portal are typically a network with non trusted devices - you don't own them, you don't control them - you don't know who is using your portal, not what they are doing, etc. They are only there so they can use your Internet connection.
Also : keep the LAN for your trusted devices, or, why not, only for the pfSense GUI admin access, something that should be totally forbidden on the non trusted portal network.

I use unbound, the resolver with the settings it had when I installed pfSense.
These settings were defined by Netgate. let's presume they know what's goof for pfSense, thus you and me.
My ISP, AFAIK, doesn't f*cck up my DNS requests, I'm allowed to use any DNS server on the planet, and that includes Internet's main 13 root servers, all the TLDs and of course every domain name server. My resolver resolves just fine.
So, no special knowledge is needed to make it work on the captive portal. No forwarding hassle.
There's one thing : you should allow UDP and TCP connection to port 53, to the portal NIC (pfSense) itself. That's where unbound listens for DNS requests.
Breaking DNS is the most known reason why the portal "doesn't work"'. See here : Troubleshooting Captive Portal.

Thanks again @Gertjan for the great response! For starters, I will tweak the DHCP lease to 12-24 range and keep an eye. Then we'll see I guess :P

BTW, now that I think of the session pfSense assumes, perhaps it's a ticket for the dev team to investigate that even though the client IP changes (MAC stays the same), the portal session is detected by the server and the portal login page prompts for a "Disconnect" ("you are already connected"). Then the clients press "Disconnect" and log in again, of course. I would expect from what we established above that pfSense would create a new session (MAC / IP mismatch) and prompt for login immediately.

Moved to here.

@Gertjan that is a good idea in theory, but this would also mean that the voucher is not going to be "invalid" on all systems when used up in one.

@veldthui said in Captive Portal with login but no authentication:

That was why I was asking if i could just get them to input their name

Why do you want them to enter a name ?
It's easy to create a text field, and have the content discarded.
Doing something with name the user entered, like writing it to a file, is another level.
It is technically possible that the portal login code adds the entered user name as a pfSense user, the ones you can see under "System > User Manager > Users" but this creates a situation where unknown / non trusted users starts to add 'stuff' to the pfSense config file ..... that's far from safe.

Like the password, you can also hard code a user name : all logged in users will actually use the same login name and password at that moment.

You don't want to use this method :

323c1821-1dcc-421d-9eec-bbeed1cabfa6-image.png

as the user now doesn't have to enter anything, right ?

@Gertjan
Thanks for clarifying. I was guessing somewhat like this, but was not sure.
Yes, allowing access to someone using self registration could be difficult.
Beside of some law restrictions the requestor must be able to receive the access code by mail/SMS or somehow else.

My favorite would be sending the code by mail, anyhow, after an update you may need to check if all is still running.
So my pages for the voucher QR code printing need to copied to the pfSense again after every update.

Back to self registration: its a challenge, if connected to CP you are already connected to the WiFi, but without internet access (code still not entered), so how to receive the access code?
May be by building a dynamic portal page which shows the access code after entering a string, a captcha or something else, as said a challenge 😊 .

Regards

@Gertjan - This is the solution! Thank you very much.

@uggiz said in Captive Portal - Cron - Authentication issues:

its possible to get a "Quota used" message when the users gets logged out?

A browser getting a none solicited message from a web server with info ?
Noop. Never seen that before. Browers can connect to web server, get the file (page) they are looking for, and bye bye the connection.
It is possible to have a "logout" or "you are connected" browser windows open, and have that windows load some Jave stuff that questions the current status. if it was possible to get the "max allowed" and "current" bytes used .... but .....

See for yourself :

#!/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"; } } ?>

Create a file called /root/cap.php and put the above content in it.
Now call it :

php -q /root/cap.php

and you see : no 'used' info is avaible in the pfSense portal session database.
The max quota is :

[traffic_quota] => 104857600

= 100 Mbytes in my test case = Ok.

Ok ... you could, on the web server java side, get the max and used info from these files directly.

Another info source is :

32e69f3b-9c5f-4239-9d3d-417955ee1941-image.png

as the main log will be bombarded with these message (imho : they do not belong there - call me and I'll tell you how to ditch them).

edit :

Another way to have the user have page where you control the info :
Have seat-belts ? Put them on.
Read this close the initially irrelevant forum thread : captive portal is not working on mobiles
But in that forum thread I discovered something : the future of the captive portal ( ! )
It already exist, and you add it easily.
One condition : don't use KEA as your DHCP (portal ) server, you have to use ISC. because you have ti create a DHCP option for the HCP portal server.
Instructions are present in the forum thread.
You need to create one file (content of this file : see thread):

26a4bd49-d5c9-43a8-9383-374fd662abfe-image.png

and now, if you have an Apple device, you can test : connect to the portal - and notice is connects faster - and when connected, tap on the SSID of the portal, and you'll see something new.
Open the new suggestd link called "Portal" and the text "This network proposes a portal page".
The page you now open - the "You are connected page" is the future "portal status page".
Btw : I've also see (real) Samsung devices using this new RFC 8910. Others devices : dono ...

Why I'm telling all this ?
The page you saw is created here :
/usr/local/captiveportal/index.php
That where uyour changes go with the info you want to show - if the user wants to see it (and if they know how to request the info, because again, this is "portalling" as it will be done in the future ...)

Btw : I've this method running for several month now. Works great. Doesn't interfere with the existing capture method at all, it completely bypasses it. The device will know where to go as soon as DHCP request has been answered. No more DNS hassle, web interception. Just plain KIS.
Read the RFC and you'll get the picture.

edit : sorry : I went way to far again / was ranting. Sorry.

I came to the conclusion that running a proxy filter is a pain in the a**. It did not work on Android, sometimes it did not work with iOS - at least Windows was the least pain as it seems to implement WPAD in an administrator-friendly way (we announced our proxy using DHCP).

My solution: no Squid at all. I am now running two machines with Pi-Hole. The to-be-released version 6 supports allowlists so we can configure a "you cannot do anything per default" and allowing certain websites using our pre-defined lists. The other DNS filter runs the current stable release with a bunch of blocklists.

You can also use pfBlocker-ng's DNSBL capabilities, but Pi-Holes web interface is so much faster and easier to work with (it get's even faster with v6). I am using pfBlocker-ng's IP blocking capatabilities :)

Regards

@Gertjan thank you for the info, gonna test it 🙏🎉