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

Alexs20
Getting noticed

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

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

22 Replies 22
alemabrahao
Kind of a big deal
Kind of a big deal

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:

 

 

alemabrahao_0-1692379030595.png

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

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Alexs20
Getting noticed

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
Kind of a big deal
Kind of a big deal

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:

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

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
alemabrahao
Kind of a big deal
Kind of a big deal

You can use an IPSK with Radius Athentication too.

 

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

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Alexs20
Getting noticed

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

Alexs20
Getting noticed

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
Kind of a big deal
Kind of a big deal

If you have so many criticisms, talk to your Meraki sales representative.
 
But what Meraki looks like to me is definitely not for you.
I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
PhilipDAth
Kind of a big deal
Kind of a big deal

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
Getting noticed

Really? Then how you would implement VLAN roaming?

Alexs20
Getting noticed

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
Kind of a big deal
Kind of a big deal

Open your mind.

 

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

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Alexs20
Getting noticed

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
Kind of a big deal
Kind of a big deal

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

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Alexs20
Getting noticed

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
Kind of a big deal
Kind of a big deal

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

 

I think you are confusing things.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Alexs20
Getting noticed

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
Kind of a big deal
Kind of a big deal

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.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Alexs20
Getting noticed

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
Kind of a big deal
Kind of a big deal

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.
I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Alexs20
Getting noticed

PM

alemabrahao
Kind of a big deal
Kind of a big deal

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

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Alexs20
Getting noticed

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 🙂

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels