upstream sent too big header while reading response header from upstream
-
Good day. A group of messages like the screenshot below kept on appearing in the logs. The captive portal's FQDN kept repeating in the first entry, and an SSL error message appeared in the remaining entries that are six lines in this example but range from 4 to 7 lines in the logs. Do I need to change a setting or is this a normal logging that can be safely ignored?
-
@richardsago
The SSL errors : you have https access set up ? Normally, you have to, as most browsers prefer it by far.The redirect error : I'm not sure.
The web pfSense captive portal server redirect a hidden 'Phone/PC/Tablet' http request to something like http://your-pfsense-portal-IP/index.php?zone=guestnetwork&redirurl http://........ and the web browser doesn't follow the rdirection but hits the web server again with the same URL, and this start to spin around up until the "header request" to the web server becomes to big, it logs a failure.I'm using the captive portal for more then a decade now, and haven't seen this issue for a very long time.
Try this : locate the device that produces this error, and 'delete' or 'forget' the pfSense Wifi SSID.
Show your portal settings ?
-
Thank you @Gertjan for the reply. I suspected it was the captive portal's warning that many devices are connecting to its Open unsecured WiFi without a valid voucher code. Because at that time there were a lot of devices that are connected to that WiFi without a valid voucher code. The group of messages that I reported no longer appears in the logs, although now there are still a lot of devices (without voucher code) connected to the Open unsecured WiFi of the captive portal.
The captive portal's DHCP lease time is 20 days:
Here is the captive portal setup:
Captive Portal > Configuration. Timeouts is 10 days:
Did not use Captive Portal > MACs, Allowed IP Addresses, Allowed Hostnames, High Availability
Uploaded the logo in Captive Portal > File Manager
Captive Portal > Vouchers
-
@richardsago said in upstream sent too big header while reading response header from upstream:
The group of messages that I reported no longer appears in the logs, although now there are still a lot of devices (without voucher code) connected to the Open unsecured WiFi of the captive portal.
That's 20 days, imho way to long.
You might do that for cabled/wired devices connected to a portal. Not sure if such a setup actually exists IRL.
Portal device by nature are nearly always wireless.
Wireless connection never stay 'up' for long time, because radio signals ... that's a mess. You can 'see' them so you think they are working. They don't, it breaks (gets interfered) all the time. Because people don't stay in place, new radio waves start coming, others go away.
Every time a radio connection goes bad, a new channel is opened, this produces a link up event, and thus : a new DHCP request.If you have many devices on a network like a captive portal, a DHCP request with a given MAC will 'block' a lease with that MAC for a given time (20 days). Keep an eye on the DHCP pool size, and the number of free leases (non allocated IPs).
You have 'a lot of users and don't use https ?? That must be a frustrating experience for your portal users....
Try this : give them a known web site, like your own web site, or some search engine , like "https://www/google.com" or any other well known web site. When people see it, they know they are connected.
This will help the 'stupid' devices who forgot that they were redirected to the login page, not to redirect back to the login page, the issue you've shown above.Custom portal : Ok, that fine. Just remember : if issues, get the 'official' Netgate portal back, so you can be sure if an issue is, or is not, related to your own portal.
I'm using my own also. Zero issues with it.
Aha ! So you do use https access. That's good
@richardsago said in upstream sent too big header while reading response header from upstream:
captive portal's warning that many devices are connecting to its Open unsecured WiFi without a valid voucher code.
For sure devices that keep on hammering the captive portal, the login page.
Not even their users, but the device itself that lost track between the 'connected' state, and not connected.
With connected I mean : having access to a gateway, dns etc etc, not the wifi state. A captive portal is a proof that a device has a wifi up, but can't do anything, as the device (user !) has to login first before anything works.
Some devices (the not expensive ones have not expensive OS"s ^^) are bad in detecting the state the 'connection'.
So they keep on hammering .... not really your issue.Btw : Look for "rfc8910" in this forum. You'll find a new way of captive portal interaction, and it works in parallel with the existing pfSense portal implementation. This means if rfc8910 doesn't work, the original pfSense portal access method will work. No files to edit, just a setting ot two, and a file.
I'm using it for tow years or so, works perfect, and is way faster.The idea : when a device connects to the network, the very first thing it does is : asking for a DHCP lease.
So the DHCP (pfSense) server can give info to the device, like an IP, a DNS, a gateway, the lease time etc.
It could also give another DHCP 'option' where it informs the device that this is a captive portal network, and t gives the device the URL where it has to go for the login page.
This means the device knows straight away it's on a captive portal network.
Afaik, Apple and Microsoft and the recent other devices can use RFC8910. -
Thank you @Gertjan for the reply. I work for a school and the captive portal is for visitors like speakers and curriculum accreditors. The captive portal timeout used to be 12 hours but is now set to 10 days because this is slightly longer than their average duration of stay, so that they won't need to type-in their voucher code again while they're here.
Thank you for offering rfc8910 but I will wait until it's part of pfsense, to increase my chances of success.
-
Get your phone, show the 'properties' of your Portal SSID.
You find probably something like (my iphone) :
Wifi address : : Renewable (= default) - and you can select among Renewable, Fixed or No.
What happens is that the phone will rotate it's Wifi MAC : it changes the MAC 'all the time'.
Now get back to DHCP : how does the what devices needs what Lease (IP) ? It recognized a device that comes back, with it's MAC address.
The same MAC address that changes all the time ...
Fast solution : ask all portal visitors to change their Wifi SSID settings, so that their device keeps the same MAC for your your SSID. Will they do that ? No way, as they probably don't understand what you're asking.
So, you are set and ready for a DHCP pool saturation : ones a lease is given; it will stay for 10 days in the pool as 'IP x.x.x.x is reserved for device aa:bb:cc:dd:ee" but that "aa:bb:cc:dd:ee" will presents itself to the portal after a while with "ee:dd:cc:bb:aa", so the DHCP server doesn't recognize it, will give it another lease (-IP) and of course they eran the right to see the login portal once again, because they have to type the voucher code ones more. Totally ok, as the pfSense captive portal did not recognize the device.
And keep in mind on mind the DHCP server lease pool fills up ... with leases that are never reused again.
That's why the golden rule exists : DHCP leases, wherever you use them, make them like 12 hours max.
Time out - hard or soft : daily = 24 hours, but between 6 and 12 hours is better, typically smaller then the DHCP lease duration.When you start to think now : wait : "these voucher codes, it's actually not that great ?!" then your right. Visitors have to identify a lot, and it's even their own fault : their MAC is rotating, so not recognized by the portal when that happened.
You could consider activating this one :
it wouldn't even help you, as ... here we go again : "the mac can change ...".
And now you have to clean up regularly the authorized MAC list (portal settings).Btw : what I hope that you make of all this : offering a captiveportal has no perfect solution. There are advantages and drawbacks for every solution you propose.
For myself, as I have a hotel with a captive portal, where people tend to arrive in the evening, and leave in the morning, they have to use the room number as a user login, and the password is shown in the room (and it's the same for everybody, please don't tell anybody ^^)
No more voucher management for me, 98+ % of the client don't have any portal issues.
If a client stays several days, they have to login when they come back in the hotel. Not really annoying for them as they forgot to select the SSID as auto connect, so they have to do it manually anyway. My captive portal login page pops up very fast so the 'remember' that they have to enter their room number and the secret password.
This works well for more then a decade now. -
Thank you @Gertjan for the usual helpful information. Visitors kept on misplacing the voucher code printouts and so I thought to increase the DHCP pool, DHCP lease time, and captive portal timeouts so that they only need to type in the voucher code once and they don't need to remember to keep the voucher printout. I suspected the upstream error message happened because the captive portal DHCP leases are high. There were only 13 visitors who used captive portal starting when it was activated last month but the DHCP leases are high and many in the DHCP lease device description matches my other VLAN users (Faculty, Staff, Students). The last visitor left yesterday and this is the DHCP active leases now:
This is the show all DHCP leases:
Privacy Policy · Cookie Policy