Visit Website →
← Back to blog

Secure Split Tunneling for IT Teams: DNS Agent + EDR and Audit Rules

September 3, 2026
Secure Split Tunneling for IT Teams: DNS Agent + EDR and Audit Rules

Split tunneling is a legitimate architecture choice, not a shortcut. It is safe for most business use when paired with an endpoint DNS security agent and EDR that watches network telemetry, but it remains a poor fit for regulated or high-risk workloads. The single highest-priority control is DNS filtering at the endpoint. The single highest-priority policy rule is defaulting to inverse split tunneling and approving every exception individually.

TL;DR:

  • DNS leaks and resolver conflicts remain common issues that can expose internal hostnames and lead to misrouted traffic if not properly managed.
  • Split tunneling creates security gaps by bypassing network inspection tools, increasing risks of malware C2 communication and data exfiltration.
  • Endpoint DNS security agents and EDR telemetry are critical controls that must be deployed universally to close visibility gaps in split tunneling environments.
  • Approval, auditing, and regular testing of split-tunnel exceptions are essential to prevent shadow IT and ensure compliance with security policies.
  • Verifying configurations through leak tests, log comparisons, and scheduled audits helps maintain secure and properly functioning split tunneling setups.

Table of Contents

What Is VPN Split Tunneling and How Does It Differ From Full Tunneling?

Split tunneling sends only selected traffic through the VPN tunnel while everything else goes straight to the internet. Full tunneling forces all traffic, without exception, through the encrypted tunnel and back through corporate inspection points. That single design decision determines whether your security stack sees 100% of a device's traffic or only a fraction of it, and it's why full tunneling remains the default for centralized security monitoring at organizations that can absorb the performance cost.

Four implementation patterns dominate real deployments, and each solves a different operational problem:

  • App-based split tunneling routes traffic by application. Only named apps (say, an ERP client or a remote desktop tool) go through the VPN; everything else, including the browser, goes direct.
  • URL/domain-based split tunneling routes traffic by destination. Corporate domains and internal apps go through the tunnel; general web traffic bypasses it.
  • Inverse split tunneling flips the default: all traffic goes direct unless it matches an explicit allow list. This is the more defensible posture for security teams because nothing gets tunnel access by accident.
  • Dynamic or contextual split tunneling adjusts routing based on conditions like network location, device posture, or destination reputation, often managed through the VPN client's policy engine rather than a static list.

Deployment surface matters too. Client-based VPN software handles most app and domain rules today. Router-level split tunneling, common in consumer gear, works at the network layer and can't see individual processes. Cloud connectors (SASE or ZTNA brokers) increasingly replace both, applying split-tunnel-like logic per session rather than per device.

How Does Split Tunneling Route Traffic and Resolve DNS?

Split tunneling relies on the VPN client modifying the local routing table, adding specific routes for tunnel-bound traffic while leaving the default route untouched for everything else. The client also sets metrics that decide which route wins when both the tunnel and the local network could theoretically carry a packet. Per-app tunneling goes further, binding rules to process IDs or application identifiers so the operating system enforces which programs use the tunnel at the socket level.

DNS resolution is where most split-tunnel configurations quietly break. A client is supposed to send DNS queries for internal domains to the corporate resolver over the tunnel, and everything else to whatever resolver the local network hands out. In practice, several things go wrong:

  1. Resolver leakage. The OS caches or races DNS queries across multiple network adapters, and a query intended for the internal resolver goes out over the public interface instead, exposing internal hostnames to an ISP or a Wi-Fi operator.
  2. Split-brain DNS conflicts. When both a public and internal resolver can answer the same domain differently, misconfigured priority lets the wrong answer win, sometimes silently rerouting a login page to a non-corporate IP.
  3. Background service bypass. Update services, telemetry agents, and some browser components ignore the VPN client's per-app rules entirely and query DNS directly, a pattern documented in vendor reports of real-world DNS leaks even when the VPN showed "connected."
  4. Windows-specific quirks. Windows' handling of multiple network adapters is notoriously inconsistent with split-DNS setups, and different VPN clients patch around it with varying success.

Engineers should run a quick DNS leak test from a managed endpoint immediately after any client update, compare resolver IPs against the expected internal address, and confirm nothing at the OS level is querying an unexpected server.

What Security Risks Does Split Tunneling Create or Amplify?

Split tunneling's core risk is simple to state and hard to fully close: any traffic that skips the tunnel also skips whatever inspection lived on the other end of that tunnel. That gap shows up in four concrete ways.

