Step 1: Understand What VPNs Are

A Virtual Private Network (VPN) encrypts traffic and routes it through a remote server. While this can be beneficial for privacy and security on personal or untrusted networks, it presents significant challenges on managed networks such as schools, libraries, and corporate environments.

On these networks, VPNs effectively create a secure tunnel that bypasses local protections, making it impossible for administrators to apply Acceptable Use Policies (AUPs). When a VPN is active, content filters, firewalls, and monitoring tools can no longer see or control the traffic. This means:

• Policy Evasion: Users can access blocked categories (adult, gambling, extremist, etc.) despite filtering rules.
• Accountability Risks: Activity is hidden from logs, reducing visibility into misuse or harmful behavior.
• Legal & Compliance Issues: Organizations responsible for safe browsing (e.g., CIPA in schools, HR policies in businesses) can be exposed to liability if users bypass controls.
• Security Gaps: Malicious files, phishing attempts, or data exfiltration may pass through the VPN tunnel undetected.

Blocking VPNs is complex because they reuse common ports like 443 (HTTPS), rotate IP addresses frequently, and adopt new protocols (e.g., WireGuard) that are designed to blend in with normal traffic. This is why organizations should view VPN blocking as a layered, best-effort strategy. The goal is not perfect prevention, but raising the barrier enough that casual users cannot easily bypass protections.

Learn more: What is a VPN?

Step 2: Start with DNS Filtering

The first and simplest line of defense against VPN usage is at the DNS layer. By blocking access to known VPN and proxy domains (provider websites, app bootstrap hosts, and API endpoints), administrators can stop many casual attempts before they even begin. If a user can’t reach the download page, update server, or handshake host, the VPN client often fails to connect.

DNS filtering is effective because it’s network-wide: apply the controls at your router, firewall, or DNS resolver and all connected devices inherit the same protections. This reduces the likelihood that users can install or activate VPN clients without being noticed.

However, DNS filtering is not enough on its own. Advanced VPN clients may connect directly by IP or use encrypted DNS (DoH/DoT) to bypass your resolver. That’s why DNS filtering should be viewed as one piece of a broader policy for VPN control — complementary to firewall rules, port blocking, DPI, and endpoint restrictions. Think of it as your first layer of defense that removes easy circumvention paths and reduces the volume of attempts you need to handle at deeper layers.

Quick Wins

• Block domains: Add popular VPN providers and “proxy/anonymizer” categories to your DNS filter.
• Enforce SafeSearch: Prevent users from finding VPN download sites and proxy lists through search engines.
• Apply at the edge: Configure DNS at the router or firewall so all devices on the network inherit the rules automatically.

Step 3: Block Common VPN Ports & Protocols

Most VPNs rely on specific ports and protocols to establish connections. By blocking or restricting these at your firewall, you can significantly reduce the number of VPNs that will connect successfully on your network. This approach is one of the most effective “first line of defense” techniques because many commercial VPN services default to well-known ports. While determined users may still tunnel VPN traffic over common ports like 443 (HTTPS), blocking the obvious ports removes a large portion of casual VPN usage.

This won’t catch every case (some VPNs tunnel over TCP/443), but it removes low-hanging fruit and makes it much harder for users to casually bypass your filters.

Step 4: Control QUIC (UDP/443)

QUIC is a relatively new transport protocol originally developed by Google and now standardized as the foundation of HTTP/3. Unlike traditional web traffic that runs over TCP, QUIC runs over UDP on port 443 and was designed to make web browsing faster and more reliable, especially on mobile networks.

While QUIC improves performance, it also creates new challenges for network administrators. Because it operates over UDP, QUIC traffic does not behave like traditional HTTPS (TCP/443) connections and often bypasses deep packet inspection (DPI) or SSL inspection tools. This makes it harder for filtering and security systems to analyze or block unwanted content.

VPN providers have quickly adopted QUIC because it allows their traffic to blend in with modern web protocols while avoiding many of the restrictions that firewalls place on TCP traffic. In practice, this means that if QUIC is left unmonitored, VPN tunnels can hide inside what looks like legitimate web browsing traffic, undermining acceptable use policies and filtering rules.

To regain visibility and control, administrators should disable or restrict QUIC on their networks so that traffic falls back to standard HTTPS over TCP/443. This brings encrypted traffic back into a channel where existing firewall, content filtering, and inspection tools are more effective. Many enterprise firewalls and DNS filters now offer policy settings specifically for QUIC/HTTP3 management.

