VPN On Demand

How VPN On Demand Works

VPN On Demand is a policy-driven connection mode, so the device or app does not keep a tunnel permanently active. Instead, the VPN client watches for trigger conditions, such as a target domain, hostname, or network destination, and establishes the tunnel only when those conditions are met. That makes the feature useful for selective protection, but it also means the policy is the security boundary.

Because the tunnel is created in response to reachability rules, the quality of the rule set matters as much as the VPN technology itself. Poorly scoped triggers can send too much traffic into the tunnel, while gaps in the rule set can leave sensitive traffic outside it. In practice, VPN On Demand is less about “always on” privacy and more about conditional trust enforcement.

Where It Fits in Remote Access Security

VPN On Demand is usually part of a broader remote-access design rather than a standalone control. It is commonly used to protect only the traffic that needs internal reachability, while leaving ordinary internet use outside the tunnel. That can reduce overhead, avoid unnecessary routing complexity, and make remote access feel less intrusive for users.

The design trade-off is that the policy must correctly identify when protected access is needed. If the trigger logic is too narrow, users may fall back to direct access paths that were never meant to be exposed. If it is too broad, the organisation can create a de facto always-on tunnel without the operational benefits of a full always-on design. For a broader remote-access perspective, see Remote Access Identity Guide.

Security Implications of Conditional Tunnelling

The main security value of VPN On Demand is that it narrows encrypted access to defined conditions, which can reduce unnecessary exposure of internal routes and services. The main security risk is that the same policy logic becomes a point of failure: if the rules are misconfigured, stale, or incomplete, the device may connect when it should not, or fail to connect when it should.

That makes the feature sensitive to changes in DNS, application endpoints, split-tunnel behaviour, and network segmentation. It also means the trust decision is often made before the user notices anything has happened, which can obscure whether traffic is genuinely protected. In environments that rely on conditional access patterns, zero trust principles are often used to validate access decisions at the point of connection, not just at the endpoint of the tunnel, as reflected in NIST SP 800-207 Zero Trust Architecture.

When VPN On Demand is used for remote access control, the surrounding authentication and device-trust decisions are just as important as the tunnel itself. The tunnel should not be treated as a substitute for strong entry-point authentication or least-privilege reachability policy.

Operational Controls and Failure Modes

Practitioners should think of VPN On Demand as policy engineering, not just client configuration. The trigger set needs to be reviewed for business relevance, change-controlled when domains or services move, and tested across the actual devices and applications that depend on it. Otherwise, the feature can silently degrade into an access gap or an accidental blanket tunnel.

Common failure modes include stale destination rules, overlapping exceptions, incompatible DNS behaviour, and users bypassing the intended connection path because an application resolves or routes differently than expected. Good operational hygiene also includes validating what happens when the VPN is unavailable, because a conditional tunnel that fails closed in the wrong place can become a business outage, while one that fails open can create unintended exposure.

Risk and Threat Considerations

VPN On Demand concentrates risk in the trigger rules and in the tunnel initiation path. If an attacker can influence destination resolution, abuse a trusted domain, or obtain valid user credentials, they may be able to reach internal resources through a tunnel that the organisation assumes is only opening for legitimate use.

Failure mechanism: Weak policy boundaries, stolen credentials, or session abuse can cause the client to establish a trusted VPN path for traffic that should not have been authorised, or to leave intended access paths unprotected.

Impact: The result can be unauthorized internal access, broader lateral movement opportunity, and reduced visibility into which traffic should have been subject to stronger controls.

Practitioner Guidance

What to watch for: Review VPN On Demand rules whenever internal domains, SaaS dependencies, or remote-access workflows change. A rule set that once matched business intent can become unsafe or ineffective after a DNS change, application migration, or endpoint reclassification.

Governance implication: Treat the trigger policy as a high-value access control artefact, not a convenience setting. It should have an owner, a change process, and periodic validation against the services it is meant to protect.

Related resources from NHI Mgmt Group

• When is a reverse proxy better than a VPN for access control?
• Should security teams re-evaluate identity tooling when regional demand accelerates?
• How should security teams replace VPN trust with zero trust access controls?
• What is the difference between zero trust and a traditional VPN model?