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 the transport behind HTTP/3. It runs over UDP/443 (not TCP) and was designed for speed and reliability, especially on mobile and lossy networks. That performance gain comes with a tradeoff for administrators: QUIC traffic is harder for traditional HTTPS controls to see or shape.

Practically speaking, you generally can’t perform deep inspection on QUIC like you might on TCP/443 with classic HTTPS proxies. QUIC’s handshake + TLS 1.3 minimize what’s visible to middleboxes, so many NGFW/SWG features don’t apply. This makes QUIC a convenient evasion path for VPNs and other tunneling tools that want to blend into “normal” web traffic.

What to do

• Block or restrict UDP/443 at the edge: Deny QUIC outright or allowlist only specific business apps. Verify traffic downgrades to TCP/443.
• Use browser/endpoint policies: Disable or limit HTTP/3/QUIC in managed Chrome/Edge/Firefox profiles where supported.
• Monitor and alert: Track QUIC events in firewall logs; alert on spikes from a single host or segment.
• Exception handling: If a business app truly needs HTTP/3, allowlist precisely (domain/IP/ASN) and monitor closely.

Context: SNI today, ECH tomorrow

On TCP/443, many devices can still use SNI (the TLS hostname) to block known VPN/proxy domains without full decryption. But SNI visibility is shrinking as ECH (Encrypted Client Hello) rolls out. Plan accordingly: pair SNI rules with DNS enforcement (force resolver, block DoH/DoT) and, where feasible, IP/ASN allow/deny for critical services.

Quick validation

1. DevTools protocol check: In a browser, show the Network “Protocol” column. With QUIC allowed you’ll see h3; after enforcing, you should see h2/h1.
2. Firewall logs: Before/after compare of outbound UDP/443 sessions; post-policy should show drops or a sharp reduction.
3. VPN spot test: Try a VPN that prefers QUIC/HTTP/3; connection should fail or fall back to TCP where other detections apply.

Bottom line: QUIC isn’t bad—it’s the future of the web—but unmanaged QUIC is a blind spot. Control it to keep your broader VPN-blocking layers effective.

Step 5: Use DPI / TLS Fingerprinting

Basic port and domain blocking will stop many VPNs, but advanced services are designed to mimic normal HTTPS. This is where Deep Packet Inspection (DPI) and TLS fingerprinting help—especially once you’ve limited QUIC (Step 4) so traffic falls back to TCP/443 where these controls are most effective.

DPI (Deep Packet Inspection) looks beyond ports and destinations to identify apps/protocols by behavior. Even if a VPN runs on TCP/443, DPI can detect signatures for OpenVPN, WireGuard, IPSec, L2TP, or vendor “stealth/obfuscation” modes and block or alert accordingly.

TLS fingerprinting examines the TLS handshake characteristics to derive a “fingerprint.” Different clients— including VPN apps—negotiate distinct cipher lists, extensions, and ordering that differ from standard browsers. Matching these fingerprints against known sets helps flag VPN tunnels that blend with HTTPS.

SNI filtering (today) & ECH (tomorrow)

On TCP/443, you can often match on SNI (Server Name Indication) to deny known VPN/proxy hostnames without full TLS decryption—useful for coarse domain-level control. Be aware this is fragile: as ECH (Encrypted Client Hello) adoption grows, SNI will be hidden from intermediaries.

• Use SNI now: Create deny rules for VPN/proxy categories and known brands on TCP/443.
• Pair with DNS enforcement: Force resolver usage and block DoH/DoT so you still control domains when SNI is unavailable.
• Plan for ECH: Expect fewer SNI matches; lean more on DPI/App-ID over TCP and precise IP/ASN allow/deny where appropriate.
• Selective TLS inspection (managed devices): Where policy allows, decrypt specific categories on corporate endpoints to enhance detection; keep scope narrow.

Deployment tips

• Start in “alert” mode: Gauge false positives and performance impact before enforcing “block.”
• Keep signatures fresh: Update DPI/TLS fingerprints regularly; vendors add new VPN detections often.
• Correlate signals: Combine TLS fingerprints/DPI hits with DNS logs and IP/ASN intel to raise confidence even as SNI/ECH evolves.
• Log for audit: Send detections to your SIEM and attach to your Step 9 test evidence.

Bottom line: Limit QUIC to regain vantage on TCP/443, use SNI while it lasts, and rely on DPI/TLS fingerprinting (plus DNS enforcement) as your durable, layered detection path.

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).