First RADIUS Request in Sign-on with my RADIUS server mode

[Alexs20]

Hi,

I am testing the configuration where "Sign-on with my RADIUS server" is enabled

And when device connects for first time I do not see any initial RADIUS Access-Request message, but Splash page is coming right away.

But what if device already pre-authenticated? Why we need to bring the splash page in that case? Why not to just send Radius-Request message, receive the Accept message and let it enter the network?

Thanks

[alemabrahao]

Fetching the Splash URL

Splash authentication always begins the same way. An unauthenticated client must send an HTTP GET request for a web page. The AP sees the request coming from an unauthenticated client so it redirects the client to the splash URL. The diagram and HTML output below show the redirect process in detail:

Before sending the HTTP GET, the client first sends a TCP SYN to the URL's IP address, then the AP replies back on behalf of the site with TCP SYN ACK. After that, the client sends the HTTP GET. You can see this only in the wireless/monitor mode captures and you can identify the AP is responding on behalf of the real site by looking at the source mac address, which will be AP's ethernet mac address. For other packets seen on the air, the source mac address will be the default gateway mac address.

Full doc.

https://documentation.meraki.com/MR/MR_Splash_Page/Splash_Page_Traffic_Flow_and_Troubleshooting

[Alexs20]

This doc doesn’t answer my question and it also has important part missing in the diagram.

Before the client send any kind of messages, as a first step, it Connects to AP! And at that point AP should make a decision, restrict the device to Captive portal requests only or grant full access without bothering the client with all kind of web authentication.

And this is how most captive portals work.

In case of Meraki, the AP doesn’t query RADIUS server at device’s connection time, it just stupidly puts it in restricted mode where first attempt to any TCP traffic will trigger the redirection to the captive portal. At least this is what I observe.

Imagine you have a game console, that has no browser to deal with the Captive Portal, and you want to allow it to connect, just by registering it in RADIUS DB with the hope that AP is smart enough to check that status first. The result – it will not work.

[alemabrahao]

In the case of devices that don't support Splash Page, you can put them in an allowed list. I think you are confusing some things.

Allow List

Applies the following settings to a client:

• Is exempt from all firewall rules, both Layer 3 and Layer 7 (Applies to both the MX Security Appliance and the MR Access Points)
• Bypasses AMP

• Bypasses a Click-through Splash page 
• Bypasses a Billing (paid access) Splash page and access the network on an SSID without paying or authenticating
• Bypasses a Sign-on Splash page without authenticating (Applies to both the MX Security Appliance and the MR Access Points)
• Is exempt from Per-client bandwidth limit (Applies to both the MX Security Appliance and the MR Access Points)
• Is exempt from Traffic shaping rules (Applies to both the MX Security Appliance and the MR Access Points)
• Bypasses Content filtering on MX Security Appliance 

https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Blocking_and_Allowing...

[alemabrahao]

You can use an IPSK with Radius Athentication too.

https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_with_RADIUS_Authentication

[Alexs20]

Not sure how I can deal with Captive Portal in "IPSK with Radius" mode

[Alexs20]

Not an option at all, we may have thousands browserless devices in hundred customer networks, and we do not want to mod these lists in Miraki Cloud admin console for each device.

It should be MAC based, otherwise it is just a ugly workaround

[alemabrahao]

If you have so many criticisms, talk to your Meraki sales representative.

But what Meraki looks like to me is definitely not for you.

[PhilipDAth]

You shouldn't get an Access-Request till the user has typed in their username and password into the splash page and clicked on login.

A device which has already authenticated but is within the expiry period should not see the splash page.

[Alexs20]

Really? Then how you would implement VLAN roaming?

[Alexs20]

Oh, I see that people asked for the same behavior, without proper answer as well
https://community.meraki.com/t5/Wireless-LAN/How-to-use-both-MAC-based-authentication-and-Click-thro...
It is simply not implemented "yet" (that was 2 years ago) ... That's sad.

[alemabrahao]

Open your mind.

https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

[Alexs20]

This link you posted has nothing to do with Splash pages... we are going in cycles.

