Mac-based authentication with ISE / cloud RADIUS server and CoA

[jamesw]

We're testing out the following:

Association requirements: MAC-based access control 
Splash page: Cisco Identity Services Engine (ISE) Authentication

We run a cloud RADIUS server which acts as the ISE in terms of the RADIUS handling.

So the flow currently works like this:

Client associates to SSID

Local AP sends Access-Request to configured RADIUS cloud server IP

Our RADIUS replies with an Access-Accept and a Cisco-AVPair redirect url

Client is redirected to our splash page URL and registers etc

All good up until this point, but the problem is that to get the user online, we have to send a CoA request back to the local AP from our cloud RADIUS. Whilst we can open the firewall and perform a port forward to the AP, this only works if there is a single AP. More than one AP, and the solution falls over because you can't externally access all the different AP's using a single port forward.

Why can't Meraki allow the RADIUS proxy option to work with this setup? For true captive portal authentications we can send a CoA back to the Meraki cloud which in turn authenticates the user on the local AP. But for ISE, it disables the RADIUS proxy option. 

Not everyone runs a local RADIUS server!

Does anyone know an alternative way of achieving MAC authentication AND external captive portal fall-back?

Thanks

J

[PhilipDAth]

I've never heard of someone trying to do that.  It is way outside the scope of a typical design like this.  It would be exhausting if Meraki tried to allow for every single possible design.  They just need to concentrate on the most common setups.

It might not be a question of "Why can't Meraki allow the RADIUS proxy option to work with this setup?", but more of a question of why you can't use the recommend design where everything is inside of the network - because it is only going to cause you grief.

https://documentation.meraki.com/MR/Encryption_and_Authentication/CWA_-_Central_Web_Authentication_w... 

[jamesw]

Thanks for the reply!

We're not using any kind of strange design, nowhere in the documentation does it mention or indicate that you must use a local, on-site based ISE server. Everything is moving off-site to the cloud, including the way Meraki has worked from day one - they are a cloud controller and RADIUS server, with just the AP's on site.

In reality, we're doing no different by hosting our RADIUS server in the cloud, it's just that there seems to be an expectation that an ISE server locally which isn't practical when you are a large service provider.

Therefore, I feel Meraki should make it possible to proxy this traffic/feature or at least some API service so that we can send the CoA to the Meraki cloud, which can then send the signal direct to the relevant AP, without any firewall/port forward mess.

The problem actually arises because Meraki are the only vendor I know that do not support MAC authentication with proper captive portal bypass. They do not allow you to select both MAC-based access control along with splash sign on via RADIUS server. So, their recommendation is to use the ISE option, which, in its current state, is one step forward and two steps back 🙂

[PhilipDAth]

Can you run a site to site VPN into your cloud so that there is no need for NAT?

[jamesw]

I see your point, but the problem is we are not a "customer" but a service provider. We don't own the kit, or install it, or have access to the setup on site. We provide a cloud captive portal/authentication/analytics service, so, it's not easy to ask our customers to configure site-so-site to us as we have thousands of Meraki customers around the globe using our solution and for now, we still can't support MAC authentication with captive portal bypass.

[PhilipDAth]

Thinking sideways; could you write a little proxy RADIUS server for clients to run on-premise?  It really just needs to tunnel the requests.

[jamesw]

We could, but it goes against the reason we exists, because customers don't want to install/set up anything that they don't already have. So, we can generally work with any wireless kit just by running our captive portal and RADIUs in the cloud, at no cost or extra software/hardware installed on the customers site.