Allow LAN access and block internet
-
I've got a captive portal page working which, once users authenticate they can access the internet. We have a media server with content that I want users to be able to access without having to authenticate.
When a device connects through wi-fi it takes them to the custom captive portal page. If they do not provide a voucher or a user name and password within a certain amount of time their wi-fi connection is dropped and they have to re-connect to the wireless network.
So right now internet access is blocked unless users authenticate which is exactly what I want. Users can also access the media server on our LAN, but only until the wi-fi connection is dropped.
I have configured the DHCP lease times:
default - 10,800 seconds
maximum - 86,400 secondsI have setup the captive portal Idle timeout to 180 minutes and the hard timeout to 230 minutes. Those sound like settings for users that have authenticated, but what I am looking for is a setting to change the time given to users that do not authenticate before they are dropped from the network.
Thanks for any feedback!
-
This:
@jkman:I have setup the captive portal Idle timeout to 180 minutes and the hard timeout to 230 minutes. Those sound like settings for users that have authenticated, but what I am looking for is a setting to change the time given to users that do not authenticate before they are dropped from the network.
isn't clear.
Non-authenticated users are not dropped - they can simply not using the Internet. That's all.
-
Sorry for not being clear.
This is not exactly true:
@Gertjan:Non-authenticated users are not dropped - they can simply not using the Internet. That's all.
Users can connect and access the LAN, but the following happens:
@jkman:When a device connects through wi-fi it takes them to the custom captive portal page. If they do not provide a voucher or a user name and password within a certain amount of time their wi-fi connection is dropped and they have to re-connect to the wireless network.
I want to prevent their connection from being dropped and I am uncertain of how to do that.
-
The only thing I can imagine you're talking about is the behavior of Apple devices. They attempt to access the internet and access http://www.apple.com/library/test/success.html. If they don't get "Success" back they assume they're behind a portal. If the user doesn't take positive action within a certain amount of time, the Wi-Fi connection is torn down and they're put back on cell data (or whatever).
This is a client function. pfSense isn't doing anything.
Users can either punch through the captive portal, tell their device they want to use the Wi-Fi connection without internet access, or you can whitelist http://www.apple.com/library/test/success.html so the device test passes whether or not they're through the portal. Note that this will mean the user doesn't automatically get the portal page automatically and will have to open safari and try to connect to a page to get it.
Access points have no idea whether or not the portal has been negotiated.
pfSense has no way to drop the Wi-Fi connection. Except, maybe, RADIUS reply attributes, but that would require authentication first.
-
The only thing I can imagine you're talking about is the behavior of Apple devices. They attempt to access the internet and access http://www.apple.com/library/test/success.html. If they don't get "Success" back they assume they're behind a portal. If the user doesn't take positive action within a certain amount of time, the Wi-Fi connection is torn down and they're put back on cell data (or whatever).
This is a client function. pfSense isn't doing anything.
Users can either punch through the captive portal, tell their device they want to use the Wi-Fi connection without internet access, or you can whitelist http://www.apple.com/library/test/success.html so the device test passes whether or not they're through the portal. Note that this will mean the user doesn't automatically get the portal page automatically and will have to open safari and try to connect to a page to get it.
Access points have no idea whether or not the portal has been negotiated.
pfSense has no way to drop the Wi-Fi connection. Except, maybe, RADIUS reply attributes, but that would require authentication first.
THANK YOU!!! Wow, you're right. I spent far too much time trying to figure this one out. Apparently it's also an issue with the newer versions of Android (4.3). That gives me what I need to work through this. Seriously a huge thanks!
-
One last follow up on some settings that appear to have helped trick the devices. YMMV:
In the allowed hostenames section I added the following two entries
- 1e100.net
- gsp1.apple.com
I do not know how permanent of a fix this is. If the OS's change and start testing different URL's for internet access, it would of course break. This effectively tricks the OS into thinking that it has a valid internet connection and it appears that the wi-fi connections are no longer dropped. I know this was never the fault of pfSense, but I did not see this information listed anywhere and thought it might be beneficial to anyone doing a search on the topic.
If it does not work, use the Packet Capture feature to sniff out what domain the device is trying to connect to when connecting up to the wi-fi. That should tell you what you need to know. I used the reverse DNS lookup so that I could see the domain names. Also, you shouldn't need any of the sub domain stuff, only the main domain name but I could be wrong. Hopefully that gets anyone else going in the right direction.
-
Not just www.apple.com
See
Using Apple Products with Captive Portal
iOS 6 issues
Not getting a "captive portal detected" message on iOS devices
etc.IOS devices have a boatload of URLs to test if the Internet is reachable.