OK. In that case I don’t see any way to make this work )-: When you set an on-demand rule, connections that match that rule are held until the demand is satisfied. This makes sense when you think about the intended use case for on-demand rules, namely, a split VPN. Typically this pans out as follows: There’s a site that’s only available on the organisation’s intranet. The device manager deploys an on-demand VPN configuration to access that intranet. The user runs an app that connects to that site. The system treats that as demand and starts the VPN connection. And holds the app’s connection until the VPN connection is established. Once that’s done, it releases the app’s connection, which then connects to the site over the VPN. This yields an obvious chicken’n’problem when the VPN provider relies on a connection that also matches the on-demand rule. The system can avoid this problems if the provider does it directly, from within its own process. This is the same sort of logic that NECP uses to avoid VPN loops.
Topic:
App & System Services
SubTopic:
Networking
Tags: