The captive portal does not redirect to the login page on IOS devices

susobaco

Re: Redirect all pages to Captive Portal login page until authenticated

I guess it has something to do with what's being said in this post. My particular problem is with IOS devices. Safari doesn't recognize that there's a captive portal, and I think when it starts, it only makes requests to https://, so it doesn't redirect. It's a real problem when there are enough users with this type of software, because you have to go one by one, making a request http:// to leave the captive portal. Cheers

Gertjan

Hi,

What a iOS does, is described here Redirect all pages to Captive Portal login page until authenticated.

As soon as the wifi connections comes up , check your pfSense logs !
You will find a request :
.... http://captive.apple.com/hotspot-detect.html ....

This http (not a https request !) is generated by the iOS (not a browser like safari or other browser).
If the returned text is not "Succes" the iOS knows it's probably behind a portal, and launches something that looks like Safari (but isn't Safari) - a minimal navigator. This navigator, visible to you on your iDevice, will repeat the request http://captive.apple.com/hotspot-detect.html. What happens is that this http request will be intercepted, and according to your Portal settings, redirected to a http or https web server, the one that shows the pfSense captive portal login page.

This works. I can connect just fine with all my Apple device, most of my clients (portal users) connect just fine without any manual interaction (they need to enter a user and password).
All I do is selecting the Wifi network on my apple device. The login page shows up right away.

After identification, all connected users are redirected to https://www.google.com - This is my choice, and make aware the portal visitor that his connection to the net is activated.

Your problem is not what you see what happens, the issue is : your settings.

susobaco

@gertjan said in The captive portal does not redirect to the login page on IOS devices:

As soon as the wifi connections comes up , check your pfSense logs !

Thank you for your response and forgiveness for my ignorance, I am new to this distribution. Can you tell me what particular logs I have to read? Thank you. When an appel device, after connecting to the wifi network, makes an http request, no problem, it exits the portal. The problem is when you make a https request. The rest of devices, android, pc windows, pc linux, do not have any problem

Gertjan

@susobaco said in The captive portal does not redirect to the login page on IOS devices:

Can you tell me what particular logs I have to read?

I use this option :

0_1545038359388_3b60c78a-2f03-4c1b-b6d2-d9d0e4abb259-image.png

This means all pfsense logs are sended to a (my) central syslog device.

This is my iPhone, obtaining an IP, and the Portal connections :

2018-12-17 09:18:31	Local7.Info	192.168.1.1	Dec 17 09:18:33 dhcpd: DHCPDISCOVER from 90:b9:31:77:5e:26 via sis0
2018-12-17 09:18:32	Local7.Info	192.168.1.1	Dec 17 09:18:34 dhcpd: DHCPOFFER on 192.168.2.9 to 90:b9:31:77:5e:26 (iPhone-5S-Gertjan) via sis0
2018-12-17 09:18:34	Local7.Info	192.168.1.1	Dec 17 09:18:35 dhcpd: DHCPREQUEST for 192.168.2.9 (192.168.2.1) from 90:b9:31:77:5e:26 (iPhone-5S-Gertjan) via sis0
2018-12-17 09:18:34	Local7.Info	192.168.1.1	Dec 17 09:18:35 dhcpd: DHCPACK on 192.168.2.9 to 90:b9:31:77:5e:26 (iPhone-5S-Gertjan) via sis0
2018-12-17 09:18:36	Local5.Info	192.168.1.1	Dec 17 09:18:37 pfsense.brit-hotel-fumel.net nginx: 192.168.2.9 - - [17/Dec/2018:09:18:37 +0100] "GET /hotspot-detect.html HTTP/1.0" 302 0 "-" "CaptiveNetworkSupport-355.200.27 wispr"
2018-12-17 09:18:36	Local5.Info	192.168.1.1	Dec 17 09:18:38 pfsense.brit-hotel-fumel.net nginx: 192.168.2.9 - - [17/Dec/2018:09:18:38 +0100] "GET /index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html HTTP/1.0" 200 1502 "-" "CaptiveNetworkSupport-355.200.27 wispr"
2018-12-17 09:18:40	Local5.Info	192.168.1.1	Dec 17 09:18:41 pfsense.brit-hotel-fumel.net nginx: 192.168.2.9 - - [17/Dec/2018:09:18:41 +0100] "GET /hotspot-detect.html HTTP/1.1" 302 5 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 12_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/16B92"
2018-12-17 09:18:40	Local5.Info	192.168.1.1	Dec 17 09:18:42 pfsense.brit-hotel-fumel.net nginx: 192.168.2.9 - - [17/Dec/2018:09:18:42 +0100] "GET /index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html HTTP/2.0" 200 824 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 12_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/16B92"
2018-12-17 09:18:41	Local5.Info	192.168.1.1	Dec 17 09:18:42 pfsense.brit-hotel-fumel.net nginx: 192.168.2.9 - - [17/Dec/2018:09:18:42 +0100] "GET /captiveportal-2style.css HTTP/2.0" 200 1083 "https://portal.brit-hotel-fumel.net:8003/index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html" "Mozilla/5.0 (iPhone; CPU iPhone OS 12_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/16B92"
2018-12-17 09:18:41	Local5.Info	192.168.1.1	Dec 17 09:18:42 pfsense.brit-hotel-fumel.net nginx: 192.168.2.9 - - [17/Dec/2018:09:18:42 +0100] "GET /captiveportal-nvx-logo.png HTTP/2.0" 200 6976 "https://portal.brit-hotel-fumel.net:8003/index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html" "Mozilla/5.0 (iPhone; CPU iPhone OS 12_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/16B92"
2018-12-17 09:18:41	Local5.Info	192.168.1.1	Dec 17 09:18:42 pfsense.brit-hotel-fumel.net nginx: 192.168.2.9 - - [17/Dec/2018:09:18:42 +0100] "GET /hotspot-detect.html HTTP/1.0" 302 0 "-" "CaptiveNetworkSupport-355.200.27 wispr"
2018-12-17 09:18:41	Local5.Info	192.168.1.1	Dec 17 09:18:43 pfsense.brit-hotel-fumel.net nginx: 192.168.2.9 - - [17/Dec/2018:09:18:43 +0100] "GET /index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html HTTP/1.0" 200 1502 "-" "CaptiveNetworkSupport-355.200.27 wispr"
2018-12-17 09:18:50	User.Notice	192.168.1.1	Dec 17 09:18:52 root: FreeRADIUS: User x has used 0 MB of 1024 MB daily allotted traffic. The login request was accepted.
2018-12-17 09:18:50	Local5.Info	192.168.1.1	Dec 17 09:18:52 pfsense.brit-hotel-fumel.net nginx: 192.168.2.9 - - [17/Dec/2018:09:18:52 +0100] "POST /index.php?zone=cpzone1 HTTP/2.0" 302 0 "https://portal.brit-hotel-fumel.net:8003/index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html" "Mozilla/5.0 (iPhone; CPU iPhone OS 12_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/16B92"

