General: DevForums tag: Network Extension Network Extension framework documentation Network Extension and VPN Glossary DevForums post Debugging a Network Extension Provider DevForums post Exporting a Developer ID Network Extension DevForums post Network Extension vs ad hoc techniques on macOS DevForums post Extra-ordinary Networking DevForums post Wi-Fi management: Wi-Fi Fundamentals DevForums post TN3111 iOS Wi-Fi API overview technote How to modernize your captive network developer news post iOS Network Signal Strength DevForums post See also Networking Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I am seeing an interesting behavior on iOS 16.4+ when I set NEVPNProtocol includeAllNetworks flag to TRUE as part of my tunnels's saved preferences. After my packet tunnel provider starts up and goes through the usual setup of adding routes, where let's say we just just add NEIPv4Route.default() to route everything and eventually setting via: setTunnelNetworkSettings. Any subsequent calls to cancelTunnelWithError will cause the phone to get into a state where the tunnel provider goes away but it appears that my routes did not properly clean up, essentially causing a device to get into a state where all network traffic is now dead. The only way to recover is to go into OS Settings -> VPN and change selected profile to some other one, or just remove ours and go through installation again. It appears to only be happening on iOS 16.4+ devices, any previous versions clean up just fine. Curious if anyone has seen such behavior? Thanks in advance.

Experiencing an internet connectivity issue on iPhone device with one of iOS VPN configuration in PacketTunnelProvider. We have set up a full tunnel route configuration as follows: _pcktTunProvider.protocolConfiguration.includeAllNetworks = YES; _pcktTunProvider.protocolConfiguration.excludeLocalNetworks = NO; _pcktTunProvider.protocolConfiguration.enforceRoutes = NO; With these settings, the VPN successfully establishes a connection, and all traffic is routed through the tunnel as expected. Issue we are facing: However, we encounter a problem when we attempt to disconnect the VPN. When we call the following method from PacketTunnel network extension: (void)cancelTunnelWithError:(nullable NSError *)error The VPN disconnects, but the device loses all internet connectivity and is unable to access any resources. What we have tried: We have also tried using the following method with the same result:       - (void)stopTunnelWithReason:(NEProviderStopReason)reason completionHandler:(void (^)(void))completionHandler Interestingly, when we call the following method from the app side. The VPN disconnects and the device retains its internet connectivity. [enabledConfig.connection stopVPNTunnel]; But for our use case we cant call stopVPNtunnel from App if App is not running so looking for a solution that could clear the tunnel from NE as cancelTunnelWithError Api causes internet blocker issue. One more similar ticket here: https://forums.developer.apple.com/forums/thread/730689

Assume a VPN client with a packet tunnel provider is implemented where the NEPacketTunnelNetworkSettings of the tunnel indicate that all traffic must be routed through it (includedRoutes=0.0.0.0/0). One of our requirements is that we don't want to force our customers to use a DNS server operated by the VPN. Some customers want to route their traffic over the VPN, but operate their own DNS servers. Other customers might be using a DNS proxy provider on their Mac. Others might have a DoH/DoT configuration profile installed. We essentially would like all traffic to be routed through the VPN, but DNS resolution should use the DNS resolver that the Mac would have used if the VPN were not connected. We considered two potential solutions to implement this. Firstly, we tried setting in the configuration an NEDNSSettings object where the nameservers field is set to an empty array. In our testing, it appears that such setup (includedRoutes=0.0.0.0/0 with nameservers=[]) results in no DNS resolver appearing in /etc/resolv.conf. scutil --dns reports that no global resolver is set on the system when such configuration is applied. DNS resolution on the system is entirely broken when these settings are applied. This fundamentally makes sense: we're telling the system that all traffic must go through the VPN interface, but also the VPN interface provides no DNS resolver! Interestingly, with this setup DNS resolution is still possible if a DNS proxy provider or DoH/DoT configuration profile is installed. An alternative approach we considered is based on the fact that we are able to determine the IP address(es) of the local DNS resolvers on the network. We could set those resolver IPs in the NEDNSSettings configuration. For instance, if the LAN of the Mac provides a DNS forwarder at 192.168.1.1, we could pass nameservers=["192.168.1.1"] in the NEDNSSettings . Then, in NEPacketTunnelNetworkSettings we can set includedRoutes=["0.0.0.0/0"] and excludedRoutes=["192.168.1.1/32"]. This setup works, as all traffic goes through the VPN, except that DNS queries are forwarded to 192.168.1.1. However, this doesn't properly handle a DNS proxy provider or DoH/DoT configuration profile installed on the Mac. With this setup, DNS resolution ignores the DNS proxy/encrypted DNS configuration, and all DNS queries are always sent to 192.168.1.1. We could fix this if our network extension was able to detect that such provider/configuration profile is enabled and switch back to specifying an empty array of resolvers, but of course privacy consideration prevent such information from being available to a sandboxed network extension. Is there a way for developers in NEDNSSettings to indicate that we want the system DNS resolver to handle all queries as if our VPN hadn't been installed?

