[solved] (no real problem) Login Page not Working on Smartphones only
-
rfc7710:
DHCPv4 Option 160
DHCPv6 Option 103(as URI Encoded String)
should announce captive Portal URL but it seems android and IOS do not support this option yet or again only in OPEN networks
giving up now. switching to password based 802.11X and let my users sign a paper version of the "terms of use". welcome back to 1990
-
Issue found:
IOS and Android are doing Captive Portal Checks only on OPEN Wifi Networks. (Android checkshttp://connectivitycheck.gstatic.com/generate_204)
unexpected behaviour … so what to do now? I dont want an open wifi where firesheep works ;)
What a bullshit... open Wifi is no Option!!!Good news.
Your are not well informed ;DI'm using pfSense for many years now in a hotel.
I tell nothing about "how to operate it" to my clients and they all connect just fine, using whatever exists …. I can tell you for sure that the fact they use Windows 98 XP 7 8 10 or some Server - ALL Apple devices and most (if recent) Android things. Important to know is that most clients are not "computer or network" experts ...
"It just works".
And it better should work, otherwise they leave the place - my place, and that costs me $/€.Here is why : because all OS's are "Hot-spot - portal -aware" these days. It's as simple as that. And that takes care of the info you showed above : your source is plain wrong.
The exact how and why it works - has being discussed on this forum so many times that I'm not going to explain again why it works.
The most important part has been said just above.Example : when I select on my iPhone my hotel's "Client Wifi Portal Network", it spins around a second or two, and then .... it opens the login page !! With no interaction from me !! I enter the login ID's (room number and a password, the client can find it in his room) and go => he is on the net (this is a real time graph, undated every 5 minutes).
Btw : you don't need option like :
DHCPv4 Option 160
DHCPv6 Option 103otherwise you have found that info already on the pfSense Captive portal Help pages.
Read again de debug pages (stated above twice) - and list for yourself the ipfw firewall rules used by your Captive portal - "decode" them (yep, you will have to take some time to actually read them up until the moment that you understood them, not thinking you understood them, and you will then understand how a simple a http (NOT https) request IS redirected to the build in web server (in pfSEnse) that hosts and shows the login page.
When this page is posted back with valid credentials, the IP and MAC of the visiting device is put into the same ipfw, as a rule (in a table, actually) and stays there until soft or hard time out - or logout if you activated that (and the clients logs out, something that actually never works because no one accepts popups in their browsers these days).Btw : the AP(s) should have it's DHCP server shut down - router mode shut down - even shut down Wifi encoding like WPS or whatever (if not, people need yet another password). The pfSense DHCP server should distribute IP's the DNS (normally this would be the IP of pfSense - Gateway (== pfSense also)
You decided to go off the road, and try the non default Forwarder. This means that pfSEnse is not resolving anymore : just check that the IP's of your DNS's are listed in the rules of ipfw ** otherwise it won't work : NO DNS means => problems.** I guess so, otherwise the Forwarder could NOT be used with the captive portal. You understood already the the ipfw rules are build en maintained by pfSEnse only, and you can not easily modify them. Understand also that the firewall rules present in the GUI for the captive portal is NOT using ipfw, but another firewall present in FreeBSD, the rules in the GUI are 'used' when the client / visitor is authenticated.
This is btw yet another damd good reason to use the default ( !!) DNS Resolver and not the DNS Forwarder - the latter is often not well understood and thus very error prone in "wrong hands". See the DNS forum for some good examples about how thing's should NOT being done ….ipfw : also see https://forum.pfsense.org/index.php?topic=112936.msg769881#msg769881 for new ipfw syntax.
-
Let me guess you dont use a WPA2 Password in your Hotel Network like everywhere else.
Its a repeatable behaviour:
OPEN Wifi Network - Everythink works perfectly and the login page opens automatically or there is a message to open the page
WPA2 Secured Network - Nothing is happening. And sometimes The devices just dont use it because "there is no internet connection" on Android you get a message like this "no internet connection. do you want to stay at this network or change to another"
Maybe i should do i wireshark testing to see whats really happening.
Just setting the wifi network to open without password at the accesspoint completely changes this behaviour.
i tested with 2 Android devices (Android 6.1 and 7) and 1 Iphones and 1 IpadDNS: I dont use resolver because there is a domain with DNS Server in the LAN Network with about ~2000 static(?) and ~150 mobile devices, 3 VPN Networks to connect branches and Clients. pfsense not resolving and just forwarding is wanted behavior and again: DNS is working just fine, i can do fully qualified lookups when connected to wifi without authenticated to Portal.
btw: for the client there is no difference in Resolver and Forwarder. Its Just resolve at pfsense or resolve at other host.
I have a working Captive Portal Setup for Guests with voucher and what i want now is a secondary Captive Portal for employes private devices. Only difference in configuration: WPA2 Passphrase instead of OPEN without passwordBut i have a testing setup (old minimal hardware but still working) and will do a "default config" Test
-
Let me guess you dont use a WPA2 Password in your Hotel Network like everywhere else.
Noop.
Because I asked myself : what flows "readable" through the air ?
Pretty much nothing these days. Everything is SSL these days except for some old, non maintained sites.
So, encoding WPA2 above SSL …. why complicate my visitors with double authentification ?
Most, if not all public hot spots do not use encrypted Wifi these days. They will hit the portal.
Example : when you visit McDonalds, is it WPA encrypted ? Of course not.But : when I enable WPA2 (or whatever auth scheme) my portal still works.
OPEN Wifi Network - Everythink works perfectly and the login page opens automatically or there is a message to open the page
WPA2 Secured Network - Nothing is happening. And sometimes The devices just dont use it because "there is no internet connection" on Android you get a message like this "no internet connection. do you want to stay at this network or change to another"
Maybe i should do i wireshark testing to see whats really happening.
Look to me right now that your problem is more situated between AP and the visiting device.
This WPA2 thing has nothing to do with pfSense. I presume your AP isn't integrated into the pfSense box.DNS: I dont use resolver because there is a domain with DNS Server in the LAN Network with about ~2000 static(?) and ~150 mobile devices, 3 VPN Networks to connect branches and Clients. pfsense not resolving and just forwarding is wanted behavior and again: DNS is working just fine, i can do fully qualified lookups when connected to wifi without authenticated to Portal.
Good.
Wanted you to know that that is an important thing.btw: for the client there is no difference in Resolver and Forwarder. Its Just resolve at pfsense or resolve at other host.
For basic internet surfing : correct. The forwarder even has it merits probably.
-
just an FYI.. Captive portal works okay for me on smartphones and using WPA2. I had a similar problem in the past, but was related to DNS. Once I pointed the DNS to the pfsense box ( instead of using another DNS ) it started working fine..
-
@dboe732
thanks for your information
DNS is Pointed to pfsense IP Address on the related OPT interface, but resolving is located on Windows Domain DNS that is configured to use Provider's DNS Service and OpenDNS as fallback.actually im testing dns resolver instead of forwarder but there seems to be some problems with openvpn and LAN fqdn.
meantime i did a PEAP Setup (Windows NPS) to use username / password for fallback if time runs out ;)
@Gertjan
Yes and thats a sad thing. i would never use a open wifi without VPN and even less with company hardware. Thats why we use an "always on" openvpn on our notebooks. there are so much things to gamble with.
You wont believe what information i gathered in open networks with 1-5 klick tools.
independent of this i just dont want a "everybody can use it" Network in "my" companyback to topic:
i think i have a spare AP somewhere. i dont believe that the issue is located there but i can do some tests.
dboe732 says he has a working setup so there must be something wrong with my settings although its working on most clientsi think tomorrow i will have the time to do a fresh install with just WAN and Captive Portal Interface.
-
…
independent of this i just dont want a "everybody can use it" Network in "my" companyI understand.
But my company (a hotel) all trusted devices (our own stuff) are all wired without exception. Never ever my company LAN will flies over a radio connection, not even WPA2.
The captive portal is for non trusted devices, they can not even communicate with each other (AP isolation and every visitors is restricted to communicate with the gateway (== pfsense) only).
So, my clients can only visit the "net" with my connection portal connection, as this is intended usage of the captive portal in the first place.
I presume that they (my hotel clients) will use a SSL connection when they connect to their Gmail, facebook, their bank, or whatever handles their private info.Btw : when I activated the WPA2 on my AP's, everything still worked fine. Had to enter the password ones, of course.
-
Company devices authenticate with PEAP and a Certificate. We just need mobile devices like tablets for our repair group, wireless barcode scanners for warehouse management.
–---------------------
Today i made the Update to 2.3.4_1 and i cant believe it, i dont want to believe it, but now it works with the same setup than before. Except on one Android 4.2 Tablet where i had to browse manually to the portal page, but i dont care about one old OS.
i guess sometimes if there is a problem you have to do a reboot, although highly unlikely on pfsense. until today i had at most to restart third party packages like squid
thank you very much for your support.
-
… wireless barcode scanners for warehouse management.
… and thes etrusted devices also have to hit also a login page - captive portal ?
Today i made the Update to 2.3.4_1 and i cant believe it, i dont want to believe it, but now it works with the same setup than before. Except on one Android 4.2 Tablet where i had to browse manually to the portal page, but i dont care about one old OS.
Keep in mind : things can go even better : what about the latest stable version 2.3.5 ? ;)
Btw 2.3.4_1 di not existed very long time, some nasty bugs security pushed it to _2 (using my memory, it's already old stuff now) -
thanks again
thats what the webinterface showed for updating.
tomorrow i will go further up until latest stable… users dont like internet downtime ;)--
no, entrusted devices use peap without captive portal. The new captive Portal site is for private devices. its a "present" from the Management
