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 ... View more

Hi All, I’ve been having issues getting one-armed concentrator BGP working correctly, and am looking for advise / feedback from anyone who has implemented already. Establishing BGP with the upstream device (3560v2 switch in lab env, ASR9k in prod) is straight forward enough, the issue is that our MX sends its BGP updates with a bogus next hop of 192.0.2.1 (the concentrator’s real IP is 10.40.3.34/29 in this environment). Actually, I observed in PCAPs that the correct next hop is initially sent, then 5 seconds later, a further update is sent by the MX with the bogus 192 address…   The upstream device rejects the prefixes as the next hop is not connected: Oct 24 02:16:34.247: BGP(0): 10.40.3.34 rcv UPDATE about 10.6.50.0/25 -- DENIED due to: non-connected NEXTHOP;   I have had the same occur in two separate Meraki Organisations where I have tried this. Support tell me it is an intermittent bug which seems to have been around since v13.9 (first BGP release), but still no ETA on resolution.   I have configured a route map to set the correct next-hop IP to work around the issue, though I would expect it to send the correct next hop all the time...   Has anyone else hit this issue, or did it just work (ie, send the correct Next Hop address)? Have others done as I have, and worked around the issue? Has this proven to be a stable solution? Thanks for any comments!   Tim ... View more