07-24-2018 02:00 AM
I'm testing a setup that I enabled RADIUS authentication on captive portal with CHAP and RADIUS MAC based authentication both. If user MAC already have in RADIUS database user should bypass the captive portal and automatically connect and if MAC address is not found on RADIUS user should fallback to captive portal based auth
Idea here is capture user information with device MAC address in the initial phase and allow them registered users to connect without go through captive portal. however if I enabled RADIUS MAC auth in wireless networks tab, only devices which already have MAC address stored in RADIUS can connect to network. all the other users failed to connect.
Is there any way to connect and fallback to captive portal auth if initial MAC based auth failed? In gest control settings it only have two options and both are for password based auth. I don’t want users to key in password every time they connected to network after first time.
I used built in captive portal only method without RADIUS and it works fine for single AP. but when users start to roam around multiple AP's it will start to fail and users having pop-ups for sign in even within the auth time frame.
As per my understanding the built in session handling also done by the AP itself rather than communicating the controller. But due to some reason it fails every time for roaming users even with fast roaming enabled. (Never tried zero handoff). Now we need to keep everything on radius. for radius we are using freeradius on debian
08-02-2018 03:08 AM
@carbonnation99 I suggest you first focus on getting the normal mode of the captive portal to work. This normally works perfectly fine without fast roaming enabled (which you should hardly ever really need, zero hand-off should always be avoided).
Make sure the connectivity between your APs and the controller is working as it should, especially in this case make sure you don't have any STUN errors in the device list. If your controller is not located on the local network, what is the network latency between the APs and the controller?
If you are unable to fix this with the above tips, please share a detailed network diagram.
Regarding the Radius auth; AFAIK you cannot do this without implementing a custom captive portal; the initial Radius Auth process on the WLAN is simple; if a device does not authenticate, it is not allowed access to the network, therefore it will not be able to access the UniFi Captive Portal either.
08-05-2018 03:46 AM
Thank you for the reply
I already implemented captive portal with the support of your PHP API Client. Thanks for the amazing work and the setup is work extremely well. We already have a deployment that we used external captive portal with social media auth and it works flawlessly. For this site, we have very less complaints because there are limited roaming users.
But things get changed when we try to deploy the same setup on a different place where 90% of the clients are roaming. The initial connection went smoothly always but roaming users frequently get disconnected. (Cannot get internet). This is more on Apple users than Android. We disabled Fast roaming and from the beginning ZERO hand-off is disabled and we tried to enable advanced features which enable minimum RSSI, but no go
Latency from the AP to the controller is very less and there are no STUN errors on any devices. I also think this is may be due to a network. I’ll soon do a full investigation when I have time
For the RADIUS whole idea behind this is seamless connectivity. Having open SSID and users should be able to connect automatically (after selecting the SSID) after the initial registration. I select MAC based auth because for me that seems the only solution since HS2.0 need much complex configuration on the client side. For MAC based auth if MAC address is already in DB auth is instant. But the issue is under settings if I enabled this option no one can connect to the AP if the MAC is not in DB as you mentioned.
Then I tried the PAP and CHAP with inbuilt captive portal and that’s also working fine but I cannot use it since the whole idea is seamless connectivity.
As you mentioned I got it that there is no inbuilt feature in the controller that fall back to the captive portal if the MAC based auth fail. But even with the custom captive portal is it possible to implement configure above-mentioned setup? I mean if MAC based auth success user should immediately connect. If MAC auth failed user should redirect to a captive portal
I tried my setup with custom Linux box. I do the same kind of captive portal redirection if the MAC auth failed and managed to get it to work. I use Centos and OpenWRT both but this is from the gateway level. And even pfsense also has inbuilt option to enable this feature. But our network team will not be happy if we need to deploy custom ugly looking Linux boxes everywhere.
I think the Unifi controller should include features like MAC+PAP or CHAP in the guest portal. Any other way to implement this?
08-05-2018 04:19 AM
@carbonnation99 Good to hear you’re using the API client!
Regarding the roaming; I have never seen that myself, I guess it is a network misconfig. Check the VLAN to see whether the devices are able to re-connect to the next AP with the IP config which they received when connected to the initial AP. Maybe you need to do a Wireshak capture to see what exactly is going on.
For the MAC authentication part I would implement that in the first step immediately after the client is redirected to the external portal: check the device MAC address against a whitelist or perform authentication through Radius before rendering any page. Actually quite simple I think...
11-26-2018 03:04 PM
Does this method of passing MAC authentication avoid the issue of captive portal requiring user interaction even when automatically accepted? We currently have Cisco & it specifically has a setting to use captive portal when MAC authentication fails. In the captive portal piece the user then registers & upon completing necessary fields their MAC is added to RADIUS. The end result is every time a user comes within range it automatically re-connects in the background with no interaction on their part. We're trying to re-created this on UniFi.
11-26-2018 10:04 PM - edited 11-26-2018 10:05 PM
Yes this is what exactly we need. If I enable radius-mac based authentication in unifi controller it only allow device which MACs are already known and prevent other devices from connect. I'm looking for method that fallback to captive portal if MAC is not already known and bypass the captive portal if MAC is already known