In short: QUIC is not inherently bad—it is the future of web traffic—but without controls in place, it can become a blind spot. Administrators that care about enforcing Acceptable Use Policies or preventing VPN circumvention should pay close attention to QUIC.

Step 5: Use DPI / TLS Fingerprinting

Basic port and domain blocking will stop many VPNs, but more advanced VPN services are designed to mimic normal HTTPS traffic so they can slip through undetected. This is where Deep Packet Inspection (DPI) and TLS fingerprinting become essential.

DPI (Deep Packet Inspection) looks beyond the port number and destination, examining the actual traffic patterns inside the packet. Even if a VPN runs on TCP/443 (the same port as HTTPS), DPI can detect tell-tale signs of VPN protocols like OpenVPN, WireGuard, L2TP, or IPSec. Many modern firewalls and secure web gateways include this type of “application control” that allows administrators to block or flag encrypted tunnels, even when they’re disguised as normal web browsing.

TLS fingerprinting takes this one step further by looking at the unique “fingerprint” created during the TLS/SSL handshake. Different applications, including VPN clients, often present distinct patterns when they negotiate encrypted sessions. Security tools can compare these patterns against a database of known fingerprints to identify VPN traffic with a high degree of accuracy. For example, OpenVPN and WireGuard leave different TLS signatures than a browser like Chrome or Firefox.

Together, DPI and TLS fingerprinting help close the gap left by simple port or IP blocking. They give administrators the ability to recognize VPN tunnels that would otherwise be invisible, making it much harder for users to bypass filtering rules or Acceptable Use Policies. However, these techniques require more advanced firewalls or security appliances, and they can add processing overhead, so they should be deployed as part of a layered strategy alongside DNS filtering and firewall rules.

In short: If your organization is serious about stopping VPN circumvention, DPI and TLS fingerprinting are powerful tools that move you from simple blocking to intelligent detection.

Step 6: Stop DNS Evasion (Local DNS, DoH & DoT)

Users don’t need a full VPN to bypass filtering—simple local DNS changes can route their lookups around your resolver. Add to that Encrypted DNS (DNS-over-HTTPS and DNS-over-TLS), and you have two common paths that quietly undermine Acceptable Use enforcement. Treat DNS evasion with the same priority as VPN blocking.

Why local DNS changes are a problem

• Bypass of policy: A user points their device to a public resolver and sidesteps your block/allow rules.
• Blind spots: Your logs, alerts, and reports now miss what they resolve and visit.
• Inconsistent coverage: Guest, BYOD, and IoT devices are the easiest to misconfigure or manipulate.

Force DNS at the gateway (the foundation)

“Forcing DNS” means the network only allows DNS queries to your approved resolver(s), and silently drops or redirects everything else. This keeps all clients—managed or not—on the same policy.

• Egress allow-list: Allow UDP/TCP 53 only to your DNS resolver IPs; drop all other DNS egress.
• Policy-based NAT/redirect (optional): Transparently redirect any outbound UDP/TCP 53 to your resolver.
• Block DoT: Deny TCP 853 to the Internet unless you terminate DoT on your own resolver.
• Block known DoH endpoints: Deny access to well-known DoH hostnames and IPs (and their bootstrap IPs).
• DHCP authority: Serve your resolver IPs via DHCP; disable “DNS relay” features that leak to WAN.
• IPv6 parity: Mirror all rules for IPv6 (UDP/TCP 53, TCP 853). If you don’t manage IPv6, disable it at the edge.

Harden the browser & OS (prevents user overrides)

• Browser policies: Use Chrome/Edge/Firefox policies to disable or lock Secure DNS/DoH to “off” or to your enterprise DoH endpoint.
• OS controls / MDM: Remove local admin where possible; push Wi-Fi profiles that set DNS and prevent edits.
• Extension control: Block proxy/VPN/DNS-changing extensions in managed browsers.

Encrypted DNS (not a VPN, but same evasion impact)

DoH/DoT encrypt DNS lookups so they can’t be seen or filtered by traditional DNS controls. If enabled to public providers, they effectively nullify your DNS policy. Either terminate encrypted DNS on your resolver (enterprise DoH/DoT) or block it outbound. Get the full overview here: Encrypted DNS (DoH & DoT).

Practical checklist

• Allow DNS only to your resolver IPs (v4/v6); drop or redirect all other port 53 traffic.
• Block TCP 853 (DoT) outbound; if you provide DoT, allow-list only your resolver.
• Block known DoH hostnames/IPs; enforce browser DoH policies to “off” or your enterprise endpoint.
• Serve DNS via DHCP; verify clients receive your resolver and cannot change it.
• Replicate all controls for IPv6; don’t leave AAAA paths unprotected.

