We're seeing nessionmanager problems caused by having a configuration present on the system which. Has includeAllNetworks set in the protocol Was previously connected & then disconnected After VPN disconnection we sometimes see that DNS and other things are not working. The VPN extension is no longer running, so I'd expect that settings would have been cleaned up, but they aren't in some cases. The system won't recover on its own, and when we delete the VPN configuration we see a set of messages from VPN session manager. There are two I've seen, on different systems. One shows the utun interface being cleaned up, and various network settings being removed. The other refers to deregistering an Enterprise VPN Session, [NESMVPNSession unsetDefaultDropAll], and IP Drop-All disabled. In both of these cases the cleanup is being done hours after the session was disconnected and the extension unloaded from memory. Does anyone know what exactly is happening there, and why the OS isn't cleaning up on disconnect?

We're looking at taking a Network Extension VPN implemented as an App Extension, and porting it to a System Extension. We still intend to distribute through the app store as well, but have requests for out-of-store distribution. I remember seeing a thread about this some time back, but I haven't been able to locate it. If someone has a link to that thread please point me that way :-) We have some questions about bundle IDs, APIs, and entitlements, because we're looking to minimize customer disruption. Can we just add the SystemExtension entitlement to the current App ID for the network extension, update the profile, and continue with the same ID, or will we need to define a new ID? What will happen if someone installs the application from a package outside the app store, and then goes to the app store page for the application? Will the App Store recognize that the app is already installed? What about version differences? It looks like our management app can still use sendProviderMessage to communicate with the extension, and that we don't need XPC unless we want to give other applications the ability to talk with the extension. Is this correct? Can a System Extension use the NSWorkspace openURL API? It looks like a System Extension doesn't have the option of writing to a file, because it's not running as a logged in user and doesn't have access to a user's file systems. Is this correct? For certificate-based authentication the SystemExtension needs to be able to access and use a client certificate. Is there a recommended way for the extension to access the client certificate, e.g, if the extension starts without the GUI because of an on-demand VPN configuration? In that case it doesn't seem like it would have keychain access.

We have an App Group defined in our entitlements file so that two pieces of our software, a management GUI and a VPN extension, can write files to the same location. This is not just for regular log files. There's data we want to record which isn't appropriate for the system logs. What we're seeing on the iOS and macOS betas is that the write() file always fails, and we end up with \0s written to the file instead of the data. This is true both with the shipping versions of our applications on the App Store and with builds made with Xcode 15 and run on the devices in the debugger. Happens from both the Network Extension and the management application. Both macOS and iOS. Shipping apps and freshly built with latest tools. There's nothing we see in the Console logs that would appear to explain this. I didn't see anything in the release notes that would address this, but I could easily have missed something. Anyone else seen this?

We're seeing this message when trying to run test automation on iOS 17. We're building the app on Sonoma, using Xcode 15, and running on iOS 17 (physical iPhone 13). At one point in the test we want to verify that something is correctly set in the iOS Setting app. We were previously doing this by launching com.apple.Preferences On iOS 17 we're getting a failure because "XCTAutomationSupport couldn’t be loaded because it is damaged or missing necessary resources" I suspect that the error message is not actually representative of the real error Anyone seen this before?

We're seeing server trust failures with iOS 17 that we don't see with iOS 16, particularly in debugging, when we build with Xcode 15. We handle func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) and choose to deal with recoverable server trust failures of particular kinds ourselves. After our checks we end up calling the completion handler: let credential = URLCredential(trust: serverTrust) completionHandler(.useCredential, credential) And everything continues. This is working on macOS Venture and earlier and iOS 16 and earlier. It also works if we install our current release build on iOS 17. If we build with Xcode 15 and test on iOS 17 then calling the completion handler with .useCredential ends up failing with a -1200 error, and a message about a recoverable trust failure. Has anyone else seen this behavior? Does anyone know if this is related to just Xcode 15, or to Xcode 15 + an interaction with iOS 17? Maybe the SDKs used with Xcode 15 are being stricter? In any case it would seem that saying .useCredential should cause it to .use the credential...

In our PacketTunnelProvider we are seeing behavior for enforceRoutes which appears to contradict the documentation. According to the developer documentation (my emphasis): If this property is YES when the includeAllNetworks property is NO, the system scopes the included routes to the VPN and the excluded routes to the current primary network interface. If we set these IPv4 settings: IPv4Settings = { configMethod = manual addresses = ( 172.16.1.1, ) subnetMasks = ( 255.255.255.255, ) includedRoutes = ( { destinationAddress = 0.0.0.0 destinationSubnetMask = 0.0.0.0 }, ) excludedRoutes = ( { destinationAddress = 10.10.0.0 destinationSubnetMask = 255.255.255.0 }, ) overridePrimary = YES } Then if enforceRoutes is set to YES, then we do not see traffic for the excluded network, which is the expected behavior. If enforceRoutes is set to NO, then we do see traffic for the excluded network. In both cases includeAllNetworks and excludeLocalNetworks are both NO. The excluded network is not one of the local LANs. Is this a known issue? Is there some documented interaction that I missed here? Is there a workaround we can use to make this function as intended, with enforceRoutes set to YES?