All this info isn't really needed normally, but it shows clearly how the entire process works.

@susobaco said in The captive portal does not redirect to the login page on IOS devices:

When an appel device, after connecting to the wifi network, makes an http request, no problem, it exits the portal ...

Sorry ?
As soon as an iDevice obtains an Ip (and Gateway !, and DNS !!) the Ethernet connection is up to the pfSense router/firewall.
The iDevice then throws out an http URL request : http://captive.apple.com/hotspot-detect.html
Becausean URL like http://captive.apple.com/hotspot-detect.html means nothing to our OS (any OS, actually); it will first resolve the domain and sub domain captive.apple.com. This implies that your DNS should work on your captive portal interface. As soon as you iDevice obtained an IP for captive.apple.com, it will send the URL over to the web server(apple's web server !) on port 80, with the path : /hotspot-detect.html.
It's this part that gets intercepted : the http request will get redirected to the web server hosted by pfSense. Etc etc..

To establish a connection, an iOS does NOT make an HTTPS request, because : by very nature, HTTPS can not be intercepted, and redirecting is very complicated.

The Apple device "logon procedure" is totally automated by our iDevice (iPhone, iPad, etc) without you doing nothing - there are no personal settings involved.

Consider this :
We both have the same iOS. (12 and something). No settings on an iPhone are needed to make it work.
pfSense : we both have the same version, the one that works :

2.4.4-RELEASE-p1 (amd64)
built on Mon Nov 26 11:40:26 EST 2018
FreeBSD 11.2-RELEASE-p4

The only thing that is different, is your Captive Portal, and other settings.
My settings work.
Yours don't.

So, tell us us your settings and we tell you what is wrong ^^

susobaco

I'm sure you're right and you're a problem with my configuration. I send some screenshots to see if you are so kind as to help me guess what I'm doing wrong. Thank you.

https://palautgn.duckdns.org/index.php/s/XE7rcwgQHkHtjWb

Gertjan

@susobaco said in The captive portal does not redirect to the login page on IOS devices:

I'm sure you're right and you're a problem with my configuration. I send some screenshots to see if you are so kind as to help me guess what I'm doing wrong. Thank you.

https://palautgn.duckdns.org/index.php/s/XE7rcwgQHkHtjWb

Instead of using the DNS Forwarder (and sell all your DNS requests to 8.8.8.8 and 8.8.4.4) use the default DNS Resolver.
The nice thing about that one is : it works without any chances in the 'default' setup.

