Skip to main content
Cisco Meraki Documentation

RADIUS Authentication and Accounting with a Sign-On Splash Page

This article explains the process of RADIUS authentication and accounting for networks using a Sign-On Splash Page, detailing the client connection and authentication steps, the role of RADIUS in session tracking, and the conditions that trigger deauthentication. It also provides troubleshooting tips and additional resources for network administrators.


This document focuses on how the Splash Page using RADIUS authentication behaves and in particular how it is affected by using RADIUS accounting.


An SSID is configured to use Splash Page with RADIUS Authentication. After a client connects to the SSID, their first HTTP GET request is intercepted by the AP and the client is redirected to the configured splash page. The client enters their credentials and that information is sent to the RADIUS server by the Meraki Cloud Controller. If RADIUS grants access, that information is sent back to the Cloud Controller and the client can proceed. 

If RADIUS accounting is enabled on top of this, it creates accounting start and stop messages (client authentication and deauthentication) and provides additional client session information. RADIUS accounting also introduces additional deauthentication behavior that is important to be aware of.

Additional details on the splash page flow and troubleshooting for various splash page options that the dashboard has to offer can be referenced in our Splash Page Traffic Flow and Troubleshooting article. This article will focus on Sign-on with splash page configuration on dashboard.

Connecting to SSID with RADIUS Splash and Authentication Process

When a client connects to the SSID, it will be able to associate to the AP (assigned an IP and will be listed as a client on Dashboard) but it will be unable to access network resources (assuming Walled Garden is set to “block all traffic until sign-on is complete”) until after they have authenticated through the splash page. The following steps occur once the client associates to the access point.

The client is redirected to the splash page on their first HTTP GET request. If you are looking at a packet capture from the client you will see a “Temporary Redirect” HTTP packet after the GET:


Within that packet you should see the Splash Page redirect URL:


When the client enters their credentials on the Splash Page, those credentials are sent to the Meraki Cloud Controller. The Cloud Controller then sends a RADIUS Access-Request to the RADIUS server.

Looking at a packet capture from the client, you will see the client establish a TLS session with the Cloud Controller.

In a capture from the RADIUS server you can see the contents of the Access-Request (use filter “radius”). In this case is the Cloud Controller and is the private IP of the RADIUS server.

After the RADIUS server receives the request it will respond to the Cloud Controller with an Access-Accept (or Reject if credentials don’t match user on RADIUS).

RADIUS Access-Accept message:

Once the RADIUS Access-Accept message is received by the Cloud Controller, the client will be permitted to proceed. They will be redirected either to the URL they were trying to fetch originally or a different URL as specified in Configure > Splash Page on Dashboard.

On Dashboard you can see the status of a client’s authorization (navigate to Network-wide > Monitor > Clients and select the client) and how long until they will be deauthenticated due to Session Timeout or Splash Frequency settings:

Splash RADIUS Standard Deauthentication Methods

There are four ways to deauthenticate RADIUS users who authenticate using splash page sign-on.

  1. Revoke access from the clients page in the Dashboard
  2. Use Splash Frequency Settings
  3. Configure Session Timeout on the RADIUS server. This will override the Splash Frequency settings.
  4. Change-of-Authorization (CoA) Disconnect

RADIUS Accounting

RADIUS Accounting (defined in RFC2866) is used to track additional information on a user’s session but it is important to note that it introduces additional deauthentication methods. Below will discuss how Meraki handles RADIUS Accounting.

When a client connects to a Splash Page SSID with RADIUS Auth and with Accounting enabled, the authorization process is the same, except there will be two additional RADIUS packets which will be the Accounting-Request and the Accounting-Response:

The request will be the accounting start message:

With RADIUS Accounting enabled, clients will be deauthenticated under these additional criteria regardless of Splash Page frequency settings or RADIUS session timeout settings:

  • Disconnect from SSID for > 1 min
    • This parameter can be disabled on Dashboard by disabling “Data-carrier detect” which is an option under accounting


  • The client transmits fewer than 1 KB per minute for at least 3 minutes
    • This parameter will be disabled if an idle-timeout is not set on the customer’s RADIUS server

With RADIUS Accounting disabled, the only deauthentications (as listed above) are caused by either the Splash Page frequency, RADIUS session timeout, or a manual revoke on the Dashboard.

RADIUS session timeout settings will always override Dashboard Splash Page frequency settings.

  1. The system will regard a login session as stopped if one of the following 5 events occurs:

    • User-Request: The user calls the logout http endpoint on splash (manual logout)

    • Session-Timeout: The login session expires (session timeout)

    • Lost-Carrier: The client disconnects from the network for more than 1 minute (lost carrier)

    • Idle-Timeout: The client transmits fewer than 1 KB per minute for at least 3 minutes (idle timeout)

    • Admin-Reset: An administrator revokes the login session via Dashboard (admin reset)

  2. If the login session is not stopped, the client may continue to use the network, and no RADIUS stop accounting message is sent to the RADIUS server.

  3. Within 60 seconds of a login session stopping, the client may no longer use the network, and should instead see splash.

  4. After at least 120 seconds, but within no more than 180 seconds, of a login session stopping, a RADIUS stop accounting message should be sent to the RADIUS server, with the total number of bytes and packets transmitted by the client.

 To see the accounting messages, run a packet capture from the RADIUS server and filter by “radius” in the capture.

The stop messages will be in the Accounting-Request packets
Further down you will see the specific message
It is recommended to add the Acct-Terminate-Cause as a column so it is easy to see (right click on the “Acct-Terminate-Cause” field as highlighted above and select “Apply as Column”)