Solving the Connected but No Internet Error on Guest WiFi

Solving the Connected but No Internet Error on Guest WiFi — A Purple Technical Briefing [INTRODUCTION & CONTEXT — approximately 1 minute] Welcome to the Purple Technical Briefing series. I'm your host, and today we're tackling one of the most persistent and frustrating issues in enterprise venue networking: the "connected, no internet" error on guest WiFi. If you manage WiFi infrastructure at a hotel, retail chain, stadium, or conference centre, you will have seen this. A guest's device shows full signal bars, it's associated to your access point, it's been assigned an IP address — and yet the browser returns nothing. The captive portal never loads. The guest calls the front desk. Your support team runs a ping test, everything looks fine on paper, and yet the problem keeps recurring. Here's the thing: in the vast majority of cases I encounter across enterprise deployments, this is not a hardware fault, not a firewall misconfiguration, and not a bandwidth problem in the traditional sense. It is a DNS timing issue — and it is almost always triggered by network congestion. Today I want to walk you through exactly why that happens, how to diagnose it reliably, and how deploying an enterprise DNS filter resolves the bottleneck permanently. [TECHNICAL DEEP-DIVE — approximately 5 minutes] Let's start with the fundamentals. When a guest device connects to your WiFi network, the very first thing it needs to do — before it can load a single webpage, before your captive portal can redirect it, before any authentication can happen — is resolve a domain name to an IP address via DNS. The Domain Name System is the phonebook of the internet. Without it, your device has no way of knowing where to send traffic. Now, here's where the problem begins. Most consumer devices — iPhones, Android handsets, Windows laptops — have a built-in mechanism called a captive portal detection probe. On iOS, for example, the device sends an HTTP request to a known Apple endpoint, something like captive.apple.com. On Android, it hits connectivitycheck.gstatic.com. On Windows, it probes msftconnecttest.com. These probes are designed to detect whether the network requires a login page before granting internet access. The critical point is this: these probes are DNS-dependent. The device must first resolve the domain name of the probe endpoint before it can send the HTTP request. And that DNS query has a timeout — typically between one and five seconds depending on the operating system. If the DNS resolver on your network does not respond within that window, the device concludes that the network has no internet connectivity, even though it is fully associated and has a valid IP address. That is the "connected, no internet" error. It is not a connectivity failure — it is a DNS response failure. So why does DNS fail on a congested network? This is the part that catches a lot of teams out. DNS queries are sent over UDP by default, on port 53. UDP is a connectionless protocol — there is no handshake, no acknowledgement, no retransmission at the transport layer. If a DNS packet is dropped due to network congestion, the client simply waits until the timeout expires and then either retries or gives up. On a guest WiFi network with hundreds or thousands of concurrent devices — think a stadium during a match, a hotel at full occupancy, a conference centre during a keynote — the upstream link and the DNS resolver can become saturated very quickly. The problem is compounded by the fact that guest networks typically share a single upstream DNS resolver, often the ISP's default resolver or a public resolver like 8.8.8.8. When every device on the network is simultaneously probing for captive portal detection, running background app updates, and making DNS queries for social media and streaming services, that single resolver becomes a bottleneck. Query response times climb from the normal sub-50-millisecond range into the hundreds or even thousands of milliseconds. Timeouts start occurring. The "connected, no internet" errors begin flooding in. There is also a secondary mechanism worth understanding: TTL exhaustion. DNS responses include a Time To Live value that tells the receiving device how long to cache the resolved IP address. On a congested network where devices are constantly associating and disassociating — which is common in high-density venues — cached entries expire and must be re-resolved frequently. This increases the DNS query load on the resolver precisely when the network is under the most stress. Now, the traditional response to this problem is to throw bandwidth at it — upgrade the upstream link, add more access points, implement QoS policies. These are all valid measures, but they do not address the root cause. The root cause is that your DNS resolution path is unoptimised for high-density guest environments. And that is exactly what an enterprise DNS filter solves. An enterprise DNS filter — such as the DNS filtering capability within Purple's guest WiFi platform — operates as a local, high-performance DNS resolver that sits between your guest devices and the upstream internet. Rather than forwarding every query to a remote public resolver, it maintains a local cache of frequently resolved domains, handles captive portal detection probes natively, and applies policy-based filtering to block malicious or non-compliant domains before they ever reach the upstream resolver. The result is dramatically reduced DNS query latency — typically from two-to-three-second timeouts down to sub-200-millisecond responses — which means captive portal detection probes succeed on the first attempt, the "connected, no internet" error disappears, and guest onboarding time drops significantly. From a standards perspective, this architecture aligns with IEEE 802.11 recommendations for high-density deployments and supports compliance with GDPR data handling requirements by allowing you to log and audit DNS queries — which is relevant if you are operating under a public sector or hospitality licence. It also supports PCI DSS network segmentation requirements by ensuring guest DNS traffic is isolated from your corporate resolver infrastructure. [IMPLEMENTATION RECOMMENDATIONS & PITFALLS — approximately 2 minutes] Let me give you the practical deployment guidance. When you are rolling out an enterprise DNS filter on a guest WiFi network, there are three configuration decisions that will determine whether you succeed or fail. First, resolver placement. Your DNS filter must be deployed as close to the guest network as possible — ideally on the same VLAN or subnet as your guest access points. Every hop between the guest device and the resolver adds latency. If your DNS filter is sitting in a remote data centre and your guest network is in a hotel in Manchester, you are adding round-trip time that defeats the purpose. Use a local appliance or a cloud-delivered DNS filter with a regional point of presence. Second, captive portal DNS passthrough. This is the most common misconfiguration I see. When you deploy a DNS filter, you must ensure that the captive portal's own domain — the URL that guests are redirected to for authentication — is whitelisted in the filter. If the filter blocks or delays resolution of your captive portal domain, you will recreate the exact problem you were trying to solve. Always test captive portal resolution explicitly after deploying any DNS filtering policy. Third, TTL tuning. Configure your local DNS resolver to serve short TTLs for captive portal detection probe domains — Apple, Google, Microsoft — so that devices re-query frequently and always get a fast local response rather than waiting for a cached entry to expire and then hitting a congested upstream resolver. A TTL of 30 to 60 seconds for these specific domains is a reasonable starting point. The pitfall to avoid is over-filtering. Some teams deploy aggressive DNS blocklists that inadvertently block domains used by legitimate guest applications — streaming services, corporate VPN endpoints, cloud storage. This generates a different class of support ticket but is equally damaging to guest experience. Start with a conservative policy, monitor DNS query logs for blocked domains, and refine over a two-week period before locking down the configuration. [RAPID-FIRE Q&A — approximately 1 minute] Let me run through the questions I get asked most often on this topic. "Can I just use 8.8.8.8 as my guest DNS resolver?" You can, but under load it will timeout. A local or regional resolver will always outperform a public resolver on a congested network. "Does this affect WPA3 deployments?" No — WPA3 improves authentication security but does not change the DNS resolution path. The same DNS timeout problem occurs regardless of the encryption standard in use. "How do I know if DNS is the actual cause of my 'connected, no internet' errors?" Run a packet capture on the guest VLAN during peak load. Filter for UDP port 53 traffic. If you see DNS queries with no corresponding response within two seconds, DNS timeout is your culprit. "Does an enterprise DNS filter help with compliance?" Yes — DNS query logging provides an audit trail that supports GDPR accountability obligations and can assist with incident response. Purple's platform includes this logging natively. [SUMMARY & NEXT STEPS — approximately 1 minute] To summarise: the "connected, no internet" error on guest WiFi is overwhelmingly a DNS timing problem caused by network congestion overwhelming an unoptimised resolver path. The fix is not more bandwidth — it is a local, high-performance enterprise DNS filter that resolves captive portal detection probes quickly, maintains a local cache, and applies policy-based filtering to reduce upstream query load. The three things to do this week: run a DNS packet capture during peak load to confirm the diagnosis; review your current DNS resolver placement and identify whether it is local or remote; and evaluate an enterprise DNS filter deployment on your guest VLAN. If you want to go deeper on any of this, the Purple platform documentation covers DNS filter configuration in detail, and the guest WiFi optimisation guides on purple.ai are worth reviewing alongside this briefing. Thanks for listening — I'll see you on the next one. [END OF EPISODE]