MX Anchored Guest SSID with ClearPass Guest Portal - CoA Fails due to CP / Meraki integration limits

[Timbo]

Hi All,

Has anyone deployed an MX anchored Guest SSID with MAB auth against ClearPass using a ClearPass hosted sign-on portal? I have deployed this successfully with ISE several times, though have hat an issue with CoA when using ClearPass.

The issue is that the RADIUS request is generated by the WAP, sent through the tunnel to the anchor MX, which forwards it to CP. CP is configured with the MX as a NAS, and the RADIUS request is answered with an accept, and server initiated redirect. Once the user signs in, CP needs to CoA the session, which is where my issue is. CP will always use the NAS-IP-Address taken from the RADIUS Acct packet for the session. The issue is that because the MR built the RADIUS request, it put its IP into that field, which means CP sends the CoA to the WAP, not the MX IP (which is where Meraki Engineering advise it is expected). The WAP drops the CoA, and the user is not re-authenticated, and is consequently stuck in a portal redirect loop. The solution works fine when using bridge mode, as the WAP is expecting the CoA, it is an anchor-specific issue.

This works fine with ISE as it uses the real source IP of the RADIUS Auth/Acct packet, not the NAS-IP-Address taken from within it. In any other enterprise wireless solution you can override (specify) the NAS-IP-Address on the WLC, however Meraki doesn’t support this. I have worked extensively with Aruba TAC, they have advised CP can’t be changed to use the real IP, only NAS-IP.

I have considered most alternatives, however they are generally unacceptable to the customer, who are a large enterprise with tight security controls. I am currently trying to use the supported EXCAP Click-Through option, using CP to allow guest registration and sign-on, sending the Meraki Cloud the expected Grant URL. This does partially work, though isnt really a supported design.

Here are some of the constraints which determined the current solution:
* Require custom portal with both self registered and sponsored login options, desire to reuse expositing ClearPass infrastructure.
* Must be tunnelled across their SD-WAN environment to provide separation from corporate traffic.
* Not permitted to host splash pages Internet / public facing. This is the reason VPN access to DC is required
* Not permitted to open RADIUS to Internet, precluding the standard Meraki or EXCAP hosted Logon page, as this requires that Meraki Cloud send RADIUS request over the Internet (/24 source range)

Any advice / thoughts would be welcome.

Thanks, Tim

[PhilipDAth]

Another thing to consider - MAB is likely to break with iOS 14.x with the MAC address randomisation.

[Timbo]

Yes, I've been meaning to look into that. I recall about 5 years ago Windows started randominsing MAC's, however  only did so when probing. For a given SSID I always saw the same MAC presented by a client.

I just found the below, looks like Apple have adopted a similar approach:

To reduce this privacy risk, iOS 14, iPadOS 14 and watchOS 7 use a different MAC address for each Wi-Fi network. This unique, static MAC address is your device's private Wi-Fi address for that network only.

https://support.apple.com/en-au/HT211227

[CptnCrnch]

To be honest, I didn't even know that something like anchoring exists in Meraki-land. Until now, this was a pure "legacy" Cisco WLC-thing to me.

Currently, I'm also not fully able to grasp why that design has been chosen. Wouldn't it be easier to have all WAPs talk directly to your ClearPass instance?

[Timbo]

Yes, it would be easier to bridge clients into a local site VLAN and allow them to route natively across the SDWAN tunnels to ClearPass Portal servers, however this is not a design their security team are happy to embrace, even with tight WLAN ACL, S2S VPN ACL, etc...

In a perfect world, the guest traffic would all go straight out to the Internet from the local site, however their requirement to use ClearPass portals require Guests can access the DC one way or another. Would be great if specific traffic (ie, portals) could even be NAT'd behind the WAP IP (Mgmt VLAN has VPN access), with all other traffic bridged to an Internet only VLAN.