Skip to main content
English (US)

Solving the Connected but No Internet Error on Guest WiFi

You will be able to diagnose why guests see "connected, no internet" on guest WiFi and fix the cause with a configuration change, not new hardware. The guide shows how to separate DNS timeouts from DHCP, walled garden and rate-limit faults, then deploy a nearby enterprise DNS filter on the access points you already run.

By Tom HackettPublished Updated
📖 10 min read2,240 words2 worked examples3 practice questions10 key definitions

Video overview

Listen to this guide

View podcast transcript
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 convention center, 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 cell phones, 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 acknowledgment, 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 game, a hotel at full occupancy, a convention center 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 unoptimized 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 CCPA/CPRA 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 license. 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 center and your guest network is in a hotel in Chicago, 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 allowlisted 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 time out. 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 CCPA/CPRA accountability obligations and can assist with incident response. Purple's platform includes this logging natively. [SUMMARY & NEXT STEPS - approximately 1 minute] To summarize: the "connected, no internet" error on guest WiFi is overwhelmingly a DNS timing problem caused by network congestion overwhelming an unoptimized 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 optimization guides on purple.ai are worth reviewing alongside this briefing. Thanks for listening - I'll see you on the next one. [END OF EPISODE]

Part of our core series: Guest WiFi Guide →

Interactive Diagnostic ToolUpdated for Enterprise WiFi & Captive Portal Architecture

Guest WiFi “Connected, No Internet” Root-Cause Diagnostic Tool

Select your venue deployment profile, active connection failure symptom, and wireless infrastructure vendor to calculate probe timeout risks, diagnose DNS/DHCP bottlenecks, and generate multi-vendor remediation steps.

Estimated Probe Latency
~325 ms
Target: <50ms for reliable Apple CNA
Timeout / Drop Probability
88%
Risk Level: Critical
Recommended DHCP Lease
480 mins
Subnet: /21
Active Probe Domain
captive.apple.com
Fallback: connectivitycheck.gstatic.com

Root-Cause Diagnostic Analysis: Captive portal login popup never appears on mobile devices

Severity: Critical
Root Cause:

OS captive portal detection probe DNS queries exceed the 2-5 second timeout window due to upstream resolver latency or dropped UDP packets.

Business Impact:

Devices display "Connected, No Internet" and automatically drop the connection or fail back to mobile cellular data.

Primary Engineering Remedy:

Deploy a local enterprise DNS caching filter, allowlist probe domains, and ensure UDP port 53 is allowed pre-authentication.

Vendor Implementation Guide: Cisco Meraki (Meraki Dashboard)

  1. DNS Configuration & Resolver Tuning:
    Under Wireless > Configure > Access control > Addressing and traffic, set Client IP assignment to "External DHCP server" or "Bridge mode" with reliable public Anycast DNS (1.1.1.1, 8.8.8.8).
  2. DHCP Scope & Lease Duration:
    In Security & SD-WAN > Configure > Addressing & VLANs, decrease DHCP lease time on the Guest VLAN to 30 minutes to prevent scope starvation.
  3. Walled Garden Pre-Authentication Rules:
    Under Wireless > Access control > Walled garden, enable Walled garden and add: *.purple.ai and the portal hosts only. Leave the OS probe hosts (captive.apple.com, connectivitycheck.gstatic.com, msftconnecttest.com) out, or devices will think they are online.
Configuration Snippet:
# Meraki Dashboard Configuration:
# 1. Wireless > Configure > Access Control > Splash Page: "Sign-on splash page"
# 2. Walled Garden ranges: *.purple.ai, fonts.googleapis.com (not the OS probe hosts)
# 3. Client IP assignment: Bridge Mode (NAT mode restricts Layer 2 client isolation)

Experiencing guest WiFi onboarding failures across your venue?

Purple works with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet, and manages the pre-auth walled garden and DNS allowances that most of these failures trace back to.

