Captive Portal redirect does not work for a few clients
-
Hello,
we have captive portal issues with a few (say 10 out of 300) clients both IOS and Android that do not load the portal page.
Packet Capture shows that HTTPS redirects do not work, but HTTP redirects do. For these clients, pfsense behaves as if "Disable HTTPS Forwards" were enabled, but of course, it is not. The majority of clients do work perfectly well also with HTTPS requests. All clients here share the same captive portal zone. The clients with the issue would also work well, if they initially request a HTTP site, but nowadays this is quite rare and the normal iphone user would not know how to do that.To make it more complicated, one client with the issue works one day well, and the other day not. Reboot of the client does not change a thing.
pfsense is a 2.6.0 as a cluster with prim and sec on VMWare ESXi. DHCP is not on the pfsense but on an external server. Client network is routed, no layer 2 connection between the clients and the pfsense.
Anyone of you have an idea?
best regards
-
First things first : you have this package installed, and activated the patches :
Btw : you might want to use 2.7.0-beta, is close to release.
@Rhicinus said in Captive Portal redirect does not work for a few clients:
For these clients, pfsense behaves as if "Disable HTTPS Forwards" were enabled
https can't be redirected any.
Captive portal support is actually not a pfSense, but a facility build in the client OS.
@Rhicinus said in Captive Portal redirect does not work for a few clients:
but HTTP redirects do
The captive portal is based upon the fact that http request can be redirceted.
A modern OS, like iOS, emits a http:// request as soon as the wireless interface comes up.Example (first log line below) :
iOS emits this request :
http://captive.apple.com/hotspot-detect.htm
and the result, the page that comes back should say : ..... I leave it up to you to discover ;)If it doesn't, the iOS presumes a captive portal is in play.
It restarts a severely stripped down instance of Safari (no cache, no cookies, no nothing) full screen, and request the same page again.
The answer won't be "Success", it will be (because the http was redirected to the captive portal web server) the pfSEnse captive login page.True : it happens to me ones in a while that my iPhone 'refuses' to connect.
Two reasons : I mess around with the portal severely, settings and 'code', just to test things out.
The other reason is : iOS also tries to use the more modern Apple proposed captive portal RFC (DHCP option based) and if it even 'thinks' that the portal is 'modern' then that wifi connection gets flagged as such.
The solution is always the same : Delete the wifi profile on the phone - it doesn't contain any user settings as a password (portal networks don't use password - they use a TLS connection to authentify against the portal web server, and from then on all connection are TLS anyway[ok, except DNS]) - and re connect.
It always works for me.
Consider this : get a new PC, or a new iPhone, it will work 'out of the box'. Whatever happens afterwards : ask the owner ^^@Rhicinus said in Captive Portal redirect does not work for a few clients:
Client network is routed, no layer 2 connection between the clients and the pfsense.
You mean pfSense can't see the MAC addresses of the connected captive portal users ?
@Rhicinus said in Captive Portal redirect does not work for a few clients:
Reboot of the client does not change a thing
Rebooting an iPhone ?
I thought that wasn't needed anymore since 2015 ?!@Rhicinus said in Captive Portal redirect does not work for a few clients:
DHCP is not on the pfsense but on an external server.
Not an issue as long as leases are distributed.
@Rhicinus said in Captive Portal redirect does not work for a few clients:
Anyone of you have an idea?
Yeah.
You didn't mention the most important criteria of a portal : DNS.
A connecting device should obtain an IP, network, gateway and DNS.
Then it throws out a hidden http request (see above) and for that to work, DNS should work.
Not some "8.8.8.8" DNS, as all non local DNS are not accessible at this moment. By default, the DNS will work on the pfSense portal interface.
Did you test that ?In the past, this page Troubleshooting Captive Portal was mandatory.
It still is, but these days it talk about the new firewall 'pf', as Netgate made 'pf' MAC aware.
2.6.0. uses ipfw, which was ditched after 2.6.0. -
Thank you very much for this detailed answer. I appreciated very much your explanation of the redirecting technique.
@Gertjan said in Captive Portal redirect does not work for a few clients:
First things first : you have this package installed, and activated the patches :
Btw : you might want to use 2.7.0-beta, is close to release.
This package indeed needs an update. Will do so this evening.
We won't use a beta version in this production environment. But we have a Dev cluster and will check this on that.
The solution is always the same : Delete the wifi profile on the phone - it doesn't contain any user settings as a password (portal networks don't use password - they use a TLS connection to authentify against the portal web server, and from then on all connection are TLS anyway[ok, except DNS]) - and re connect.
It always works for me.Yes, this also worked for our test client!
You mean pfSense can't see the MAC addresses of the connected captive portal users ?
Exactly
You didn't mention the most important criteria of a portal : DNS.
A connecting device should obtain an IP, network, gateway and DNS.
Then it throws out a hidden http request (see above) and for that to work, DNS should work.
Not some "8.8.8.8" DNS, as all non local DNS are not accessible at this moment. By default, the DNS will work on the pfSense portal interface.
Did you test that ?Yes, DNS works good on the inside interface of the pfsense, with host override for the portal page redirect.
In the past, this page Troubleshooting Captive Portal was mandatory.
It still is, but these days it talk about the new firewall 'pf', as Netgate made 'pf' MAC aware.
2.6.0. uses ipfw, which was ditched after 2.6.0.I am aware of this page, thank you. The problem is also with troubleshooting in the Prod environment. I cannot change some settings just to test if it works. There would be the risk to interrupt the connectivity of the 300-400 working clients. I have to do non-invasive things like packet capture and log examination.
If this issue remains or even spreads to more clients or the "Wifi forget" on the phone won't help anymore we would need to reproduce the setting in a testing environment.Again thank you
R.
