Support checklist

Structured triage for guest-network and Sign In incidents — 1st-line information gathering, issue categorisation, network checks, escalation criteria and 2nd-line actions for Service Gateway and Meraki deployments.

When a user reports they can’t get onto the network — or can’t sign in, or disconnects unexpectedly — follow this checklist. It is written for 1st-line support and includes the information to collect before escalating to 2nd-line.

1. Basic information from the user

Identify the user

• Collect the user’s contact details (email, phone number).
• Note whether the user has previously accessed the network and whether the issue is recurring.

Ask about the user’s device

• Is the device connected wirelessly (Wi-Fi) or wired (Ethernet)?
• What operating system is being used (Android, iOS, iPadOS, macOS, Windows, Linux) and which version?
• Has the user recently:
  • Upgraded the operating system or installed new firmware?
  • Changed network settings or security configuration?
  • Installed new applications or security tools (VPN, antivirus)?
• Identify the device class — phone, laptop, printer, IoT sensor.

Scope of the issue

• Are other users at the same location affected?
• If not all users are affected, note any patterns (same OS version, same device class, same Access Policy).
• Ask whether the user is aware of a recent major OS update. iOS 18 / iPadOS 18 and macOS 15 introduced new MAC-address behaviour that frequently surfaces here — see MAC randomization in Apple products.

2. Categorise the issue

No access to the Captive Portal

• Test whether the Captive Portal loads from a reference device.
• Confirm the user is connecting to the correct SSID and that the browser supports redirection.
• Verify no blocking security setting on the device (VPN, firewall, proxy).
• Check the admin dashboard for a blocking entry (for example a MAC Blacklist) matching the user’s MAC.
• For iOS-specific portal-detection delays on Cisco WLC deployments, see Improving captive-portal detection for iOS.

No IP address assigned

• Service Gateway customers: in the admin dashboard, verify whether the user’s MAC is registered and an IP has been assigned. Confirm the user is on the expected VLAN and IP network for the location.
• Meraki customers: check the Meraki Dashboard for the SSID’s DHCP configuration if Meraki provides DHCP.
• Own-DHCP customers: ask the operator to validate the DHCP server.

Disconnection for unknown reasons

• Check timers and Access Policy settings that might affect the user (session duration, inactivity limits) in the admin dashboard.
• Look for heavy network load or AP / controller issues.
• Search the logs for recurring problems tied to the user’s MAC address.

Redirection issues

• In the admin dashboard, look at the user’s login records to see whether a sign-in attempt was made and what the redirect target was.
• Confirm the user’s email domain or SAML credentials are not blocked by Access Policy.
• Test using the same domain / SAML credentials on a reference device.

Login failure

• Open the user’s login record in the admin dashboard.
• For email / SAML: check the Access Policy’s email pattern allow-list — the user’s domain may not be allowed.
• For SAML: check the SAML log for the received assertion. See Sign In Module issues for module-specific failure patterns.
• For SMS: check the SMS provider’s delivery log.
• Test the same method yourself from a reference device with valid credentials.

3. Network and operator-system checks

Network monitoring

Check the operator’s system for:

• Issues with the Service Gateway.
• Errors in the routing table.
• Recent network reconfigurations.
• Replacement of network equipment (access points, routers, switches).
• Connectivity issues on the VLAN or SSID tied to the location.

Verify that the correct VLAN and IP network are active at the location.

Admin dashboard

Use the admin dashboard to:

• Check whether an IP has been assigned to the user’s MAC (Service Gateway customers).
• Search by MAC, IP or email to view login attempts and errors.
• Track the user’s connection history on the guest network.

Meraki-specific checks

• Verify Walled Garden settings in the Meraki Dashboard — traffic to the Sign In Captive Portal endpoints must be allowed pre-auth.

4. Escalation to 2nd-line support

If the issue persists after the steps above, gather the following before handing over:

User-tracking data

• MAC and IP address of the user’s device.
• User’s email and phone number, or other login identifier.
• Precise timestamps (with timezone) of the failure.
• A narrative description of exactly what the user did.

Device and network data

• Connection type — wired or wireless.
• Operating system and version.
• Any pattern across affected users (same device class, same OS update, same Access Policy).

Network status

• Notes or screenshots from the admin dashboard and network monitoring tools.
• Confirmation that the expected VLAN, SSID and IP network are configured at the location.

Actions already taken

• List every step performed during 1st-line triage so 2nd-line doesn’t repeat them.

5. Actions for 2nd-line support

Service Gateway customers

1. Verify DHCP configuration:
   • Ensure DHCP Addr. Required is enabled on the affected SSID for proper DHCP behaviour — see Improving captive-portal detection for iOS.
   • Check for conflicts in the DHCP server or IP pool in the admin dashboard.
2. Check IP Helpers:
   • Verify IP Helpers are configured to forward DHCP traffic between VLANs and the DHCP server.
   • Ensure they point to the correct DHCP server and are enabled on the appropriate routers / switches.

Meraki customers

1. Verify Walled Garden settings:
   • The Meraki Dashboard’s Walled Garden must permit traffic to the Sign In Captive Portal endpoints.
   • Adjust the configuration if entries are missing or incorrect.
2. DHCP settings:
   • Review the SSID’s DHCP settings in the Meraki Dashboard if Meraki provides DHCP.
   • For external DHCP, ask the customer to validate their server configuration.

Deeper network diagnostics

• Review logs from the network equipment for signs of packet loss, timeouts or other transport issues.
• Verify that session policies and timers are not negatively affecting the user.

Verification of OS-specific issues

• Investigate whether there are known compatibility issues with the current operating system and version. Major OS updates frequently change Wi-Fi behaviour — see MAC randomization in Apple products and Impact of Fast Transition (802.11r).
• Test using different device types and operating systems to determine whether the issue is OS-specific.
• Check whether other users with the same OS version or device class are reporting similar issues.

Verification of policies and filtering

• Ensure the user’s domain or SAML credentials are not blocked or incorrectly filtered by an Access Policy.
• Perform a test sign-in using the same login method to validate.

Related

Improving captive-portal detection for iOS

DHCP Addr. Required on Cisco WLC guest SSIDs.

MAC randomization in Apple products

iOS 18 / macOS 15 MAC handling.

Impact of Fast Transition (802.11r)

Why 802.11r should be disabled on guest SSIDs.

Sign In Module issues

Module-specific failure modes.