Useful? Link to this tool

The connected but no internet error on guest WiFi occurs when connectivity checks fail before the captive portal loads. In busy venues, UDP port 53 DNS queries (RFC 1035) time out during congestion. Resolving it requires pointing guest DHCP scopes to a caching DNS filter, completing walled garden domains across controllers like Cisco Meraki, and reviewing traffic shaping rules.

What does "connected, no internet" look like on guest WiFi?

The guest sees full signal bars and a joined network, but nothing loads. The login page never appears, so they cannot accept terms or sign in. They then walk to the front desk, the help point or the service counter.

Each operating system words the warning differently. Your venue support team should recognize all of them:

  • Windows shows "No internet" under the network name.
  • Android shows "Connected without internet" or "Internet may not be available".
  • iPhone and iPad show "No Internet Connection" under the network name.

All three come from the same mechanism. After joining, the device asks for a known web address to test the connection. If that test returns the expected page, the device treats the connection as working. If it returns a login page, the device opens the captive portal. If it gets no answer at all, the device reports "no internet".

Operating system Connectivity-check hostname What the guest sees on failure
iOS, iPadOS, macOS captive.apple.com "No Internet Connection"
Android connectivitycheck.gstatic.com "Connected without internet"
Windows 10 and 11 www.msftconnecttest.com "No internet"

Before the device can request any of these pages, it has to look up the hostname through DNS. That lookup is where most high-density failures start.

What usually causes connected no internet errors on guest WiFi?

DNS timeouts on a congested network

DNS (Domain Name System) turns a hostname into an IP address. Most DNS queries travel over UDP port 53, as defined in RFC 1035. UDP has no built-in retransmission, so a dropped query simply waits for the device's own retry timer.

Congestion arrives in bursts. Think of halftime at a stadium, breakfast check-out at a hotel, or a train pulling into a station. Hundreds of devices join within seconds, and every one sends a lookup at once. If the resolver sits several hops away across a busy WAN link, queries get delayed or dropped. The device gives up, the portal never opens, and the guest sees "no internet".

The other usual suspects

DNS is the most common cause in busy venues, but not the only one. Rule these out as well:

  • Missing walled garden entries. The walled garden is the list of domains a device may reach before login. If your portal or its assets are missing, the page cannot load.
  • DHCP pool exhaustion. If the address pool runs out, devices assign themselves a 169.254.x.x address and cannot reach anything.
  • Rate limits or QoS throttling UDP port 53. A per-client or per-SSID limit set too tightly can starve DNS during a surge.
  • Encrypted DNS. DNS over HTTPS (DoH, RFC 8484) and DNS over TLS (DoT, RFC 7858) send lookups to outside resolvers. A walled garden that blocks those resolvers stops the lookup before login.
  • An upstream outage. If the WAN link itself is down, every device fails and every wired port fails too.

How do you work out which cause you have?

Start with the pattern, not the hardware. Use this matrix to narrow the cause before you change anything.

What you observe Most likely cause First action
Errors spike at predictable peaks, fine at quiet times DNS timeouts under congestion Point guest DHCP at a nearby caching DNS filter
Every device fails, all day Upstream WAN outage or wrong DNS server in DHCP Test the WAN link and the DHCP DNS setting
Device shows a 169.254.x.x address DHCP pool exhausted Enlarge the pool or shorten lease times
Portal starts to load but stalls or shows a blank page Portal domains missing from the walled garden Add the domains from your Purple setup article
Only some Android devices or laptops fail Private DNS, DoT or DoH set on the device Ask the guest to switch Private DNS to Automatic
Fails only above a set number of devices per AP Rate limits or QoS on UDP port 53 Review guest SSID traffic-shaping rules

