Out of the Box Captive portal not working
-
Connect and tell the phone to go to http://10.10.10.10/ (or something else RFC1918 if your local network includes 10.10.10.10.)
The goal is to eliminate both DNS issues and https issues.
-
I used the 10.10.10.10 test, as that is not on my network. When my iPad is in airplane mode with WiFi enabled. It exhibits the same behavior, where it doesn’t want to load the portal. But if I turn off airplane mode it will successfully load to the captive portal. To me this almost sounds like a DNS issue. Because of it working when I enable cellular again. The dhcp settings for the 50 vlan are set to 8.8.8.8 for DNS
-
Well if airplane mode is breaking it then that's not CP's fault.
If you are telling them to use 8.8.8.8 as the DNS server then you have to add 8.8.8.8 to the Allowed IP Addresses in the Captive Portal settings so they can resolve names before they authenticate. Without that the device never tries to go anywhere so there's nothing for the portal to redirect to the login page.
-
This post is deleted! -
Well if it works not in airplane mode and does with airplane mode off, then it's not the captive portal, it's the phone.
It should work if you enable airplane mode then enable wifi. At least my iPhone works fine.
You could test with a laptop too so you have real diagnostic tools at your disposal.
-
@derelict
I Deleted the previous post, cause its working. It is just super slow to connect. from the time it joins the wifi connection. It takes a good 30 seconds before the wifi strength symbol to pop up. Then it will allow it to go to the captive screen -
@afmiller said in Out of the Box Captive portal not working:
The test wifi is unsecure
Non related to the captive portal : this concerns a Access Point setting : WPA encoded, or no encryption.
For captive portals networks, the Wifi networks is often not encrypted.@afmiller said in Out of the Box Captive portal not working:
ipad successfully connects to the network
Ah, an iPad : this means the portal will be detected fully automaticity. Connect to the Wifi network, and the login portal will pop up. You do not have to open a browser or anything to make this happen. The OS (iOS) takes care of everything.
An "Out of the Box Captive portal" will work in two minutes or so if you enable the captive portal on the LAN interface, with the build in User Manager.
Making it work on a VLAN is as making it working on a dedicated extra LAN port (called OPTx) : not a problem at all : as long as your VLAN is setup correctly. Among others : DNS - DHCP and a initial "pass all rule" on the firewall for it's VLAN interface
FreeRadius : A simple advise : make everything work with the build in User Manager first. As soon as everything works as you would like, add FreeRadius. FreeRadius is not a "click install click start" setup. Many aspects have to be understood, some debugging like running freeRdius by hand usingradius -Xare needed to see what really happens.
So, again : proceeed by steps :
Set up your VLAN. Everything should be ok, like DHCP, DNS, firewall rule.
Then ; activate the portal on that interface with minimalistic settings (== User Manager)
Then, if you have a weekend all for yourself, add FreeRadius support.edit :
A default setup is : just use the build in default DNS Resolver. Do not try to use out-of-the-box resolvers like 8.8.8.8. DNS settings can be changed - these are all expert settings. A captive portal needed perfect DNS settings.
Nearly all cases where people say : my captive portal doesn't work is because the 'broke' DNS (see the captive portal documentation set debug help pages).edit :
@afmiller said in Out of the Box Captive portal not working:It takes a good 30 seconds before the wifi strength symbol to pop up
For reference : on my old iPad or old iPhone 5S it takes something between 2 and 5 second before the login page pops up (after selecting the captive portal network).
Bigger delays : probably DNS time outs ... => wrong DNS settings. -
-
-
Classic
Although using the LAN interface as the captive portal interface isn't the best choice, it has something very important : a general pass rule.
On a dedicated interface, you need to pass traffic that you would allow for your users. One of them should take care of "UDP traffic to any port 53". Simply copying the default rule from LAN will do the trick.
Of course, you can narrow down your rules for captive portal users (actually, you should !) but again : do not forget to have DNS coming in.
The default ipfw rule set adds the IP of the interface of the Captive portal as a accepted "all traffic" destination : this means that when you use the resolver unbound or forwarder dnsmasq on pfSense, you'll be fine without thinking about DNS issues or rules.
When you want to communicate all DNS requests to some outsider then you have to deal with it.Consider this : no one ever asks about : what is needed for DHCP ?
On any interface, LAN and others, the ip firewall does accept incoming broadcasts, and replies, all for port 69. Without these, even DHCP wouldn't work .... Hidden 'DHCP' rules are setup for evey LAN type interface.
Remember : if no pass rules are triggered, the firewall blocks.