This is the bug: https://forums.developer.apple.com/forums/thread/729348?answerId=780151022#780151022 [quote='780151022, LostButFound, /thread/729348?answerId=780151022#780151022, /profile/LostButFound'] This issue still happens for me. With and without VPN, with both OpenVPN and Wireguard. With and without filtering (mostly with filters though, both LuLu and Little Snitch). On two different machines, M1 and M3. It's random. If I have to bet, there's a deadlock caused by running x86 code on Arm hardware. As a software engineer I saw cases where Intel tolerates bad multI-threading more than Arm. Are the Apple devs working on this? This is a very serious issue that makes these very expensive laptop unusable! At least provide a way to reset the network stack! 0  comments [/quote] It seems that the Network Extension Framework has a bug where combining VPN and Network filters causes deadlocks and timeouts in networking on irregular basis, regardless of the network interface used. This issue happens at a lower level than network interfaces. It can be either a Network Extension Framework bug or a kernel module bug. Given that the network extension frame isn't open source, I can't even debug it, which I would've happily done. Yes, even though I'm not an apple developer, but this bug is so bad that I'm happy to build MacOS components in debug mode and attach a debugger on them when the issue happens... but it's not open source. So, we have a bug, and we need help from apple devs to fix it... what am I supposed to do? Is there a chance I can get a dev to contact me to debug this together? What are my options?

When our NETransparentProxyProvider system extension is installed on the system it seems that external images from emails do not load on the Mail application. The extension does not have to be running to experience this issue. When we uninstall the extension, these same images load on the Mail application. Another way to get the images to load seems to be to disable "Hide IP address" under Settings > Privacy. We can see this issue present on the latest macOS 14.5. I have filed FB13805670 for this issue. Please advise if this is a known issue or if there is a solution.

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

