Hi, We are currently working on porting our PacketTunnelProvider app extension to run as a system extension. Things are mostly working great, but we're now testing upgrades from the existing app extension to a system extension. We have an existing configuration that gets created and runs perfectly fine with the app extension. Then, when we go and upgrade to the system extension, and attempt to connect using the same existing configuration. We see this error in the nesessionmanager logs: 10:00:57.717694-0700 nesessionmanager Signature check failed: code failed to satisfy specified code requirement(s) error 10:00:57.717914-0700 nesessionmanager Rejecting agent com.agentBundleID.bundleID because it does not satisfy the code signature requirements error 10:00:57.717937-0700 nesessionmanager Failed to launch com.agentBundleID.bundleID If we create a new configuration profile in our upgraded app w/system extension it works fine. The problem only occurs with existing profiles. Our app doesn't even get any notification about this error, startVPNTunnelWithOptions:andReturnError: doesn't return any error that we can work with. My gut tells me this has to do with the ProviderDesignatedRequirement not being correct, but I really have no way to confirm this at all. The NETunnelProviderProtocol has no way to specify that in its API. Our providerBundleIdentifier was unchanged between the two extensions. Is there anything that we can do here? Or are we stuck re-creating the configuration profile after an upgrade?

We are using Manged App Configurations to dynamically push values to our app. We eventually want these values to reach our Network Extension process (specifically PacketTunnelProvider). However, there's some problems here: MDM providers only allow us to send configurations to app, not the extension. There's not really a way for us to reach the app configuration from the extension (even if the extension and app are in the same app group), because the app config is placed in [NSUserDefaults standardUserDefaults] A workaround would then be for the app to monitor for any AppConfig changes using NSUserDefaultsDidChangeNotification, and then write the app config settings to a shared NSUserDefaults instance. But when the app is in the background (most of the time for network extension apps), those notifications don't fire. I've attempted to use KVO to notify on any changes such as below: [[NSUserDefaults standardUserDefaults] addObserver:self forKeyPath:@"com.apple.configuration.managed" options:NSKeyValueObservingOptionInitial | NSKeyValueObservingOptionNew context:NULL]; - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context { NSLog(@"%@", [change description]); } But I am not seeing any KVO notifications here, even when NSUserDefaultsDidChangeNotification fires. This would be a workaround, but if the app is not running (due to connect-on-demand) or some other reason, this still would not work. Is there any possible workarounds or things that we can do here? Any help would be appreciated. Thanks

I am running into an issue with running a PacketTunnelProvider as a system extension, and fast user switching. Since the VPN is running as root, it runs outside any user context, and is accessible to all users on the machine. I can see the following behavior: Login to User A Connect VPN Fast switch to user B Open Safari, observe that traffic is directed and sent out the VPN. (As noted by the ability to browse otherwise un-reachable websites). Is there a way to detect that a fast user switch is happening? And disconnect the VPN when user B takes control of the screen. I know NSWorkspace is not a daemon-safe API. So NSWorkspaceSessionDidResignActiveNotification and like will not be useful here. One alternative would be to use NSWorkspace notifications in the GUI and alert the system extension via XPC. But that wouldn't work in the case where there isn't a GUI, such as with ConnectOnDemand. Is there a daemon-safe API to use or some other alternative? Thanks

Hi, We run a PacketTunnelProvider VPN on our macbooks. When we updated the Mac to MacOS Sonoma, we see strange behavior with regards to the Wi-Fi menu in system settings. After we connect a VPN, the Wi-Fi switch gets blanked out, and it doesn't detect any other networks. This is in contrast to the wifi task-bar, where we can see it functioning normally. Wi-Fi and the VPN also function normally. Switching Wi-Fi networks does not work, and after, the Mac will not connect to any Wi-Fi networks until it restarts. After disconnecting the VPN, this problem remains. The only way to fix this is to restart the Mac. I've filed FB13205010. I'm wondering if anyone has seen anything like this, because it makes having a VPN unusable on this version of macOS. All of the following screenshots were taken at the same time.

