Skip to content
Troubleshooting

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.

  • Collect the user’s contact details (email, phone number).
  • Note whether the user has previously accessed the network and whether the issue is recurring.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

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.

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.
  • Verify Walled Garden settings in the Meraki Dashboard — traffic to the Sign In Captive Portal endpoints must be allowed pre-auth.

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

  • 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.
  • Connection type — wired or wireless.
  • Operating system and version.
  • Any pattern across affected users (same device class, same OS update, same Access Policy).
  • 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.
  • List every step performed during 1st-line triage so 2nd-line doesn’t repeat them.
  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.
  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.
  • 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.
  • 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.
  • 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.

Next