Captive Portal Triage: Connected, No Login Page, No Internet
Tech GuruConnected only proves Wi-Fi association. Captive portal triage needs the full chain: client joins SSID, gets DHCP, reaches gateway, resolves DNS, triggers an HTTP portal redirect, authenticates through voucher/RADIUS/payment, receives allowed policy, then reaches the internet through NAT and upstream routing.
Triage rule: Stop at the first broken layer and preserve its evidence. Test association, addressing, name resolution, portal discovery, authentication, policy, and upstream routing in order; changing several layers at once destroys the fault boundary.
The Short Version
- Start by deciding whether the issue affects one device or everyone.
- DHCP and DNS failures often look like portal failures because the login page never gets a normal HTTP request.
- HTTPS-first browsing, private MACs, stale cookies, walled gardens, and OS captive probes can all change symptoms.
The Reader Question
Why does Wi-Fi connect but the captive portal or internet does not work?
This runbook is for a small-site operator or support technician with authorized read access to client, DHCP, DNS, portal, authentication, firewall, and WAN status. It assumes one clean test device and a known portal URL. Menu names differ across MikroTik, UniFi, pfSense, OPNsense, and appliance portals, so use the packet path as the common model.
Current Platform Boundaries
Documentation was checked on 15 July 2026. RFC 8910 lets a network advertise a captive-portal API URI through DHCP or IPv6 router advertisements, reducing reliance on interception, but client and platform support still varies. RouterOS documentation says HotSpot can be blocked by device mode, uses only the default routing table rather than PCC multi-table routing, and currently relies on IPv4 NAT. By contrast, OPNsense 26.1.6 added native captive-portal IPv6 support and later 26.1 releases include fixes. Never apply one platform’s IPv6 or routing conclusion to another without checking its deployed release.
Before You Start: Safe Defaults
- Test with a fresh device or private browser session.
- Use a plain HTTP URL when portal auto-popup fails.
- Check DHCP lease, gateway, DNS, portal auth, NAT, and upstream in order.
- Keep a documented local login URL or QR code for users when auto-detection fails.
Reference Model
The reference model below shows the practical order for captive portal triage connected no login page no internet. Open each step for the operational detail behind the diagram.
Decision Matrix
| Choice | Best Fit | Watch Point |
|---|---|---|
| No IP | DHCP, VLAN, bridge, or pool issue | Check lease table and AP/gateway VLAN. |
| IP but no portal | DNS, HTTP redirect, or portal disabled | Open plain HTTP URL and inspect portal rules. |
| Portal but login fails | Voucher, payment, RADIUS, time, or stale session | Check auth logs and voucher roll. |
| Login works but no internet | NAT, firewall, route, DNS after auth, or ISP | Check WAN gateway and allowed rules. |
First 60 Seconds
Ask whether one device, one AP, one VLAN, or everyone is affected. A single iPhone stuck with private MAC behavior is a different problem from every customer missing DHCP leases.
Portal Detection Is Messy
Operating systems use captive portal probes, while modern browsing often starts with HTTPS that a portal cannot transparently redirect without certificate errors. RFC 8910 describes explicit portal discovery because interception resembles a man-in-the-middle technique and becomes less reliable as clients harden. A known plain HTTP test URL remains a diagnostic tool, not a reason to downgrade the authenticated portal or collect credentials over HTTP.
Platform Checks
For MikroTik, check device mode, HotSpot host and active tables, default-table routing, DNS, walled garden, rate limits, and IPv4 NAT. For UniFi, check hotspot status, guest policies, vouchers or payment/RADIUS, AP state, and the deployed Network application release. For pfSense, check the captive portal zone, vouchers, DNS, firewall, NAT, and the current documented IPv6 behavior. For OPNsense, verify the exact 26.1 patch level when troubleshooting newer IPv6 or accounting behavior.
A Practical Pilot Scenario
Reproduce with one fresh client and record timestamps at each layer before changing configuration. Compare with a second operating system only after the first chain is documented. If everyone fails at the same first layer, shift to site scope; if only one client fails, capture its private-address mode, lease, probe result, and remembered-session state without asking the user to disable privacy permanently.
A successful triage record names the first failing hop and the restoring action: no lease, wrong DNS, unreachable portal, bad certificate, rejected voucher, missing post-auth rule, wrong routing table, or dead WAN. It also includes a clean end-to-end retest after the fix. A popup appearing is not enough if authorization or internet access still fails.
Implementation Details
Export portal, firewall, NAT, routing, DHCP, DNS, and authentication configuration before edits. Change one object, note its prior value, and retest from a deauthorized client. If service worsens, restore that object or the known-good configuration rather than layering on more bypass rules. Avoid rebooting until volatile logs and active-session evidence are captured.
- Define scope: one client, one AP, one VLAN, one address family, or all users.
- Record association, client address, DHCP lease, gateway, DNS servers, routes, and system time.
- Test gateway reachability, then DNS by querying a known name; do not infer one from the other.
- Inspect the operating-system probe or RFC 8910/CAPPORT discovery, then open a known plain HTTP test URL.
- Verify portal certificate, walled-garden dependencies, voucher/payment/RADIUS decision, and active-session record.
- After authorization, test DNS again, then firewall/NAT, default route, policy routing, WAN gateway, and both IPv4/IPv6 where supported.
- Capture the first failure, one change, rollback value, and fresh-client validation.
Evidence To Collect
- Client OS/version, SSID/AP/VLAN, observed private MAC for this session, DHCP lease, gateway, DNS, and IPv4/IPv6 routes.
- Probe or CAPPORT result, HTTP status and redirect target, portal DNS answer, certificate name/validity, and walled-garden dependencies.
- Voucher, RADIUS, or payment reference and timestamp, authentication decision, active-session entry, and assigned policy.
- Post-auth DNS, NAT/firewall counter, routing-table decision, WAN gateway, and known HTTPS reachability.
- Redacted packet capture or logs around the failure, exported known-good config, changed object, rollback result, and clean-client retest.
Validation Checklist
- Fresh client can join, get DHCP, open portal, authenticate, and browse.
- DNS works before portal redirect as designed.
- Voucher/payment/RADIUS path logs success.
- NAT and WAN gateway work after auth.
- A repeatable support script exists for staff.
Maintenance Cadence
- Daily at customer sites: run one clean-client portal and post-auth internet test.
- Weekly: review DHCP pool pressure, probe failures, auth rejects, stale sessions, certificate warnings, and walled-garden errors.
- Monthly: test IPv4 and IPv6 deliberately where enabled, rotate the test client, verify time sync, export config, and test staff escalation.
- Before firmware, portal, payment, routing, or firewall changes: recheck platform release notes and preserve the exact rollback configuration.
Troubleshooting
| Symptom | Likely Cause | First Check |
|---|---|---|
| No login page | DNS/redirect/probe issue | Use plain HTTP URL and check portal redirect/walled garden. |
| Login rejected | Voucher expired, wrong roll, RADIUS/payment issue | Check auth logs and system time. |
| Login accepted, no internet | NAT, route, DNS, or ISP problem | Test WAN gateway, NAT rules, and post-auth DNS. |
Common Mistakes
- Assuming Wi-Fi connected means network connected.
- Testing only HTTPS websites and missing redirect behavior.
- Forgetting private MAC and stale session behavior.
- Blocking DNS required for portal detection.
- Fixing portal UI while DHCP or NAT is the real issue.
Useful Gear And Buyer Notes
A client adapter, travel router, cable tester, LTE hotspot, or spare AP is justified only when the evidence isolates a physical or fallback need. Verify chipset and OS support, captive-portal behavior, cellular bands and data limits, PoE standard, outdoor rating, warranty, and return policy; no diagnostic gadget replaces DHCP, DNS, auth, and routing logs.
Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.
- Amazon search: USB C Ethernet adapter
- Amazon search: travel router
- Amazon search: network cable tester
- Amazon search: LTE hotspot
- Amazon search: spare outdoor access point
Related TechGeeks Reading
- PisoWiFi Operations Notes: Start Here
- Networking Field Notes: Start Here
- Network Security Field Notes: Start Here
What This Does Not Protect or Validate
A working plain-HTTP redirect does not prove that OS probes, CAPPORT, certificate handling, payment, RADIUS, or post-auth policy work. One client test does not cover private-address rotation, every browser, dual-stack behavior, roaming, peak load, or a second WAN. Packet capture at one point may miss policy decisions made elsewhere.
No original multi-platform captive-portal lab was performed for this article. Portal logs and packet captures can contain device identifiers, usernames, destinations, and payment references; limit capture, redact exports, restrict access, and follow applicable privacy and retention requirements. A captive portal is not Wi-Fi encryption, and troubleshooting steps must not create an open administrative bypass or send credentials over an insecure page.
Practical FAQ
Why does the popup not appear?
OS captive detection may fail, HTTPS may not redirect, or DNS/portal probes may be blocked.
Should I post a login URL?
Yes. A QR code or simple HTTP login URL helps when auto-popup fails.
Why only one phone?
Private MAC, stale cookies, remembered network state, or OS-specific captive behavior can affect one client.
References
- https://www.rfc-editor.org/rfc/rfc8910.html
- https://manual.mikrotik.com/docs/authentication-authorization-accounting/hotspot-captive-portal/
- https://help.mikrotik.com/docs/spaces/ROS/pages/93749258/Device-mode
- https://docs.opnsense.org/releases/CE_26.1.html
- https://docs.netgate.com/pfsense/en/latest/troubleshooting/captiveportal.html
- https://help.ui.com/hc/en-us/articles/115000166827-UniFi-Hotspots-and-Captive-Portals
- https://support.apple.com/en-us/102509
- https://source.android.com/docs/core/connect/wifi-mac-randomization
- https://blog.apnic.net/2017/03/15/wi-fi-security-public-wifi-networks/
Final Thought
Captive portal triage becomes calm when you stop treating the portal as one thing and test the chain in order.