Where are your Captive portal ( WIFI_PALAU ) settings ?

Non related questions :
Do you really need (65535 -2) DHCP leases for your portal ?

What is this :
0_1545049291679_adfaee8e-a8b0-4990-a67e-827b8e6bf0c3-image.png

What are your WIFI_PALAU Firewall settings ?

susobaco

I enclose the configuration of the captive portal and the firewall. Then, you propose to deactivate the DNS service Forwarded and activate the DNS resolve?
What you see there is a host override of the server in the gateway of the captive portal. I read in some forum that you had to do so to implement the https certificate on the server.
Actually I don't need so many, with about 1000 connections I have enough, it was more than anything a test.

https://palautgn.duckdns.org/index.php/s/XE7rcwgQHkHtjWb

Gertjan

@susobaco said in The captive portal does not redirect to the login page on IOS devices:

What you see there is a host override of the server in the gateway of the captive portal. I read in some forum that you had to do so to implement the https certificate on the server.

Correct.
You are using a domain locally that isn't yours ! "duckdns.org" isn't yours, right ? I don't know if that is wrong, but added to that you outsource all DNS requests (the Forwarder).
This combination seems highly 'not standard' to me, although can't test drive such a situation to confirm, or the other way around.

I'm using "my own" domain name, as you can see above, brit-hotel-fumel.net and added "portal" upfront to make the sub domain. This sub domain is a "host override so it point locally to my "Portal Interface".
Because I "own" and manage brit-hotel-fumel.net somewhere on a Debian bind (DNS) server, I set up setup acme so it renews this "portal. brit-hotel-fumel.net" certificate.

Your firewall : looks good to me.

Btw : this is mine :
0_1545072401881_dd84aece-cf68-4d5e-bba9-b354aa7873b4-image.png

LIne 1 : No outgoing mail on port "25" - that's over now. Identify (smtp on 597 or better : 465 or get lost).
Line 2 : My AP's can send over logs to my syslog server "poweredge" (on LAN) (true, should limit this to the syslog port ;) )
LIne 3 : AP's can go everywhere except LAN - thus they can go on the net (updates, ntp etc)
Line 4 : My portal net can ping the pfsense portal interface
Line 5 : Pure gadget : clients on the portal can see (connect to) my 3 printers (on LAN) - more smart client can print : free service if the client manages to print with his device
Line 6 : Disabled (part of an expermient to force visitors to use MY DNS (pfSEnse)
LIne 7 : Portal clients can access MY pfSense portal DNS.
Line 8 : Block all other DNS servers - any destination.
Line 9 : Block all other pfSense Portal ports
Line 10 : Block all NetBios stuff - any destination.
LIne 11 : Block all WAN address access.
Line 12 : Those who are still there, and don't want to go to my LAN? can pass (globally : all visitors/clients Internet traffic)

Maybe this list can be optimized - some rules have become useless. But : this list is the result of more then 10 years of portal usage in a hotel as stated : very "hostile" / clients/visitors : clients of a hotel.

susobaco

@gertjan said in The captive portal does not redirect to the login page on IOS devices:

Correct.
You are using a domain locally that isn't yours ! "duckdns.org" isn't yours, right ? I don't know if that is wrong, but added to that you outsource all DNS requests (the Forwarder).
This combination seems highly 'not standard' to me, although can't test drive such a situation to confirm, or the other way around.

The domain is signed by let's encrip. It is a ddns service domain "duckdns.org" is one of the acme options. Note that the machine name and the domain name match that of the certificate. I think I've already tried it, but I'll do what you tell me, use the dns resolver. I'll do some tests and I'll tell you.

Thank you

susobaco

Nothing, everything remains the same, I have activated the dns solver and deactivated the forwarded The devices ios, connect, but when they open safari and try to navigate https://gloogle.com does not redirect. if they navigate to http://captive.appel.com, then the captive portal leaves. With this configuration, some old android don't redirect well either. I reconnect the forwarded dns

Gertjan

@susobaco said in The captive portal does not redirect to the login page on IOS devices:

The devices ios, connect

To the Wifi, I presume.

@susobaco said in The captive portal does not redirect to the login page on IOS devices:

but when they open safari

Right after selecting the Wifi network, nothing happens for several seconds, but then a navigator will open automatically. This isn't Safari - but some build in navigator.

@susobaco said in The captive portal does not redirect to the login page on IOS devices:

https://gloogle.com

If you are not authenticated, an https will make you hit the wall. https (SSL) can not be intercepted, neither redirected.
Visiting http://www.google.com:80 would show the captive portal login screen.

edit :
No : visit http://captive.apple.com/hotspot-detect.html manually.
You should see
Success on the screen
If not, http can't pass, or, before that : DNS doesn't work.
What you could try :
Snif (packet capture) DNS traffic coming from your iDevice on your portal network.
You should see (UDP ?) packet passing by that resolve "captive.apple.com" - and the answer.

Sees also this : https://www.netgate.com/docs/pfsense/captiveportal/captive-portal-troubleshooting.html

ipfw table all list

looks good ?

susobaco

@gertjan
Hello, if an ios connects to the wifi, no window of any kind comes out.
If I navigate to the address, if it appears sucess.
The packets I captured are the following.

--- table(cp_ifaces), set(0) ---
em0 2100 116164 74882688 1545131838
--- table(wifi_palau_auth_up), set(0) ---
10.0.12.60/32 2016 204 32789 1545131837
--- table(wifi_palau_host_ips), set(0) ---
10.0.0.101/32 0 51537 42404307 1545131836
--- table(wifi_palau_pipe_mac), set(0) ---
--- table(wifi_palau_auth_down), set(0) ---
10.0.12.60/32 2017 292 197855 1545131838
--- table(wifi_palau_allowed_up), set(0) ---
10.0.0.0/24 2000 917 126624 1545131832
17.253.109.202/32 2012 4 1269 1545131309
17.253.109.203/32 2004 8 1180 1545131095
217.160.0.91/32 2002 7310 10766880 1545131548
2001:8d8:100f:f000::266/128 2002 0 0 0
--- table(wifi_palau_allowed_down), set(0) ---
10.0.0.0/24 2001 831 280458 1545131707
17.253.109.202/32 2013 7 2555 1545131312
17.253.109.203/32 2005 13 1586 1545131123
217.160.0.91/32 2003 2612 152545 1545131595
2001:8d8:100f:f000::266/128 2003 0 0 0

I'm going to read the tutorial well, to see what I can be doing wrong

Gertjan

This is your pfSense portal address :
@susobaco said in The captive portal does not redirect to the login page on IOS devices:

10.0.0.101

Right ?
(and for my personal curiosity : why some IP in the middle of a range ?? Never understood why people chose a setting like that)

@susobaco said in The captive portal does not redirect to the login page on IOS devices:

--- table(wifi_palau_allowed_down), set(0) ---
.......
217.160.0.91/32 2003 2612 152545 1545131595
2001:8d8:100f:f000::266/128 2003 0 0 0
......
--- table(wifi_palau_allowed_up), set(0) ---
.....
217.160.0.91/32 2002 7310 10766880 1545131548
2001:8d8:100f:f000::266/128 2002 0 0 0

IPv6 in a IPv4 only network ... why not .... strange.

Dono what you used as a source for your setup, but it has not much to do with what 'Negate' proposes : see the 2 or 3 Official Captif portal Videos on Youtube.

Still, can't explain why your iOS devices won't work with your portal. Somehow you make them bail out.

When you connect to your portal, and check the Gateway and DNS settings on your iPhone (Pad), they are ok ?
I know, it's difficult to check DNS using a nslookup tool on these devices - or a 'dig'. To check if DNS is really working.

susobaco

@gertjan said in The captive portal does not redirect to the login page on IOS devices:

(and for my personal curiosity : why some IP in the middle of a range ?? Never understood why people chose a setting like that)

It is a configuration inherited from the old server

I can try deactivating ipv6. Well, after vacation. I wish you a happy new year. And thank you for your interest. I will return to the subject in a few days.

free4

--- table(cp_ifaces), set(0) ---
em0 2100 116164 74882688 1545131838
--- table(wifi_palau_auth_up), set(0) ---

Why are you enabling the captive portal on your WAN interface ? Why do your captive portal clients have public IP v4/v6 addresses? It seems like a configuration mistake...or a very uncommon configuration.

Also, about IPv6: the captive portal is not officially IPv6-compatible yet. It has not be tested with v6 IP.

susobaco

Hello, happy new year to you all. I'm back. In principle, the interface where the captive portal is activated, has no ipv6 address, so the dhcp6 server is disabled. The configuration of the server is: LAN interface connected to the administrative vlan, which has internet connection, two WAN00 and WAN01 for some internet connections to balance in case of demand, and a third OPT1 interface in which is the vlan Congresual and the captive portal. Is the configuration badly done?

susobaco

@susobaco SOLVED !!!! The captive portal does not redirect to the login page on IOS devices

Hello, SOLVED!!!!!! After trying all possible combinations, in the end, I found the error. It was my fault, when customizing the captive portal, I didn't write the code well or I don't know what I did. Putting the default design that brings pfsense, ios devices open the login window to connect to the wifi without any problem. Thank you all for your help and patience.