Context: I work on Home Assistant App, a smart home platform which connects locally to their smart home server. The Apps essentially needs the local network permission and every single user gives the permission, but some in macOS 15.3 are reporting that even though the permission is given, the app still reports it is not, and logs also confirm that. Since there is no way to reset local network permission on macOS I am kind of on a dead end here. How can the user get out of this situation? I also read https://developer.apple.com/forums/thread/763753?answerId=824036022&replyId=824036022 and the TN3179 but still no solutions for my case.

I'm building an app that helps manage my own wifi access points. Now, all my wifis emit SSIDs starting with the same prefix. Is it possible for me to list down all the SSIDs near me that start with that prefix, so that determine which of my wifis are near me? (Swift) Can NEHotspotHelper or NEHotspotConfigurationManager help in this regard?

Hi, I am working on a use case where I want to read the wifi signal strength data in the terms of RSSI (Received Signal Strength Indicator) values (or) any other way of representation. when my iPhone is connected to the wifi and Move around the house. Is this use case possible ? If yes, what are all the entitlements that I have to obtain?

Hi, I would like to confirm if the matchDomains property in NERelayManager operates exclusively at the application layer. Specifically, it seems that adding IPv4 addresses or IPv4 CIDR blocks to the matchDomains list does not work, as the relay manager appears unable to match them. Relay Configuration For example, I tried adding the following IPv4 patterns to the matchDomains list: 11.22.33.44 11.22.. 11.22.* In this configuration, I expected traffic to be routed to the relay server as defined by the matchDomains entries. However, the relay manager did not handle these IPv4 patterns as anticipated. On the other hand, when using only the excludedDomains property, the desired IPv4 traffic is successfully routed to the relay server as expected. Purpose of Forwarding IPv4 to the Relay Server The primary reason for forwarding IPv4 traffic to the relay server is to address cases where certain applications—such as those developed with Flutter or React Native—use their own custom network stack. These custom network stacks often do not respect the relay configuration. As a result, even when these applications use domains that are matched by the relay manager’s matchDomains, their TCP connections to DNS-resolved IPv4 addresses bypass the relay server and connect directly to the IPv4 server. This behavior makes it critical to enable IPv4 matching to ensure all traffic, regardless of the application’s network stack implementation, is routed through the relay server. Questions Can IPv4 addresses or IPv4 CIDR blocks be used with matchDomains? If not, is there an alternative method to enable IPv4 matching while keeping matchDomains enabled? Thank you for your assistance.

I added a Content Filter to my app, and when running it in Xcode (Debug/Release), I get the expected permission prompt: "Would like to filter network content (Allow / Don't Allow)". However, when I install the app via TestFlight, this prompt doesn’t appear at all, and the feature doesn’t work. Is there a special configuration required for TestFlight? Has anyone encountered this issue before? Thanks!

In our iOS networking related app for the app store (with network extension using packet tunnel provider), we are supposed to read the list of nameservers for the network. We use res_ninit function. This function returns only 3 items (but in reality the network has more dns servers. In my case 5. Some ipv4 and some ipv6) Looking at the header file at iOS 18.2 -> user/include/resolve.h, it shows that the __res_state struct has a maximum limit of 3 for the nsaddr_list array. It seems that the reason the res_ninit function returns only 3 values is because of this. For our code to work correctly, it needs to know all the dns servers, but we only get partial results. Is there any other api that can get us all the dns servers ?

We're seeing some new and odd behavior where our NEPacketTunnelProvider instance is receiving a stopTunnelWithReason:completionHandler: call with reason NEProviderStopReasonInternalError. Can anyone shed some light into how to diagnose this situation? Here are some basic details: Our PacketTunnel has been in use for years and we only started seeing this issue recently. We're able to reproduce this behavior with some light browsing. The documentation provides no insight on why/when this might occur. Can anyone shed some light into how to diagnose this situation? Things we’ve tried so far: We grabbed a sysdiagnose and looked through the logs: a. Right before the stopTunnel, we see log items referring to a "nesessionmanager" (PID 2038) getting killed. Presumably, this is due to hitting a highwater threshold. (See sysdiagnose items listing below) b. Thinking these were due to memory pressure, we added logging of available/used memory. c. We confirmed that the PacketTunnel was only using 11,808.73 KB. d. Since, there is plenty of memory available the PacketTunnel was not killed for using too much memeory. We wondered if this could be due to our UI's usage of objects like: NETunnelProviderManager and NETunnelProviderSession a. We ran an experiment where we swiped closed the UI to ensure these manager/session objects are not used. b. Without the UI, we still saw the random stopTunnel with NEProviderStopReasonInternalError. We wondered if our routes were the problem, but they seem correct. a. See the NEPacketTunnelNetworkSettings listing below LISTING: From the system_logs.logarchive, the nesessionmanager log items: 2025-01-23 15:07:59.176146 -0800 0x278 memorystatus com.apple.xnu memorystatus: killing process 2038 [nesessionmanager] in high band ? (140) - memorystatus_available_pages: 18932 default kernel 2025-01-23 15:07:59.179641 -0800 0x278 memorystatus com.apple.xnu memorystatus: killing_highwater_process pid 2038 [nesessionmanager] (highwater 140) 7056KB - memorystatus_available_pages: 19161 compressor_size:69593 default kernel 2025-01-23 15:07:59.179888 -0800 0x278 memorystatus com.apple.xnu memorystatus: failed to kill a process and no memory was reclaimed default kernel 2025-01-23 15:07:59.185695 -0800 1 0x45e0c user/501/com.apple.nesessionmanager [2038] exited with exit reason (namespace: 1 code: 0x2) - JETSAM_REASON_MEMORY_HIGHWATER, ran for 266329ms default launchd 2025-01-23 15:07:59.231188 -0800 31 0x45bf2 com.apple.networkextension nesessionmanager(2038) exited default UserEventAgent 2025-01-23 15:07:59.253371 -0800 31 0x45bf2 com.apple.networkextension nesessionmanager exited with active sessions, re-launching nesessionmanager to clear agent status default UserEventAgent LISTING: From the system_logs.logarchive, the stopTunnel from PID 2046 2025-01-23 15:07:59.201581 -0800 SamplePacketTunnel [Extension com.REDACTED.PacketTunnel]: Calling stopTunnelWithReason because: None 2025-01-23 15:08:20.783112 -0800 SamplePacketTunnel 2025-01-23 15:08:20,786 2046 ERROR REDACTED (285805) - Exiting after waiting for stopTunnelWithReason LISTING: routes from NEPacketTunnelNetworkSettings { tunnelRemoteAddress = fd12:3456:789a:1::1 DNSSettings = { protocol = cleartext server = ( 2606:4700:4700::1234, 2606:4700:4700::2345, ) matchDomains = ( , ) matchDomainsNoSearch = NO } IPv6Settings = { configMethod = manual addresses = ( fd12:3456:789a:1::1, ) networkPrefixLengths = ( 64, ) includedRoutes = ( { destinationAddress = 2606:4700:4700::2345 destinationNetworkPrefixLength = 128 }, { destinationAddress = 2606:4700:4700::1234 destinationNetworkPrefixLength = 128 }, ) excludedRoutes = ( { destinationAddress = REDACTED destinationNetworkPrefixLength = 128 }, { destinationAddress = REDACTED destinationNetworkPrefixLength = 128 }, ) } MTU = 3072 } Thanks for taking a look, any help or suggestions would be greatly appreciated

Hi, I would like to confirm whether the matchDomains property in NERelayManager operates strictly at the Application Layer. Specifically, it seems that adding IPv4 addresses or IPv4 CIDR blocks to the matchDomains list does not work, as the relay manager appears unable to match them. For example, I tried adding the following IPv4 patterns to the matchDomains list: 11.22.33.44 11.22.. 11.22.* However, these IPv4 addresses or patterns are not routed through my Relay server. Additionally, I have observed that when using only the excludedDomains property, the desired IPv4 traffic is correctly routed to the relay server as expected. My question is: Can IPv4 addresses or IPv4 CIDR ranges work with matchDomains? If not, is there an alternative approach to enable IPv4 matching while matchDomains is active?

