VPN and ZTNA compatibility (Windows Client)

The ScoutDNS Windows Client is designed to operate alongside modern VPN and ZTNA clients. In practice, compatibility varies by which ScoutDNS client version you’re on, by vendor, and by tunnel mode. This page tracks what works for both the v1 (Scout360) device agent and the v2 (Windows Client) public beta.

[!IMPORTANT] The Windows Client (v2) is in public beta. See the v2 deployment guide for install, prerequisites, and verification. The v1 Scout360 agent remains the recommended default until V2 reaches general availability. This compatibility page will grow as we and our customers test more environments.

How v2 differs from v1 with VPN and ZTNA

The original Scout360 agent (v1) and the new Windows Client (v2) take very different approaches to DNS interception. The difference is what drives the better VPN and ZTNA compatibility in v2.

v1 (Scout360), loopback adapter model. The v1 agent installs a loopback network adapter on the device and sets the device’s primary DNS server to that loopback address. Windows then routes most standard adapter-DNS traffic to the agent first, and the agent decides where to forward it. NRPT-routed, DirectAccess-routed, and ZTNA-routed queries bypass the loopback adapter because Windows applies those rules before consulting adapter DNS.

This works well on devices that own their own DNS configuration. It works less well alongside a VPN or ZTNA client, because both products try to manage the same surface:

• The VPN or ZTNA client typically wants to push its own DNS servers onto the adapter, or insert NRPT rules to route internal namespaces through the tunnel. v1’s loopback adapter competes for that primary-DNS slot.
• Order of installation, network reconnects, and tunnel up/down events can cause one product to silently override the other’s DNS settings.
• GPO-pushed NRPT rules, DirectAccess rules, and ZTNA-supplied namespace routing all happen inside the Windows DNS Client before the query ever reaches the loopback adapter. v1 never sees those queries, which is fine for resolution but limits visibility.
• In full tunnel modes, the VPN can route around the loopback adapter entirely.

v2 (Windows Client), kernel-level WFP interception. The v2 client does not change adapter DNS, does not install a loopback adapter, and does not modify NRPT. Instead, a Microsoft-attested Windows Filtering Platform (WFP) kernel driver redirects plaintext UDP/53 through the local ScoutDNS service, blocks TCP/53 fallback fail-closed so truncated-response retries cannot bypass policy, and blocks common encrypted-DNS bypass paths (known public DoH endpoints and standard DoT/DoQ ports).

That ordering matters:

• Adapter DNS, NRPT entries, GPO-pushed DNS policy, and ZTNA-supplied namespace rules remain owned by Windows and the VPN or ZTNA client. ScoutDNS does not overwrite those settings. For internal namespaces that should resolve through a tunnel or corporate resolver, configure a matching Local Forwarder in the ScoutDNS profile.
• The WFP driver sees the query after Windows has decided where it should go. For configured Local Forwarder namespaces, the query is sent to its intended destination (the corp DNS server, the VPN-provided resolver, or the ZTNA stub). For everything else, the query is resolved through ScoutDNS encrypted DNS for policy and visibility.
• Because there is no adapter competition, install order and reconnect events are much less likely to put the integration into an inconsistent state.
• In full tunnel modes, whether ScoutDNS is in effect depends on whether the VPN or ZTNA client enforces its own DNS at a layer above or below WFP. Most tested products work cleanly; the exceptions are noted per-vendor below.

The net effect is that v2 adds DNS policy and visibility without replacing or competing with the VPN or ZTNA client’s existing DNS handling.

v1 (Scout360 device agent): VPN and ZTNA support

The general rule for v1:

• VPNs that support split tunnel typically work. Public DNS continues to flow through the v1 loopback adapter and resolve via ScoutDNS. Internal namespaces routed through the tunnel use the VPN-provided DNS servers.
  • Exception: if the VPN client also uses its own loopback adapter for DNS handling (some clients do this for their own filtering or for DoH/DoT enforcement), it will compete with v1’s loopback for the primary DNS slot and the integration generally does not work reliably, even in split tunnel mode.
• Full-tunnel-only VPNs generally do not work with v1. In full tunnel mode the VPN takes ownership of DNS at the adapter level, which conflicts with v1’s loopback adapter as the primary DNS server.

What tends to go wrong specifically:

