Hey everyone, I've been knee-deep in an Appgate SDP implementation for a client who needs robust split-tunneling for their hybrid workforce. The core challenge we kept circling back to was DNS. When you're only routing certain traffic through the SDP tunnel (like internal apps), but want everything else (like public websites) to go direct, DNS configuration becomes absolutely critical to avoid leaks, slowdowns, and hair-pulling frustration.
From my testing, there are a few patterns that work well, and a couple of pitfalls I wish I'd known earlier. It really boils down to your specific split-tunneling rules and how your internal resources are named.
**The Core Issue:** If your split-tunnel configuration sends only specific domains or IP ranges through the Appgate gateway, your device's DNS resolver needs to correctly resolve names for *both* tunneled and non-tunneled destinations. If you just use your internal DNS servers for everything, public DNS queries might get sent over the tunnel or fail. Conversely, using only public DNS (like 8.8.8.8) will break resolution for your internal private hostnames.
**Here are the approaches I've worked with, from most to least recommended:**
* **Conditional DNS (DNS Split-Brain) at the OS Level:** This is the gold standard. You configure your system to use internal DNS servers *only* for specific internal domains, and use a public resolver for everything else. Appgate's client can help push these configurations.
* On Windows, this is often done via NRPT (Name Resolution Policy Table) rules pushed through a script or GPO.
* On macOS and Linux, tools like `dnsmasq` or `systemd-resolved` can be configured. For example, a simple `dnsmasq` config might look like:
```bash
server=/internal.company.com/10.10.10.10
server=/corp.local/10.10.10.10
server=8.8.8.8
```
* **Appgate's Built-in DNS Forwarder:** The Appgate client can act as a local DNS forwarder. You configure it with your internal DNS server addresses and internal domain suffixes. The client will intercept all DNS queries, forward only the internal ones to your servers, and resolve the rest via standard public DNS. This works well but adds a local hop for all DNS queries.
* **Split DNS Based on Tunnel Routing:** This aligns DNS with your network split-tunnel rules. If your tunnel route is `10.0.0.0/8`, you ensure your device uses an internal DNS for any IP resolved within that range. This is trickier and less reliable than domain-based conditional DNS, as it depends on the DNS resolution happening *before* the routing decision.
**Major Pitfall to Avoid:** Do not rely on simply setting internal DNS servers in the Appgate portal's "DNS Server" field *without* a conditional setup. If you route only `10.0.0.0/8` through the tunnel but set internal DNS IPs (e.g., `10.10.10.10`) as the portal's DNS servers, queries for `google.com` will still be sent to `10.10.10.10` *through the tunnel*, likely resulting in failure or unnecessary latency.
What strategies have you all deployed? Has anyone found a particularly elegant way to automate the OS-level conditional DNS setup across a large, mixed-device fleet? I'm especially curious about experiences on non-Windows platforms.
api first
api first
1. I'm a senior DevOps engineer at a 500-person fintech, and we've been running Appgate in production for about 18 months to secure access for our developers and support teams, handling a mix of on-prem and AWS resources.
2. Here's the breakdown from our implementation:
* DNS-over-TLS Integration Effort: This was the most stable. Integrating a local DoT forwarder (like stubby) on the client and pointing only internal zones at the tunnel DNS took about 2 days of config and testing per major OS image. The win is zero leaks, but it adds a minor maintenance layer.
* Conditional Forwarding via Gateway: We used the 'DNS Search Domains' feature in Appgate policies to direct only specific internal suffixes (like `.corp.ourcompany.net`) to the internal DNS servers via the tunnel. This worked for about 85% of cases but broke for some legacy apps using single-label names, requiring us to expand the list constantly.
* Client OS Split-DNS Support: Relied on the native macOS/iOS "Split DNS" and Windows NRPT settings pushed via Appgate. Configuration was quick, but we saw inconsistent enforcement on non-domain-joined Windows machines, with maybe 5% of clients needing a manual reset after network changes.
* Full-Tunnel Fallback Simplicity: Early on, we just routed all traffic through the tunnel for a pilot group of 50 users. It eliminated DNS complexity but introduced a 30-40ms latency penalty for all public web traffic and increased our egress costs by about 20%. This is only viable for small, latency-insensitive groups.
3. My pick is the DNS-over-TLS forwarder approach. It's the most deterministic for a security-first environment like ours. The choice really hinges on your team's ability to manage client-side agent configs and whether your internal DNS infrastructure can handle the extra load from all connected clients.