Deep dive: Block DNS Filtering Evasion  |  Background on DoH/DoT: Encrypted DNS (DoH & DoT)

Step 7: Apply Endpoint Restrictions

On managed devices, use MDM/Group Policy to block VPN apps and VPN/proxy extensions, restrict local admin rights, and lock network settings to retain control. Endpoint controls reduce the chance users can install or run tunneling software even if network controls miss something.

Endpoint hardening (recommended)

• Block VPN apps & Tor Browser: Use application allow-listing (e.g., AppLocker, WDAC) or MDM to prevent installation/execution.
• Browser extensions: Disallow proxy/VPN/DNS-changing extensions via Chrome/Edge/Firefox policies.
• Remove local admin: Standardize least-privilege to stop driver installs, TAP adapters, and service changes.
• Lock network settings: Prevent edits to DNS, VPN profiles, and Wi-Fi configurations via OS/device policies.

Complementary control: block known VPN & Tor endpoints (network side)

In addition to endpoint restrictions, maintain deny-lists of known VPN egress IPs and Tor relays/exits on the firewall. This won’t catch everything (providers rotate IPs and use cloud ranges), but it cuts down casual use and gives your monitoring a head start.

• Use curated feeds: Subscribe to reputable blocklists for VPN providers and Tor exit nodes; schedule automatic updates.
• Watch false positives: Many VPNs live in cloud ranges (AWS/GCP/Azure). Start in “monitor/log” mode, then block with care.
• Cover IPv6: Add v6 entries where available; don’t leave AAAA paths open.
• Log & alert: Create alerts for repeated connections to blocked IPs—useful for user coaching and incident response.

Introduce Tor (not a VPN, but a common evasion tool)

Tor routes traffic through multiple relays to hide origin and destination. It’s not a VPN, but it can similarly defeat filtering and logging by encrypting and bouncing traffic outside your policy controls. Tor is harder to block comprehensively because:

• Dynamic infrastructure: Relay and exit IPs change frequently; bridges are unpublished by design.
• Pluggable transports: Protocols like obfs4 and domain-fronted transports (e.g., meek) are built to look like normal HTTPS/CDN traffic.
• Port agility: While classic Tor uses ORPort (~9001/tcp) and DirPort (~9030/tcp), modern setups often run over 443/tcp to blend in.

Practical steps include blocking known Tor exits/relays, monitoring for Tor TLS/DPI signatures where supported, and preventing Tor Browser installation on endpoints. See our guide: How to Block the Tor Network (DNS & Firewall).

Quick reference: what to block/monitor

Bottom line: lock down the endpoint to stop tunnel apps from running, and complement it with IP-based blocks for known VPN/Tor infrastructure. Use logs and alerts to iterate—both ecosystems change often.

Step 8: Monitor & Alert on Attempts

VPN control is never “set and forget.” Providers rotate IPs, add protocols, and adopt tricks like QUIC and encrypted DNS. Active monitoring is what turns your controls into an adaptive system: you see bypass attempts, tune policies, and prove enforcement. Without monitoring, VPN and Tor traffic becomes a blind spot—and Acceptable Use enforcement weakens over time.

What to collect (minimum viable telemetry)

• DNS resolver logs: Queries to VPN/Tor domains, DoH endpoints, unusual NXDOMAIN spikes.
• Firewall/NGFW logs: Allowed/blocked sessions, app-ID/DPI verdicts, QUIC events, long-lived TLS sessions.
• Web filter / SWG: Category hits (proxy/anonymizer), bypass pages, user/device attribution.
• Endpoint logs: App installs/executions (VPN/Tor), network setting changes, extension installs.
• DHCP/Identity: Map IP→device→user (DHCP leases, AD/Azure AD/IdP auth) for accountability.

Dashboards that matter

• Top talkers & long-lived sessions: Hosts with sustained outbound TLS/UDP flows to unknown ASNs.
• QUIC activity: QUIC connections by host, by destination, trend over time.
• VPN/Tor detections: App-ID/DPI hits (OpenVPN, WireGuard, IPSec, Tor), by user/device.
• DNS evasion: DoH/DoT hits, port 53 to non-approved resolvers, AAAA-only paths (IPv6 leak).
• Policy outcomes: Blocks vs. allows for proxy/anonymizer categories; exceptions used.

High-signal alerts (start here)

Thresholds, baselines, and noise control

