K, I'll check if it's possible for me to do those changes. Thanks!

Thanks. I'm not doing any pre-flight checks for determining the status of the network to setup the VPN tunnel, and regarding the NEOnDemandRuleConnect - I defined a rule to always connect (this is the closest thing to always on). I do have logs at the server, but it seems the client isn't sending any requests. So it's a client issue.However, one of my users described something more specific, and he says it's persistent:He was at the office, connected to the LAN, and the VPN was off.Then he left the office, and walk home. The Mac entered sleep mode.At his home, he opened the Mac and connected to his WIFI. Then he tried to turn on the VPN.The VPN was stuck at 'connecting' phase. He needed to press the disconnect button, and then try reconnecting again. Only then it succeeds.From the logs I saw that when he first clicked the connect button, the error "network is unreachable" appeared.When he pressed the connect button the second time, everything was fine.So I think this is the situation:The VPN protocolConfiguration disconnectOnSleep is set. So when the Mac enters sleep mode, the system calls stopTunnelWithReason. When the Mac awakes, because my OnDemandRules, the OS would start the PacketTunnelProvider again.However, it seems that sometimes in those cases, the network would be unreachable.If I'm right, how can I solve it? And how can I print when the Mac enters sleep mode?

Thanks, I'll try to capture this error and search for more helpful logs.But if it's really something like "VPN connection is still being cached somehow, possibly an interface that no longer exists" - if I'll add exit(0) at all the "correct" places (where the extension should stop), will it help?

1. "Adding a exit(0) will terminate your program and I would bet this is not the desired action in this case." - this is not accurate. I'll add the exit(0) only where the user asked to stop the tunnel, so instead of a "clean exit" from the extension, I'll just terminate it.I read here at the forums that this is already acceptible behavior (because of the (knwon) bug that if you are trying to connect shortly after a disconnection, the connection will succeed, but you will get a disconnection after 20 sec).So I'm guessing that using this approch is considered ok, but please correct me if it may cause harm in some way.2. By " capture the incoming "Network is unreachable" error and programmatically force a disconnect on the VPN and then a new connect", you mean something like calling cancelTunnelWithError?3. Thanks for the quick replies!

K, I'll do it and report if I'll find something interesting.Thanks again!

Very old thread, but did you manage to disply the portal page when you are using VPN with Packet Tunnel Provider, and entering a place with a captive portal WIFI?

Update:Upgrading the OS to 10.15.2 (from 10.15.1) solved this issue. But any idea what caused it? Can it happen on users' Macs which run the app from the App Store (and not from Xcode as I did)?

If it will reproduce I'll collect all the info and open a bug.Thanks!

"Are are you talking about screen lock, that is, the device is awake but the screen is locked / off?" - in this case I think the notification should be shown, doesn't it? Isn't this the default behavior?And as for "device is truly asleep, your code is not running" - when the device is aleep, nothing runs even within the Packet Tunnel Provider? I thought the device do create some traffic even when on sleep mode, to check mails etc..

Got it. Thanks!

I'm using HTTP so simulate detection of a captive-portal, so there are cases I must use HTTP.I'll use the exception for the Extension only.Thanks!

Got it, thanks!

I'm having the same problem -I'm calling requestAuthorization at the containing app, and the user approves notifications.Then at the Extension, I'm calling getNotificationSettings, but the authorizationStatus is notDetermined, and the error is "Notifications are not allowed for this application". Trying to post notifications from the containing app is working fine, but I want to send the notifications from the extension, because the app might be in background mode.Also, looking at the Mac's Notifications Settings, I see that the "Allow Notifications from myApp" is enabled.I tried to test it on several devices - iphone with iOS 13, Mac with macOS 10.14.5 and Mac with macOS 10.15.2.

The onDemandRules contains only one class, onDemandRuleConnect, without any rules to match so it always applies:let onDemandRuleConnect = NEOnDemandRuleConnect() myVpn.onDemandRules = [onDemandRuleConnect]This is the description of the NEOnDemandRuleConnect class:When rules of this class match, the VPN connection is started whenever an application running on the system opens a network connection. Network connectivity will be blocked until the VPN is connected.So whenever there's traffic, the VPN should try to connect, but as I said above, it will fail. So AFAIK, all the traffic should be blocked, including the incoming email.I have a guess that might explain it, but I don't know if it's true:If the emails are pushed to the device from the mail server (aginst been fetched by the iPhone), and according to the above description, "the VPN connection is started whenever an application running on the system opens a network connection", maybe it's not consider to openning a network connection?

Thanks for the reply, but it's kind of surprising. I checked now at the documentation, and this is probably the relevant part (which I never noticed before, Taken from https://developer.apple.com/documentation/networkextension/netunnelprovidermanager):The Per-App VPN app rules serve as both routing rules and VPN On Demand rules. This is in contrast to IP destination-based routing, where the VPN On Demand rules are configured separately from the routing rules. When the onDemandEnabled property is set to true and an app that matches the Per-App VPN rules attempts to communicate over the network, the VPN will be started automatically.So can you explain what will heppen at the above case, where the VPN is not per app and I set the onDemandRules to "always connect"?Which traffic will start the VPN? And once the VPN is enbaled, if I understand correctly not all the app's traffic is guarenteed to go through the VPN, is it correct (the mail app didn't trigger the VPN to start, but if the VPN was already running, the mail would go via the VPN or bypass it)?And final question - Is it related to onDemand at all? If I set the VPN to be not per app and not onDemand, and I start the VPN, then it's the same scenario where not all traffic must go through it?P.S - I can't use the per-app because not all of my users have MDM system.The only way to configure Per-App VPN is by enrolling the device in a Mobile Device Management (MDM) system, and then linking apps that are managed by the MDM system with a VPN configuration created from a com.apple.vpn.managed.applayer configuration profile payload