Three checks your support team can run

  1. Check the device's IP address. A 169.254.x.x address points to DHCP, not DNS. A normal guest-range address means the device joined properly.
  2. Time a lookup from a test device. Run nslookup captive.apple.com from a laptop on the guest network. A slow or failed answer during a busy period confirms a DNS bottleneck.
  3. Capture packets on the guest VLAN. A VLAN (virtual LAN) separates guest traffic from your other networks. Filter the capture on udp port 53 and look for queries with no matching response.

Then check when the errors happen. In WiFi Analytics, compare connection and login volumes against the times guests report problems. Failures that track your busiest hours point firmly to congestion.

How does an enterprise DNS filter fix the bottleneck?

An enterprise DNS filter is a resolver you control, placed close to the guest network. It replaces the distant ISP or public resolver that DHCP hands out today. It does three jobs that remove the timeout.

It answers from cache. Connectivity-check hostnames are requested thousands of times an hour in a busy venue. A nearby filter answers repeat lookups from its cache, so they never cross the congested WAN link.

It drops unwanted traffic early. Queries for malicious or blocked categories are refused at the filter. That frees WAN capacity for lookups that matter.

It logs every query. You get a record of which domains failed, when and how often. That turns guesswork into evidence the next time a manager reports a problem.

Where to place it

For a distributed estate, such as a retail chain with hundreds of small sites, a cloud-delivered filter with nearby edge locations is usually the practical choice. For a single large site, such as a stadium or convention center, a resolver hosted on site keeps lookups off the WAN entirely. In both cases, hand out two resolver addresses in DHCP so one failure cannot take the network down.

Two settings that decide success

First, allow your captive portal domains in the filter. A filter that blocks or delays the portal recreates the exact error you set out to fix. Second, keep guest DNS separate from corporate DNS. PCI DSS treats network segmentation as the way to keep a guest network out of your cardholder data environment's scope.

Got questions about your specific setup?

Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.

How do you fix it on each vendor and operating system?

On your access points and controller

Purple is hardware-agnostic and runs as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. The fix follows the same three steps on every one of them:

  1. Update the DNS servers in the guest DHCP scope to your enterprise DNS filter.
  2. Complete the walled garden. Cisco Meraki, HPE Aruba and Ruckus all use the term "walled garden". Follow the Purple setup article for your vendor, which lists the exact domains to allow.
  3. Check guest traffic shaping so per-client limits do not throttle UDP port 53 during a surge.

Do not copy settings between vendors. Menu names and defaults differ, so use the vendor's own documentation alongside the Purple setup article.

On the guest's device

When a single guest is affected and everyone else is fine, your desk team can try these steps:

  • Forget the network and rejoin to trigger a fresh connectivity check.
  • Open a plain http:// address in the browser to force the portal to appear.
  • On Android, set Private DNS to Automatic. A fixed Private DNS provider can block the lookup before login.
  • Pause any VPN app until the guest has signed in.

Worked scenarios

The figures below are illustrative, not drawn from a named deployment. Use them as a model for what to measure at your own venue.

A 200-room hotel at breakfast

Situation. Front-desk complaints about "no internet" cluster between 7am and 9am, when guests check email before checkout. The access points show healthy signal and spare airtime. Guest DHCP hands out the ISP's resolver, several hops across a busy line.

What was done. The IT manager ran nslookup during the peak and saw lookups failing outright. The team pointed guest DHCP at a cloud DNS filter, added the portal domains to the walled garden and kept guest DNS separate from the property management network.

Outcome. Measured in WiFi Analytics and the desk log, portal completions at peak rose from 81% to 97%. WiFi complaints at the desk fell from about 15 a morning to two. For more on hotel guest networks, see our hospitality pages.

A 30,000-capacity stadium at halftime

Situation. Fans reported "connected without internet" at every halftime, while the first ten minutes of each half ran cleanly. Packet captures on the guest VLAN showed DNS queries with no response during the surge.

What was done. The network architect deployed an on-site resolver with a cloud fallback. The team removed a per-client rate limit that throttled UDP port 53, and moved the DHCP scope to the new resolver.

