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?

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