We're looking at mitigation options for the TunnelVisioning attack that exploits DHCP option 121 to set routes. It looks like Per-App VPN doesn't have the problem, but in standard mode we aren't able to touch potentially malicious host routes, so while we can mitigate it we can't eliminate the security problem completely. Is there any way to tell iOS and macOS to ignore DHCP option 121? Or even better, does Apple have a fix in the works?

Some users are unable to connect our PacketTunnelProvider-based VPN after upgrading our app from the Mac App Store. It might be related to whether or not you're connected at the time of the upgrade (or if our extension is loaded). Without TestFlight on the Mac it's tough to repro - we only get one shot per machine. After the upgrade our app launches, but hitting the connect button doesn't do anything, and it generates neagent and nesessionmanager console errors. We've found that killing our extension process fixes the issue in at least some cases, as does rebooting the Mac (which would also kill the process). I see appstoreagent killing our app, and it looks like nehelper is getting the message that the VPN profiles are now associated with the new app: default 14:28:32.154902-0700 nehelper App for configuration 65.154.227.166 (com.netmotionwireless.MobilityOSX) changed After the app restarts and the user tries to connect there are errors: error 14:28:39.323170-0700 neagent [u 7A49BFF0-7089-4B8D-BD2E-397E6551737D:m (null)] [<private>(<private>)] Hub connection error: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service on pid 0 named com.netmotionwireless.MobilityOSX.Extension" UserInfo={NSDebugDescription=connection to service on pid 0 named com.netmotionwireless.MobilityOSX.Extension} error 14:28:39.323797-0700 nesessionmanager NEVPNTunnelPlugin(com.netmotionwireless.MobilityOSX[453]): Validation of the extension failed error 14:28:39.323570-0700 neagent Failed to start extension com.netmotionwireless.MobilityOSX.Extension: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service on pid 0 named com.netmotionwireless.MobilityOSX.Extension" UserInfo={NSDebugDescription=connection to service on pid 0 named com.netmotionwireless.MobilityOSX.Extension} On appstoreagent performing the upgrade, should we expect that -stopTunnelWithReason: is called on the extension? If not can we rely on our app's -applicationShouldTerminate being called? Any thoughts about what to look for, or strategies for simulating an App Store upgrade?

Are there any official restrictions against getting location from a packet tunnel provider, in particular "Always On" permissions? It seems to work fine, I'm just asking because it triggers the permissions prompt(s), and we had a surprise with FaceID/TouchID also working fine until they suddenly didn't with an iOS release, the reason being they triggered UI.thanks,Eric

We're been using LAContext -evaluatePolicy:localizedReason:reply: in our packet tunnel provider extension without problems, but with the release of iOS 13.3.1 we're now getting LAErrorNotInteractive. We are not setting interactionNotAllowed (and I tried forcing it to NO w/no change in behavior).LAContext *bioConext = [LAContext new]; if ([bioConext canEvaluatePolicy:LAPolicyDeviceOwnerAuthentication error:&err]) { [bioConext evaluatePolicy:LAPolicyDeviceOwnerAuthentication localizedReason:@"string" reply:^(BOOL success, NSError * _Nullable error) { // ... error is LAErrorNotInteractive here ... }]; }Is there a new restriction on calling this from an extension because of the need to display UI?

A call to NETunnelProviderManager -startVPNTunnelWithOptions:andReturnError: when in airplane mode or all interfaces are disabled will return without an error, but the tunnel isn't started. In the console it's clear what the problem is:default14:39:25.852701 -0700nesessionmanager-[NESMSession handleCommand:fr:393 NESMVPNSession[...]: Received a start command from appname[512]default14:39:25.865293 -0700nesessionmanager-[NESMSession setStatus:]:755 NESMVPNSession[...]: status changed to connectingerror14:39:25.867015 -0700nesessionmanager-[NESMSession handleNetworkPre:638 NESMVPNSession[...]: No network availabledefault14:39:25.870846 -0700nesessionmanager-[NESMSession setStatus:]:755 NESMVPNSession[...]: status changed to disconnectingdefault14:39:25.876285 -0700nesessionmanager-[NESMSession setStatus:]:753 NESMVPNSession[...]: status changed to disconnected, last stop reason No network availableIs there a way to programmatically get hold of this error so I can let the user know? Currently we're doing preflight checks to try to avoid this situation, but there's the occasional corner case where this gets through, and we don't have a way to detect it. I'm not sure how easy it is for Apple to propagate errors back from NESMSession to NEVPNManager.thanks,Eric