Somewhere between iOS 16 and iOS 16.5, we've been noticing a new timer when starting up our PacketTunnelProvider. When we start the VPN session and if we take longer than 60 seconds to call the completion handler in (void)startTunnelWithOptions:(NSDictionary *)options completionHandler:(void (^)(NSError *))completionHandler We see that our VPN gets shutdown by the OS. 11:19:15.371532-0700 nesessionmanager NESMVPNSession[Primary Tunnel:test:7A492A00-109B-4DC9-970F-563A7BBC65A6:(null)]: Plugin NEVPNTunnelPlugin(com.netmotionwireless.Mobility[inactive]) initialized with Mach-O UUIDs ( "69923795-443E-3B0D-9D51-1DC84EB26A08" ) 11:19:15.372733-0700 nesessionmanager NESMVPNSession[Primary Tunnel:test:7A492A00-109B-4DC9-970F-563A7BBC65A6:(null)] in state NESMVPNSessionStateStarting: plugin NEVPNTunnelPlugin(com.netmotionwireless.Mobility[inactive]) started with PID 27315 error (null) 11:19:15.389348-0700 nesessionmanager NESMVPNSession[Primary Tunnel:test:7A492A00-109B-4DC9-970F-563A7BBC65A6:(null)] in state NESMVPNSessionStateStarting: plugin NEVPNTunnelPlugin(com.netmotionwireless.Mobility[inactive]) attached IPC with endpoint 0xd5a820210 . . . 11:20:15.290251-0700 nesessionmanager NESMVPNSession[Primary Tunnel:test:7A492A00-109B-4DC9-970F-563A7BBC65A6:(null)]: State timer (60 seconds) fired in state NESMVPNSessionStateStarting 11:20:15.290375-0700 nesessionmanager NESMVPNSession[Primary Tunnel:test:7A492A00-109B-4DC9-970F-563A7BBC65A6:(null)] in state NESMVPNSessionStateStarting: timed out 11:20:15.293574-0700 nesessionmanager NESMVPNSession[Primary Tunnel:test:7A492A00-109B-4DC9-970F-563A7BBC65A6:(null)]: Leaving state NESMVPNSessionStateStarting 11:20:15.293813-0700 nesessionmanager NESMVPNSession[Primary Tunnel:test:7A492A00-109B-4DC9-970F-563A7BBC65A6:(null)]: Entering state NESMVPNSessionStateStopping, timeout 20 seconds 11:20:15.294034-0700 nesessionmanager NESMVPNSession[Primary Tunnel:test:7A492A00-109B-4DC9-970F-563A7BBC65A6:(null)]: config request: pushing handler [(null)] (null) 11:20:15.294286-0700 nesessionmanager <NESMServer: 0xd5a904120>: Request to uninstall session: NESMVPNSession[Primary Tunnel:test:7A492A00-109B-4DC9-970F-563A7BBC65A6:(null)] 11:20:15.294426-0700 nesessionmanager NESMVPNSession[Primary Tunnel:test:7A492A00-109B-4DC9-970F-563A7BBC65A6:(null)]: status changed to disconnecting We can see this with the log message State timer (60 seconds) fired in state NESMVPNSessionStateStarting Is there anything we can do to influence the length of this timer or change the state the VPN is in, other than calling the completion handler? Thanks

Hi, I am wondering if anyone knows anything about when TestFlight for macOS will officially be released? I was hoping it would be released with macOS 12, but that has not been the case. I know Apple updated the App Store Connect to be able to upload macOS builds to TestFlight, and the TestFlight beta was last updated in August. But I have not heard anything since. Thanks

Hi, If I am sending a UDP packet or ICMP packet through an unbound BSD socket, and I have the don't fragment bit enabled on those packets, is there a way to get the source IP address and interface MTU of whatever packet that was sent? I am specifically looking the case where the packet fails to leave the device I am using, due to the packet size being larger than the interface MTU. The way that this is indicated to me is the send operation returning EMSGSIZE. This is useful with PMTU discovery for example on a cellular interface, where the MTU can be around ~1430. Thank you.

