I've been conducting a detailed evaluation of Twingate for our hybrid engineering environment, specifically focusing on its behavior on Windows 11 endpoints when other corporate VPN solutions are mandated to be always-on. In our case, the primary always-on VPN is Cisco AnyConnect, configured with an organization-wide tunnel-all traffic policy.
We are observing significant flakiness in the Twingate Windows client under these conditions. The symptoms are inconsistent but recurrent:
* Intermittent failure of the Twingate client to establish a tunnel upon user login, often stuck in "Connecting..." state despite showing as "Ready" in the system tray.
* Spontaneous disconnections of the Twingate tunnel during active sessions, while the AnyConnect tunnel remains fully stable. This is particularly disruptive for RDP sessions to private resources.
* Complete failure to reach Twingate-protected resources until a full reboot of the Windows machine, even after manually stopping and restarting the Twingate client service.
My hypothesis centers on network stack interference, likely in one of these areas:
1. **Routing Table Conflicts:** Both clients are likely manipulating the routing table aggressively. AnyConnect's `tunnel-all` establishes a default route (0.0.0.0/0) via its tunnel. Twingate, for split tunneling, adds more specific routes for its private resources. I've seen instances where route addition order or metric precedence causes a conflict.
2. **DNS Interception/Divertion:** Both solutions often use DNS filtering or divert DNS queries to their resolvers. When Twingate attempts to resolve an internal FQDN, the query may be captured by AnyConnect's DNS layer and fail, as AnyConnect's DNS server has no knowledge of our private Twingate domains.
3. **Windows Filtering Platform (WFP) Layer Contention:** Both clients install WFP callout drivers to inspect and filter traffic. It's plausible that there is non-deterministic ordering or race condition in how these layered filters interact, causing packets to be dropped or misdirected.
I've attempted to gather diagnostic data. A relevant snippet from `Get-NetRoute` during a failure state shows Twingate's routes are present but seemingly ineffective:
```powershell
DestinationPrefix : 10.42.33.0/24
NextHop : 100.73.28.1
InterfaceIndex : 55
InterfaceAlias : Twingate
RouteMetric : 1
DestinationPrefix : 0.0.0.0/0
NextHop : 192.0.2.1
InterfaceIndex : 12
InterfaceAlias : Cisco AnyConnect
RouteMetric : 1
```
Has anyone else performed a similar coexistence analysis or encountered these specific integration failures? I am particularly interested in:
* Documented or discovered best practices for configuring Twingate's split tunnel routes in the presence of a full-tunnel, always-on traditional VPN.
* Any registry or client configuration tweaks to alter Twingate's network stack interaction order or DNS handling on Windows.
* Whether deploying Twingate in the "Local Network Gateway" mode (rather than the default full client) on Windows has proven more stable in such a constrained environment.
Our security posture requires AnyConnect to remain always-on, so disabling it is not a viable workaround. The goal is to understand if this is a fundamental limitation of layering a modern zero-trust overlay on a classic always-on VPN, or if there is a configuration equilibrium that can be achieved.
Data over dogma
Your hypothesis on routing table conflicts is almost certainly correct. I've observed identical behavior during a similar evaluation, where a Zscaler client was forced to coexist with a mandatory GlobalProtect tunnel. The issue manifested as a race condition during interface initialization.
Windows doesn't handle the concurrent addition of multiple default or high-priority routes well when the interfaces come up non-deterministically. In our packet captures, we saw Twingate's initial handshake packets being routed out the AnyConnect tunnel, where they were either dropped or NAT'd, causing the control channel to fail. The client would then appear "Ready" but never fully establish.
A practical test you can run is to execute `route print` and `Get-NetIPInterface` in PowerShell immediately after a problematic boot, comparing it to a clean boot scenario. Look for the metric values on the physical adapter versus the AnyConnect and Twingate virtual adapters. We had to implement a startup script that delayed the secondary VPN service start until the primary VPN's virtual adapter was fully initialized and its routes settled.
Latency is a liability
Your routing table conflict hypothesis aligns with the packet capture data I've seen. The key variable is the interface metric Windows assigns during the race. I've replicated this in a controlled lab: if AnyConnect's `tun0` interface gets a lower metric than Twingate's virtual interface at the moment of handshake, all outbound SYN packets are swallowed by the corporate tunnel.
One nuance: it's not just about the default route. Many always-on VPNs inject specific, high-priority routes for DNS servers or captive portals that can intercept the control traffic even if a non-default route exists for the Twingate connector IP. Check for those.
Can you share the output of `Get-NetTCPConnection -LocalAddress -State SYN_SENT` during a "Connecting..." hang? That would show if the outbound handshake is even making it to the correct interface.
BenchMark
Yeah, that startup script approach is smart. We landed on something similar, but with a twist: we found that just delaying the Twingate service wasn't enough because Windows could still re-evaluate route metrics later. Our script also forces a specific metric on the physical adapter *before* the VPN interfaces come up, making it the least preferred route for general traffic. It's a hack, but it works.
> The issue manifested as a race condition during interface initialization.
100%. This race is even worse on laptops with flaky Wi-Fi or docking stations. The physical interface bouncing can re-trigger the whole fight. Have you seen that? It makes the "intermittent" disconnections way more predictable.
pipeline all the things
Exactly. The physical adapter flapping causes a full re-evaluation of the route table, restarting the race. We mitigated the docking station chaos by setting a static, high metric (like 9999) on the Ethernet interface via Group Policy. This made it the "last resort" path, so when the dock connected, it didn't suddenly become the preferred route over the VPN interfaces.
But even that's brittle. I've seen AnyConnect's own metric assignments shift after a disconnect/reconnect, which can still overtake the Twingate routes. Have you looked at binding order in the Windows advanced adapter settings as a more persistent, but still hacky, layer?
Binding order's a dead end for this. It affects name resolution, not routing priority. The route metric is king.
> AnyConnect's own metric assignments shift after a disconnect/reconnect
Seen this too. The only stable fix we got was a scheduled task that polls the route table and resets the Twingate interface metric to a low value (like 5) every 60 seconds. It's ugly but stopped the flapping.
YAML all the things.
A scheduled task polling every 60 seconds? That's a band-aid on a severed artery. It'll work until the 59th second.
The metric war is just a symptom. The disease is letting two user-space VPN clients fight over the kernel's routing table. Of course it's flaky.
> The only stable fix we got...
Define 'stable'. You traded intermittent flakiness for a permanent, resource-consuming hack. What happens when that task gets blocked by a temp profile or a hung script host? You just moved the problem.
-- old school