Hi, I’m urgently seeking assistance with an issue in my app development. The app allows users to control which domains are routed through my relay servers (six server URLs). However, I’ve encountered a problem: When a single relay configuration (for a single server URL) contains more than 70 domains, only one configuration can be active at a time. If I manually activate another relay configuration (for another server URL), the previously activated one automatically deactivates. Is there a way to overcome this limitation? Also, is there a maximum amount of domains that can exist across the per-app relays? I’m referencing the Apple documentation here: https://developer.apple.com/documentation/networkextension/relays Any guidance or insights into resolving this issue would be greatly appreciated! Thank you in advance :)

I am trying to setup an extension using DNSProxyProvider that intercepts the DNS traffic on UDP and inserts our custom device identifier and send it to our custom DNS Server which gives us the response which I forward to the requesting client. I have been able to append the identifier with the domain name when sending out request to our custom DNS and I am getting the response back just fine but when I try to write the response to the udpflow I get this error in Console Logs. Error Domain=NEAppProxyFlowErrorDomain Code=9 "The datagram was too large" UserInfo={NSLocalizedDescription=The datagram was too large} Here is what I have tried so far. Truncating the datagram size to less than 10 bytes. Sending in dummy Data object while trying to write to the flow. Double checking the Signing and Capabilities, for Targets, the App and Network Extension. Attached below is code from my NEDNSProxyProvider. The DNS request is process in the handleNewFlow function which calls processUDPFlow override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool { if flow is NEAppProxyTCPFlow { NSLog("BDDNSProxyProvider : Is TCP Flow...") } else if let udpFlow = flow as? NEAppProxyUDPFlow { NSLog("BDDNSProxyProvider: handleNewFlow : \(udpFlow)") processUDPFlow(udpFlow) // < -- } return true } In the code below I concatenate domain name in the request with deviceId and send it to our server. Also have the Logs lines in, please ignore them. // Read incoming DNS packets from the client self.udpAppProxyFlow = udpFlow udpFlow.readDatagrams { datagrams, error in if let error = error { NSLog("Error reading datagrams: \(error.localizedDescription)") return } guard let datagrams = datagrams else { NSLog("No datagrams received.") return } // Forward each DNS packet to the custom DNS server for (index, packet) in datagrams.enumerated() { let dnsMessage = self.parseDNSMessage(from: packet.0) NSLog("tDatagram Header: \(dnsMessage.header)") for question in dnsMessage.questions { NSLog("tDatagram Question: \(question.name), Type: \(question.type), Class: \(question.klass)") } for answer in dnsMessage.answers { NSLog("tDatagram Answer: \(answer.name), Type: \(answer.type), Data: \(answer.data)") } let oldDomain = self.extractDomainName(from: packet.0)! let packetWithNewDomain = self.replaceDomainName(in: packet.0, with: "827-\(oldDomain)") // func to append device ID NSLog("Packet's new domain \(self.extractDomainName(from: packetWithNewDomain ?? packet.0) ?? "Found nil")") self.sendToCustomDNSServer(packetWithNewDomain!) { responseDatagram in guard let responseDatagram = responseDatagram else { NSLog("Failed to get a response from the custom DNS server") return } let tDatagram = (responseDatagram, packet.1) udpFlow.writeDatagrams([tDatagram]) { error in if let error = error { NSLog("Failed to write DNS response back to client: \(error)") } else { NSLog("Successfully wrote DNS response back to client.") } } } } // Continue Reading Datagrams - DO NOT REMOVE! self.processUDPFlow(udpFlow) } } Following is the function I use to replace domainName // Ensure the datagram is at least the size of the DNS header guard datagram.count > 12 else { NSLog("Error : Invalid datagram: Too small to contain a DNS header") return nil } NSLog("BDLine 193") // Start reading after the header (12 bytes) var offset = 12 // Parse the original domain name while offset < datagram.count { let length = Int(datagram[offset]) // Get the length of the next label offset += 1 // Check for the null terminator (end of domain name) if length == 0 { // Domain name ends here break } // Validate that the length is within bounds guard offset + length <= datagram.count else { NSLog("Error : Invalid datagram: Domain name length exceeds packet size") return nil } // Skip over this label offset += length } Everything is falling into place other than this last Error I get when I try to write back to flow. What am I missing here and how can I resolve this issue? Any help would be appreciated. Thanks

Hi, We are developing software that configures a network extension via a system extension on MacOS. The host application (run as service) enables network extension and system extension capabilities. It registers the network extension. The network extension has network extension capabilities and configures an app-group to be bundled into the service. What we have built is already working, i.e. we build, sign, notarize and ship the code (it's already running on hundreds of SIP enabled customer devices in production). But, we are currently falling back to manual profile management (i.e. download and import the profile) so that Xcode accepts the entitlements suffixed with -systemextention. Recently we are testing deployment on iOS devices. For iOS profiles we cannot overcome the issues with setting the profile manually, XCode complains about mismatching networkextension entitlements even when manually importing the profile. So I thought I get to the bottom of why automated signing is not working and hopefully overcome the issues with iOS. Upon configuring automatic signing we ran into the following problem: For a network extension that is installed via a system extension the network extension capabilities are expected to be defined with a -systemextension suffix, i.e.: <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.developer.networking.networkextension</key> <array> <string>packet-tunnel-provider-systemextension</string> <string>app-proxy-provider-systemextension</string> <string>content-filter-provider-systemextension</string> <string>dns-proxy-systemextension</string> <string>dns-settings</string> <string>relay</string> When using automated signing the profile in our development account reflects these settings, i.e. the profile is correctly generated with the values above. However, XCode complains that the network extension capabilities don't match. I went as far as to configuring a new application-ID so that XCode would generate a new profile in the development account. I then downloaded and decoded the generated profile. The capabilities of the development portal profile were created as expected (as above), but somehow, the locally generated profile that is generated by XCode auto-sign expects: <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.developer.networking.networkextension</key> <array> <string>app-proxy-provider</string> <string>content-filter-provider</string> <string>packet-tunnel-provider</string> <string>dns-proxy</string> <string>dns-settings</string> <string>relay</string> What XCode auto-sign expects is not reflected in the development account profile (!). I tried to overcome this by changing the entitlements of the project to omit the -systemextension suffix. XCode auto-sign seemingly works then, but once the application is actually signed by CodeSign the signing fails because the capabilities don't match with the development account profile. I tried profile re-generation by clearing Library/Developer/Xcode/UserData/Provisioning Profiles, but it always results in the same problem - either XCode is happy and the code signing fails when building, or the other way round. Bottom Line: I think that somehow XCode evaluates the profile validity differently from CodeSign; somehow when using automatic signing XCode does not take the network extension + system extension into account, but only expects the capabilities of the network extension. If anybody know how to overcome this problem please help :)

In https://developer.apple.com/forums/thread/128705?answerId=405119022#405119022, it is said that But if it’s holding up connections that match the on demand rules, that’s the correct behaviour. So if there was an on demand rule to connect for all domains (Connect rule without any matching criteria), all traffic would be held up while in the connecting state. The problem is that a customer can have SSO configured so that auth happens outside of the vpn app. So sequence would be Connect for all domains on demand rule triggers vpn connection VPN, in order to connect, tries auth through a broker app. VPN is in connecting state and blocks broker app traffic and so auth cannot complete and it cannot connect. I tried adding an on demand rule for EvaluateConnection and never connect for the auth domains. However, that caused the vpn to never be triggered to connect. Is it possible to support the scenario of an on demand rule to connect for all domains while having a vpn connection dependent on auth done in a separate app? Do you have any recommendations?

I am working on a MacOS application in which I need System Extension along with some network extension capabilities. In order to distribute the app externally, I have to create a Developer ID application (provisioning profile) using the App ID that already has Network extension capability. I have followed this documentation to create the App ID and provisioning profiles: https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.networking.networkextension?language=objc What I have: 2 App IDs (For app with network and system extension capability and for extension with only network extension capability) *2 Developer ID application (For both App and Extension) My App's entitlement file contains: <key>com.apple.developer.networking.networkextension</key> <array> <string>app-proxy-provider</string> <string>packet-tunnel-provider</string> </array> My system extension's entitlement file contains: <key>com.apple.developer.networking.networkextension</key> <array> <string>packet-tunnel-provider</string> <string>app-proxy-provider</string> <string>content-filter-provider</string> <string>dns-proxy</string> </array> Both the targets now have the following error: Provisioning profile "StandaloneCSAExtension" doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement. Note: Instead of Developer ID application if I create a normal development provisioning profile with the same App ID, everything works perfectly fine, the only reason why we need to move to Developer ID application is because we need to distribute the app externally. Please help me if I have missed anything. Thanks in advance!

We have an application, which activates two network extensions (Content Filter, Transparent Proxy) during app launch which is written in Swift. When we are activating multiple network extensions under the same app bundle, in Ventura and Sonoma, under Privacy and Security it shows "Details" button. On click of it we see below issues: - It shows the app bundle name instead of respective network extension bundle name. - On click of OK button, it adds only one extension under "Network -> Filters -> Filters & VPN" and only after machine restart, we can see both the extensions under this screen. These issues are not seen in Sequoia. In Sequoia, it shows the extension names under the app name. There are separate controls to enable/add each of the extension. Attached the screenshots of Sonoma and Sequoia for reference Already submitted the feedback ticket. (FB16331169)

Hello, I'm developing a Mac application that uses a network extension. I'm trying to implement XPC to pass data between my main app and system extension and I'm using the SimpleFirewall demo app as a guide to do this. One thing I can't understand is how the ViewController in the SimpleFirewall main app has access to the class IPCConnection in the SimpleFirewallExtension without it being public and without SimpleFirewallExtension being imported in ViewController.

hi all. I’m working on a content filter system extension on MacOS. I try to disable the filtering in system settings, and it will cause smb shared folder connection interrupted. what I do in stopFilterWithReason:completionHandler: is waiting for the connection that is being filtered be allowed, then invoked the completionHandler. did I do something wrong here? is there a way to avoid the connection interruption?

Hi, We are developing an app using PacketTunnelProvider from Network Extension framework. It is packaged as a system extension. We are trying to implement an "always-on" functionality, but cannot manage to start the extension before user login, with or without on-demand enabled. However we see in other posts (1, 2) that a network extension packaged as sysex should automatically start before user login. Are we missing something? Is it a limitation of PacketTunnelProvider? Thanks

​ I developed a Content Filter using the Network Extension, and when deployed to a batch of hosts (50 +), the installation worked for most of them, but there were six exceptions: five of them were macOS 10.15 and one of them was macOS 12.5. ​ The phenomenon of these 6 hosts is: in the System Settings->Network, two content filters with the same name appear. When one of the content filters with the same name is clicked, shows "Please use 'X Agent Extension' to control this content filter configuration" ('X Agent Extension' is the program I developed, this content filter can be deleted by clicking the minus sign in the lower left corner). Click on another content filter with the same name, shows 'Please use 'null' to control this content filter configuration', (but this content filter can't be removed by clicking the minus sign in the bottom left corner). ​ These systems are clean, use CLI 'systemextensionsctl list', and have only one systemextension in the output (this systemextension is my content filter). Online reference "https://forums.macrumors.com/threads/how-to-delete-custom-dns-profile-from-network-preference.2293322/" this paper, by closing the SIP, and delete file '/Library/Preferences/com.apple.networkextension.plist', then restart the system can remove the abnormal content filters with the same name. After restarting the system and reinstalling my content filter, the two content filters with the same name disappear (only the Content Filter I reinstalled) and the exception scenario cannot be repeated. ​ I would like to know, why do I have two content filters with the same name, how can I avoid this phenomenon, is there a way to remove the wrong content filter without closing SIP.

I've implemented a custom system extension VPN for macOS, using Packet Tunnel Provider. I have a XPC connection, from the containing app to the (system) extension. What is the expected behavior after the Mac's sleep/wake? Will the same XPC remain valid? Should I start a new connection?

It's been two weeks since I submitted the MDM capability request form as our app requires an MDM to activate the DNS Proxy component. There's been zero emails about it, and I can't find anywhere to check the status on it. Does anyone have experience regarding the "MDM capability" request or is anyone from Apple able to provide some insight into what is expected?