Hi, We are running a PacketTunnelProvider, and are testing the effects of Encrypted DNS (DoH or DoT). According to WWDC20-10047, "resolution within the VPN tunnel will use the VPN's DNS settings and not your system-wide settings". We've been testing by enabling encrypted DNS system-wide using a configuration profile. However, we can see that in System Preferences -&gt; Network, both the VPN configuration, and the encrypted DNS configuration are active and running. And that DNS is encrypted, interfering with the proper function of our VPN application. Is this expected behavior? How can the behavior of encrypted DNS in conjunction with a VPN be characterized?

Hi, I'm writing a test app to send ICMPv6 packets. When I try to set the IPV6_DONTFRAG socket option, I get the error "operation not permitted" (EPERM). I am able to set the IPV6_DONTFRAG socket option on UDP sockets running IPv6. I am also able to set the IP_DONTFRAG socket option on ICMPv4 sockets. To summarize: UDP - IPV4, don't fragment option can be set UDP - IPV6, don't fragment option can be set ICMP - IPV4, don't fragment option can be set ICMP - IPV6, don't fragment option can't be set Is there a reason/workaround to get this to work? Another example, if the following command, I get that output language ~ % ping6 -D www.google.com ping6: IPV6_DONTFRAG: Operation not permitted If I run language sudo ping6 -D -s 1600 www.google.com the pings start to be sent, but according to a packet capture, they are fragmented. It seems like the socket option is not set/not followed? Thanks

Hi, We are running a VPN in a network extension using the NEPacketTunnelProvider APIs. When we re-configure the VPN adapter, such as on a roam, any active NSURL session task fails. Using a test app we've been seeing that TCP streaming using BSD sockets remains unaffected, but NSURL tasks get killed. This is what the NSURL task fails with. 021-04-05 17:18:31.202678-0400 TCPStreamer[17967:460702] Task 2B2AE33C-145B-46E5-96F0-15C1E21791B5.4006 finished with error [-1009] Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={​​​​​​​​_kCFStreamErrorCodeKey=50, NSUnderlyingError=0x1144d42a0 {​​​​​​​​Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={​​​​​​​​_kCFStreamErrorCodeKey=50, _kCFStreamErrorDomainKey=1}​​​​​​​​}​​​​​​​​, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDownloadTask 2B2AE33C-145B-46E5-96F0-15C1E21791B5.4006, _NSURLErrorRelatedURLSessionTaskErrorKey=(   "LocalDownloadTask 2B2AE33C-145B-46E5-96F0-15C1E21791B5.4006" ), NSLocalizedDescription=The Internet connection appears to be offline., NSErrorFailingURLStringKey=URL, NSErrorFailingURLKey=URL, _kCFStreamErrorDomainKey=1}​​​​​​​​ 2021-04-05 17:18:31.202699-0400 TCPStreamer[17967:460702] The Internet connection appears to be offline. 2021-04-05 17:18:31.203880-0400 TCPStreamer[17967:460700] Connection 4007: received failure notification 2021-04-05 17:18:31.203897-0400 TCPStreamer[17967:460700] Connection 4007: failed to connect 1:50, reason -1 2021-04-05 17:18:31.203934-0400 TCPStreamer[17967:460700] Connection 4007: encountered error(1:50) 2021-04-05 17:18:31.204591-0400 TCPStreamer[17967:460700] Task C0AB5E94-0CD8-4FBD-804F-99CA7C75F4CC.4007 HTTP load failed, 0/0 bytes (error code: -1009 [1:50]) I am wondering if this is intended, or if this is something I should file a bug for. Running the same test on macOS does not produce this issue. Thanks

Hi, We are looking for a way to identify the interface index. We need this information to bind our BSD sockets to the VPN's network interface (e.g. utun2). We've been unable to find a reliable way to determine the correct interface index to bind to. Thanks