Outcome. Unanswered DNS queries at halftime dropped from 12% to under 1% in follow-up captures. Fan logins during the interval rose by 40% on the previous game.

How do you stop connected no internet errors happening again?

  • Never rely on a distant public resolver alone. Public DNS performs well in general, but a resolver several hops away adds delay you cannot control during a surge.
  • Alert on unanswered DNS queries. Configure your firewall or core switch to flag rising UDP port 53 drops on the guest network, which signal timeouts before guests notice.
  • Review DNS filter blocklists every month. Over-aggressive categories break legitimate apps and create new support tickets.
  • Set a log retention period. DNS logs link IP addresses to the domains visited, so treat them as personal data under CCPA/CPRA.
  • Adopt RFC 8910 where your hardware supports it. It lets DHCP tell the device where the captive portal is, so the device relies less on a connectivity-check lookup.
  • Consider Passpoint for returning visitors. Passpoint (also called Hotspot 2.0) and OpenRoaming let devices join securely without a captive portal, which removes this failure mode for them entirely.

Purple runs Guest WiFi at 80,000+ live venues in over 90 countries, with 500 million users and logins a year. From healthcare waiting rooms to trains, the pattern holds: fix DNS before you buy bandwidth.

Frequently asked questions

Do we need new access points to fix connected no internet errors?

No, in most cases you do not. When the error tracks peak times, the cause is usually DNS resolution, not access point hardware. The fix is a configuration change: point guest DHCP at a nearby enterprise DNS filter, complete the walled garden and review traffic-shaping rules. Replace hardware only after packet captures show the access points themselves dropping traffic at normal loads, and after you have ruled out DHCP and DNS.

Does Purple work with the hardware we already own?

Yes, Purple runs on the access points you already have. Purple is hardware-agnostic and deploys as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. There is no rip and replace. Purple publishes a setup article for each vendor, listing the walled garden domains your controller needs so the captive portal loads before guests sign in.

Will an enterprise DNS filter slow down our guest WiFi?

No, a well-placed DNS filter usually makes lookups faster. It sits closer to the guest network than an ISP or public resolver and answers repeat lookups from its cache. The risk lies in placement and configuration, not in filtering itself. Hand out two resolver addresses for redundancy, and allow your captive portal domains so the filter never delays the login page.

Why not just give guests a public resolver such as 8.8.8.8?

You can, but it does not fix congestion timeouts. A public resolver still sits across your WAN link, so every lookup competes with the traffic surge that causes the failure. It also gives you no filtering and no query logs for troubleshooting. A nearby enterprise filter answers from cache, refuses unwanted categories and records every failed lookup, which public DNS cannot do for you.

How do we handle DNS query logs under CCPA/CPRA?

Treat DNS logs as personal data, because they link IP addresses to the domains a device visited. Set a defined retention period, restrict access to your network and security team, and record the purpose in your privacy notice. Purple is ISO 27001 certified and CCPA/CPRA compliant, and your DNS filter supplier should show equivalent certification before you route guest traffic through it.

How much effort does deployment take?

The change itself is small; testing takes most of the effort. You update the DNS servers in the guest DHCP scope, add portal domains to the filter's allow list and check the walled garden. Plan to test during a real peak, such as a breakfast rush or halftime, because a quiet afternoon will not reproduce the congestion that caused the error.

Will Passpoint or OpenRoaming remove the error?

Yes, for devices that use them. Passpoint and OpenRoaming let devices join securely without a captive portal, so there is no portal to fail. First-time visitors and devices without a Passpoint profile still use the captive portal, so you still need fast DNS and a complete walled garden. Run both together: Passpoint for returning visitors, a tuned portal for everyone else.

Key Definitions

Captive portal

The login page a guest network serves before granting internet access. RFC 8910 defines a DHCP and IPv6 Router Advertisement option that tells the device the portal's API address, so it does not have to infer the portal from a failed web request.

