In https://developer.apple.com/forums/thread/128705?answerId=405119022#405119022, it is said that But if it’s holding up connections that match the on demand rules, that’s the correct behaviour. So if there was an on demand rule to connect for all domains (Connect rule without any matching criteria), all traffic would be held up while in the connecting state. The problem is that a customer can have SSO configured so that auth happens outside of the vpn app. So sequence would be Connect for all domains on demand rule triggers vpn connection VPN, in order to connect, tries auth through a broker app. VPN is in connecting state and blocks broker app traffic and so auth cannot complete and it cannot connect. I tried adding an on demand rule for EvaluateConnection and never connect for the auth domains. However, that caused the vpn to never be triggered to connect. Is it possible to support the scenario of an on demand rule to connect for all domains while having a vpn connection dependent on auth done in a separate app? Do you have any recommendations?

It looks like matchDomains works as expected for browser apps. Can you confirm if it is supported for non-browser apps? For example, if a non-browser app uses Core framework calls such as CFHostStartInfoResolution to resolve a domain to an IP and then directly connects to that IP, would that be expected to trigger the on demand rule?

From the docs: In iOS, iPadOS, and macOS, VPN On Demand lets Apple devices automatically establish a connection on an as-needed basis. It requires an authentication method that doesn’t involve user interaction—for example, certificate-based authentication. I wanted to confirm that authentication methods other than certificate-based authentication is supported for on demand rules. For example, would a token based authentication be supported? In general, it would not require user interaction. The exception would be when the token expires in which case we would temporarily disable on demand so that the user could login for a fresh token.

We have noticed that sometimes there are frequent sleep and wakeup calls in our PacketTunnelProvider logs despite no user interaction. For example:   2023-02-28 10:37:04.446111 UTC wake   2023-02-28 10:37:07.446953 UTC sleepWithCompletionHandler   2023-02-28 10:37:10.245550 UTC wake   2023-02-28 10:37:13.245609 UTC sleepWithCompletionHandler   2023-02-28 10:37:14.601693 UTC wake   2023-02-28 10:37:17.601220 UTC sleepWithCompletionHandler   2023-02-28 10:37:20.476486 UTC wake   2023-02-28 10:37:23.478591 UTC sleepWithCompletionHandler   2023-02-28 10:37:26.884939 UTC wake   2023-02-28 10:37:29.884604 UTC sleepWithCompletionHandler   2023-02-28 10:37:32.232937 UTC wake   2023-02-28 10:37:35.234157 UTC sleepWithCompletionHandler   2023-02-28 10:37:35.861171 UTC wake   2023-02-28 10:37:38.862450 UTC sleepWithCompletionHandler   2023-02-28 10:37:39.672081 UTC wake   2023-02-28 10:37:42.673964 UTC sleepWithCompletionHandler   2023-02-28 10:37:47.362123 UTC wake   2023-02-28 10:37:50.363501 UTC sleepWithCompletionHandler   2023-02-28 10:37:53.759341 UTC wake   2023-02-28 10:37:56.762477 UTC sleepWithCompletionHandler   2023-02-28 10:37:58.879447 UTC wake   2023-02-28 10:38:01.881076 UTC sleepWithCompletionHandler   2023-02-28 10:38:05.284252 UTC wake   2023-02-28 10:38:08.284785 UTC sleepWithCompletionHandler   2023-02-28 10:38:10.398992 UTC wake   2023-02-28 10:38:13.399746 UTC sleepWithCompletionHandler   2023-02-28 10:38:16.801673 UTC wake   2023-02-28 10:38:19.801687 UTC sleepWithCompletionHandler   2023-02-28 10:38:21.183971 UTC wake   2023-02-28 10:38:24.185463 UTC sleepWithCompletionHandler   2023-02-28 10:38:27.645370 UTC wake   2023-02-28 10:38:30.643598 UTC sleepWithCompletionHandler   2023-02-28 10:38:33.439431 UTC wake   2023-02-28 10:38:36.440460 UTC sleepWithCompletionHandler   2023-02-28 10:38:39.838367 UTC wake   2023-02-28 10:38:42.839743 UTC sleepWithCompletionHandler   2023-02-28 10:38:44.961735 UTC wake This can be problematic since we disconnect the tunnel connection on sleep and reconnect on wake. What could be causing such frequent sleeping and waking? Is there a workaround that could be used to avoid having to reconnect so often? Maybe a way to tell if the device screen is even on or unlocked when it is waking up?

This issue only happens once in a while. But after calling NETunnelProviderSession startTunnelWithOptions for a perApp VPN the Per-App VPN will get stuck in a connecting state. In PacketTunnelProvider, logging shows that it finishes init but startTunnelWithOptions is never called. On the console logs, the neagent has an extension request started: neagent Extension request with extension <extension name> started with identifier... However, when the issue occurs there is never a later log for neagent [Host <extension name>]: Starting with options.... There aren't any crashes or Jetsam events reported when it happens. It looks like this issue can be avoided by not trying to manually connect the Per-App VPN and just letting the app trigger the connection. Is manually connecting a Per-App VPN not supported?