Different rate limits based on login ?
-
@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
-
@EDaleH said in Different rate limits based on login ?:
the DNS Resolver does need SSL/TLS enabled and pointed at your certificate
Never had that one activated (enabled) on my pfSense. Not for my LANs not for my portal.
Also called DOT, right ?
DOT would be fine, I guess, for super trusted devices - and you have to set up manually the DNS host address and the DNS pfSense host LAN IP on the device first.
Afaik, DHCP is not going to do that.
The IP will be used to connect to the the DOT capable DNS server (in this case : our pfSense resolver) and a certificate exchange will tell the DNS client that de cert mentions the pfSense DNS host name, as it is present in the cert. If this test works out well, the DNS client will trusts the DNS server, and a DNS request can take place.Using way less words : DOT doesn't belong on the captive portal (my opinion, of course).
DOT on a LAN already asks for a manual ( !! ) setup on every device. Nobody is going to do that on a captive portal network.Better yet, from what I make of it,, the 'pf' initial portal firewall doesn't even allow "TCP 853" access.
(see /tmp/rules.debug and look for all the portal firewall rules )Port 853 proto TCP could be reached on pfSense if you add the IP host on the allowed hosts list, but that would expose all the pfSense ports on the captive portal .... Not good for a non trusted network.
Golden rule : captive portal users should use their device with standard, out of the box "network" settings.
For those who do not want that their DNS traffic going over UDP, port 53, over the wire or (yes, I know) open Wifi, then well ...... do not use a captive portal.
Or, next best solution : connect anyway. And as soon as you are connected, fire up your favorite VPN, so everything from this point will be scrambled, DNS included. -
@Gertjan said in Different rate limits based on login ?:
Using way less words : DOT doesn't belong on the captive portal (my opinion, of course).
Well, I had to google that to try to fully understand your reply. I have a simplistic view. We are asking for secure communications between the device and pfSense and iOS for one seems to demand it. When the browser (temporary or other browser) asks for a page that uses SSL security, the only way it gets the certificate data is if it is stored on the system already, available through internet access or locally supported. My understanding suggests it is a good idea to ensure the device can resolve to an address and reach the Captive Portal web page without failing to achieve that or be monitored/messed with, by a local unscrupulous client hanging around to mess things up. I turned that on 3 or 4 years ago and everything has worked extremely well. I am not sufficiently familiar with it to argue one side or the other. As I recollect, without it I was getting a "man-in-the-middle" warning.
This google search (DNS DOT) result seems to make sense:
"DoT works by sending DNS requests over an encrypted TLS tunnel, adding a layer of security over an existing TLS connection. The data in the request is then encrypted with a unique key unique to the communication session. The DNS request and response are then sent as data packets encrypted and integrity-protected by the TLS protocol. This adds an extra layer of protection, allowing only the intended devices involved in a communication session to access the data. By doing so, DoT helps protect user data and prevents unauthorized third-party access, which can be especially useful when users use shared networks, such as public Wi-Fi.... cloudns.net "
-
I enabled SSL/TLS on DNS resolver and selected my CERT. That seemed to slow down the initial sign in a bit.
Here is what my packet dump for the DHCP.09:59:29.226604 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 332: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 318) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx, length 290, xid 0x89ea128, Flags [none] (0x0000) Client-Ethernet-Address xx:xx:xx:xx:xx:xx Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Discover Client-ID (61), length 7: ether xx:xx:xx:xx:xx:xx MSZ (57), length 2: 1500 Vendor-Class (60), length 15: "android-dhcp-14" Parameter-Request (55), length 12: Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15) MTU (26), BR (28), Lease-Time (51), RN (58) RB (59), Vendor-Option (43), URL (114), Unknown (108) SLP-NA (80), length 0"" 09:59:29.226767 xx:xx:xx:xx:xx:xx > xx:xx:xx:xx:xx:xx, ethertype IPv4 (0x0800), length 403: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 389) 192.168.0.1.67 > 192.168.0.3.68: [udp sum ok] BOOTP/DHCP, Reply, length 361, xid 0x89ea128, Flags [none] (0x0000) Your-IP 192.168.0.3 Client-Ethernet-Address xx:xx:xx:xx:xx:xx Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Offer Server-ID (54), length 4: 192.168.0.1 Lease-Time (51), length 4: 555068 Subnet-Mask (1), length 4: 255.255.255.0 Default-Gateway (3), length 4: 192.168.0.1 Domain-Name-Server (6), length 4: 192.168.0.1 Domain-Name (15), length 9: "home.arpa" URL (114), length 74: "https://MYDOMAIN.tld:8005/rfc8910.php?zone=MYZONE" 09:59:29.242187 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx , length 300, xid 0x89ea128, Flags [none] (0x0000) Client-Ethernet-Address xx:xx:xx:xx:xx:xx Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Request Client-ID (61), length 7: ether xx:xx:xx:xx:xx:xx Requested-IP (50), length 4: 192.168.0.3 Server-ID (54), length 4: 192.168.0.1 MSZ (57), length 2: 1500 Vendor-Class (60), length 15: "android-dhcp-14" Parameter-Request (55), length 12: Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15) MTU (26), BR (28), Lease-Time (51), RN (58) RB (59), Vendor-Option (43), URL (114), Unknown (108) 09:59:29.242282 xx:xx:xx:xx:xx:xx > xx:xx:xx:xx:xx:xx, ethertype IPv4 (0x0800), length 403: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 389) 192.168.0.1.67 > 192.168.0.3.68: [udp sum ok] BOOTP/DHCP, Reply, length 361, xid 0x89ea128, Flags [none] (0x0000) Your-IP 192.168.0.3 Client-Ethernet-Address xx:xx:xx:xx:xx:xx Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: ACK Server-ID (54), length 4: 192.168.0.1 Lease-Time (51), length 4: 555068 Subnet-Mask (1), length 4: 255.255.255.0 Default-Gateway (3), length 4: 192.168.0.1 Domain-Name-Server (6), length 4: 192.168.0.1 Domain-Name (15), length 9: "home.arpa" URL (114), length 74: "https://MYDOMAIN.tld:8005/rfc8910.php?zone=MYZONE"I removed MACs and actual domain name. But from the looks of it, it seems to be getting the 114
As mentioned, the sigin page does show, I accept and then the devices waits for that generate_204 page for a bit. It does not connect instantly, like it did w/o dhcp 114v and SSL/TLS portal.
-
Arrrrrrrrrrr Stupid mistake. my dhcp 114 entry still had 8005 instead of 8003 in it. I created a second barebones portal yesterday, to make sure it was working right on widnows 11(latest).
I forgot to change it back to 8003.Now the only problem I have manual log out page.
I would have thought I could access it with
https://MYDOMAIN.tld:8003/logout.php
But I get nginx 404 not found error.
Direct port IP
https://192.168.0.1:8003/logout.php
also gives nginx 404 not found error.
It is only when I use the LAN IP (not VLAN IP) of the https://192.168.200.1:8003/logout.php does the page show.
Funny thing is, after portal login, I get the logout page for a short bit, before andrioid closes it. But I seem to not be able to reach the logout page after being fully connected. Suggestions? -
@Swicago said in Different rate limits based on login ?:
. Suggestions?
That one I can help with. You are getting the default logout page. Go to the captive portal and download that page. Then save it in the /usr/local/captiveportal/logout.php directory and now you have both control over it and the ability to load it directly.
-
There does not appear to be a download button for default logout page.
I can download error page and my login page, but no logout page -
@Swicago said in Different rate limits based on login ?:
https://MYDOMAIN.tld:8003/logout.php
But I get nginx 404 not found error.
Direct port IP
https://192.168.0.1:8003/logout.php
also gives nginx 404 not found error.Did you create / upload a logout.php file ?
@Swicago said in Different rate limits based on login ?:
It is only when I use the LAN IP (not VLAN IP) of the https://192.168.200.1:8003/logout.php does the page show.
Your "MYDOMAIN" resolves to 192.168.200.1, right ?
Port 8003 is the captive portal's port, right ?@Swicago said in Different rate limits based on login ?:
Funny thing is, after portal login, I get the logout page for a short bit, before andrioid closes it.
That's probably this one :
That's another example of an option that doesn't exists anymore, as it doesn't work anymore.
You know why .... (so why are you surprised it doesn't work ?? ).
I'll give you a hint : most, if not every browser these days, will not allow popup windows anymore. And I bet you won't find many browser with it activated, as it was "as nice try, but everybody hated them".So, shut down that option, and forget that it exists.
But there is good news also.
Remember the future ? The "Option 114" functionality ? It has you covered.
I can go straight to the Portal disconnect page, and disconnect my session, with the tap of a finger (ok, two taps).When I go to my current Wifi connection (my portal connection) I have to tap in the blue circled I, and then I see :
That I am connected to a 'portal'
And when I click on the (I translate) blue text "Open the page of the portal" I will see right away :
where I can disconnect the session.
This page is the same as the login page ! Because an open session exist, instead of the login page, this page is shown. Brilliant, right ? No need to learn or make another page. the device already knows about it.Me ,as an pfsens portal admin, could even put on this page the time I was connected, the number of bytes that I consumed, etc.
The thing is, this functionality is to new. This is bleeding edge.
Most phone OSes don't even know that this portal 'status' (logout) is avaible (look to the east).
US Phone (Apple) do this for a while know, and it works great.
But ordinarily people (like me) don't know this functionality yet - I guess I'm the only one in France.All this said, you can use plan B :
If you really have to logout users, do it for them ?!
Here :
which means : after 5 minutes of no activity on the session( the MAC/IP) then pfSense will disconnect the portal user for you.
This will work great : just charge 10 $ per kilo byte for your portal.
Now you, and your portal users don't have to worry, they will will disable their Wifi on their device as soon as they are done. This means : no more traffic. This means they will be disconnected automatically.Ok, 5 minutes is way to small of course
Mine is set to 120 minutes (of non activity).
But I don't care, and don't ask money for my connection, and I've enough bandwidth to offer.
I use the portal KIS rule : If you can connect to it, that's great. If you can't, that's fine also.
I've tried about every new device that exists out there, and as soon as I remove the shrink wrap, the device can connect to my portal just fine. Slide on the Wifi, select my portal, and bam, if offers a login page. Me,a s the admin, I know all the passwords ^^ If the device can't login, a discussion with the owner must take place, as people tend to "do things" with their phone / device. That's fine for me.Wait for it : Plan C ! Give your users an iPhone or iPad
(I'm joking again, and a lot, this evening) -
Yes, the dhcp 114 is giving my device a notification where I can see the connection and log out. But I just wanted a backup solution in case this didn't work right on all devices, such as TVs.
Turns out the URL for logout is the same as the login.
When I enter https://MYDOMAIN.tld:8003/index.php?zone=MYZONE it loads the logout page. SO that solves that issue as well.Now it appears I can support new and old devices.
Thank you both for all your help and insights. -
Found a bug in
One line 1742 you will find function "portal_ip_from_client_ip"
If someone calls https://MYDOMAIN.tld:8003/index.php and omit "zone=MyZone", this throws an Exception in PHP on line 1746 due to global variable $cpzone being "" empty string.
I added the following to /etc/inc/captiveportal.inc
function portal_ip_from_client_ip($cliip) { global $cpzone; /* Fixes bug when portl URL is called without zone */ if(empty($cpzone)) { return false; }The function returns false at the end, if it cannot find what zone interface you belong too by default. So all this does is the same, but fixes that bug that will show a message in pFsense crash reports.
-
Yeah, known.
https://forum.netgate.com/topic/195520/issues-after-update-from-24-03-to-24-11/15
It was there for years.But some how, there was somebody who wanted to enter portal login manually.
Humans are very bad at typing a text string like an URL.
One character off, or not specifying the &zone= parameter will trigger this bug.Nobody (forum) talked about it, as nobody has to enter the URL manually.
I'm pretty sure none of my hotel clients use the URL manually, as it isn't shown no where.You triggered the bug as you want have the portal users to disconnect themselves "as fats as possible".
May I ask : why ?
And a low idle time out won't do the job for you ?And seriously, a TV as a portal client ? (
) ... how ? why ? what context ? -
@Gertjan said in Different rate limits based on login ?:
a TV as a portal client ? ( ) ... how ? why ? what context ?
People show up with their home with them. In a RV park it is not impossible for a Motorhome or 5th wheel to show up with an Echo, Robot Vacuum, Doorbell and at least 2 TVs, printer, scanner, zoom workstation, solar/car charging controller and remote monitoring cameras as well. To avoid the login, either they show up with a travel router, you rent them one or you provide a custom solution, (pfSense + OpenWRT for eg). They stay anywhere from a day to all season (5-6 Months). They can need 30-50 Mbps each so the park needs the bandwidth to support them as well. pfSense plays a critical role in getting the solution started.
-
@EDaleH said in Different rate limits based on login ?:
People show up with their home with them. In a RV park it is not impossible for a Motorhome or 5th wheel to show up with an Echo, Robot Vacuum, Doorbell and at least 2 TVs, printer, scanner, zoom workstation, solar/car charging controller and remote monitoring cameras as well.
Thanks for the reminder. You're right, people can live on wheels.
You mentioned quiet a list of equipment but didn't you miss the most important one ?
(They can't afford a) Starlink disk ?!
All this equipment and they leave 'home' without a connection to actually use it .... serious ?
Also, portal wifi indoors, ok. Never thought about the fact that my 'colleagues', camping owners, now need to set up water tight outdoor Wifi access points so camping clients can connect their stuff.
The same camping owner that complains because he has these huge and ugly 4G/5G antennas all around his place ... -
@Gertjan said in Different rate limits based on login ?:
(They can't afford a) Starlink disk ?!
They can't afford the cost of the bandwidth they use. We have accounts with 1 TB/mo limits. If an RV park makes an investment in infrastructure for their "seasonal clients", they often prevent the installation of Satellite dishes for cosmetic, lawn maintenance or revenue reasons. Seasonal would be fixed inventory that could be called a cottage because they stay from season to season. Those "transient" who stay for shorter periods do show up with Starlink but may still want to access cheaper or more bandwidth. RV parks are remote and often in heavily treed areas so dishes and phones can be unreliable. No one wants the Starlink dish placed in the middle of the access road and shaded, treed sites are the most popular. Good WiFi can make or break an RV Park's success.