If you have SSID A (VLAN 1000) with Splash page and SSID B (VLAN 2000) with Splash page as well then there is no way to let to guest to login only once in any of them and then let it roam between them without showing the Splash page second time.

[alemabrahao]

You're a complicated person, did you at least get the idea of L3 roaming?

Large WLAN networks (for example, those found on large campuses) may require IP session roaming at layer 3 to enable application and session persistence while a mobile client roams across multiple VLANs. For example, when a user on a VoIP call roams between APs on different

VLANs without layer 3 roaming, the user's session will be interrupted as the external server must re-establish communication with the client's new IP address. During this time, a VoIP call will noticeably drop for several seconds, providing a degraded user experience. In smaller networks, it may be possible to configure a flat network by placing all APs on the same VLAN.

You can also configure the splash page frequency.

https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Splash_Page_Frequency

[Alexs20]

Did you read my post about two different SSIDs with splash page configured on both?
Where exactly in all quotes you posted from that L3 roaming doc I can see how to bypass second Splash Page when user that already logged in first SSID connects to second (for first time!) ?
I think we are talking about two different things. In your scenario, to have L3 to work user should connect to SSID 1, then Login in Splash page, then connect to SSID 2, AGAIN LOGIN in Splash page, and only then L3 roaming start to work if he moves between them... but my problem is with the SECOND SPLASH, on SECOND SSID, when user connects to it for first time, while he already logged in first SSID. SSID names are different, not the same, but AP could be the same!
But NM, the Meraki Employee in the thread I found and posted before has confirmed that this is impossible and Meraki not implemented it yet, so we just wasting the time.

unless ... you are ready to not to simply copy-paste quotes from all kind of docs but to help me guiding with real configuration steps that will allow me to bypass splash page on the second SSID

[alemabrahao]

There are two different SSIDs, it is the expected behavior, ask for authentication again.

I think you are confusing things.

[Alexs20]

No this is not expected. Imagine you are a Guest in hotel. You are coming to your room and connect to SSID (Rooms), you see the login page and accept Terms and Conditions of using WIFI in the Hotel, then you go to the Restaurant, and connect to another SSID (Restaurant) and instead of just connect to the network you see the Terms And Conditions AGAIN. 
As a administrator I should be able to configure roaming between different SSIDs, and this is why you need to query device's registration status with Radius server Before Showing the splash page, not after.
Just to repeat myself - Ruckus and Aruba controllers doing that in a right way and Talking to the Radius before making the decision Do or Do Not show the splash page.. but not Meraki, unfortunately.

[alemabrahao]

Buddy, believe me it is, I work with wifi for at least 10 years.

If you don't believe it, just open a ticket to Meraki.

[Alexs20]

Lol, wanna compare skills? Well, I also work in the same industry for almost the same amount of time... maybe little less but not significant, 8 years. And I am also a developer with 20+ years experience with different network protocols and I already did a few vendor's integration.

And I can say for sure that even if for Meraki it is an "expected behavior", this is not the same for the rest of the world.

[alemabrahao]

I don't want to compare skills, buddy, I'm just saying that in this case it's the expected behavior.

What you are talking about is something specific to the Radius configuration, that is, it expects to receive a certain attribute. Whether Meraki supports it or not is another question.

It would be interesting if you let us know which Radius attribute you need. Can you show the functionality you enable in Controller Ruckus for example? To compare if there is a way.

[Alexs20]

PM

[alemabrahao]

I see, you are actually using a Hotspot network.

I have never particularly worked with hotspot networks, but Meraki has a Hotspot feature. I don't know if it's what you're looking for, but it's worth taking a look at the documentation.

https://documentation.meraki.com/MR/Other_Topics/Hotspot_2.0_Configuration_Example

[Alexs20]

Yeah, I saw that. This is hotspot 2 not the same as the regular hotspot, not all devices support hotspot 2 connections. For example for Android devices - only starting Android 11 with special HW, the same with Apple, only devices from last 5-6 years. And this is a problem, because we are trying to cover 99.9% of devices.
Unfortunately the closes implementation of the regular hotspot is what Meraki calling - Sign-on with Radius, which has very limited functionality.
But anyway, thanks for trying to help and direct me, but looks like not all problems possible to resolve in a easy way 🙂