Different rate limits based on login ?

[Swicago]

@EDaleH,

Thanks for the reply. I am actually looking at the source code of radius.
I believe it may be easier to modify
/usr/local/share/pear/Auth/RADIUS.php
and add an extra attribute that can return weather or not a user can be logged in more than once "multiple" or if they get booted "last/first".Basically overriding the default setting in the portal page "Concurrent user logins". Then captiveportal.inc could be left alone.

The other option is to add support to the voucher system to store bw_up, bw_dn and noconcurrentlogins attributes per voucher roll and have that override portals setting. However this option looks to be far more complex than modifying Radius to support an extra attribute.

[Swicago]

I have added support for Non-Conccrent-Logins with Radius.

First file is the dictionary. I added new attribute "pfSense-Non-Concurrent-Logins"

/usr/local/share/freeradius/dictionary.pfsense

# -*- text -*-
# Copyright (C) 2019 The FreeRADIUS Server project and contributors
#
# dictionary.pfsense
# pfSense Captive Portal Dictionary
#
# https://github.com/pfsense/pfsense/blob/master/src/usr/share/doc/radius/dictionary.pfsense
#

VENDOR          pfSense                         13644

BEGIN-VENDOR    pfSense

ATTRIBUTE       pfSense-Bandwidth-Max-Up                1       integer
ATTRIBUTE       pfSense-Bandwidth-Max-Down              2       integer
ATTRIBUTE       pfSense-Max-Total-Octets                3       integer
ATTRIBUTE       pfSense-Non-Concurrent-Logins           4       string

END-VENDOR      pfSense

Then I added support for the new attribute in
/usr/local/share/pear/Auth/RADIUS.php

                } elseif ($vendor == 13644) { /* Netgate */
                    switch ($attrv) {
                    case 1: /* pfSense-Bandwidth-Max-Up */
                        $this->attributes['bw_up'] =
                          radius_cvt_int($datav);
                        break;
                    case 2: /* pfSense-Bandwidth-Max-Down */
                        $this->attributes['bw_down'] =
                          radius_cvt_int($datav);
                        break;
                    case 3: /* pfSense-Max-Total-Octets */
                        $this->attributes['maxbytes'] =
                          radius_cvt_int($datav);
                        break;
                    case 4: /* pfSense-Non-Concurrent-Logins */
                        $this->attributes['noconcurrentlogins'] =
                          radius_cvt_string($datav);
                    }
                }

Last I modified
/etc/inc/captiveportal.inc

        /* read in client database */
        $query = "WHERE ip = '{$clientip}'";
        $tmpusername = SQLite3::escapeString(strtolower($username));
        //if (config_get_path("captiveportal/{$cpzone}/noconcurrentlogins") !== null) {
        if (config_get_path("captiveportal/{$cpzone}/noconcurrentlogins") !== null
                /* RADIUS Support for NON CURRENT LOGINS */
                || (isset($cpzone_config['radacct_server']) && $cpzone_config['radacct_server'] == 'Radius' && !empty($attributes['noconcurrentlogins']))
        ) {
                $query .= " OR (username != 'unauthenticated' AND lower(username) = '{$tmpusername}')";
        }
        $cpdb = captiveportal_read_db($query);

        /* Snapshot the timestamp */
        $allow_time = time();

        if ($existing_sessionid !== null) {
                // If we received this connection through XMLRPC sync :
                // we fetch allow_time from the info given by the other node
                $allow_time = $attributes['allow_time'];
        }
        $unsetindexes = array();

        $cpzone_config = config_get_path("captiveportal/{$cpzone}", []);
        /* RADIUS NON CURRENT LOGINS */
        if (isset($cpzone_config['radacct_server']) && $cpzone_config['radacct_server'] == 'Radius') {
                $cpzone_config['noconcurrentlogins'] = !empty($attributes['noconcurrentlogins']) ? $attributes['noconcurrentlogins'] : $cpzone_config['noconcurrentlogins'];
        }

This allows me now to support a slow free user that can have multiple connections or faster tier users where connection is limited to what ever I set "pfSense-Non-Concurrent-Logins" as in Radius user config. In my case I set it to last. Default portal is set to multiple and Radius overrides it, just as it does bandwidth.

Next I will see how I can make the Radius user valid for a few days after 1st login. That will simulate vouchers that are only valid for a certain number of days. Maybe this is already supported, else I'll just mod captiveportal.inc and RADIUS.php again for support.

