Captive Portal Triage: Connected, No Login Page, No Internet
Tech GuruQuick Answer
Find the first failed layer: association, address and route configuration, DNS, portal discovery, authentication, access policy, or upstream connectivity. Compare one affected client with a known-good client before changing settings. Some systems use CAPPORT discovery rather than an HTTP redirect, and NAT is relevant only where the design uses it. Preserve timestamps and logs, make one bounded change, then repeat a fresh authorized customer journey.
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 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
RFC 8910 describes advertising a captive-portal API URI through DHCP or IPv6 router advertisements; support varies. MikroTik documents device-mode and default-table constraints plus an IPv4-dependent HotSpot path. OPNsense 26.1.6 introduced native captive-portal IPv6 support, with later fixes. These are platform-specific examples: use the actual installed release notes and test each enabled address family.
Before You Start: Safe Defaults
- Use a dedicated client whose portal authorization has expired or been removed through the supported procedure. A private browser does not clear gateway authorization tied to the device/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 diagram illustrates an IPv4/HTTP portal path. Use the same layer-by-layer method for the installed platform's addressing and discovery mechanisms; not every portal requires HTTP interception or NAT.
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 installed release and its IPv6/accounting fixes; the 26.1 introduction is historical context, not a requirement to stay on that branch.
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.
- Post-auth firewall policy and upstream routing work for each supported address family, including NAT where the design uses it.
- 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?
Publish the official HTTPS login URL, with a QR code if useful, and verify its certificate. A known plain-HTTP URL may trigger portal discovery, but it is a diagnostic step, not a place to enter credentials or payment details. Never bypass a certificate warning to complete login.
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/
