I would like to implement a Sign-on splash with customer-hosted RADIUS for guest authentication.
I am following the instructions at this link: https://documentation.meraki.com/MR/Splash_Page/Configuring_RADIUS_Authentication_with_a_Sign-on_Spl...
I am trying to configure my RADIUS server with the proper client IP addresses for the RADIUS requests. In the documentation it states I can obtain these addresses from the Firewall Information page. However, the firewall information page just shows two /24 subnets and a /20 subnet as potential sources. This is way too many addresses to add to the RADIUS server.
How can I get the actual specific IP addresses of the RADIUS requests to enter as clients?
TimS,
The MX should use the highest value VLAN routable IP. So if you don't have any vlan's configured it's the default LAN IP for the MX. If you do have VLAN's it should be the highest # VLAN. To verify you can check the radius logs as well and see the client-ip address request when you test as well.
https://documentation.meraki.com/MX-Z/Other_Topics/MX_and_Z1_Source_IP_for_RADIUS_Authentication
That only works for Internal User authentication.
For guest user authentication, the requests come from Meraki's cloud.
We have verified this with packet captures and it states this in the documentation I linked to.
Support just responded me and is telling me that we need to open the firewall for all of the subnets and add those subnets as RADIUS clients. This seems like a bit of a security issue. Especially since the rule isn't specific to RADIUS but also applies to NTP so much of those subnets could be referencing just NTP servers and have no need to be allowed inbound.
Client felt that this was the best way to centrally manage authentication across all of their global locations.
Meraki Authentication only appears to work for each Network so then they have to configure the guest at every site they may end up visiting.
Is there a better way to do this?
Client also pointed out how the RADIUS message is sent in clear text over the internet, exposing the username. Would love another way to accomplish this.