[solved] (no real problem) Login Page not Working on Smartphones only

Hanswerner

Hello,

I have two captive portal setup on a dedicated nics with untagged vlans on the switch side for guests and employes using wifi.
one portal is using vouchers and the other username / password.

Everything is working as expected except on mobile devices like IOS / Android Smartphones or Tablets.

Windows and OSX Laptops Connect to wifi and mostly they get the message " there are additional login information needed". if there is no message like this they get redirected to the portal page if they try to use a website.
Portal Page: 192.168.1.1:8004/index.php?zone=zone1&rediurl=(…)

if i try this with android or ios nothing happens. (no difference in https or http)
If i type the address manually the portal page shows up and i can login and it works.

SO ... what can i do to get a "all device" portal page? (maybe even on https? there are not much pages without https anymore.)
i tried dhcp 160 without any result

Gertjan

Hi,

First : use the build in captive portal login, and change if when everything work.
Always read this : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting - most problems come from the fact that DNS doesn't work on the Captive portal interface.

The build in captive portal page is small, and when you look at the html you will understand that it doesn't care about what device is trying to show it. It works on every navigator, no matter it's size.

And when you understood what https actually is, you will understand that you can not intercept https://… traffic so the captive portal login page pops up first. Your browser will YELL - and will not let you do so.
I tell you a secret. EVERY OS on earth does something special when it's NIC gets connected : it send out a hidden "http" (not https) request and when it receives the page (status "200") the it knows it has a good connection to the net. If not, because perhaps a captive portal is present, it launches a browser (which the end-user can see !) and restarts the http request. Our captive portal (pfSense) send out the Captive portal login page !) and now the end user can enter its credentials. Upon success, pFsense captive portals adds firewall rules to let traffic from the end-users device go through, and now ... the connection is established.

Hanswerner

Hi,

same problem with default and changed. its not a matter of display the page its a matter of redirect to it. if i browse it manually it works even on Android and IOS. I dont care about the redirect url after login i just want to see the login page automatically when opening a browser. better if i get same message as on windows "there is a secondary login needed" -> klick -> page pops up and i can enter username and password (or voucher)

ah, all devices use the same Accespoint and the same VLAN (untagged on switch side)

DNS works with pfsense itself as DNS Server. DNS Forwarder is enabled. i can do lookups but no ping.
anything else to check here?

Its working on IE / Edge / Firefox / Chrome on OSX and Windows.

–-
https: there are plenty of captive portal sites that work with https (about 10 times a year i use them with a startpage https://google.com)
haproxy can reditrect https without any interception. i have a working setup in our DMZ. browsing https://mycompany.de/index.php redirects to internal
https://10.10.20.1/index.php
so i think its "just" a matter of implementation. point all dns requests to the Firewall IP until successfull login maybe
---> Not possible with pfsense.. i can live with that, because smartphones do a http connectivity check ;)

Hanswerner

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!!!

Hanswerner

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

Gertjan

@Hanswerner:

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 ;D

I'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 103

otherwise 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.

Hanswerner

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 Ipad

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.
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 password

But i have a testing setup (old minimal hardware but still working) and will do a "default config" Test

Gertjan

@Hanswerner:

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.

@Hanswerner:

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.

@Hanswerner:

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.

@Hanswerner:

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.

dboe732

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..

Hanswerner

@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" company

back 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 clients

i think tomorrow i will have the time to do a fresh install with just WAN and Captive Portal Interface.

Gertjan

@Hanswerner:

…
independent of this i just dont want a "everybody can use it" Network in "my" company

I 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.

Hanswerner

@Gertjan

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.

Gertjan

@Hanswerner:

… wireless barcode scanners for warehouse management.

… and thes etrusted devices also have to hit also a login page - captive portal ?

@Hanswerner:

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)

Hanswerner

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