As I've mentioned multiple times, we've discovered some very annoying failures when using a TPP, including FaceTime, AirDrop, and some VPNs. (Tailscale works fine, weirdly enough.) In doing some experimentation today with FortiNet, I was able to get the TPP to work if I added the FortiNet server (which, in our case, is an amazon VM) to the TPP's excludedNetworks list. While it is not working, the tcpdump I got for the host was: 15:15:35.584029 IP (tos 0x0, ttl 64, id 1976, offset 0, flags [none], proto UDP (17), length 412) 192.168.43.16.55067 > ${hidden}.ipsec-msft: [udp sum ok] NONESP-encap: isakmp 1.0 msgid 00000000 cookie d66f571dcfc483ba->0000000000000000: phase 1 I ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=2 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=enc value=aes)(type=keylen value=0080)(type=auth value=fde9)(type=hash value=sha1)(type=group desc value=modp2048)) (t: #2 id=ike (type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=enc value=aes)(type=keylen value=0100)(type=auth value=fde9)(type=hash value=sha2-256)(type=group desc value=modp2048)))) (vid: len=16 4a131c81070358455c5728f20e95452f) (vid: len=16 8f8d83826d246b6fc7a8a6a428c11de8) (vid: len=16 439b59f8ba676c4c7737ae22eab8f582) (vid: len=16 4d1e0e136deafa34c4f3ea9f02ec7285) (vid: len=16 80d0bb3def54565ee84645d4c85ce3ee) (vid: len=16 7d9419a65310ca6f2c179d9215529d56) (vid: len=16 cd60464335df21f87cfdb2fc68b6a448) (vid: len=16 90cb80913ebb696e086381b5ec427b1f) (vid: len=16 4c53427b6d465d1b337bb755a37a7fef) (vid: len=16 b4f01ca951e9da8d0bafbbd34ad3044e) (vid: len=8 09002689dfd6b712) (vid: len=16 12f5f28c457168a9702d9fe274cc0100) (vid: len=16 afcad71368a1f1c96b8696fc77570100) E.......@.....+.6.8c......6......oW........................|...d...........X.......(..............Q........................(..............Q.........................J.....XE\W(...E/........m$ko....(.......C.Y..glLw7."........M...m..4......r........=.TV^.FE..\......}...S..o,....R.V.....`FC5.!.|...h..H........>.in.c...B{.....LSB{mF].3{.U.z..........Q.......J..N.... .&.............Eqh.p-..t...........h...k...wW.. 15:15:35.901666 IP (tos 0x0, ttl 46, id 23154, offset 0, flags [none], proto UDP (17), length 272) ${hidden}.ipsec-msft > 192.168.43.16.55067: [udp sum ok] NONESP-encap: isakmp 1.0 msgid 00000000 cookie d66f571dcfc483ba->d1ec3b9d2f311bf5: phase 1 R ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=enc value=aes)(type=keylen value=0080)(type=auth value=fde9)(type=hash value=sha1)(type=group desc value=modp2048)))) (vid: len=16 4a131c81070358455c5728f20e95452f) (vid: len=16 afcad71368a1f1c96b8696fc77570100) (vid: len=8 09002689dfd6b712) (vid: len=16 12f5f28c457168a9702d9fe274cc0204) (vid: len=16 4c53427b6d465d1b337bb755a37a7fef) (vid: len=16 8299031757a36082c6a621de00000000) (vid: len=16 9b15e65a871aff342666623ba5022e60) (vid: len=16 ca4a4cbb12eab6c58c57067c2e653786) E...Zr......6.8c..+.......Z>.....oW.......;./1.................<...........0.......(..............Q.........................J.....XE\W(...E/........h...k...wW...... .&.............Eqh.p-..t.......LSB{mF].3{.U.z..........W.`...!............Z...4&fb;...`.....JL......W.|.e7. 15:15:35.901756 IP (tos 0x0, ttl 64, id 41586, offset 0, flags [none], proto ICMP (1), length 56) 192.168.43.16 > ${hidden}: ICMP 192.168.43.16 udp port 55067 unreachable, length 36 IP (tos 0x0, ttl 46, id 23154, offset 0, flags [none], proto UDP (17), length 272) ${hidden}.ipsec-msft > 192.168.43.16.55067: [no cksum] [|isakmp_rfc3948] `.....<"..:...E..8.r..@.}q..+.6.8c...Q....E...Zr......6.8c..+......... 15:15:38.904628 IP (tos 0x0, ttl 46, id 23155, offset 0, flags [none], proto UDP (17), length 272) ${hidden}.ipsec-msft > 192.168.43.16.55067: [udp sum ok] NONESP-encap: isakmp 1.0 msgid 00000000 cookie d66f571dcfc483ba->d1ec3b9d2f311bf5: phase 1 R ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=enc value=aes)(type=keylen value=0080)(type=auth value=fde9)(type=hash value=sha1)(type=group desc value=modp2048)))) (vid: len=16 4a131c81070358455c5728f20e95452f) (vid: len=16 afcad71368a1f1c96b8696fc77570100) (vid: len=8 09002689dfd6b712) (vid: len=16 12f5f28c457168a9702d9fe274cc0204) (vid: len=16 4c53427b6d465d1b337bb755a37a7fef) (vid: len=16 8299031757a36082c6a621de00000000) (vid: len=16 9b15e65a871aff342666623ba5022e60) (vid: len=16 ca4a4cbb12eab6c58c57067c2e653786) E...Zs......6.8c..+.......Z>.....oW.......;./1.................<...........0.......(..............Q.........................J.....XE\W(...E/........h...k...wW...... .&.............Eqh.p-..t.......LSB{mF].3{.U.z..........W.`...!............Z...4&fb;...`.....JL......W.|.e7. 15:15:38.904763 IP (tos 0x0, ttl 64, id 8956, offset 0, flags [none], proto ICMP (1), length 56) 192.168.43.16 > ${hidden}: ICMP 192.168.43.16 udp port 55067 unreachable, length 36 IP (tos 0x0, ttl 46, id 23155, offset 0, flags [none], proto UDP (17), length 272) ${hidden}.ipsec-msft > 192.168.43.16.55067: [no cksum] [|isakmp_rfc3948] `.....<"..:...E..8"...@.....+.6.8c...Q....E...Zs......6.8c..+......... So, given that, I tried adding let msftIPSecHost = NWHostEndpoint(hostname: "", port: "4500") let msftIPSecRule = NENetworkRule(destinationNetwork: msftIPSecHost, prefix: 0, protocol: .any) settings.excludedNetworkRules = [msftIPSecRule] and... it worked. At least, the fortinet client worked, and AirDrop transmission worked. Note that I never saw the flows for port 4500 in handleNewUDPFlow(:initialRemoteEndpoint:) -- just having a UDP rule that would intercept them seems to have caused it to fail. Anyone encountered this, or have an explanation? (I am now trying it in our actual product to see how it works.)

