IncludeAllNetworks

What IncludeAllNetworks Changes in a VPN

IncludeAllNetworks turns a VPN from a selective tunnel into a full-tunnel path. That means the client routes traffic for internal and external destinations through the VPN interface, so the VPN becomes the default egress path unless another exception is explicitly defined.

This setting matters because routing is not just a transport detail. It determines whether DNS, web access, SaaS connections and internal application traffic are forced through the same trust boundary, which can simplify policy enforcement but also change performance and availability expectations.

Why Full-Tunnel Routing Matters for Security

Forcing all traffic through the tunnel can improve consistency of inspection, logging and access control, especially where organisations want a single place to apply web filtering, data loss controls or proxy policy. It also reduces the chance that protected and unprotected traffic take different paths, which can otherwise create blind spots.

The trade-off is that the VPN now sits on the critical path for everything the endpoint does. If the tunnel is unstable, overloaded or misrouted, users may lose internet access or fall back to unsafe workarounds, and security teams may incorrectly assume traffic is still subject to central controls when it is not.

Operational Effects on Users and Networks

IncludeAllNetworks can change latency, bandwidth use and split-path behaviour, because remote traffic no longer exits directly to the internet. That can be helpful for standardising corporate policy, but it can also break local access patterns, interfere with captive portals, and increase load on the VPN infrastructure.

It also affects how organisations think about segmentation. A full tunnel does not by itself guarantee zero trust or least privilege, but it does create a more controlled routing model that can support those goals when paired with strong authentication, policy enforcement and traffic visibility.

When to Use It and What to Verify

Practitioners usually choose this setting when they need central inspection, remote-user control or a simpler trust model for unmanaged networks. It is most useful when the organisation wants the VPN to be the authoritative route for both internal applications and general internet access.

Before enabling it broadly, confirm the VPN capacity, DNS behaviour, exception handling and failover design. A full-tunnel client should have clear behaviour when the tunnel drops, because route leakage, captive fallback or silent bypass can undermine the intended security model.

Risk and Threat Considerations

Full-tunnel VPN routing creates a concentration risk: if the tunnel, concentrator or policy layer fails, a large share of user traffic can lose protection or availability at once. It also creates a trust-boundary risk because organisations may assume all traffic is inspected when split routes, exceptions or fail-open behaviour can still bypass central control.

Failure mechanism: Misconfiguration, tunnel instability or an overly permissive exception can send some traffic outside the intended control path, reducing logging, filtering and traffic inspection.

Impact: Attackers and users alike can exploit that gap to bypass monitoring, reach unsafe destinations, or create inconsistent enforcement that weakens incident detection and response.

Practitioner Guidance

What to watch for: Treat this setting as a routing control, not just a convenience option. Verify how it behaves with DNS, local subnets, captive portals and tunnel loss, because those edge cases often determine whether the design is actually secure in production.

Governance implication: If the organisation relies on full-tunnel routing for inspection or policy enforcement, document who owns the VPN path, the exception model and the failure mode so that security, networking and endpoint teams apply the same assumptions.