The captive portal does not redirect to the login page on IOS devices
-
@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 :
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.
-
@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
-
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
-
@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 listlooks good ?
-
@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 0I'm going to read the tutorial well, to see what I can be doing wrong
-
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 0IPv6 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. -
@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.
-
--- 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.
-
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 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.
