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?
boscpear
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Post
Replies
Boosts
Views
Activity
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?