Unprotected internet-bound traffic. A laptop on café Wi-Fi that sends general browsing traffic direct to the internet, rather than through the corporate egress, loses the protection of your web proxy, TLS inspection, and content filtering for that traffic. On a hostile network, that's the difference between a blocked phishing page and a successful credential capture.

DNS leakage and domain disclosure. Every DNS query that bypasses the tunnel tells whoever controls that network which domains a device is resolving, sometimes including internal application names that hint at your infrastructure. It's a reconnaissance gift handed out for free.

Malware command-and-control bypass. This is the risk that keeps SOC analysts up at night. Malware that establishes a command-and-control channel over ordinary HTTPS traffic, indistinguishable at a glance from a user checking webmail, has a clean path to the internet if that traffic isn't routed through the tunnel. Split tunneling creates exactly this kind of visibility gap, letting C2 beacons travel unseen by any perimeter tool that only inspects tunneled traffic.

Broken enforceability of SWG, DLP, and firewall egress policy. Secure web gateways, data loss prevention rules, and egress firewall policies are built on the assumption that traffic passes through them. Split tunneling routes traffic around that assumption. A DLP rule that blocks uploads of files containing Social Security numbers only works on traffic it can see, and split-tunneled uploads simply don't cross its path.

There's a downstream cost too: incident response gets harder. When an analyst investigates a compromised endpoint, a device that split-tunneled most of its traffic leaves a fragmented log trail, part VPN logs, part nothing at all, which slows containment and complicates figuring out what data left the building. Lateral movement risk also climbs on networks where a compromised endpoint can reach both the internet directly and internal resources over the tunnel simultaneously, effectively bridging two trust zones.

None of this means split tunneling is reckless by design. It means the traffic it exempts from the tunnel needs a different set of eyes watching it, which is exactly what the next layer of controls is for.

What Security Risks Does Split Tunneling Create or Amplify? — overview diagram

Which Compensating Controls Make Split Tunneling Safe to Operate?

The fix for split tunneling isn't abandoning it. It's replacing the visibility the tunnel would have provided with controls that live on the endpoint itself, so protection travels with the device regardless of which path traffic takes.

Endpoint DNS security agent, deployed everywhere, non-negotiable. This is the top-priority control, full stop. A DNS-layer security agent, in the pattern of Cisco Umbrella or Cloudflare Gateway, intercepts every DNS query at the OS level before it leaves the device, blocking known-malicious domains and logging resolution activity regardless of whether the VPN tunnel is up. Because DNS filtering catches C2 domain resolution and malicious redirects at the moment they happen, it closes the single biggest gap split tunneling opens: traffic that never touches your tunnel still touches your DNS filter.

EDR with network telemetry and process correlation. Endpoint detection and response tools that log outbound connections per process, not just per device, let analysts spot a process making unusual direct-to-internet connections and tie that behavior back to a specific binary. This is what turns "the device beaconed somewhere odd" into "process X, launched from this path, at this timestamp, talked to this IP."

CASB or SaaS-layer DLP, plus endpoint DLP where regulation demands it. Since split-tunneled traffic often heads straight to cloud apps, a cloud access security broker enforces data controls at the SaaS layer itself rather than relying on network-path inspection. Pair it with endpoint DLP for regulated data types that must never leave the device unencrypted or unlogged.

UEM/MDM posture checks, MFA, and conditional access. Unified endpoint management verifies device compliance (patch level, disk encryption, EDR agent health) before granting network access, and conditional access policies can require multi-factor authentication before a device is allowed to request a split-tunnel exception in the first place.

Secure-by-default routing: inverse split tunneling. Instead of tunneling everything and excluding a growing list of exceptions, default all traffic to the tunnel and carve out only small, well-scoped exclusions, typically bandwidth-heavy, low-risk traffic like video conferencing media streams. Inverse split tunneling reduces accidental exposure compared with the more common whitelist-by-exclusion model, because nothing bypasses inspection unless someone deliberately put it on the list.

ControlWhat it catchesDeploys to
Endpoint DNS security agentMalicious domains, C2 resolutionAll managed endpoints
EDR with network telemetryAnomalous process-level connectionsAll managed endpoints
CASB / SaaS DLPData exfiltration via cloud appsCloud app traffic
UEM/MDM + MFANon-compliant devices, unauthorized exceptionsException requests

