Using a VPN with ScoutDNS

The problem

A VPN creates an encrypted tunnel between the device and a remote server (usually a company gateway). When the VPN is configured to send all traffic through that tunnel, the ScoutDNS roaming agent can’t reach the ScoutDNS cloud, its heartbeat and DoH queries are sucked into the tunnel along with everything else.

Symptoms when this happens:

• Agent shows Offline or Disabled in the Manage Clients view while the VPN is connected.
• DNS queries from the device disappear from the ScoutDNS activity log.
• The agent fails open (per design): DNS reverts to whatever resolver the VPN provides, so the device still has internet, but filtering and logging are bypassed.

The fix: split tunneling

Most VPN clients support split tunneling, which sends some traffic (typically internal corporate destinations) through the tunnel and lets the rest go out the device’s regular internet connection. Turn on split tunneling and exclude:

• ScoutDNS cloud destinations so the agent can reach the cloud directly.
• DNS traffic in general (since the agent intercepts DNS on the loopback and then forwards over HTTPS).

[!NOTE] Specific implementation varies by VPN. Common terms used by vendors include “Split Tunneling”, “Bypass List”, “Exclusion List”, “Allowed Apps”, or “Routed/Direct Networks”. Consult your VPN’s documentation for the exact setting name.

Alternative: ScoutDNS Relay on the corporate side

For organizations that don’t want to enable split tunneling (some regulated environments forbid it), an alternative is to terminate the VPN tunnel inside a network that has a ScoutDNS Relay deployed. The Relay handles filtering for traffic exiting the tunnel, and roaming agents can be disabled while the VPN is up.

Tradeoff: this only protects users while they’re connected to the corporate VPN, not when they’re off-VPN.

Related

• Roaming clients (device agents)
• Relay setup and configuration
• Prevent DNS bypass