We have four build agents. 2 x Intel, 8GB RAM 1 x M1, 8 GB RAM 1 x M2, 8GB RAM The only differences in the configurations are the processor types. On the Intel systems things work fine. On the M1/M2 systems we see the "Force Quit Applications" dialog, with the message: "Your system has run out of application memory." None of the processes it offers to quit are big, but checking Activity Monitor shows testmanagerd using 9+ GB (yes GIGABYTES) of Memory. It show "Real Memory" of about 1GB. Anyone have an idea of what's going on here? All of the systems are running the most current Ventura build, and Xcode 14.3

We're seeing two odd things with DNS in our Network Extension. One is a problem which appears to be related to an interaction between enforceRoutes and DNS One of the configurations we have is setting ourselves as the default DNS resolver by setting matchDomains to [@""], and specifying a list of DNS searchDomains. When enforceRoutes is YES we aren't seeing all the DNS resolution we expect. When enforceRoutes is NO it looks like it's working. Same iOS version (16.3), same VPN extension. The only difference in configuration is enforceRoutes set to YES in the failing case. excludeLocalNetworks in YES in each case. Is there some known interaction there that I'm missing? The other issue is that some customers with that configuration aren't seeing DNS name completion. I.e., if matchDomains is [ @"aaa.com", @"aab.com" ] then trying to resolve foo in a browser should attempt foo.aaa.com and foo.aab.com. We're not seeing that at all. If matchDomains is the same as searchDomains then resolution is happening fine.

I used to be able to use the Console on macOS to examine iOS device issues, and identify system issues that were causing problems with my app. The volume of logs generated with more recent versions of iOS is so large that the logs are basically useless. If I'm using Console to stream the log on macOS then it holds no more than a few seconds of data before is starts throwing away old lines. If I use sudo log collect --size <size>m --device-udid <UDID> I can specify a max of 999m, and that runs out in 5 seconds on average. Can't specify 'g' as an option for size :-( There doesn't appear to be a way to exclude logging information I don't need or to stream the log to a file with more than a 999 MB capacity. Is there some way to do this? I have a hard time believing that all this logging would be happening with no effective way to access it over longer times. Or maybe someone did just really mess up the logging system with current releases...

When I try to run unit tests in Xcode 14.3, it's often freezing up. Needs to be "Force Quit"ed. This happens most often the first time I try to run a suite through the GUI. Running a single test sometimes freezes, but not always. I can't pause the test execution, and when I try to exit Xcode it asks if I want to cancel the tests, but then it doesn't cancel them and I need to force quit at that point. Is there any know issue with 14.3 that would cause this?

We've been setting DNSSettings.matchDomains to an array containing an empty string in order to have all DNS requests sent to our NEPacketTunnelProvider. This worked fine in older versions of macOS, but we have a customer running Ventura who are seeing no DNS request being sent in that case. Is there any known change in the behavior of DNSSettings.matchDomains in Ventura?

We're seeing MPTCP traffic on the VPN's utun interface which does not match the IP routes defined in the network settings at VPN connection time. The routes defined at connection time are all private IP address spaces (10., 192.168. etc.), but we're getting MPTCP traffic destined for some AWS addresses. Is there any known issue with MPTCP routing &amp; VPNs on macOS/iOS?

We have a need to use IPv6 literals in URLSession host addresses at times. This has its roots in issues with load balancing, and which hosts share what information, and it isn't something we can work around right now. The IPv6 literal we're using was returned in the session metrics of a previous URLSession as the remote address of that connection. What are the formatting requirements for that, if any? I.e., if we're setting "61:ff4a::7a81:5002" // Not the real address :-) As the host part of a URLComponents(), then what's sent is 61%3aff4a%3a%3a7a81%3a5002 Which is kind of what I'd expect since it's escaping it. If we set "[61:ff4a::7a81:5002]" Which is what's specified in RFC-2732 then we get a host-not-found error Is there somewhere in the documentation about how we can use an IPv6 literal as a URLSession host address? In Supporting IPv6 DNS64/NAT64Networks the advice is "don't", but that's not one of our options...

We're seeing an accessibility error at several points in our tests Failed to get list of active applications: Accessibility error kAXErrorServerNotFound from AXUIElementCopyMultipleAttributeValues This was working previously. We didn't do any significant iOS updates on the devices, so I'm not sure what could have changed. One example is setting the device orientation: UIDevice.shared.orientation = .portrait When I break in the debugger at that point I also see the error when I try po XCUIDevice.shared.orientation = .portrait. If I try a second time then it works fine, but the first call always fails which causes the test to fail. There are some other calls which behave similarly. First call always fails with the error above, second call is fine. They're not throwing an exception, so I can't handle it with a do/try/catch. Is there an accessibility setting that needs to be made manually on the iOS device for this to work?

I'm seeing the connection to the VPN gateway failing in our Network Extension (not a System Extension) most of the time. Sometimes it succeeds. There's no difference in what the application or the extension are doing in the two cases. I can't see a pattern to when it fails, but In the console I see different messages. The only thing I've seen showing up consistently on failures but not successes is the message about the swfs_pid_entry. On failure: vpn_extension Gateway address 10.10.10.10, port 443 kernel ALF, old data swfs_pid_entry &lt;private&gt;, updaterules_msg &lt;private&gt;, updaterules_state &lt;private&gt; vpn_extension connect failed with error 65 (No route to host) kernel connect() - failed necp_set_socket_domain_attributes vpn_extension Connect returncode 65 On success: vpn_extension Gateway address 10.10.10.10, port 443 trustd  User has disabled system data installation.