Captive Portal pass through for all possible users
-
Hi!
Is there any way to setup the Captive Portal so that it does not stop any traffic from newly connected devices but will still present them with a web page if they open a browser? We have publicly accessible wifi, so we need to present a legal agreement, however for a number of reasons we have to allow traffic through from the moment a client connects. This is mostly due to the fact that we cannot get the portal to appear on Apple devices consistently, but that's an aside. Bottom line, a client connects, traffic is allowed through and the user is presented with the Captive Portal, which the user does NOT have to respond to in order to reach the internet. Could anyone kindly offer suggestions?
-
This is mostly due to the fact that we cannot get the portal to appear on Apple devices consistently, but that's an aside.
~~Enter these hosts in your Allowed Hosts from your CP to fix this problem.
captive.apple.com
www.airport.us
www.ibook.info
www.thinkdifferent.us
www.appleiphonecell.com
www.itools.info~~ -
Not passing those sites is key to getting the portal page to automatically appear when an Apple device connects.
-
Hmm i couldnt get a aApple device to work unless i entered those. But i dont own a Apple device so only tried it once.
-
The key to getting the portal page to appear automatically on Apple devices is to have the URLs it automatically checks NOT return the word "Success." This means not passing them through. Passing them will result in the device thinking it has internet and not bringing up the mini-browser automatically. It will then be incumbent for the user to start a browser and browse to a non-https site to get the portal page.
My main problem with Apple devices is they give up too quickly and disassociate with the wireless network thinking there's no internet there. This is particularly true if there is another network available that the device knows about. Sometimes people want to gather too much useless information on the portal page and they get timed out entering it.
Most "portal page not appearing" problems are:
-
DNS not working through the portal before authentication (Need pass-through to DNS servers)
-
Static DNS servers in the client (same result as #1)
-
Trying to initially browse to an https site.
-
-
Regarding the Apple devices–the key was the lack of consistency. Not every apple device (even if they were the same model and the same OS version) would automatically pull up the portal page once connected and and attempt to connect to the internet was made. Some apps automatically pulled it sometimes, others never, and only sometimes it would appear if we tried browsing. We did packet captures, had iOS developers look at it, tried a number of Allowed Hosts configs. In the end, Apple's doing some nonsense under the hood and we cannot work with it.
Unless someone can say they've had actual success with this, we have to change the captive portal to allow traffic regardless of whether a device has authenticated (or simply click "Continue") or not. Has anyone any insight?
-
It will then be incumbent for the user to start a browser and browse to a non-https site to get the portal page.
This is actually the very reality we have to overcome. Given the nature and function of our wifi deployment we are unable to leave it up to the user to open a browser. Everything has to be automated, or at least obvious enough that an iPhone toting grandma can handle it. Alas, I'm afraid that Derelict has shown us that we've no choice but to allow users to reach the internet without going through the captive portal first. If only there was a way to bring up the captive portal on their devices without requiring they click "continue"/"accept".
-
….. Everything has to be automated, or at least obvious enough that an iPhone toting grandma can handle it. Alas, I'm afraid that Derelict has shown us that we've no choice but to allow users to reach the internet without going through the captive portal first. If only there was a way to bring up the captive portal on their devices without requiring they click "continue"/"accept".
I have some good news for you.
For some reason that I can't explain, about half of these connections http://www.test-domaine.fr/munin/brit-hotel-fumel.net/pfsense.brit-hotel-fumel.net/portalusers.html (real time info) are Apple devices. You're looking at the stats of your pfSense captive portal.
Apple devices makes 'login' as easy one can make it. My grandmother NEVER asked me how to handle our portal. She was online without reading a notice - or asking someone about it. Read again: I'm not joking. Ok, true, I gave her the password.Apple devices will 'poll' (doing a simple http request) to one of the sites that EMWEE listed (more may exist) as soon as the wifi link (= radio link) is established (from Apple device to AP).
The answer should be: "Success" which means: the AP has an Internet connection.
Of course, our portal will NOT reply with "Success", it shows our Portal login page.
Apple devices (btw: Microsoft is doing the same thing) will launch in that case a special version of the included browser (called something like 'SNA') without user intervention needed.
Our portal login page shows up ….So, again, simply connecting to a pfSense portal with a iDevice WILL present the user with a login screen.
If this is NOT your case, you have a pfSense portal setup problem.
Most of my client that present themselves at our reception (hotel) with question related to the "Internet-Wifi" access are ANDROID users - but this is rare. We are in 2015, nearly everbody knows what a 'portal' is these days.
Note: my pfSense portal is situated in a hotel, in France, where things are always different as elsewhere …
What will not work: connecting to the Wifi portal (by selecting one of the Portal SSID's), closing the 'NSA browser that pops up 'because that not what you want' - and opening your Facbook app.
That won't work. The Facebook app (or gmail mail client, or whatever app that uses the net as a non browser) will not show the login page. The connection will not be opened. -
It works every time for me. I never hear about problems with iOS devices getting served the portal page unless it's one of the above problems. We see hundreds or thousands of different devices every week. All go through pfSense's captive portal.
-
Thanks for input Gertjan! Unfortunately, what you described is only largely the case. About 10-15% of the time Apple devices simply don't get the portal after connecting, even after opening an app that begins making requests. iPod Touches actually have this issue at a higher percentage than the iPhones, and these rates are consistent across versions of iOS. Further, our Portal setup is very basic–-Portal: On, Authentication: No, the subnet for the WAPs are in allowed IPs and there's a fistful of devices in Pass Through, but that's it.
What's interesting is that Android devices do not have these issues, nor do Windows devices. There are SOME devices that get 3-4 different IPs from DHCP over the course of a day, but I'm doubtful this has anything to do with what's causing these Apple devices getting the portal. It is strictly Apple devices that are not receiving the Captive Portal, and frustratingly it is only SOME of the time.
-
There are SOME devices that get 3-4 different IPs from DHCP over the course of a day, but I'm doubtful this has anything to do with what's causing these Apple devices getting the portal.
IP/MAC pairs changing before the captive portal times out can completely break things. Your lease expiration time MUST be greater than your portal hard timeout. Your DHCP pool MUST be big enough so that devices get the same IP address through the course of their stay. Mine is a /19. Doesn't mean that I have that many devices on the network at once, but it gives me a few days before expired leases get used again.
-
About 10-15% of the time Apple devices simply don't get the portal after connecting, even after opening an app that begins making requests.
It MUST be a web browser. As has already been stated, if you don't log into the portal and start another app, it's just going to hang and time out.
Captive portals break the internet until whatever login method is done. That's just a simple fact. I would say 99.9 percent of the calls the help desk takes is because the default page they try to load is a secure site and no portal page appears.
Presenting the portal web page upon connection to the network is 100% the responsibility of the device in question. All we can do is be sure these devices have everything they need to make their decisions.
An RFC standard would also probably help instead of this MITM BS.
-
Derelict, thank you, and understood. I pretty much sure that was going to be the case.
That leaves us in a pickle. We have to let traffic through without being stopped at the portal and still somehow send users the portal agreement. Any thoughts on achieving this?
-
If I understand correctly, you will have to modify the default ipfw rules in /etc/inc/captiveportal.inc to pass all traffic except port 80, then only connections attempted to port 80 will be forwarded to the portal.
There is no way to achieve what you want with the stock portal.
-
I can live with that. Nothing good ever comes easily. Thanks, Derelict!