• Baseline first: Measure “normal” for your environment (top destinations/ASNs, typical QUIC rate) for 1–2 weeks.
• Alert on deviation: Use percent-over-baseline or rolling standard deviation to reduce false positives.
• Tag business apps: Allow-list your SaaS/CDNs to avoid noisy alerts (e.g., Microsoft, Google, Cloudflare).
• Retain logs: Keep at least 90 days (ideally 180–365) for investigations and audits.

Investigate & respond (runbook tips)

• Correlate quickly: Pivot DNS ⇄ firewall ⇄ endpoint ⇄ identity to identify the user/device.
• Verify control gaps: Check gateway DNS enforcement, QUIC policy, and endpoint permissions.
• Coach before punish: First-time events often indicate configuration gaps or user confusion.
• Document exceptions: If business VPNs are needed, whitelist by policy with time-bound approvals.

Power it with a SIEM (visualize & prove)

Centralize logs and build dashboards/alerts in a SIEM to make this operational. Trunc (our SIEM & log management platform) simplifies ingestion from DNS resolvers, firewalls/NGFWs, web filters, endpoints, and identity providers, then gives you prebuilt VPN/Tor/DoH detections, visualizations, and scheduled reports for audits. Learn more: Trunc SIEM  |  Log Analysis.

Quick start: example queries

• DoH hits: dns_query where domain in (known_doh_list) or dst_port = 443 and sni in (known_doh_sni)
• Long-lived TLS: firewall_session where proto = tcp and dport = 443 and duration > 1200 and asn not in (business_allow)
• QUIC surge: firewall_log where proto = udp and dport = 443 group by src_ip over 15m having count > 100
• VPN DPI: appid in ("openvpn","wireguard","ipsec","l2tp") or tls_fingerprint in (known_vpn_ja3)
• Tor: dst_ip in (tor_exit_list) or appid = "tor"

Bottom line: Controls stop yesterday’s tunnels; monitoring finds today’s. Use dashboards to see attempts, alerts to react fast, and a SIEM like Trunc to prove enforcement to auditors and stakeholders.

Step 9: Test & Validate Regularly

VPN controls decay over time. Providers rotate IPs, introduce new protocols, and browsers change defaults (e.g., QUIC/DoH). Regular testing is what keeps your posture current, proves Acceptable Use enforcement, and catches regressions early.

Recommended cadence

• Monthly smoke test (15–30 min): Quick checks on one device per OS (Windows, macOS, ChromeOS, iOS, Android) across key layers (DNS, firewall ports, QUIC, DoH, DPI).
• Quarterly deep test: Full matrix below (multiple devices/SSIDs/VLANs; both IPv4 and IPv6); validate alerting and evidence capture.
• Event-driven: After network changes (firewall/NGFW upgrades, rule updates), browser/OS updates, policy changes, blocklist feed changes, or incidents.
• Annual external assessment: Include VPN/Tor bypass attempts as part of a pen test or audit.

What to test (scope & methods)

Test set (keep current)

• Commercial VPNs: NordVPN (NordLynx/WireGuard), ExpressVPN (Lightway), Proton VPN (OpenVPN/IKEv2/WireGuard), Cloudflare WARP.
• Non-VPN tunnels: Tor Browser (plus pluggable transports), Outline/Shadowsocks where applicable.
• Evasion checks: Browser DoH, local DNS change, QUIC enabled browsers, IPv6-only paths.
• Devices: At least one test per OS (Windows/macOS/iOS/Android/ChromeOS) and per relevant SSID/VLAN.

How to track (evidence & accountability)

Maintain a simple “VPN Blocking Test Log” so results are provable and trends are visible. Store screenshots, CLI outputs, and SIEM links.

Where to visualize & alert

Centralize logs and validations in a SIEM for dashboards, alerting, and scheduled reports. Trunc can ingest DNS, firewall/NGFW, web filter, and endpoint logs; ship prebuilt detections (VPN/Tor/DoH/QUIC); and produce monthly/quarterly compliance summaries. See: Trunc SIEM  |  Log Analysis.

Reference: Strategies to Block VPNs

Step 10: Use the VPN Blocking Checklist

Use this evidence-based checklist to validate your setup. Fill in the Status column (✓/✗/N/A), describe How Implemented, and attach Evidence (screenshots, config exports, SIEM links). Frequency indicates how often to review.

Need more depth? See Strategies to Block VPNs, the encrypted DNS overview at /encrypteddns, and Tor-specific guidance: How to Block the Tor Network (DNS & Firewall).