My current code changes do not affect portal in default, so it can still run as originally coded.

[EDaleH]

@Swicago said in Different rate limits based on login ?:

modifying Radius to support an extra attribute

I believe that someone at Netgate told me there was no more room to "add" a radius attribute or the variable would overflow (much like data quota does), it is easier to simply place the FREE user in the "daily" and the "FasterTier" user in say "monthly" in the freeRadius user database and check the datacounter filename for a match on the username. If you want to logout the existing user to make it "last login" equivalent, that would require a call to the disconnect routine for the original user and that is less straightforward as the communication between captive portal and freeRadius is asynchronous; tied to the reauthenticate/accounting interval. You could check to see if there is any value in the used-octets file to determine if someone has already logged in but then you would have to do something like create a file on disk with the new username in it and in the reauthenticate routine in captive portal, disconnect the off side user at the next reauthenticate interval. That would be fairly easy to do. The sample code below does something similar:

$d_max_file = "/var/log/radacct/datacounter/monthly/max-octets-" . $cpentry[4];

					$d_max = array();
					if (file_exists($d_max_file)) {
					  $file_max_OK = "File exists";
					  $d_max_handle =  fopen($d_max_file, "r");
					  while(!feof($d_max_handle)) {
					    $d_max[] = fgets($d_max_handle);
					  }
					  fclose($d_max_handle);

				$cpdb_50 = captiveportal_read_db();
				$nbr_logins_50 = 0;
				$user_50 = $cpentry[4];
				foreach ($cpdb_50 as $cpentry_50) {
					if($cpentry_50[4] === $user_50) {
						$nbr_logins_50 = $nbr_logins_50 +1;
						$time_used = $time_used + (time() - $cpentry_50[0]);
					}
				}
				unset($cpdb_50);

Add a variable to keep track of the username and you can check the session start ($cpentry_50[0] I believe), choosing to disconnect the oldest session. This would occur on every reauthenticate interval so the two could be both connected for a couple of them.

Something like this (around line 751 in captiveportal.inc 24.11 Stbl) would disconnect them:
captiveportal_disconnect($cpentry, 17);
captiveportal_logportalauth($cpentry[4], $cpentry[3], $cpentry[2], "DISCONNECT - REAUTHENTICATION FAILED", $auth_result['reply_message']);
$unsetindexes[] = $cpentry[5];

[Swicago]

@EDaleH , @Gertjan ,

As I posted up above, 3 files need editing and then it works as expected. Thanks again for trying to help out.
I know have 1 portal to rule them all. LOL

[EDaleH]

@Swicago said in Different rate limits based on login ?:

Next I will see how I can make the Radius user valid for a few days after 1st login.

It looks like we were replying to each other at the same time and overlapped our replies.

Impressive solution, well done. As far as your timeout requirement, the solution may partially be in the code I sent with my prior reply. If you can get away with it, I believe Captive Portal will disconnect by itself at the hard timeout value anyway. I needed to share time amongst all connected devices to one user account and the solution below includes that consideration.

			$cpdb_50 = captiveportal_read_db();
			$nbr_logins_50 = 0;
			$user_50 = $cpentry[4];
			foreach ($cpdb_50 as $cpentry_50) {
				if($cpentry_50[4] === $user_50) {
					$nbr_logins_50 = $nbr_logins_50 +1;
					$time_used = $time_used + (time() - $cpentry_50[0]);
				}
			}
			unset($cpdb_50);

The $time_used variable is tracking total connect time. The next piece of code maxes out a data quota and lets freeRadius disconnect (everyone logged into that user) on the next reauthenticate interval for each of them in turn.

			if (($auth_result['result'] === false) || (intval($time_used) > $cpentry[7])) {
				if((intval($time_used) > $cpentry[7]) && ($cpzone == "vlan50")) {
					$d_max_file = "/var/log/radacct/datacounter/forever/max-octets-" . $cpentry[4];
					$d_used_file = "/var/log/radacct/datacounter/forever/used-octets-" . $cpentry[4];
					$d_log_file = "/var/log/radlog/forever-used-octets";

					$d_max = array();
					if (file_exists($d_max_file)) {
					  $file_max_OK = "File exists";
					  $d_max_handle =  fopen($d_max_file, "r");
					  while(!feof($d_max_handle)) {
					    $d_max[] = fgets($d_max_handle);
					  }
					  fclose($d_max_handle);
					}
					$d_used = array();
					if (file_exists($d_used_file)) {
							$d_used_handle =  fopen($d_used_file, "r");
							while(!feof($d_used_handle)) {
  								$d_used[] = fgets($d_used_handle);
							}
							$dused = $d_used[0];
							fclose($d_used_handle);
						$d_used_handle =  fopen($d_used_file, "w");
						fwrite($d_used_handle,strval($d_max[0] + 1));
						fclose($d_used_handle);
					}
					if (file_exists($d_log_file)) {
						$d_log_handle =  fopen($d_log_file, "a");
  							fwrite($d_log_handle,$d_log_file . "," . str_replace("\n","",strval($user_50)) . "," . str_replace("\n","",strval($nbr_logins_50)) . ","  . str_replace("\n","",strval($dused)) . "," . str_replace("\n","",strval($d_max[0])) . "," . date("Y-m-d h:i:sa") . "\n");
						fclose($d_log_handle);
					}
					unset($d_max);
					unset($d_used);
				}
				captiveportal_disconnect($cpentry, 17);
				captiveportal_logportalauth($cpentry[4], $cpentry[3], $cpentry[2], "DISCONNECT - REAUTHENTICATION FAILED", $auth_result['reply_message']);
				$unsetindexes[] = $cpentry[5];

Maybe that will stimulate one possibility to consider?
.

[Swicago]

@EDaleH ,

Radius actually already supports expiration date. And portal respects it.

I just wrapped up coding also Voucher based bandwidth limits and no concurrent login control. For vouchers, I hijacked the description field to add extra attributes. For Vouchers, bandwidth limits is global to the roll, like minutes.

If you think anyone would be interested, I can re-upload my full changes of both RADIUS and VOUCHER control with specific bandwidth and login controls. Changes for voucher was a little tougher. Stupid spelling mistakes LOL.

[EDaleH]

@Swicago

@Swicago said in Different rate limits based on login ?:

If you think anyone would be interested, I can re-upload my full changes of both RADIUS and VOUCHER control with specific bandwidth and login controls.

There is always someone interested. Although not immediately applicable to my current setups, I for one... am.

[Swicago]

@EDaleH
Well all righty then.

I will do full post of all code changes for both RADIUS No Conncurrent Login support and Voucher Badwidth & Non Concurrent Login support. Also, corrected some spelling mistakes for the non concurrent attribute.

Here are my diffs for each current file vs their backups

Radius specific
/usr/local/share/freeradius/dictionary.pfsense

17d16
< ATTRIBUTE     pfSense-No-Concurrent-Logins            4       string

Radius specific
/usr/local/share/pear/Auth/RADIUS.php

709,711d708
<                     case 4: /* pfSense-No-Concurrent-Logins */
<                         $this->attributes['noconcurrentlogins'] =
<                           radius_cvt_string($datav);

Voucher specific
/etc/inc/voucher.inc

226d225
<       $config_per_roll = array(); /* Roll configs */
230,239d228
<               /* Voucher roll config override support */
<               if(preg_match('/\bnoconcurrentlogins\s?=\s?(multiple|first|last)\b/',$rollent['descr'],$matches)) {
<                       $config_per_roll[$rollent['number']]['noconcurrentlogins'] = $matches[1];
<               }
<               if(preg_match('/\bbw_down\s?=\s?(\d+)\b/',$rollent['descr'],$matches)) {
<                       $config_per_roll[$rollent['number']]['bw_down'] = intval($matches[1]);
<               }
<               if(preg_match('/\bbw_up\s?=\s?(\d+)\b/',$rollent['descr'],$matches)) {
<                       $config_per_roll[$rollent['number']]['bw_up'] = intval($matches[1]);
<               }
249d237
<       $config_voucher = array(); /* Voucher Roll ovverride config */
306,307d293
<                               /* Store any voucher override configs found */
<                               $config_voucher = isset($config_per_roll[$roll]) ? $config_per_roll[$roll] : array();
399,401c385,386
<       /* Return minutes left and voucher roll override configs */
<       /* Note captiveportal/index.php needs to be modified to check if array returned */
<       return array($total_minutes,$config_voucher);
---
>
>       return $total_minutes;

Voucher specific
/usr/local/captiveportal/index.php

<       $auth_return = voucher_auth($voucher);
<       //$timecredit = voucher_auth($voucher);
<       /* Support array or single var return */
<       $timecredit = is_array($auth_return) ? $auth_return[0] : $auth_return;
<       /* Support voucher configuration override */
<       $voucher_configuration = is_array($auth_return) ? $auth_return[1] : array();
---
>       $timecredit = voucher_auth($voucher);
221,224d215
<               /* Copy all voucher configs into attributes */
<               foreach($voucher_configuration as $config_key => $config_value) {
<                       $attr[$config_key] = $config_value;
<               }

Both Radius and Voucher changes
/etc/inc/captiveportal.inc

1952,1958c1952
<       //if (config_get_path("captiveportal/{$cpzone}/noconcurrentlogins") !== null) {
<       if (config_get_path("captiveportal/{$cpzone}/noconcurrentlogins") !== null
<               /* RADIUS Support for NO CONCURRENT LOGINS */
<               || (isset($cpzone_config['radacct_server']) && $cpzone_config['radacct_server'] == 'Radius' && !empty($attributes['noconcurrentlogins'])
<               /* VOUCHER Support for NO CONCURRENT LOGINS */
<               || ($attributes['voucher'] && !empty($attributes['noconcurrentlogins'])) )
<       ) {
---
>       if (config_get_path("captiveportal/{$cpzone}/noconcurrentlogins") !== null) {
1974,1983d1967
<
<       /* RADIUS NO CONCURRENT LOGINS */
<       if (isset($cpzone_config['radacct_server']) && $cpzone_config['radacct_server'] == 'Radius' && !empty($attributes['noconcurrentlogins'])) {
<               $cpzone_config['noconcurrentlogins'] = $attributes['noconcurrentlogins'];
<       }
<       /* VOUCHER NO CONCURRENT LOGINS */
<       if ($attributes['voucher'] && !empty($attributes['noconcurrentlogins'])) {
<               $cpzone_config['noconcurrentlogins'] = $attributes['noconcurrentlogins'];
<       }
<
2058a2043
>
2084,2088c2069
<               /* VOUCHER Bandwidth control */
<               if ($attributes['voucher'] && (!empty($attributes['bw_up']) || !empty($attributes['bw_down']))) {
<                       $bw_up = round(!empty($attributes['bw_up']) ? intval($attributes['bw_up']) : $dwfaultbw_up, 0);
<                       $bw_down = round(!empty($attributes['bw_down']) ? intval($attributes['bw_down']) : $dwfaultbw_down, 0);
<               } elseif (isset($cpzone_config['radiusperuserbw'])) {
---
>               if (isset($cpzone_config['radiusperuserbw'])) {

I'd upload my files, but I didn't see where that can be done.

If using radius, it already supports bandwidth per user, but not device restriction. This adds support for device restrictions. Use extra option "pfSense-No-Concurrent-Logins"

To add bandwidth and device control via Vouchers
The following can be added to the description field of a voucher roll
noconcurrentlogins=last,bw_down=5000,bw_up=500
The above tells pfsense that only the last device can use the voucher and that bandwidth is 5000kbs down and 500kbs up.
You do not need to specify all options and portal defaults will apply if not supplied.

Cheers

[EDaleH]

@Swicago said in Different rate limits based on login ?:

I'd upload my files, but I didn't see where that can be done.

I am going to assume you are running the current pfSense Plus 24.11 Stable. The diff files are compact and convenient as long as they are applied to the correct version which will be obsolete in only a few months but the post will survive. Posting the entire file(s) could result in versioning issues if someone uses them with a different version so I think the diff files are perfect. I prefer the old followed by new representation so you can search for the old code in the newly updated files. This is an ongoing challenge with customized code so you will have to re-run a diff on the next version's updated files against the prior version of the same file, and then re-integrate your changes, then produce a new diff, and so on. It is the safest way to "keep up".

@Swicago said in Different rate limits based on login ?:

If using radius, it already supports bandwidth per user,

I found that when there are multiple logins per user that the time accounting is not reliable on either Captive Portal or freeRadius. Captive Portal applies time limits to each session and starts over if there is a disconnect/reconnect or "last login" for authenticated users. Vouchers work for last login though. The next problem is that with multi logins per user, do you want to track each user against the data/time limits or do you want to cumulate users time/data against a single limit for data/time? How do you handle idle time and do you start over if they log out and then log in again? Lastly, if you have multiple portals authenticated by freeRadius, the users can use their freeRadius credentials to log into the other portal (free Radius Tunnel Attribute not supported by Captive Portal). These items do not affect your specific installation but they are hiding in the background.

You could consider raising a Redmine to add your feature to the project. That is where the diff files will assist in the implementation and you can upload your files to a Redmine safely, make sure you include the pfSense version info as well.

[Swicago]

@EDaleH ,

Good to know about the bug report page. I'll have to see if I have a login there and report/ask for the feature.
I am using 24.11-RELEASE and have backups of my files. I suspected as well that IO may have to re-apply my patches on later versions.
In my case, time constraints is not really a concern. My multi login tier is my slow tier and only uses a single login and never expires.
If a client wants to use faster tier, then taht is voucher based and only the last logged in device can use it. Also these vouchers are good for 7 days.

Background: My wife and I bought a campground last year. It uses a 3rd party service to run a portal and the wifi towers. It is costly and the system is dated/sucks. I am in the process of replacing all towers. We don't charge clients for internet, but still need to regulate usage, so that we have enough bandwidth to go around. This is where my so called free tier comes in. Anyone can use the Free slow Tier. 2mbs down. And each campsite that stays with us gets one voucher for one device at 6mbs, free of charge. This will let them watch netflix and such. I never expect too many devices at once to overload the bandwidth, but I will use shaping to always leave a bit for office vlan.

Anyhow, thanks again for responding to my initial post with suggestions. Was hoping I wouldn't have to do custom code, but I guess that was not a choice.

[EDaleH]

@Swicago said in Different rate limits based on login ?:

My wife and I bought a campground last year.

Interesting twist, I am retired and spent much of the last 2 decades running around in a Motor Home (10 yrs full time). We ended up helping sites setup their WiFi, often with pfSense. Our summer home stop was at an RV park (~120 sites) that I still take care of after about 15 years (all on pfSense) as a hobby. About 3 years ago, they brought in Fiber at great expense and we buried fiber in the Park out to all of 20 or so APs. The park's throughput last summer went from a monthly low of 7 TB to a high of 20 TB. Latency is 2 ms from the ISP and 4-6 ms to the end user. The impact on the park has been substantial, fully booked a couple of years in advance and grandkids visit because the gaming is better than at home. Most of the satellite dishes are gone because everyone is streaming instead. There are a lot of clients that come so they can work from their MH/Cottage all summer. The ISP feed is an expensive business account (conditional for bringing in the fiber about 10 Km) and revenue is now covering the entire cost of the internet itself. The wifi infrastructure, much like power/water/sewer upgrades is a capital expense that will have to be written off over time though. It is currently running on an XG-1541 max. I modified the captive portal code about 3 years ago and have ported it through each version up until the current version. Last year it had 0 down time outside of the seasonal APs loosing power during a couple of power outages. Transient stayed up because they are on a UPS. There are no office sales of wifi, no support requests and it is all automated or rented for the season. Single login at the beginning of the season/visit and automated cleanup when time/data expire. Have you implemented RFC8910 (DHCP 114) for the smartphones? Be careful with Kea as it likes to change the IPs frequently and is very different from ISA DHCP.

[Swicago]

@EDaleH ,

That is the next thing I am trying to get working. RFC8910

I have the /usr/local/captiveportal/rfc8910.php pulled from mega thread https://forum.netgate.com/topic/188402/captive-portal-not-working-on-ios-devices-only-dhcp-114

I uploaded my CA cert into pfSense.
I added the 114 DHCP entry to my DHCP of my portal VLAN "https://MYDOMAIN:8003/rfc8910.php?zone=MYZONE"
I enabled HTTPS option on the portal and select my cert and entered my ddomain.

I can reach the DOMAIN from all my hosts, because I added a DNS Resolver entry and point the domain to my portal ip address. This way I was able to verify that my ssl cert was good.

However, when I try to connect to the portal with Andriod it does not auto load the sign in, instead I have to click the SSID and load the sign in page, but it just times out saying it cannot reach webpage at https://MYDOMAIN:8003/index.php?zone=myzone&redirurl=http%3A%2F%2Fwww.google.com%2Fgen_204

What else am I missing?
Is there a way to talk to you directly or in a faster channel, that is if you have time. I feel I am close. I am def not a network guy, but learn really fast.

[EDaleH]

@Swicago said in Different rate limits based on login ?:

What else am I missing?

Start with a simple windows system that doesn't need DHCP 114 to function and get the captive portal page loading in a browser. If it doesn't autoload, try http://neverssl.com to trigger the "capture".

Only chase DHCP 114 after being certain the rest is working.

The most common mistake on the certificate is to be using the evaluation one which won't work for testing, you need to be on the production cert (ACME/let's encrypt).

At first glance you are on the right path for RFC8910 but make sure it is in the same directory as index.php or provide the full path to where it really is. The directory you list is the correct one.

As far as contacting me, I have no problem helping if I can, but will not release personal contact info on the forum so you would have to provide me with a place to drop a message anonymously where you could pick it up anonymously as well. I am not sure what that is. If you have a contact at Netgate that was prepared to be an intermediary, that might work. I discourage you from publishing any contact info here as well.

I will check here in the morning and expand on what I can. Right now I have to run.

[Swicago]

@EDaleH ,

Finally got it to work. I made a new portal with no login required, just accept on portal. Tested on windows as suggested and it was peachy with it.
Then did everything I did before to support mobiles and suddenly it worked too.
Then I added all my speed/voucher rules back onto the new portal and all seems to work, albeit after signing in it is a little slow to get the generate 204 page for android(10 seconds), but once connected it is fast. This was the case even with full bandwidth allowed(no restrictions), so not sure what that is about. Any suggestions as to what I still need to check.
I'll figure out a way to exchange info anonymously, if you are still ok with it.

Thanks a lot for your help.

[EDaleH]

The DHCP 114 string is sent to the device when it gets an address along with a Captive=True. That tells any device that is checking option 114 that it should load the DHCP 114 supplied URL before going anywhere on the internet. That means Captive Portal does not even know they are there yet. Most devices require that URL to be a secure one, iOS insists on it. iOS won't work at all with an http:// link whereas Windows will for example. The version of iOS and Android also change the way they handle DHCP 114 and only the most recent versions are handling it well. in iOS for example from ver 17 on, you will find a "Load Captive Portal Page" when you press the circled i (properties page). That should load the logout page from the Captive Portal through the loading of index.php. Logout, because the DHCP 114 string now would send a Captive=False because that page is the Vendor URL page from DHCP 114 through RFC8910.php, which is the same URL as the True page unless you change it in RFC8910.php. Index.php in that case detects you are already authorized and sends the logout page instead.

@Swicago said in Different rate limits based on login ?:

cannot reach webpage at https://MYDOMAIN:8003/index.php?zone=myzone&redirurl=http%3A%2F%2Fwww.google.com%2Fgen_204

Just a guess but if you have a redirect page in the Captive Portal that is timing out, it could cause the delay. Remove all the redirects until you are happy with how it works.

@Swicago said in Different rate limits based on login ?:

a little slow to get the generate 204 page for android(10 seconds),

You will notice that the earlier string has the redirurl added to the DHCP 114 supplied? login url. It doesn't belong there. Android should only check that page after you have logged in. I expect that the 204 page is not available until after you complete the login and your delay may be an attempt to load it twice, once by the portal and once by the device after that first attempt times out. If android is sending it as an http:// string as shown, it is that "insecure" url that is triggering the Captive Portal instead of directly loading the page without having the Portal "Capture" you and send the URL itself to the device browser. iOS can't do any http:// communications and will just hang in the temp browser if this happens. While debugging, simply get rid of any redirect urls, leave them blank.

I know this is confusing but the goal under DHCP 114 is to never be "captured", instead, to load the login page directly from the Captive Portal, whereas if you try to go directly to the internet immediately, the Captive Portal should "capture" you and redirect you to the login page. Unfortunately, because of SSL encryption, the Captive Portal can't tell if you are trying to get to the internet if the page is an "https://" secure page, it can only "Capture" you if the page request is not encrypted, i.e. an "http://" page. When Apple created and implemented DHCP 114 about 4 years ago, it basically broke the logic that the pfSense Captive Portal uses to Capture a device, thus it is critical to get DHCP 114 working so the device itself can take care of getting authorized through the Captive Portal without ever being "captured". Android is still a bit of a hybrid as you can see it appears to be using an http:// site to verify connectivity. That attempt could trigger the "Capture" and send the login URL from the Captive Portal if DHCP 114 or your SSL certificate aren't working properly. It is hard to tell, but the addition of the redirurl in the first quote is a hint that the DHCP 114 string is not being respected, likely due to SSL issues? Your android should be a very recent version to aid debugging, same for iOS.

Wrt your request to communicate directly, my "anonymous" suggestion was not to replace the forum, it was to enable the exchange of direct contact information. I am a full supporter of the value of the forum to others researching issues or as a learning tool and this exchange may be helping someone else now or in the future.

[Swicago]

@EDaleH
When I finally got it to work, the portal loaded instantly using Andriod. The delay is after login.
Since login is done via https, does dhcp resolver also need tls/ssl enabled?

As for vital info, I am all for it staying on the forum, but the back and forth on little things makes the thread huge and convoluted. Once I am done, I plan to step by step redo what I did, just like yesterday and make sure I have things noted right in order to be successful, then I would post the steps I took, so one post has the right steps needed and not a huge thread that will confuse future readers.

Anyhow, as said I feel I am close. To recap.
Created a new portal with no limits and no autgh, just accept.
Tested on windows Windows with no dhcp114, ssl portal worked as expected. Cert valid and all.
Added dhcp 114 and tested on android. It instantly connected to portal, where as before it just hung. So dhcp 114 is working. After I accept the portal auth, that is where android then tests the internet with the generate 204 page. It takes about 10seconds for it to find it and then all is good. No sure why there is a delay, I assume I am still missing something or something is still misconfigured.

[Gertjan]

@Swicago : extra info, about this :

@EDaleH said in Different rate limits based on login ?:

The DHCP 114 string is sent

The pfSense DHCP server sends it .... because a device was asking for it.
Not all devices do. Who does ? Who doesn't ? Easy to find out for yourself.

Packet capture with these options :

=> Select the interface, select full details, select UDP as a protocol, and port "67 67" as these are the ones used by the DHCP client and server.

and fire up the packet capturing.

When you connect a "114" capable device to your portal, you will see this :

The image shows the DHCP client request, and the DHCP (pfSense) answering the request.

so the device I used is "114" compatible (an iPhone).
Microsoft based devices are also compatible (not your XP based laptop of course).
Devices with the "others OS" ? I don't know. you tell me.

[EDaleH]

@Swicago said in Different rate limits based on login ?:

Since login is done via https, does dhcp resolver also need tls/ssl enabled?

The goal of local resolution through the resolver is to have a local IP available that is associated with the SSL URL for the captive portal login page. Once internet connectivity is established, it is no longer necessary so make sure your Domain DNS points to a local address for the Captive Portal login page. i.e. putting it into the resolver is not enough, your DNS has to be correct as well. Typically they would point to 192.168.1.1 if you are using the default pfSense setup.

in iOS, there is a delay while the "No Internet" indicator is on after logging in, ,,, but if you try, the internet is already there, iOS is just sorting it out so to speak. Are you sure you don't have connectivity for those 10 seconds?

[Gertjan]

@Swicago said in Different rate limits based on login ?:

but it just times out saying it cannot reach webpage at https://MYDOMAIN:8003/index.php?zone=myzone&redirurl=http%3A%2F%2Fwww.google.com%2Fgen_204

Your device, give it an static IP setup, with the correct IP, network, gateway and DNS (the last two should be the portal interface of pfSense).
No DHCP so no option 114, so the device doesn't know about the portal login page etc.
The old portal detection system still works.

Now, you must be able to go to "https://MYDOMAIN:8003/index.php?zone=myzone" manually, it should show you the portal login page right away.
There could be a delay, and I'll invent a possible reason right now :
If your portal network supports both IPv4 and IPv6, and knwoing that your device will always prefers IPv6, it (the browser) will resolve "MYDOMAIN" as always, and if a IPv6 comes back, it will use that to connect to the web (portal) server.
Or, the pfSense captive is IPv4 only ...
So, there will be a delay before your device decides to fall back to the ancient IPv4 that it also received when doing the resolving of "MYDOMAIN".

Permanent solution :
Your captive portal interface should have a IPv4 only.
and/or
Your MYDOMAIN should only resolve to an IPv4.

Btw : I'm just brainstorming here.

You can give your device a static DHCP setup on the portal, so it will always get the same IP.
Knowing your IPv4, you can packet capture the IPv4 of your device. Ask for all the details.
So you can see what it is doing, what request get what answer, what requests don't etc. So you can deduct why it is waiting.

[EDaleH]

@Swicago said in Different rate limits based on login ?:

does dhcp resolver also need tls/ssl enabled?

the DNS Resolver does need SSL/TLS enabled and pointed at your certificate