Captive Portal Bandwidth issue
-
@Gertjan said in Captive Portal Bandwidth issue:
@bishoptf said in Captive Portal Bandwidth issue:
for terms and conditions and then we record the mac address and from then on they are automatically authenticated
.... and the next time they drop by, their device, as they all do these days, generates a new random MAC address ... which will get stored also in portal.
Steady but slowly your portal will be brought to its knees because the MAC list will grow, and grow ....It s a church, right ? people don't stay for hours, what about the plain and easy, and no hassle and no maintenance, classic login, maybe without a password, just an OK button.
Not sure I understand why it should matter, why if I am not using limiters would it cause a performance issue. I think its a bug myself since I do not think just having mac addresses should be causing a performance issue. I do not have a password, the only difference is I record the mac address today so they only have to do it once. I know on my phone i've never been prompted again.
-
I connected my desktop PC to my main captive portal switch, this time it was 1 Gbit/sec switch.
I logged in, I'm using radius to login in, I guess that doesn't matter, there are no user or speed restrictions that I know of.
which is my ISP speed right now.
-
@Gertjan said in Captive Portal Bandwidth issue:
I connected my desktop PC to my main captive portal switch, this time it was 1 Gbit/sec switch.
I logged in, I'm using radius to login in, I guess that doesn't matter, there are no user or speed restrictions that I know of.
which is my ISP speed right now.
Understand that its working for you but I am not using radius and not sure if that changes the behavior but it's not wiorking for me, or reduced bandwidth/performance issues. I am going to recreate the zone etc and do more testing and see if I can figure it out...
-
@bishoptf said in Captive Portal Bandwidth issue:
Understand that its working for you but I am not using radius
I've switched to the default pfSense user manager mode, where I also have all the allowed users that can login on the portal.
Didn't make any difference. -
@Gertjan said in Captive Portal Bandwidth issue:
@bishoptf said in Captive Portal Bandwidth issue:
Understand that its working for you but I am not using radius
I've switched to the default pfSense user manager mode, where I also have all the allowed users that can login on the portal.
Didn't make any difference.I believe its the high number of approved mac addresses, I see other users having issues when modifying the cpzone with a high number of addresses and I see that also. I am going to remove most of the ones I have and see how that reacts. I know not having it on at all solves the issue, but maybe I will not add any mach address but just put an 24hr hard timeout and I assume those addresses will be cleaned up after the timeout expires, correct? Not sure what else to try, I have deleted the zone and added it back although with a different name and see the same issue. All I need is for the users to see the terms and conditions and then have access.
-
@bishoptf said in Captive Portal Bandwidth issue:
but just put an 24hr hard timeout and I assume those addresses will be cleaned up after the timeout expires, correct?
You use this option, right ? :
IMHO : don't do that, as MACs will get added, but nothing has been put in place to auto remove them. The MAC list will grow indefinitely, which obliges you to check upon this list regularly. Because no details are added like : "when the MAC" was added, you won't know what to delete, and what to leave in place.
IMHO (again) : this option should only be used when you know all the devices that use your portal. Awkward situation, because for these devices you wouldn't need a portal in the first place.
Btw : I've added 500 more random MAC addresses to my captive portal MAC list, now I have 1000 of them :
the portal didn't become any slower .....
-
@Gertjan said in Captive Portal Bandwidth issue:
@bishoptf said in Captive Portal Bandwidth issue:
but just put an 24hr hard timeout and I assume those addresses will be cleaned up after the timeout expires, correct?
You use this option, right ? :
IMHO : don't do that, as MACs will get added, but nothing has been put in place to auto remove them. The MAC list will grow indefinitely, which obliges you to check upon this list regularly. Because no details are added like : "when the MAC" was added, you won't know what to delete, and what to leave in place.
IMHO (again) : this option should only be used when you know all the devices that use your portal. Awkward situation, because for these devices you wouldn't need a portal in the first place.
Btw : I've added 500 more random MAC addresses to my captive portal MAC list, now I have 1000 of them :
the portal didn't become any slower .....
Yeah Again not sure what is different but mine is slow, going to remove most of the addresses and do some testing this morning and see how it performs. Every use case is different, this is for a church most of the same folks are there every week and the idea was this way they only add to go through the portal page once and then not have to bother with it. If I turn that off they will have to get the portal page open every time they are up there and re-directing doesn't always work that well. But not sure why I am seeing the performance issues but its pretty clear that I am, turn it off and it works, turn it on and performance is low.
-
@bishoptf said in Captive Portal Bandwidth issue:
will have to get the portal page open every time they are up
That's, afaik, ones a week, right ?
Hospital, Hotel, Mc Donalds or the local library : when you enter, you use their captive portal, and you to do some thing (filling out a forum on the screen, the login screen).
I'm using the (pfSense) captive portal for more the a decade in a hotel.
Works great.
It's very rare these days I have to assist some one with the connection.
Even the old / stupid and ignorant ones connects with the info we show in the room.True, there are still some devices that "can't connect". These are mostly the the very old devices, or their owners are way over the edge about security - the toc-tic educated ones, for example.
"they don't like unknown [wifi]network !".
Me : Ok..... then why do you want to use my hotel - for you unknown - network then ???
So, filling a form on a screen (they bought a smartphone, right ??) won't be that hard for them, they have seen worse.
And sorry, I have to say/ask it : going to a church and connecting your phone ?
The connection with the guy up there doesn't need any wifi as far as I know.
And have your phone going of during a burial is good enough to get yourself shot .... They've burned people (same church btw) for far less. -
@Gertjan said in Captive Portal Bandwidth issue:
@bishoptf said in Captive Portal Bandwidth issue:
will have to get the portal page open every time they are up
That's, afaik, ones a week, right ?
Hospital, Hotel, Mc Donalds or the local library : when you enter, you use their captive portal, and you to do some thing (filling out a forum on the screen, the login screen).
I'm using the (pfSense) captive portal for more the a decade in a hotel.
Works great.
It's very rare these days I have to assist some one with the connection.
Even the old / stupid and ignorant ones connects with the info we show in the room.True, there are still some devices that "can't connect". These are mostly the the very old devices, or their owners are way over the edge about security - the toc-tic educated ones, for example.
"they don't like unknown [wifi]network !".
Me : Ok..... then why do you want to use my hotel - for you unknown - network then ???
So, filling a form on a screen (they bought a smartphone, right ??) won't be that hard for them, they have seen worse.
And sorry, I have to say/ask it : going to a church and connecting your phone ?
The connection with the guy up there doesn't need any wifi as far as I know.
And have your phone going of during a burial is good enough to get yourself shot .... They've burned people (same church btw) for far less.More testing yesterday with the smaller list and as I expected it performed fine. I can only assume that maybe the combination of my hardware and the large number of mac addresses causes the issue. Going to try a 12 hour usage window and see how that works. I think most modern devices see that there is a sign in but some older devices even my linux laptop can be a pain getting the portal page to come up but will go with that for now. The other option is to just run an open network without the portal and no terms and conditions, lot of mixed opinions out there if its really needed but I'm not a lawyer so I will continue to try to use the portal and so I can display Terms and conditions.
-
@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.