We are trying to diagnose an issue with our VPN network extension but have discovered that the VPN logging profile, available on the Apple Developer website is not valid: We have tried installing it on multiple phones, including the latest version of iOS 17 with no success so far. We would appreciate if the profile could be updated as soon as possible.

I have an app that utilizes the Network Extension ( Packet Tunnel Provider ), but also uses MDNS to find local devices for data transfer via Network Extensions. However, once connected over Peer to Peer using AWDL0 or NWConnections, it works as expected until a user shuts the screen down. It looks like there's a difference in behavior when the device is plugged in vs when it's on just battery alone. So we can be happily sending data over p2p ( awdl0 ) then a screen shuts off and it kills the connection. Is this expected behavior and if so is there documentation? Also, Network Extensions do not appear to be able to discover over P2P, they can only connect to endpoints directly. Is this expected behavior? My thoughts; If a user allows both the Network Extension Permission and Local Network Permissions that the Network Extension should be able to discover peers via p2p. The connections ( if not asleep ) should stay active while in use.

Hi, I have been trying to add Settings Bundle to my app that utilizes DNS Proxy and Content Filter, however, I noticed some weird behavior. I worked with Settings Bundle before, but the initial implementation didn't work for some reason. So, I simplified it to just one toggle switch and tried again. Initially, I had an observer adding in the init of my SettingsBundleService class and I was using a shared instance in DNS Proxy target, as a result, SettingsBundleService was observing changes but would always return false. But when I tried to use a shared instance from the main target, it worked just fine. public final class SettingsBundleService { static let shared = SettingsBundleService() private (set) var test: Bool = false init() { registerSettingsBundle() NotificationCenter.default.addObserver(self, selector: #selector(defaultsChanged), name: UserDefaults.didChangeNotification, object: nil) defaultsChanged() Logger.statistics.log("[SettingsBundleService] – added Settings Bundle observing") } private func registerSettingsBundle(){ let appDefaults = [String: AnyObject]() UserDefaults.standard.register(defaults: appDefaults) } @objc private func defaultsChanged(){ self.test = UserDefaults.standard.bool(forKey: "enable_feature_preference") Logger.statistics.log("[SettingsBundleService] – changed: \(test)") } deinit { NotificationCenter.default.removeObserver(self) Logger.statistics.log("[SettingsBundleService] – removed Settings Bundle observing") } Could somebody advise me on what I am doing wrong here?

