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"

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.

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.

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?

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!

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.

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?

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.)

xcode15.3, ios 17.4SDK VPN NEPacketTunnelProvider, After successful socket listen local ip 0.0.0.0, data packets cannot be received in release mode, but can be received in debug mode.This bug has been bothering me for a few days. Please help me. Thank you very much. In networkExtension code: ... let ip4Set = ... ip4Set.includedRoutes = [NEIPv4Route.default()] ... func readDevicePackets(){ ... packetFlow.readPacketObjects { (packetList) in ... let sendPacketList: [NEPacket] = changePacket(packetList) ... packetFlow.writePacketObjects(sendPacketList) readDevicePackets() }

Issue: Our app is currently experiencing an unexpected behavior related to VPN functionality on iOS devices. Despite having the "OnDemandUserOverrideDisabled" parameter set to 1 in our VPN profile, users have reported that they can create a shortcut to disable the "Connect On Demand" feature. However, upon doing so, toggling off the VPN does not re-enable the feature as anticipated. This oversight results in unfiltered browsing, potentially compromising user security and privacy. Explanation: The presence of "OnDemandUserOverrideDisabled" set to 1 in our VPN profile should theoretically prevent users from toggling the "Connect On Demand" feature via any means. However, users have found a workaround using shortcuts to bypass this safeguard. Consequently, the VPN does not automatically re-engage after being disabled, leading to unintended consequences for users. Impact: The inability to reliably control VPN settings, despite profile configurations, poses a significant risk to user data privacy and security. Unintended unfiltered browsing can expose users to malicious actors and compromise sensitive information.

OS Version: macOS 13.6.3 (22G436) Code Type: ARM64 We recently observed that the system extension process CPU based on networkextension (data-filter firewall) has been 99% busy for a period of time. We try to deauthorize data-filter so that the firewall stops working and the NEFilterDataProvider object is released. However, the system extension process CPU usage is always 99% busy. Then I used Instruments-CPU Counters to observe that a thread (thread id: 0x2abf9b) has been busy, but no useful backtrace information was captured. Through the sample command, I caught the backtrace and found that the busy process (thread id: 2801563 == 0x2abf9b) is in this state. 35 Thread_1336407 DispatchQueue_442: NEFilterExtensionProviderContext queue (serial) + 35 start_wqthread (in libsystem_pthread.dylib) + 8 [0x1a1afad94] + 35 _pthread_wqthread (in libsystem_pthread.dylib) + 288 [0x1a1afc074] + 35 _dispatch_workloop_worker_thread (in libdispatch.dylib) + 648 [0x1a1963244] + 35 _dispatch_lane_invoke (in libdispatch.dylib) + 384 [0x1a19585f8] + 35 _dispatch_lane_serial_drain (in libdispatch.dylib) + 372 [0x1a1957960] + 35 _dispatch_source_invoke (in libdispatch.dylib) + 1176 [0x1a1966ce0] + 35 _dispatch_source_cancel_callout (in libdispatch.dylib) + 204 [0x1a1967890] + 35 _dispatch_continuation_pop (in libdispatch.dylib) + 504 [0x1a1953884] + 35 _dispatch_client_callout (in libdispatch.dylib) + 20 [0x1a1950400] + 35 _dispatch_call_block_and_release (in libdispatch.dylib) + 32 [0x1a194e874] + 35 __75-[NEFilterDataExtensionProviderContext setupSocketSourceWithControlSocket:]_block_invoke (in NetworkExtension) + 112 [0x1b1e0dd74] + 35 close (in libsystem_kernel.dylib) + 8 [0x1a1ac0ac0] note: the picture screenshot and the text description backtrace are from different machines, but the problem is the same. This seems to be a newly introduced bug in the network extension? This problem did not occur for a long time between 10.15 and 10.12.

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?

Hi, we are a Carrier company (Utility provider) and working on a feature to display real-time Wifi Signal strength of customer devices (connected to Router Gateway) to help customers identify low and high signal areas, and possibly install extenders to improve signal strength at weak points. This feature requires NEHotspotHelper entitlement approval to access signalStrength property. We went through this Apple documentation too and we're open to other recommendations from Apple https://developer.apple.com/forums/thread/721067 . Since we currently don't have direct point of contact with Apple to discuss this requirement, hence wanted to check it here. Kindly advise. Thanks !