Overview
Web filtering is only effective when client devices continue to use the network’s approved DNS path and do not move traffic outside the filtering control point. In guest Wi‑Fi environments with a captive portal, users may try to bypass filtering by changing DNS settings, using encrypted DNS, connecting through a VPN, or enabling privacy features such as Apple iCloud Private Relay.
Cloud4Wi recommends a layered mitigation model that reduces these techniques while preserving the normal browsing experience for allowed content. The goal is not to break access to the Internet, but to prevent devices from silently stepping outside the approved filtering path.
Why bypass happens
Most filtering systems rely on a simple assumption: the device must use the DNS resolver and traffic path provided by the network. If the client can use another resolver, tunnel DNS in encrypted traffic, or route traffic through a remote server, filtering can be reduced or completely bypassed.
This is especially relevant in captive portal deployments because guest devices are often unmanaged, users can change settings locally, and browsers or operating systems may enable privacy features automatically. In practice, filtering must be enforced at the network level, not left to the user’s device behavior.
1. Blocking local DNS changes
The simplest bypass technique is to change the DNS server manually on the client device. Instead of using the resolver assigned by DHCP or the captive network, the client sends DNS queries to another public resolver.
Recommended firewall rules
- Allow TCP and UDP traffic on port 53 only to the web filtering service’s IP range.
- Block all other TCP and UDP traffic on port 53 to any destination.
This ensures that guest devices can only resolve names through the approved filtering path.
Smoother user experience
For a smoother user experience, DNS redirection (DNAT) can be used instead of a hard block. In that model, DNS queries sent to unauthorized resolvers are transparently redirected to the approved resolver rather than simply denied.
This approach is usually less disruptive because the user does not see a visible failure when a device tries to use an alternate DNS server. Instead, the network quietly forces DNS traffic back to the intended path.
What the user experiences
In many cases, the user does not notice anything at all. Browsing continues normally, and the device appears to work as expected because the DNS request is handled transparently by the network.
If the traffic is blocked instead of redirected, the user may notice resolution failures for sites that depend on direct DNS changes. However, the rest of the browsing experience should still remain intact if the approved DNS path is working correctly.
2. Blocking DNS-over-TLS
DNS-over-TLS, or DoT, encrypts DNS traffic over a dedicated TLS connection, typically on TCP port 853. Because the queries are encrypted, the local network cannot inspect or redirect them as easily as standard DNS.
Recommended firewall rule
- Block all outbound TCP traffic on port 853.
This prevents clients from bypassing the approved DNS resolver by switching to encrypted DNS over TLS.
What the user experiences
DoT is often invisible to the user. In many cases, the browser or operating system will simply fail over to standard DNS or continue browsing without a clear warning. If the device insists on DoT, name resolution may fail until the client returns to standard DNS behavior.
3. Blocking DNS-over-HTTPS
DNS-over-HTTPS, or DoH, sends DNS queries inside HTTPS traffic. Because it uses the same transport as ordinary secure web traffic, it is harder to distinguish from normal browsing.
Firefox canary domain behavior
The WebFilter solution supports Mozilla’s canary domain mechanism. When Firefox detects that this domain is blocked by the network’s DNS resolver, it automatically disables DoH and falls back to standard DNS. This is the simplest and most effective mitigation for Firefox users.
The canary domain commonly used for this purpose is:
- use-application-dns.net
If the network returns a negative result for that domain, Firefox interprets it as a signal that local DNS policy is in place and disables automatic DoH use.
Proxy & VPN category
The WebFilter solution’s Proxy & VPN content category includes known DoH server domains. Enabling this category blocks DNS resolution of those domains, preventing browsers from establishing DoH connections to them.
This is important because some browsers or applications may try to connect directly to well-known DoH providers. Blocking the resolver domains prevents those HTTPS-based DNS sessions from being created in the first place.
Enhanced Mitigation: Block DoH Provider IPs
To establish a more robust defense, configure your firewall to block HTTPS traffic directed to the IP addresses of the leading public DNS over HTTPS (DoH) providers. Specifically, target the IPs for Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1), and Quad9 (9.9.9.9). This precise blocking action prevents DoH connections without interfering with standard HTTPS web browsing.
What the user experiences
For Firefox users, the experience is usually seamless. If the canary domain is blocked as expected, Firefox automatically disables DoH and uses standard DNS instead.
For other browsers, the behavior may vary. Some browsers may silently fall back to standard DNS, while others may still try to use encrypted DNS until the blocked resolver becomes unavailable.
4. Blocking VPN connections
VPNs are one of the most effective bypass techniques because they tunnel both browsing traffic and DNS through a remote endpoint. Once a VPN is active, the local filtering path may no longer apply to the traffic inside the tunnel.
Proxy & VPN category
Enable the WebFilter solution’s Proxy & VPN content category to block DNS resolution of known VPN provider domains. This prevents users from:
- visiting VPN websites,
- downloading VPN applications,
- resolving VPN server hostnames.
This does not eliminate every possible VPN technique, but it removes the most common consumer and commercial VPN entry points.
Block common VPN protocol ports at the router firewall
In addition to domain-based filtering, block common VPN protocol ports at the router firewall.
Examples include:
- OpenVPN: UDP 1194, TCP 1194.
- WireGuard: UDP 51820.
- L2TP/IPsec: UDP 500, UDP 4500, UDP 1701.
- IKEv2/IPsec: UDP 500, UDP 4500.
- SSTP: TCP 443.
- PPTP: TCP 1723 and GRE.
The exact list should match the VPN technologies you want to discourage in your environment.
What the user experiences
VPN blocking is usually more visible than DNS-only bypass controls. The VPN application may fail to connect, disconnect unexpectedly, or show a generic connection error.
However, normal browsing for non-blocked content should still work. The objective is to block the tunnel, not to break general guest internet access.
5. Apple iCloud Private Relay
Apple iCloud Private Relay is a special bypass case for iOS and macOS devices with iCloud+ subscriptions. It is designed to hide the user’s browsing destination from the local network by splitting the connection through Apple-managed relay infrastructure. In a guest Wi‑Fi environment that must enforce web filtering, this can interfere with web filtering and traffic inspection.
Cloud4Wi recommends treating Private Relay as a bypass vector in guest Wi‑Fi environments where web filtering is required.
How it works
Cloud4Wi recommends blocking with NXDOMAIN response the domains associated with Private Relay discovery and operation, including:
- mask.icloud.com
- mask-h2.icloud.com
NOTE: QUIC is not blocked for other services
What the user experiences
On iPhone and iPad, the user may see a system message indicating that Private Relay is unavailable on the current network. That behavior is expected.
Unlike silent DNS fallback, Private Relay blocking is usually visible to the user. The device may still browse allowed content normally, but the privacy feature itself will not function on the network. This should be documented clearly so administrators and support teams understand that the popup or warning is normal.
Apple recommends that network administrators may need to disable iCloud Private Relay in certain enterprise or school environments to comply with policies or local regulations that require auditing all network traffic. Consequently, the network may block access to this service. For further details on preparing a network for iCloud Private Relay, refer to the Apple developer documentation: https://developer.apple.com/icloud/prepare-your-network-for-icloud-private-relay/. Additionally, the service is disabled in some countries due to local regulations.
Recommended Cloud4Wi position
Cloud4Wi recommends a layered firewall-based model for guest Wi‑Fi environments:
- Allow DNS only to the approved web filtering service IP range.
- Block all other DNS on port 53, or use DNS redirection for a smoother experience.
- Block DoT on TCP 853.
- Use the WebFilter solution’s canary-domain support for Firefox.
- Enable the Proxy & VPN category to block known DoH and VPN-related domains.
- Block common VPN ports at the firewall.
- Add dedicated handling for Apple iCloud Private Relay.
- Preserve normal browsing for permitted traffic.
This approach keeps the filtering model effective without turning the guest network into a fully broken experience.
Summary
Web filtering bypass usually happens through a small set of repeatable techniques: local DNS changes, DoT, DoH, VPNs, and Apple Private Relay. Cloud4Wi recommends addressing each one explicitly at the firewall and web filtering layers while keeping the browsing experience stable for legitimate traffic.
For Apple devices with iCloud+ subscriptions, Private Relay requires special attention because the user experience is not completely silent. Blocking it can trigger a system-level warning on the device, which is normal and should be expected in environments where filtering must remain enforceable.