Your guests accept terms or sign in here. If the portal never opens, they cannot get online and the problem lands at the front desk or help point.

Connectivity check

An HTTP request each operating system sends to a known hostname after joining a network: captive.apple.com on iOS, iPadOS and macOS, connectivitycheck.gstatic.com on Android, and www.msftconnecttest.com on Windows 10 and 11. The expected page means online, a login page triggers the portal, and no answer means "no internet".

This check produces every variant of the warning your support team sees. It depends on a DNS lookup first, which is where high-density failures start.

DNS (Domain Name System)

The protocol that resolves hostnames to IP addresses, specified in RFC 1035. Most queries travel over UDP port 53, which has no built-in retransmission, so a dropped query waits on the device's own retry timer.

When hundreds of devices join at once and the resolver sits across a busy WAN link, lookups time out and the portal never opens.

Enterprise DNS filter

A resolver you control, placed close to the guest network, that answers repeat lookups from cache, refuses queries for malicious or blocked categories, and logs every query by domain, time and frequency.

It replaces the distant ISP or public resolver in your guest DHCP scope. Deploy it cloud-delivered for distributed properties or on site for a single large venue.

Walled garden

The list of domains a device may reach before authentication on a captive portal network. Cisco Meraki, HPE Aruba, and Ruckus all use the term in their controller configuration.

If your portal domains or assets are missing, the page stalls or shows blank. Purple's per-vendor setup article lists the exact domains to allow.

DHCP pool exhaustion

The state where a Dynamic Host Configuration Protocol (RFC 2131) server has no free addresses left in its scope, so new devices assign themselves a 169.254.x.x link-local address and cannot reach anything.

A 169.254.x.x address on a guest device points to DHCP, not DNS. Enlarge the pool or shorten lease times.

DNS over HTTPS (DoH) and DNS over TLS (DoT)

Encrypted DNS transports: DoH carries queries inside HTTPS as specified in RFC 8484, and DoT carries them over a TLS session as specified in RFC 7858. Both send lookups to resolvers outside your network.

A walled garden that blocks those outside resolvers stops the lookup before login. On Android, ask the guest to set Private DNS to Automatic.

VLAN (virtual LAN)

A logical network segment defined by IEEE 802.1Q tagging, which separates guest traffic from other networks on shared switching infrastructure.

Capture packets on the guest VLAN filtered on udp port 53 to find unanswered queries. Segmentation also keeps guest traffic out of PCI DSS cardholder data environment scope.

Passpoint (Hotspot 2.0) and OpenRoaming

Passpoint, also called Hotspot 2.0, builds on IEEE 802.11u network discovery and IEEE 802.1X port-based authentication so a device with a profile joins securely without a captive portal. OpenRoaming extends this across participating networks.

Returning visitors with a profile never hit the portal, so this failure mode disappears for them. First-time visitors still need fast DNS and a complete walled garden.

CCPA/CPRA personal data (DNS logs)

Under CCPA/CPRA and EU GDPR, information linking an identifier such as an IP address to activity counts as personal data, which requires a defined purpose, limited retention, and restricted access.

DNS filter logs link IP addresses to domains visited. Set a retention period, restrict access to your network and security team, and record the purpose in your privacy notice.

Worked Examples

A 200-room hotel sees front-desk complaints about "no internet" between 7am and 9am. Access points show healthy signal and spare airtime, and guest DHCP hands out the ISP's resolver several hops across a busy line. What should the IT manager do? (Figures are illustrative.)

The IT manager ran nslookup from a guest-network laptop during the peak and saw lookups failing outright, which confirmed a DNS bottleneck rather than a radio fault. The team pointed guest DHCP at a cloud DNS filter so repeat connectivity-check lookups were answered from cache. They added the portal domains to the walled garden so the login page loaded before sign-in. They kept guest DNS separate from the property management network to preserve segmentation. Measured in WiFi Analytics and the desk log, portal completions at peak rose from 81% to 97%, and desk complaints fell from about 15 a morning to two.

