Access control requires RADIUS with public IPs?

[Messy]

Hello,

Just been looking at the SD-WAN, Access Control settings which look brilliant, exactly what we need at the moment.

I was happily setting it up and getting a little confused as to why it wasn't able to reach our RADIUS servers when I saw the little sign that says "

Please make sure that:

1. Your RADIUS servers have public IP addresses (i.e., they are reachable on the Internet)."

am I missing something, is that the ONLY option? I'd be shocked if that was the case. Please tell me we don't have to expose our servers to the internet so internal devices can access internal resources.

[Mloraditch]

You may want to look at this:

https://documentation.meraki.com/MX/Access_Control_and_Splash_Page/MX_Access_Policies_(802.1X)
If you have one of the smaller models you can do more normal access control. What you found is designed for splash page control  for whole VLANs and that may be the source of the limitation.

[Messy]

this appears to be MX port access control which is not an issue, our MX's are in locked server rooms.

We were after something to stop people being able to just plug into a wallport and have instant internal network access. - The VLAN based splash page thing I found is PERFECT - except for the stupid public radius requirement.

[alemabrahao]

Yes, it is a requirement that your Radius server is accessible via the internet. The reason for this is because the ones that will communicate with your server are Meraki's public IPs and not the MX IP.

[alemabrahao]

One option is to configure a RADIUS proxy to forward authentication requests to your internal server and avoid exposing your RADIUS servers to the Internet.

[Messy]

I don't think anyone is going to ok a new server just as a work around to some stupid meraki design flaw.

thanks tho.

[Messy]

cheers for the reply.

well that sucks, what a terrible way to implement a security feature! It gone from being exactly what we want to being useless 😞

[alemabrahao]

One question. Why don't you implement 802.1x authentication on your switch ports? I find this a much more efficient and viable way.

[sinelnyyk · Accepted solution]

Hi @Messy,

Unfortunately, it indeed is correct and when using sing-on splash page you will need to specify publicly-available RADIUS server. This, however, applies also to MR, so there's no difference in this case between MX and APs.

This is simply caused by the traffic flow. When Sign-On splash is used for authentication, the authentication will be happening between Client <-> Cloud <-> RADIUS server, so Meraki Cloud needs to communicate to the cloud in this scenario, hence public IP is needed. The flow is described quite well here. When you think of that, it makes sense, but introduces some challenges. Me personally can't think of a better way to implement this without this limitation.

Good news though! You don't need to expose your RADIUS server to the whole Internet, only a couple public dashboard IPs will be enough. You can find them in the "?" > Firewall Info page when you configured the Sign-On splash. In my case it was 3 IP ranges from where RADIUS server can expect connections.

Here is also a KB for MR configuration, but it should be pretty similar on MX side as well.

I hope that helps, or at least gives you some more understanding on why it was implemented this way 🙂

[Messy]

cheers

[CarolineS]

Moderator note: Marking @sinelnyyk 's reply as the solution as it seems to be the definitive answer. Cheers!