I've implemented a custom system extension VPN for macOS using a Packet Tunnel Provider. At the Protocol Configuration, the 'includeAllNetworks' flag is unset. At the provider, I included all routes (IPv4 default route). What is the expected behavior for LAN traffic? Should the LAN traffic go via the VPN? By 'LAN traffic', I'm referring to local hosts, ssh, printer access, etc.

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?

Hi, With iOS-17.4 update, we are seeing AppProxy VPN not getting started when Apps (associated with PerAppVPN) tried to access network resource after MDM PerAppVPN profile install/update. Looks like PerApp rules associated with applayer vpn profile are broken after profile update/install as we see internet sites working without going through VPN (appProxy network extension), this start working if we toggle WiFi and then access network resource from Apps associated with PerAppVPN. Created FB13688086 with all the details for this iOS 17.4 and AppLayerVPN, looking for and update here and any feedback/pointers will help. Thanks

Because it may be quicker to ask: with a TPP, readData() gets a data size of 0 if the process has finished writing to the network. However, there seems to be no way to find out if it has finished reading from the network, other than to do a .write() and see if you get an error. (I filed a FB about this, for whatever that's worth.) Since the API is flow-based, not socket, it's not possible to tell if the app has set its own timeout. Or exited. So one question I have is: if I do flow.write(Data(count:0)) -- is that a possible way to determine if it's still around? Or will it be interpreted as read(2) returning 0? (Putting this in for testing is difficult, but not impossible -- as I said, this might be the quickest way to find out.)

We currently have a PacketTunnelProvider providing VPN to managed devices. Our profile locks this down with OnDemandEnabled and OnDemandUserOverrideDisabled set to true. We've received some reports that on device startup, there is a time period after Wi-Fi connects but before the OnDemand VPN kicks in to enable our VPN, where users are able to navigate to IPs that are meant to be captured by the VPN tunnel. Instead, they are able to reach these IPs directly during this time period. Is there an expectation in regards to when OnDemand VPN is allowed to kick in to enable the VPN? Is there anything that we can do to minimize this delay?

Hi, We are currently working on a baby monitor app that utilizes NEAppPushProvider to deliver push notifications since we can't rely on an internet connection. Similar to the example, we are adding and removing the matchSSIDs of NEAppPushManager to start and stop the extension for activating and deactivating notifications during monitoring. It works as expected. However, we now want to detect if the device loses the Wi-Fi connection, and I'm struggling to determine how to distinguish between intentional changes to matchSSIDs and an actual loss of connection. Is there another method to halt the extension? Thanks in advance!

Hi, I have been working on some kind of network filtering app for iOS using Content Filter Provider. And I have stored rules for each domain. As of right now, I use UserDefaults with my app's bundle suite to store and observe rules. I have also read this documentation page for UserDefaults link. Is it okay to use UserDefaults in my case, if I have rules added/modified dynamically as the flow is intercepted, or should I pick some other approach like Core Data, SwiftData, etc.? Thank you!

I've come to the conclusion that TPP and UDP are just utterly wonky together. This is my relevant code: let host = NWHostEndpoint(hostname: "", port: "0") let udpRule = NENetworkRule(destinationNetwork: host, prefix: 0, protocol: .UDP) let tcpRule = NENetworkRule(destinationNetwork: host, prefix: 0, protocol: .TCP) let settings = NETransparentProxyNetworkSettings(tunnelRemoteAddress:"127.0.0.1") /* * These three lines are a hack and experiment */ let quicHost_1 = NWHostEndpoint(hostname: "", port: "80") let quicHost_2 = NWHostEndpoint(hostname: "", port: "443") let quicRule_1 = NENetworkRule(destinationNetwork: quicHost_1, prefix: 0, protocol: .UDP) let quicRule_2 = NENetworkRule(destinationNetwork: quicHost_2, prefix: 0, protocol: .UDP) settings.includedNetworkRules = [quicRule_1, quicRule_2, tcpRule] settings.excludedNetworkRules = nil Directing UDP through a TPP breaks FaceTime, AirDrop, and a bunch of VPNs Despite the documentation implication that you can't do DNS control with a TPP ("A port string of 53 is not allowed. Use Destination Domain-based rules to match DNS traffic."), if I opt into UDP (settings.includedNetworkRules = [udpRule, tcpRule]), then I see traffic to port 53, and can do things with it. If I use a wild-card network rule (the code above), then the TPP does not seem to get any UDP flows at all. If I use a wild-card exclusion rule (using NWHostEndpoint(hostname: "", port: "53")), then everything starts breaking. If I use NENetworkRule(destinationHost: host, protocol: .UDP), it complains because the prefix must be 32 or less. I've filed feedbacks, and engaged with eskimo (really, thank you), and looked at previous threads, so mostly this is begging: has anyone gotten this to work as expected? I no longer think I'm being obviously wrong with my code, but I would be super delighted to find out I've missed some tricks or angles.

We're trying to make our Content Filter solution work on Shared iPads. We leverage the Network Extension framework, more specifically the Content Filter Providers. On regular, 1:1 iPads, this works perfectly fine. However, on Shared iPads we see some weird behaviour. Upon logging in with a MAID everything initially seems fine. However, in about 5 to 10 seconds the user is automatically logged out and an error indicating "a connection to iCloud could not be made" is presented to the user. After investigating the logs it turns out this is caused by the fact that the network is unreachable. For example: Jan 19 00:33:04 cloudd(CFNetwork)[5867] <Error>: Task <F5DC7C46-422D-4265-A364-B3C859BF6291>.<1> finished with error [-1009] Error Domain=NSURLErrorDomain Code=-1009 UserInfo={_kCFStreamErrorCodeKey=50, NSUnderlyingError=0xefe89ffc0 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 UserInfo={_NSURLErrorNWPathKey=unsatisfied (Path was denied by NECP policy), interface: en0[802.11], ipv4, dns, uses wifi, _kCFStreamErrorCodeKey=50, _kCFStreamErrorDomainKey=1}}, _NSURLErrorFailingURLSessionTaskErrorKey=<private>, _NSURLErrorRelatedURLSessionTaskErrorKey=<private>, NSLocalizedDescription=<private>, NSErrorFailingURLStringKey=<private>, NSErrorFailingURLKey=<private>, _kCFStreamErrorDomainKey=1} Test device: iPad Pro (11-inch) running iPadOS 17.2 (21C62) My assumption: It looks like the filter providers start "too late". In the meantime the device is trying to reach the network, but since there is a Content Filter configuration in place all traffic is denied until the extension is started (and the completionHandler has been called with a nil error). I can see in the logs that, about 5 seconds after the home screen is visible, the Content Filter Providers are starting: ... Jan 19 00:52:54 neagent(NetworkExtension)[7086] <Notice>: Extension request with data extension <our filterData bundle ID> started with identifier 63576D2C-A484-4D07-9753-ADC99BFDB7A6 ... Jan 19 00:52:55 neagent(NetworkExtension)[7086] <Notice>: Extension request with control extension <our filterControl bundle ID> started with identifier 51D19516-C860-48B8-AB83-0F43D5F613CB ... Is my assumption correct? Are the Content Filter provider even officially supported by Apple on Shared iPads? Is there anything we can do to fix this issue?

Hi all, I'm working on a small PoC to get Content Filtering (FilterDataProvider) working on macOS without any user interaction. So far, I've pushed two payloads to my machine using user-approved MDM enrollment: com.apple.system-extension-policy com.apple.webcontent-filter The application containing the network extension is present in /Applications. The installation of the profiles both succeed and I can see a Content Filter is created in the Network section of System Settings. Even the status says "Enabled", but the dot remains orange. Inspecing the system logs (specifically: filtering on process:neagent) shows me the following error: 1. Failed to find a com.apple.networkextension.filter-data extension inside of app com.my.app.containing.the.ext Only when I submit an activation request using OSSystemExtensionRequest.activationRequest, the network extension starts (without prompts, as expected) and everything works. Is this expected behaviour? Do I need to submit an activation request through code regardless of the fact that MDM pre-approved the System Extension prompts and created the Content Filter in the System Settings?