Fans at a 30,000-capacity stadium report "connected without internet" at every halftime, while the first ten minutes of each half run cleanly. Packet captures on the guest VLAN show DNS queries with no response during the surge. How should the network architect respond? (Figures are illustrative.)

The pattern pointed to congestion, so the architect deployed an on-site resolver with a cloud fallback. Keeping lookups on site took them off the WAN entirely during the surge. The team also found and removed a per-client rate limit that throttled UDP port 53, which starved DNS when thousands of devices joined at once. They moved the guest DHCP scope to the new resolver. Follow-up captures showed unanswered DNS queries at halftime dropping from 12% to under 1%. Fan logins during the interval rose by 40% over the previous game.

Practice Questions

Q1. A stadium IT director notices that during half-time, thousands of users connect to the WiFi but fail to reach the captive portal. The core switch shows heavy UDP packet drops. Should they increase the WAN bandwidth from 2Gbps to 5Gbps?

Hint: Consider what protocol is being dropped and whether it's related to payload bandwidth or connection state limits.

View model answer

No. Increasing WAN bandwidth will not solve the issue. The UDP packet drops indicate that the firewall or resolver cannot handle the sheer volume of concurrent DNS queries (state table exhaustion or CPU limits). The correct approach is to deploy a high-performance local DNS filter at the edge to cache and respond to these queries locally, bypassing the WAN bottleneck entirely.

Q2. You have just deployed an enterprise DNS filter on a hotel guest network. Guests can now resolve public websites quickly, but when they first connect, they are not redirected to the hotel's login page. What is the most likely configuration error?

Hint: Think about the domain name of the login page itself.

View model answer

The most likely error is that the captive portal's own domain has not been explicitly allowed (passthrough) in the DNS filter. The filter is either blocking or delaying the resolution of the portal URL, preventing the redirection from completing.

Q3. A public sector organization requires all guest WiFi traffic to be logged for 90 days to comply with security policies. How does deploying an enterprise DNS filter assist with this requirement?

Hint: Consider what data a DNS filter processes versus a standard firewall.

View model answer

An enterprise DNS filter natively logs all DNS queries made by client devices. This provides a clear, searchable audit trail of which domains were requested and when, satisfying the 90-day logging requirement without needing to perform deep packet inspection on all encrypted HTTPS payload traffic.

Frequently asked questions

Why does guest WiFi say connected but no internet?

The 'Connected, No Internet' status occurs when a client device associates with an access point and receives an IP address, but its operating system detection probe fails to reach the internet. On guest WiFi networks, this is most commonly caused by DNS query timeouts on captive portal detection domains (such as captive.apple.com or connectivitycheck.gstatic.com), DHCP lease scope exhaustion, or firewalls blocking pre-authentication DNS traffic.

How do captive portal detection probes work on guest WiFi across iOS, Android, and Windows?

When connecting to an open or guest WiFi SSID, modern operating systems immediately transmit plaintext HTTP probe requests to vendor test URLs (iOS uses captive.apple.com/hotspot-detect.html, Android queries connectivitycheck.gstatic.com/generate_204, and Windows tests msftconnecttest.com/connecttest.txt). If the network returns an HTTP 200/204, the OS marks the connection as having internet. If it receives an HTTP 302 redirect, it launches the captive portal browser. If the initial DNS query for the probe domain times out, the OS reports 'Connected, No Internet' and drops the link.

How do DNS timeouts trigger guest WiFi connection drops?

In high-density environments, hundreds of devices query upstream DNS resolvers simultaneously over UDP port 53. If the local guest WiFi network forwards raw queries directly to rate-limited ISP resolvers without caching, response latency spikes above 2,000ms. Mobile devices enforce strict 2- to 5-second probe timeouts. Once that threshold is exceeded, the device assumes the network is broken and abandons the connection before the splash page can load.

