@EDaleH
Same screen, alternate route to it in the menu. The Gateways must match the one(s) set in Interfaces, Wan. when changing the Gateway. I do this all the time when I restore a Production Server to the Lab setup, the gatweay setup always changes. Lately I have gotten lazy and edit the config.xml file before restoring it, as follows:

<interfaces>
<wan>
<enable></enable>
<if>igc0</if>
<blockpriv></blockpriv>
<blockbogons></blockbogons>
<descr><![CDATA[WAN]]></descr>
<ipaddr>192.168.123.111</ipaddr>
<subnet>24</subnet>
<gateway>WANGW</gateway>
<spoofmac></spoofmac>
</wan>
and:
<defaultgw4>WANGW</defaultgw4>
<defaultgw6>-</defaultgw6>
</gateways>

By editing config first, it enables internet access sooner for the package installs and that is less likely to time out during the restore if you don't edit it fast enough. I do go an get a coffee though so it has the side effect of more coffee consumption.

@Gertjan said in Help with CP on OPT1:

Looks like it's working now ?

It seems so, just a mystery as to why? My test methodology is typically to change something, test and restore if it doesn't work.

Perhaps it was just the devices acting out of sorts. (We have a lot of Chromebooks come through here)

I will try and get the prod setup working...

@rsumook
Follow Gertjan's advice but it might help if I provide a step by step overview perspective:

If you have multiple captive portals on VLans, you likely have a LAN on 192.168.1.1, an OPT(X) interface with those VLANs utilizing it. Check Interface, Assignments and verify you have at least WAN, LAN and an OPT(X) interface defined. (Note on Netgate appliances with the Marvel switch, you can associate the VLan witout the using a physical interface as the interface is a "logical" one.)

Now check Interfaces, Assignments, VLANs and make sure all of your VLans are there, typically listing association with OPT(X) in the interface column. Note: it is not unusual for them to be associated with the wrong interface, particularly after a restore to a different pfSense computer.

Next go back to Interface Assignments and make sure you have an Interface also listed for each VLan. If not, define/associate them to match the above configuration.

At this time, think about the way the data flows to and from your Access Point. The Access Point needs to have a station ID with a VLan enabled and the VLan Tag must match the Tag of the VLan definition in pfSense. Think of that data passing through the AP, getting "tagged" with the VLan ID (10,20 or 30 in your example). Your switch must use L2 routing to ensure that "tagged" data packet can flow from the port the AP is plugged into and be routed by the switch to the port the OPT(X) cable is plugged into. (note: it is common, but not necessary, to have the switch route everything to every port, just enable/associate the specific VLans tags you need with the Port(s)). This will ensure that pfSense receives you tagged data and can decode it correctly for routing to the Captive Portal.

Go to Services, Captive Portal and you will see the defined Captive Portals and note that the interface column value matches the Interfaces, Assignments value. Click on each Captive Portal and make sure it is enabled and associated with that same interface. If you want a login page instead of a simple "acccept" prompt, also make sure an authentication server is assigned and that you have credentials there for testing (note, for local database, the user needs Effective Privileges, PortalLogins).

Next check the Firewall, Rules and make sure your data can get to/from the WAN for each and every VLan. The easiest way is to setup a default any to any rule and restrict it further as necessary after you get it working. Note: once debugged, you may want to restrict all VLans so they can't load webconfig on 192.168.1.1 or communicate with the other VLans. This will make your setup more secure for your users.

In order to work, the device connecting to the Captive Portal needs an IP address and that address must be in the range of addresses assigned to that VLan,. That is done by assigning a DHCP Server to the Interface associated with the Captive Portal/Vlan Tag. (Note: if you are using RFC8910, you must setup a DHCP option 114 and that requires ICE as KEA does not yet support options). Check that all of your Captive Portals have DCHP setup.

Whew,,,, Now you can test your portal(s). First connect a device to the WiFi Station ID associated with the VLan Tag, Captive Portal Interface. If you do not see the default login screen you need to start by ensuring you have an IP address so check Status, DHCP Leases and you should see that your device got a lease and what the IP is. If not, you have a problem with the AP communication with pfSense, check the switch setup and Interface the VLan is on.

If you are missing a login screen and have no Internet access, but do have a valid IP, then perhaps you have not triggered the Login. That must be done through an http://domain.ext. I use neverssl.com to see if it will trigger the login page but that is mostly applicable to desktop and laptop computers. With Phones/Tablets they often will not allow http:// traffic through and have to be told how to load the Captive Portal login page directly as Captive Portal can not decode https traffic to be "aware" of a desire to use the WAN, thus no login page is sent in lieu of the requested url. That is where DHCP option 114, or RFC8910 comes in. See "captive portal is not working on mobiles" topic in this forum. https://forum.netgate.com/topic/184936/captive-portal-is-not-working-on-mobiles/37.

I hope that helps.

@zwo said in Captive portal:

Dlink Dir 851

A router.

@zwo said in Captive portal:

tp link APS

Google doesn't know what that is. That's ... strange.

@zwo said in Captive portal:

cumbiam force 200

? > cambium force 200 ! ... that's ... dono ...

An example : I've a some 'routers with Wifi' that I've downgraded to 'dumb' access points : the good old famous WRT54GS (was linksys before, now Cisco - or something else) :

My pfSense captive portal network uses a dedicated NIC : 192.168.2.1/24. I've set up a DHCPv4 server for this portal interface :

22989722-0c5a-42ac-921a-50eb8b2319e2-image.png

I've activated the pfSense captive portal on my 192.168.2.1/24 interface, mostly with default settings.

I've reset my WRT54GS device.
Then :

fb8d5a9e-1776-4f23-8772-bc2e2ec621c8-image.png

and the Wifi part :

2934709e-f25c-4556-bd48-77754d748f01-image.png

save - reboot and nearly done.

Hook up the router .. sorry - now access point using one of these 4 plugs :

0cb56cf8-7e2f-4528-a20f-b40e27d67498-image.png

and your online !

Btw : the same scenario (setup) is valid for nearly every device you can find out there.

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