Pro Tip: Run your DNS security agent and EDR telemetry through the same alerting pipeline. A DNS block with no corresponding EDR event, or the reverse, is often the first sign one of the two agents has silently stopped reporting.

Secure Techies configures this exact stack, network security plus endpoint controls, as the baseline for any client running split-tunnel VPN policies, and it's worth reviewing whether your current architecture reflects the same layering Bossy's security resources recommend for trust-critical environments.

How Should IT Teams Approve and Audit Split-Tunnel Exceptions?

Every split-tunnel exception needs a paper trail, or it becomes permanent shadow IT within a quarter. A workable process looks like this:

  1. Request. The employee or team lead submits a specific business justification, naming the app or domain that needs the exception and why full tunneling breaks it (usually latency-sensitive tools like video conferencing).
  2. Risk owner review. Someone in security, not the requester's manager, evaluates the exception against data sensitivity and threat exposure. Regulated data workflows get an automatic denial or an escalation.
  3. Technical preconditions. Approval requires proof that the endpoint has an active EDR agent, a functioning endpoint DNS security agent, and current device compliance status through UEM. No exceptions without all three.
  4. Time-boxed approval. Exceptions are granted for a fixed window, never indefinitely, with the expiration date logged at the time of approval.

Audit the program by correlating VPN connection logs with endpoint telemetry weekly, looking for devices whose direct-to-internet volume doesn't match their approved exception list. Set revocation triggers for any EDR agent going offline, any failed compliance check, or any exception that's simply aged out. A 30/60/90-day review cadence, tightest at 30 days for new exceptions, keeps the exception list from becoming a graveyard of forgotten approvals nobody remembers granting.

How Do You Test and Verify Split-Tunnel Configurations?

Verification has to happen before rollout and on a recurring schedule after, not just once at launch.

  • Run IP and DNS leak tests from a managed device with the VPN connected, confirming the observed public IP and resolver both match expected values for tunneled traffic. OS-specific quirks between Windows, macOS, and mobile clients make this worth repeating per platform.
  • Compare VPN egress logs against endpoint network telemetry weekly to catch users whose traffic mix has quietly shifted toward mostly direct-to-internet.
  • Query EDR for outbound connections to uncommon ports or newly seen destinations, then map each one back to the originating process.
  • Schedule automated leak checks monthly, and run a lab-based simulated C2 test in an isolated environment periodically to confirm your DNS agent and EDR actually catch what they're supposed to.

What's Secure Techies' Take on Split Tunneling for SMB Clients?

We allow split tunneling for clients only when the endpoint DNS agent and EDR telemetry are already live, never as a first step. One restaurant client wanted guest Wi-Fi separated from POS traffic without slowing either network down. We isolated guest traffic entirely from the corporate VLAN and layered endpoint DNS filtering and monitoring onto every staff device that touched both networks.

Three takeaways for smaller IT teams: deploy DNS filtering before you loosen tunnel rules, never grant an exception without a compliance check, and review your exception list more often than feels necessary.

— Alex

How Can Secure Techies Help You Deploy This Safely?

Getting the endpoint DNS agent, EDR telemetry, and exception workflow all working together is the hard part, and it's exactly where Secure Techies replaces the guesswork of piecing this together in-house. Instead of your team researching, testing, and tuning EDR rules and DNS policies from scratch, Secure Techies deploys and manages the full stack, endpoint DNS agents, EDR with network telemetry, CASB and DLP integration for cloud apps, and split-tunnel policy audits, as one coordinated engagement with a Southern California team that answers when something breaks.

Securetechie

If you're running split tunneling today without knowing whether your DNS and EDR coverage actually closes the gap, a posture assessment is the fastest way to find out. Secure Techies' cybersecurity solutions cover exactly this kind of endpoint hardening and monitoring, backed by managed IT services that keep devices compliant long after the initial rollout. Contact Secure Techies to schedule a split-tunneling posture review for your environment.

Where Can You Read More on Split Tunneling and Endpoint Security?

Where Can You Read More on Split Tunneling and Endpoint Security? — overview diagram

For deeper technical detail on DNS leaks and monitoring approaches, the VPN Split Tunneling Security Risks and Monitoring Guide covers endpoint DNS agents and EDR telemetry in more depth. Comparitech's breakdown of split-tunneling risks walks through inverse tunneling configuration. Secure Techies' own remote work security checklist and Microsoft 365 security checklist round out the endpoint and SaaS hardening steps referenced throughout this guide.

Sources