After a guest Wi-Fi complaint, identify one guest device, the failing hostname or task, the network name, and the exact time. First separate association, captive-portal, DNS-path, and policy failures. Then confirm which resolver answered, inspect the matched action, test the smallest temporary exception if justified, and verify both guest access and isolation.
A useful guest Wi-Fi diagnosis restores the intended guest task without broad allowlisting or collapsing network boundaries. Before asking for logs, record only the failed task, guest network, visible error, device class, and exact time. Ask what “does not work” means: joining the network, opening the sign-in page, resolving a hostname, loading one required service, or reaching resources that guests should never access. Do not request unrelated browsing history, personal account details, or a device inspection merely because connectivity failed. Each symptom has a different owner.
Classify the complaint before editing DNS
Start at the lowest failing layer. Confirm the device joined the intended guest SSID, received an address, gateway, and DNS configuration, and can reach the local gateway. Next check captive-portal state. RFC 8910 defines a DHCP and Router Advertisement option that can tell clients where a captive-portal API is located, but real devices and networks still vary in portal detection and presentation.1 A portal failure can look like broken DNS even when resolution is healthy.
- Cannot join: inspect authentication, radio, address allocation, capacity, and network admission.
- Joined but portal absent: inspect portal discovery, redirects, certificates, and pre-auth dependencies.
- Names do not resolve: confirm the assigned resolver is reachable from the guest segment.
- One site or app fails: inspect the exact hostname, policy action, aliases, and required dependencies.
- Private services are unreachable: confirm this is intentional guest isolation before treating it as a fault.
Keep the guest boundary intact while testing. CISA guidance on segmenting guest-network traffic and telemetry emphasizes separation from agency internal traffic; the same principle is useful beyond government environments.2 Do not move a guest onto a trusted employee network just to make the complaint disappear. That changes the security question and hides the actual guest-path failure.
Trace the guest resolution path
- Reproduce the complaint on one authorized test device connected to the same guest SSID.
- Record its network-provided resolver, exact hostname, expected task, and a five-minute window.
- Generate a fresh query and confirm which resolver received it and which action it returned.
- Check browser secure DNS, VPN, privacy relay, cellular fallback, and IPv6 as alternate paths.
- Compare one known allowed destination and the failing destination without browsing malicious content.
If the expected resolver never sees the query, editing its rules will not fix the guest. The device may use application-specific encrypted DNS, a VPN-supplied resolver, another address family, or cellular fallback. If the query arrives and is blocked, identify whether the winning source is a Tenant baseline, a guest-resource rule, a catalog entry, a redirect, or an enforced Tenant policy. If it is allowed, continue above DNS to TLS, HTTP, portal, application, or origin troubleshooting.
DNS filtering can act on domain lookups and policy outcomes. It cannot read page contents, full URLs, search terms, in-app chats, voice audio, or full browser history. A DNS event also does not prove a guest intentionally opened a site; operating systems, portal probes, embedded content, and background applications generate queries. RFC 9076 recommends treating DNS data as privacy-sensitive.3
Test a minimal guest-only correction
When evidence points to a false positive, validate the hostname and its classification through an authoritative security source or the policy owner before changing a threat decision. Then test an exact hostname exception on the guest resource rather than weakening the Tenant baseline; an enforced Tenant policy cannot be overridden. Confirm the hostname is required for the stated task through repeatable timing, official dependency documentation, or authorized application network evidence. A portal may depend on identity, certificate, content-delivery, or operating-system connectivity-check hostnames, but do not assume every query near sign-in is necessary.
Give a temporary exception an owner, expiry, and review trigger, then remove it when the visit or task ends. Avoid allowing an entire CDN, category, or provider because one portal asset failed. Avoid disabling filtering for all guests because one device uses a conflicting resolver. If acceptable and unwanted content share one hostname, DNS cannot make the content-level distinction; use the portal, application, proxy, or another suitable control.
Verify access without losing isolation
Repeat the complete guest journey from a clean state: join the SSID, receive network configuration, complete the portal if present, resolve the required hostname, and finish the original task. Then confirm a representative allowed destination still works and the intended guest-to-private-network separation remains. Test at least one other device class when the complaint appears platform-specific.
Check what happens after lease renewal and reconnection because guest identity, addresses, portal state, and resolver settings can change. Prefer aggregate resolver and portal health for routine monitoring. Open detailed activity only for a named troubleshooting purpose and short window, and do not retain a device-to-person mapping longer than the support and privacy policy allows.
Close the case with a reusable record
Tell the guest in plain language what was found, what changed, and what protection remained in place, then ask them to repeat the original task rather than merely confirming that a domain resolves. If DNS was not the cause, route the case to the network, portal, application, or remote-service owner with the evidence already collected. Record the guest network, device class, time, failing task, hostname, resolver path, matched action, corrective scope, verification results, exception owner, expiry, and review trigger. Do not store unnecessary personal details. A short operational record helps the next support helper distinguish a recurring portal dependency from capacity, resolver reachability, policy, or application failure.
Guest Wi-Fi questions
Why does guest Wi-Fi connect but show no internet?
The device may still need to complete a captive portal, may have received unusable network settings, may be unable to reach its assigned resolver, or may be blocked from a portal dependency. Test gateway, portal, DNS, and one allowed destination separately rather than assuming the DNS policy is responsible.
Should guests use the same DNS policy as employees?
Usually not by default. Guest traffic has different ownership, identity, access, privacy, and support expectations. A distinct guest network and purpose-based DNS policy make complaints easier to diagnose and help prevent a guest exception from weakening employee or infrastructure protection.
Can a DNS log identify which guest visited a page?
Not reliably. DNS shows domain lookups and policy outcomes, not page contents, full URLs, or the person behind a shared or changing address. Use the minimum device or session identifier authorized for troubleshooting, and avoid turning temporary guest support into broad surveillance.
Review one Veilty guest scope
In Veilty, keep the guest endpoint or network as a distinct resource in the appropriate Tenant. That resource may override its Tenant baseline for a justified narrow exception, while enforced Tenant policies take precedence and cannot be weakened. An invitation is account-scoped; Tenant access begins only after a Tenant role is granted. Review aggregate outcomes before opening retained activity. Saved DNS history is Tenant-scoped, end-to-end encrypted with user-held keys, and visible only to members whose Tenant roles allow access. The resolver still processes live DNS requests to answer them. Retest the guest task, keep isolation intact, and return to aggregate health when the case closes.