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

​
1. Gather basic user information

Before touching any system, collect: Who is the user
  • Email and phone number.
  • Have they accessed this network before? Is the issue recurring?
What device they’re using
  • Wired (Ethernet) or wireless (Wi-Fi)?
  • Operating system (Android, iOS, iPadOS, macOS, Windows, Linux) and version.
  • Recent changes on the device:
    • OS or firmware upgrade in the last few days.
    • Network, VPN, or security settings changed.
    • New applications or security tools installed (antivirus, VPN).
  • Device class — phone, laptop, printer, IoT sensor.
Scope of the issue
  • Only this user, or are others at the same location affected?
  • If only some — any patterns (same OS version, same device class, same access policy)?
  • Has the user seen a recent major OS update (iOS 18, macOS 15, Android 14)? Those often change behaviour — see Captive-portal detection for the iOS 18 / macOS 15 MAC-randomization changes in particular.

​
2. Categorise the issue

Pick the category that best matches the user’s report. The steps below are category-specific.

​
No access to the Captive Portal

The user joined the SSID but the portal never appears.
  • Test the portal from a reference device on the same network. If it works there, it’s a device-side problem. If it doesn’t, move to Network checks.
  • Confirm the user is on the correct SSID.
  • Confirm no VPN, firewall, or proxy on the device is intercepting traffic.
  • Check the Admin Portal for a Blacklist (block) entry matching the user’s MAC.
  • See Captive-portal detection for OS-level pop-up quirks.

​
No IP address assigned

The user connects to the SSID but the device has no address.
  • Service Gateway customers: open the Admin Portal, search for the user’s MAC, and check whether an IP has been assigned. Verify the user is on the expected VLAN and scope.
  • Meraki customers: check the Meraki Dashboard for DHCP configuration on the SSID.
  • Own-DHCP customers: ask the operator to check their DHCP server.

​
Sudden disconnection

The user was connected, then lost access for no obvious reason.
  • In the Admin Portal, open the user’s login record. Check session timers and access-policy expiry.
  • Check recent changes to the applicable Access Policy.
  • Look for unusual network load or issues on the AP / controller.
  • Search the logs for the user’s MAC — recurring errors point at a specific device or port.

​
Redirection issues (wrong destination after sign-in)

The user completed sign-in but lands somewhere unexpected.
  • Check the Access Policy’s redirect override.
  • Check the site-based redirect for the site the user is at.
  • Confirm the Context’s default redirect (Organization Settings → website).

​
Login failure

The user reaches the portal but the sign-in itself fails.
  • Open the Admin Portal and look at the user’s login attempts.
  • 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 SMS: check the SMS provider’s delivery log.
  • Try the same method yourself from a reference device with valid credentials.

​
3. Network and operator checks

If category-specific steps don’t resolve, widen the scope. Network monitoring
  • Service Gateway health.
  • Recent network configuration changes (reconfigurations, replaced access points or routers).
  • VLAN / SSID reachability at the location.
Admin Portal
  • Look up the user’s MAC / IP / email to see their complete history on the network.
  • Check for repeated errors tied to the MAC address.
Meraki-specific
  • Verify the walled garden in the Meraki Dashboard is configured to permit traffic to the Sign-In Captive Portal endpoints.
  • Confirm the Meraki Dashboard doesn’t report the client being blocked at a WLAN or group-policy level.

​
4. Escalation to 2nd line

If the issue isn’t resolved after the above, package the following and hand off: User tracking data
  • MAC and IP address.
  • Email, phone, or other login identifier.
  • Precise timestamps of failed attempts (with timezone).
  • A narrative of exactly what the user did, step by step.
Device and network data
  • Wired or wireless.
  • OS, OS version, device model.
  • Any pattern among affected users (same OS update, same device class, same location).
Network status
  • Screenshots or notes from the Admin Portal and network monitoring.
  • Confirmation of the expected VLAN / SSID / scope.
Actions already taken
  • List every step you performed so 2nd-line doesn’t re-run them.

​
5. 2nd-line actions

For reference, 2nd line typically checks: Service Gateway customers
  • DHCP Addr. Required on the SSID. Critical for iOS reliability — see Captive-portal detection.
  • IP Helper configuration: DHCP traffic forwarded to the correct server on the right VLANs.
  • Scope exhaustion or IP-pool conflicts.
Meraki customers
  • Walled garden entries on the Meraki Dashboard.
  • RADIUS connectivity between Meraki and Netgraph (the shared secret, reachability, and server / accounting-server rows shown on the Meraki Settings page).
  • Group-policy attachments at the Meraki level.

Captive-portal detection

iOS, 802.11r, MAC randomization quirks.

Sign In Module issues

Module-specific failure modes.