Personal VPN apps tunnel around every other rule you set. This guide shows how to stop them in layers: provider domains, server addresses, protocols and the devices themselves.
It is written for IT admins, MSPs, school IT teams and vendors who build filtering products, with honest notes on what protocol detection can and cannot catch.
A corporate VPN protects your users. A consumer VPN app protects the user from you: it hides traffic from your filter, your logs and your security tools. That is why most acceptable use policies forbid them on managed networks.
Once traffic leaves inside a tunnel, your DNS filter and web categories never see the destination. Every other block on the network becomes optional.
Threat detection, data loss prevention and malware scanning all depend on seeing traffic. Free VPN apps also have a history of bundling adware or collecting browsing data.
Schools that certify CIPA compliance must filter minors' access, and a tunnel defeats that. Regulated firms need records of activity on their systems.
Streaming and software licences are often tied to a country. Staff who appear to browse from elsewhere can put contracts and audit results at risk.
When something goes wrong, investigators need to know where a device connected. Tunnelled sessions leave only one opaque connection in the logs.
Tunnels add overhead and break things like local printing or captive portals. Help desks then spend time on problems the user created.
A VPN app goes through three stages: it is found and downloaded, it logs in and picks a server, then it builds the tunnel. Each stage leaves a different trace, so each needs a different control.
Rule of thumb: the earlier you stop the app, the more reliable the block. Layer 1 and 2 blocks rely on names, which are stable and easy to categorise. Layer 3 blocks rely on traffic patterns, which VPN makers deliberately change.
Many guides suggest "just block the VPN ports". That works for a minority of apps. The table shows the common tunnel types, how they usually appear on the wire and how far you can trust detection.
| Tunnel type | Typical traffic pattern | Can it be blocked by port? | Detection difficulty | What to rely on |
|---|---|---|---|---|
| IPsec / IKEv2 | UDP 500 and 4500, ESP protocol | Yes, but your own site to site and remote VPNs may use the same ports | Easy | Port rules with allowlisted corporate gateways |
| L2TP and PPTP | UDP 1701 (with IPsec), TCP 1723 and GRE | Yes, and these older protocols are rarely needed today | Easy | Block outright unless a legacy system needs them |
| OpenVPN (default) | UDP or TCP 1194, distinctive handshake | Partly, because providers can move it to any port | Moderate | Application signatures that look at the handshake |
| WireGuard based apps | UDP on a configurable port, short fixed handshake | Rarely, ports vary by provider | Moderate | Signatures, plus blocking provider domains so the app cannot fetch keys and servers |
| OpenVPN or proprietary over TCP 443 | Looks like a long TLS session to one server | No, port 443 must stay open | Hard | Domain categories, TLS inspection where lawful, IP reputation |
| Obfuscated or "stealth" modes | Traffic shaped to resemble ordinary HTTPS or random noise | No | Hard | Device controls on managed endpoints, provider domain blocks |
| Browser extension VPNs | HTTPS proxy connections from inside the browser | No | Moderate | Extension allowlists in browser policy, category blocks on proxy endpoints |
| Encrypted DNS only (DoH, DoT) | DNS hidden inside HTTPS, or TLS on port 853 | DoT yes (853), DoH no | Moderate | Browser and OS policy to disable DoH, block known DoH resolvers |
Port numbers above are common defaults only. VPN providers can and do run their services on other ports. Treat port rules as a cheap first filter, never the whole answer.
Why domains still matter for disguised tunnels: even a stealth mode VPN has to log in, download its server list and receive updates. Those calls go to named hostnames, and a well maintained VPN / Proxy / Anonymizers category catches them before the tunnel exists.
No single box covers everything. Pick the methods that match what you control, then combine at least one name based control with one traffic based control.
Consumer routers rarely inspect traffic, so they cannot stop a tunnel on port 443. Use them only as the first layer.
Most firewall vendors ship VPN application signatures. Their coverage of new and obfuscated apps varies, which is why the category layer matters.
use-application-dns.net.DNS filtering is fast and cheap to deploy across many clients. Read more in our comparison of DNS filtering vs web filtering.
Gateways see more than DNS, but only for traffic that actually reaches them. Pair them with device policy so the agent cannot be switched off.
On devices you manage, the most reliable VPN block is simply not letting the app install or configure a tunnel. Network rules then become a backstop rather than the main defence.
Apple private relay: Apple advises networks that need to disable iCloud Private Relay to return NXDOMAIN or an empty answer for mask.icloud.com and mask-h2.icloud.com. On managed devices you can also disable the feature with an MDM restriction.
Expect determined users to try a second route once the first is blocked. These are the gaps admins see most often, from a defender's point of view.
Testing should use a managed device and a separate unmanaged test device, on each network segment where the policy applies. Record the result of each check so you can repeat it after changes.
Hand made lists of VPN domains go stale within weeks. Providers launch mirror sites, affiliate review pages and new API hostnames constantly. A category database turns the problem into one policy setting.
Our VPN and proxy category covers VPN provider sites, their account and download domains, web proxies and anonymizing services. Vendors embed the data in firewalls, DNS filters and gateways, so every customer gets the same coverage.
| Organisation | Typical rule | Exceptions to plan for |
|---|---|---|
| K-12 school or district | Block the VPN / Proxy / Anonymizers category on all student networks and devices | Staff remote access to district systems, approved learning platforms |
| Office based business | Block consumer VPN apps; allow only the corporate VPN | Client VPNs for consultants, vendor support tunnels |
| MSP with many tenants | Category block as a default template, tenant level overrides | Each tenant's own VPN gateway, security testing teams |
| Library or public Wi-Fi | Block provider sites and older protocols, accept limits on unmanaged devices | Patrons who must reach an employer's VPN, under local policy |
| Healthcare or finance | Block and alert, investigate repeated attempts | Third party clinical or trading connections |
For more on sector rules, see our pages on K-12 school web filtering and web filtering for MSPs.
No. Standard protocols such as WireGuard, OpenVPN and IPsec are easy to spot, but VPNs that wrap traffic in ordinary HTTPS on port 443 can look like normal browsing. A complete approach combines category blocking of VPN provider domains, application signatures and device controls on managed hardware.
It can if you block protocols broadly. Allowlist the gateway addresses and hostnames of your own corporate VPN, and of partners you connect to, before you enable protocol or category blocks.
It stops new downloads and sign-ups, and most apps also need provider domains to log in and fetch server lists. An app that is already configured can still connect directly to server IP addresses, so add IP and protocol controls.
On managed phones use MDM: restrict which apps can be installed, block VPN configuration changes where the platform allows it, and push your own DNS or filtering profile. Unmanaged phones on guest Wi-Fi can only be controlled at the network.
In our database the VPN / Proxy / Anonymizers category covers VPN provider sites, their API and download domains, web proxies and anonymizing services. Blocking it in your DNS filter or firewall closes most of the discovery and sign-up paths.
Organisations generally control how their own networks and devices are used. Write the rule into your acceptable use policy, tell users, and check local employment and privacy rules before you inspect traffic.
120 million categorized domains in 59 categories, delivered as files that run in your own systems, with daily updates for new domains. Starter database tiers from $999; enterprise and OEM licences are quoted per deployment.
WireGuard is a registered trademark of Jason A. Donenfeld. OpenVPN is a trademark of OpenVPN Inc. Microsoft, Windows, Intune and Defender are trademarks of Microsoft Corporation. Google, Chrome, ChromeOS, Android and Google Play are trademarks of Google LLC.
Apple, iPhone, iPad and iCloud are trademarks of Apple Inc. Firefox is a trademark of the Mozilla Foundation. These names are used here only to identify the products discussed. Web Filtering Database is not affiliated with, sponsored or endorsed by any of these companies.