• Adapter DNS contention. Both v1 and the VPN want to set the primary DNS server on the active adapter. The product that touches the adapter last usually wins, which means install order and reconnect events can change the outcome unpredictably.
• NRPT and DirectAccess bypass. Windows applies NRPT rules (often pushed by GPO or by the VPN/ZTNA client itself) before the loopback adapter is consulted. The v1 agent never sees those queries.
• Reconnect inconsistency. Tunnel up/down events can leave one or the other in an inconsistent state until the agent or the VPN client restarts.

If you’re running v1 alongside a VPN or ZTNA client and hitting any of these conditions, the Windows Client (v2) public beta is designed to address them. v2 does not modify adapter DNS at all, so it does not compete for that surface and works with many full-tunnel VPNs that v1 cannot.

If you need a per-vendor v1 result that isn’t covered above, open a support ticket and we’ll either share what we’ve tested or work through it with you.

v2 (Windows Client beta): vendor compatibility

The v2 client’s WFP interception sits below adapter DNS, NRPT, DirectAccess, and ZTNA-supplied namespace routing. Compatibility is generally better than with v1, and many tested clients run cleanly alongside v2 in both split tunnel and full tunnel modes. Vendor behavior still varies. Products that enforce DNS at a layer that bypasses WFP entirely are not protected by ScoutDNS in that mode.

Split tunnel vs full tunnel, in DNS terms

Most VPN and ZTNA clients can be configured in one of two tunnel modes:

• Split tunnel. Only traffic destined for specific networks (typically internal corp namespaces) flows through the tunnel. Everything else, including DNS for public destinations, takes the device’s normal local path.
• Full tunnel. All outbound traffic, including DNS, is routed through the tunnel. The VPN or ZTNA client typically forces its own DNS servers on the adapter or via NRPT.

For the v2 client, this distinction matters because:

• In split tunnel mode, DNS for public destinations is intercepted by the ScoutDNS WFP driver, processed by the local ScoutDNS service, and resolved through ScoutDNS encrypted DNS. Internal namespaces with a matching Local Forwarder resolve through the tunnel-provided resolver.
• In full tunnel mode, DNS handling depends on how the VPN or ZTNA client enforces its own DNS. Some vendors apply DNS routing at a layer that the WFP driver can still intercept, in which case ScoutDNS continues to enforce policy. Others enforce DNS at a layer that bypasses WFP entirely, in which case ScoutDNS protection is not in effect.

Compatibility matrix

Tool	Split Tunnel	Full Tunnel	Validation
SonicWall CSE (formerly Banyan)	Supported	Supported	Validated by ScoutDNS
Enclave	Supported	Supported	Validated by ScoutDNS
WatchGuard VPN	Supported	Supported	Validated by ScoutDNS
Fortigate VPN	Supported	Supported	Validated by ScoutDNS
Cloudflare WARP	Supported	Not supported	Validated by ScoutDNS
Azure VPN	Not yet verified	Supported	Validated by ScoutDNS
Zscaler ZIA	Not yet tested	Not yet tested	Pending validation
Netskope	Not yet tested	Not yet tested	Pending validation
Twingate	Not yet tested	Not yet tested	Pending validation
Tailscale	Not yet tested	Not yet tested	Pending validation

[!NOTE] “Validated by ScoutDNS” means the combination was confirmed working in ScoutDNS’s own test environment. Real-world customer environments can differ in tunnel configuration, NRPT policy, GPO interaction, and other factors, so individual customer validation is still recommended for production rollouts. If you are running the v2 beta with a VPN or ZTNA client not listed here, or have a different result than what’s listed, please open a support ticket. We add customer-reported results to the table as we receive them, and we prioritize new vendor validation based on customer demand.

Per-vendor notes

SonicWall CSE (formerly Banyan)

SonicWall Cloud Secure Edge (CSE), formerly Banyan, coexists cleanly with the v2 client in both tunnel modes.

• Split tunnel. ScoutDNS enforces DNS policy for public destinations. CSE-supplied DNS for internal namespaces continues to resolve through the tunnel when a matching Local Forwarder is configured in the ScoutDNS profile.
• Full tunnel. ScoutDNS continues to enforce policy at the WFP layer. CSE’s adapter and NRPT changes are not disrupted. Adapter-aware resolver selection in 2.1.4 lets configured internal namespaces resolve through the CSE tunnel correctly.

