pfSense English Support > Captive Portal

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

(1/3) > >>

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

Navigation

[0] Message Index

[#] Next page

Go to full version