What walled garden domains must be allowed before guest WiFi captive portal login?

Pre-authentication access control lists (walled gardens) on guest WiFi networks must permit outbound UDP and TCP port 53 to your designated DNS resolvers, DHCP transactions (UDP 67/68), and OS detection probes (captive.apple.com, connectivitycheck.gstatic.com, msftconnecttest.com). If using external captive portal hosting, CDN styling, or social login, you must also allow your portal domain (*.purple.ai), Google Fonts (fonts.googleapis.com), and OAuth endpoints.

How does DHCP pool exhaustion cause connected without internet errors on guest WiFi?

When venues configure long DHCP lease durations (such as 24 hours) on guest WiFi in environments with rapid visitor turnover, the pool of available IP addresses quickly runs out. New arrivals may associate with the access point via 802.11 beacons, but fail to receive a valid DHCPOFFER or default gateway, receiving a self-assigned 169.254.x.x APIPA address instead. Shortening lease times to 30 to 60 minutes and configuring dynamic VLAN pooling prevents scope starvation.

How does Purple prevent captive portal and DNS timeout failures on guest WiFi?

Purple acts as a resilient, hardware-agnostic guest WiFi management platform across Cisco Meraki, HPE Aruba, Ruckus, Ubiquiti UniFi, and Fortinet architectures. By optimizing captive portal redirection flows, automating walled garden rules, and integrating with high-speed Anycast DNS, Purple ensures detection probes succeed instantly, onboarding visitors in under 3 seconds without connection drops.

Sources

  1. RFC 1035: Domain names, implementation and specification
  2. RFC 8484: DNS queries over HTTPS (DoH)
  3. RFC 7858: DNS over Transport Layer Security (DoT)
  4. RFC 8910: Captive-portal identification in DHCP and Router Advertisements
  5. RFC 2131: Dynamic Host Configuration Protocol
  6. PCI Security Standards Council: PCI DSS
  7. Information Commissioner's Office: UK GDPR guidance

Continue reading in this series

Using Packet Capture (PCAP) to Diagnose Slow WiFi Performance

This technical reference guide provides IT managers, network architects, and venue operations directors with a structured, packet-level methodology to diagnose and resolve slow enterprise WiFi performance using Packet Capture (PCAP) analysis. By dissecting raw 802.11 frames - including retransmission rates, airtime utilization, and physical layer metadata - teams can isolate RF-layer bottlenecks from wired or application issues with precision. Applicable across high-density venues including hotels, retail chains, stadiums, and convention centers, this guide delivers actionable diagnostic workflows, real-world case studies, and configuration remediation steps to reclaim network capacity and protect guest experience.

Read the guide →

Why Your Stadium WiFi Grinds to a Halt (And How to Fix It)

This authoritative technical guide examines the root cause of stadium WiFi congestion - the simultaneous background chatter of 50,000 devices loading programmatic advertisements and telemetry - and provides a detailed architectural blueprint for deploying edge DNS filtering as the primary mitigation strategy. Designed for IT Directors, CTOs, and Network Architects, it delivers actionable implementation guidance, real-world case studies, and measurable ROI frameworks to help venue operators reclaim bandwidth and deliver high-performance connectivity at scale.

Read the guide →

Why is Our Guest WiFi So Slow? Diagnosing Network Congestion

This guide diagnoses the hidden drivers of guest WiFi congestion - background telemetry, programmatic ad networks, and automated OS updates - which collectively consume up to 40% of public WiFi bandwidth before a guest even opens a browser. It provides a phased, vendor-neutral implementation framework for DNS filtering and QoS policies that reclaim that bandwidth, improve guest experience, and deliver measurable ROI. Targeted at IT Directors and Operations Managers in hospitality, retail, events, and public-sector environments.

Read the guide →

Got questions about your specific setup?

Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.