Enclave

Enclave coexists cleanly with the v2 client in both tunnel modes.

• Split tunnel. Same behavior as CSE: ScoutDNS enforces public DNS, Local Forwarders route configured internal namespaces through the Enclave-provided resolver.
• Full tunnel. ScoutDNS continues to enforce policy at the WFP layer.

WatchGuard VPN

WatchGuard VPN coexists cleanly with the v2 client in both tunnel modes.

• Split tunnel. ScoutDNS enforces DNS policy for public destinations; WatchGuard-routed internal namespaces resolve through the tunnel with a matching Local Forwarder.
• Full tunnel. ScoutDNS continues to enforce policy at the WFP layer.

Fortigate VPN

Fortinet’s Fortigate VPN coexists cleanly with the v2 client in both tunnel modes.

• Split tunnel. ScoutDNS enforces DNS policy for public destinations; tunnel-routed namespaces resolve through Fortigate’s DNS with a matching Local Forwarder.
• Full tunnel. ScoutDNS continues to enforce policy at the WFP layer.

Cloudflare WARP

Cloudflare WARP works with the v2 client in split tunnel mode only.

• Split tunnel. ScoutDNS enforces DNS policy for public destinations. WARP-routed namespaces resolve through the tunnel when a matching Local Forwarder is configured.
• Full tunnel. WARP enforces its own DNS at a layer that bypasses the WFP intercept. ScoutDNS protection is not in effect for DNS while WARP is in full tunnel mode. If WARP must run in full tunnel mode, ScoutDNS recommends running it without the v2 client and relying on Cloudflare’s own DNS controls, or switching WARP to split tunnel mode if ScoutDNS policy is required.

Azure VPN

Azure VPN works with the v2 client in full tunnel mode (validated by ScoutDNS). Split tunnel mode has not yet been verified, but is expected to work based on the general v2 architecture.

• Full tunnel. ScoutDNS continues to enforce policy at the WFP layer alongside Azure VPN’s adapter and routing changes.
• Split tunnel. Not yet verified. If you’ve tested this, please report your result.

How to test compatibility for a new VPN or ZTNA

If you’re evaluating a vendor not yet on the list, the basic compatibility test is:

1. Install the v2 client per the deployment guide.
2. Install and configure the VPN or ZTNA client. Note whether it’s in split tunnel or full tunnel mode.
3. Block-page test. From the device, browse to a known-blocked test domain (or a sample category the ScoutDNS profile blocks). The ScoutDNS block page should render. This is the load-bearing check that DNS is going through ScoutDNS.
4. Internal-namespace test. Resolve an internal hostname that should route through the tunnel. It should resolve successfully via the configured Local Forwarder.
5. Capture logs. Capture the current ScoutDNS service logs and installer logs on the device while the VPN or ZTNA client is active, then open a support ticket. If instructed by Support, you may also run the Windows Agent Diagnostic Tool; note that some checks in that tool were originally built for the v1 loopback-adapter agent and may not reflect v2 WFP-based behavior.

Resolve-DnsName by itself does not prove the traffic took the ScoutDNS path; it only proves resolution succeeded. The block-page test plus the captured service logs are the trustworthy checks.

If steps 3 or 4 fail in either tunnel mode, attach the captured ScoutDNS service and installer logs to a support ticket so we can add the result to the matrix.

Reporting compatibility results

We add customer-reported results to the matrix above. To report what you found:

• Include the VPN or ZTNA vendor and version.
• Note whether you’re on the v1 (Scout360) agent or the v2 (Windows Client) beta.
• Note the tunnel mode (split or full).
• State whether ScoutDNS block pages render and whether internal namespaces resolve correctly.
• Attach the ScoutDNS service and installer logs if anything didn’t behave as expected. If Support asks for it, you may also include output from the Windows Agent Diagnostic Tool. Note that some of its checks were built for the v1 loopback-adapter agent and may not reflect v2 WFP-based behavior.

Open a support ticket and we’ll follow up.

Related

• Windows Client (v2) deployment guide, the main v2 install and configuration reference.
• Roaming clients (device agents), the v1 (Scout360) agent reference.
• Windows Agent Diagnostic Tool, capture procedure for support tickets.
• Prevent DNS bypass, firewall-side companion to the agent’s encrypted-DNS block.