From time to time the subject of NECP grows up, both here on DevForums and in DTS cases. I’ve posted about this before but I wanted to collect those tidbits into single coherent post. If you have questions or comments, start a new thread in the App & System Services > Networking subtopic and tag it with Network Extension. That way I’ll be sure to see it go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" A Peek Behind the NECP Curtain NECP stands for Network Extension Control Protocol. It’s a subsystem within the Apple networking stack that controls which programs have access to which network interfaces. It’s vitally important to the Network Extension subsystem, hence the name, but it’s used in many different places. Indeed, a very familiar example of its use is the Settings > Mobile Data [1] user interface on iOS. NECP has no explicit API, although there are APIs that are offer some insight into its state. Continuing the Settings > Mobile Data example above, there is a little-known API, CTCellularData in the Core Telephony framework, that returns whether your app has access to WWAN. Despite having no API, NECP is still relevant to developers. The Settings > Mobile Data example is one place where it affects app developers but it’s most important for Network Extension (NE) developers. A key use case for NECP is to prevent VPN loops. When starting an NE provider, the system configures the NECP policy for the NE provider’s process to prevent it from using a VPN interface. This means that you can safely open a network connection inside your VPN provider without having to worry about its traffic being accidentally routed back to you. This is why, for example, an NE packet tunnel provider can use any networking API it wants, including BSD Sockets, to run its connection without fear of creating a VPN loop [1]. One place that NECP shows up regularly is the system log. Next time you see a system log entry like this: type: debug time: 15:02:54.817903+0000 process: Mail subsystem: com.apple.network category: connection message: nw_protocol_socket_set_necp_attributes [C723.1.1:1] setsockopt 39 SO_NECP_ATTRIBUTES … you’ll at least know what the necp means (-: Finally, a lot of NECP infrastructure is in the Darwin open source. As with all things in Darwin, it’s fine to poke around and see how your favourite feature works, but do not incorporate any information you find into your product. Stuff you uncover by looking in Darwin is not considered API. [1] Settings > Cellular Data if you speak American (-: [2] Network Extension providers can call the createTCPConnection(to:enableTLS:tlsParameters:delegate:) method to create an NWTCPConnection [3] that doesn’t run through the tunnel. You can use that if it’s convenient but you don’t need to use it. [3] NWTCPConnection is now deprecated, but there are non-deprecated equivalents. For the full story, see NWEndpoint History and Advice. Revision History 2025-12-12 Replaced “macOS networking stack” with “Apple networking stack” to avoid giving the impression that this is all about macOS. Added a link to NWEndpoint History and Advice. Made other minor editorial changes. 2023-02-27 First posted.

How often do we see control filter start and stop? I read somewhere that data filter is long lived and control Filter is short lived. When does the operating system kills the control filter process?

We need your assistance as we are currently facing an issue without a workaround for users on macOS 15.4 and 15.5. FeedbackID: FB17547675 The problem has been observed on macOS versions 15.4 and 15.5. Apple has acknowledged this issue and confirmed that it is fixed in the macOS 15.6 beta. Although we tried to reproduce the issue in our environment, it did not occur, even on macOS 15.5. Therefore, we cannot verify if the fix in macOS 15.6 beta resolves the problem. We are actively working to identify an appropriate workaround for users on macOS 15.5. Some users have reported a failure to obtain an IP address over Wi-Fi, possibly due to a DHCP failure. As a temporary solution, we added logic to restart Wi-Fi programmatically when either an APIPA address (169.254.x.x) or no IPv4 address is detected on the active interface. However, restarting Wi-Fi does not always resolve the issue, and the device may still fail to obtain an IP address over Wi-Fi or Ethernet. Could you advise if there is a reliable method to detect DHCP failure and recover the device from this state? Also, any idea, how we can reproduce this scenario in our machine? Below is the failure. default 2025-06-27 10:07:57.055003 -0700 configd DHCP en0: ARP router: No leases to query for default 2025-06-27 10:07:57.055269 -0700 configd DHCP en0: status = 'no server' default 2025-06-27 10:08:23.336215 -0700 airportd WiFiUsageBssSession:: ChannelAfterRoam=0; ChannelAtJoin=36; FaultReasonApsdTimedOut=0; FaultReasonArpFailureCount=0; FaultReasonBrokenBackhaulLinkFailed=0; FaultReasonDhcpFailure=0; default 2025-06-27 10:08:23.367852 -0700 configd DHCP en0: status = 'media inactive' default 2025-06-27 10:08:23.367909 -0700 configd DHCP en0: INACTIVE default 2025-06-27 10:08:23.988565 -0700 configd DHCP en0: status = 'media inactive' default 2025-06-27 10:08:23.988703 -0700 configd DHCP en0: INACTIVE info 2025-06-27 10:08:23.988852 -0700 configd DHCPv6 en0: Inactive default 2025-06-27 10:08:35.656415 -0700 configd DHCP en0: status = 'network changed' default 2025-06-27 10:08:35.656817 -0700 configd DHCP en0: INIT default 2025-06-27 10:08:35.656821 -0700 configd DHCP en0: supplying device type 'Mac' info 2025-06-27 10:08:35.656934 -0700 configd DHCP en0: busy default 2025-06-27 10:08:35.657351 -0700 configd DHCP en0: INIT waiting at 0 for 1.358613 info 2025-06-27 10:08:35.657404 -0700 configd DHCPv6 en0: Inactive default 2025-06-27 10:08:37.019229 -0700 configd DHCP en0: INIT waiting at 1.36206 for 2.113913 default 2025-06-27 10:08:39.136955 -0700 configd DHCP en0: INIT waiting at 3.47937 for 4.462224 default 2025-06-27 10:08:43.602229 -0700 configd DHCP en0: ARP router: No leases to query for default 2025-06-27 10:08:43.603143 -0700 configd DHCP en0: INIT waiting at 7.94533 for 8.128784 default 2025-06-27 10:08:51.735532 -0700 configd DHCP en0: ARP router: No leases to query for default 2025-06-27 10:08:51.735846 -0700 configd DHCP en0: INIT waiting at 16.0786 for 8.749985 default 2025-06-27 10:09:00.488315 -0700 configd DHCP en0: ARP router: No leases to query for default 2025-06-27 10:09:00.488550 -0700 configd DHCP en0: INIT waiting at 24.8313 for 8.496864 default 2025-06-27 10:09:08.988284 -0700 configd DHCP en0: ARP router: No leases to query for default 2025-06-27 10:09:08.988310 -0700 configd DHCP en0: reported address acquisition failure symptom default 2025-06-27 10:09:08.988579 -0700 configd DHCP en0: INIT waiting at 33.3312 for 8.300735 default 2025-06-27 10:09:17.294478 -0700 configd DHCP en0: ARP router: No leases to query for info 2025-06-27 10:09:17.294485 -0700 configd DHCP en0: symptom failure already reported default 2025-06-27 10:09:17.295454 -0700 configd DHCP en0: INIT waiting at 41.6373 for 8.798768 default 2025-06-27 10:09:26.096673 -0700 configd DHCP en0: ARP router: No leases to query for info 2025-06-27 10:09:26.096688 -0700 configd DHCP en0: symptom failure already reported default 2025-06-27 10:09:26.097553 -0700 configd DHCP en0: INIT waiting at 50.4394 for 8.807943 default 2025-06-27 10:09:34.909050 -0700 configd DHCP en0: ARP router: No leases to query for info 2025-06-27 10:09:34.909054 -0700 configd DHCP en0: symptom failure already reported default 2025-06-27 10:09:34.909375 -0700 configd DHCP en0: INIT waiting at 59.2517 for 8.877971 default 2025-06-27 10:09:43.792458 -0700 configd DHCP en0: ARP router: No leases to query for info 2025-06-27 10:09:43.792464 -0700 configd DHCP en0: symptom failure already reported default 2025-06-27 10:09:43.793641 -0700 configd DHCP en0: status = 'no server' info 2025-06-27 10:09:43.794145 -0700 configd DHCP en0: not busy DNS failure resolver #1 flags : reach : 0x00000000 (Not Reachable) resolver #2 domain : local options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300000 resolver #3 domain : 254.169.in-addr.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300200 resolver #4 domain : 8.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300400 resolver #5 domain : 9.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300600 resolver #6 domain : a.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300800 resolver #7 domain : b.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 301000 Route table Destination Gateway Flags Netif Expire 127 127.0.0.1 UCS lo0 127.0.0.1 127.0.0.1 UH lo0 169.254 link#14 UCS en0 ! 169.254.160.160/32 link#14 UCS en0 ! 224.0.0/4 link#14 UmCS en0 ! 224.0.0.251 1:0:5e:0:0:fb UHmLWI en0 239.255.255.250 1:0:5e:7f:ff:fa UHmLWI en0 255.255.255.255/32 link#14 UCS en0 !

Starting with macOS 15 (Sequoia), applications that perform network discovery operations now trigger a permission prompt: "Allow [AppName] to find devices on local networks". I am using sysctl() with NET_RT_FLAGS and RTF_LLINFO to access the ARP table and retrieve gateway MAC addresses: int mib[6]; mib[0] = CTL_NET; mib[1] = PF_ROUTE; mib[2] = 0; mib[3] = AF_INET; mib[4] = NET_RT_FLAGS; mib[5] = RTF_LLINFO; // This flag accesses ARP table entries if (sysctl(mib, 6, buf, &needed, NULL, 0) < 0) return nil; From my testing, the Local Network Access prompt does not always appear. It looks like if the MAC address is already cached in the ARP table, no prompt is shown, and the prompt only appears when the system needs to resolve a new MAC address. Is this correct behavior? Does ARP resolution by itself triggering the prompt?

i unfortunatly upgraded to Sequoia since then I see when: i select XCode ->Product->run i see Error: No route to host i cannot grant access to local network for XCode i can no longer debug my program as i did with Sonora

Hello, I have encountered an issue with an iPhone 15PM with iOS 18.5. The NSHTTPCookieStorage failed to clear cookies, but even after clearing them, I was still able to retrieve them. However, on the same system It is normal on iPhone 14PM. I would like to know the specific reason and whether there are any adaptation related issues. Following code: NSHTTPCookie *cookie; NSHTTPCookieStorage *storage = [NSHTTPCookieStorage sharedHTTPCookieStorage]; for (cookie in [storage cookies]) { [storage deleteCookie:cookie]; }

Hi, I have created an application for NFC tag scanning and read the tag data. For that, i enabled the capability: NearField Communication Tag reading. Then I added 2 tag formats in the entitlement then i added info.plist: NFCReaderUsageDescription We need to use NFC com.apple.developer.nfc.readersession.felica.systemcodes 8005 8008 0003 fe00 90b7 927a 12FC 86a7 com.apple.developer.nfc.readersession.iso7816.select-identifiers D2760000850100 D2760000850101 but even though when i run the app and tap the nfc card im getting some error: NFCTag didBecomeActive 2025-08-29 19:08:12.272278+0530 SAFRAN_NFC[894:113090] NFCTag didDetectTags 2025-08-29 19:08:12.282869+0530 SAFRAN_NFC[894:113520] [CoreNFC] -[NFCTagReaderSession _connectTag:error:]:730 Error Domain=NFCError Code=2 "Missing required entitlement" UserInfo={NSLocalizedDescription=Missing required entitlement} 2025-08-29 19:08:12.284044+0530 SAFRAN_NFC[894:113090] NFCTag restarting polling 2025-08-29 19:08:12.372116+0530 SAFRAN_NFC[894:113090] NFCTag didDetectTags 2025-08-29 19:08:12.381535+0530 SAFRAN_NFC[894:113378] [CoreNFC] -[NFCTagReaderSession _connectTag:error:]:730 Error Domain=NFCError Code=2 "Missing required entitlement" UserInfo={NSLocalizedDescription=Missing required entitlement} 2025-08-29 19:08:12.382246+0530 SAFRAN_NFC[894:113090] NFCTag restarting polling 2025-08-29 19:08:12.470667+0530 SAFRAN_NFC[894:113090] NFCTag didDetectTags 2025-08-29 19:08:12.479336+0530 SAFRAN_NFC[894:113378] [CoreNFC] -[NFCTagReaderSession _connectTag:error:]:730 Error Domain=NFCError Code=2 "Missing required entitlement" UserInfo={NSLocalizedDescription=Missing required entitlement} 2025-08-29 19:08:12.480101+0530 SAFRAN_NFC[894:113090] NFCTag restarting polling Could you please help me wha tis the issue and give solution for that?

Development environment Xcode 26.0 Beta 6 iOS 26 Simulator macOS 15.6.1 To verify TLS 1.3 session resumption behavior in URLSession, I configured URLSessionConfiguration as follows and sent an HTTP GET request: let config = URLSessionConfiguration.ephemeral config.tlsMinimumSupportedProtocolVersion = .TLSv13 config.tlsMaximumSupportedProtocolVersion = .TLSv13 config.httpMaximumConnectionsPerHost = 1 config.httpAdditionalHeaders = ["Connection": "close"] config.enablesEarlyData = true let session = URLSession(configuration: config, delegate: nil, delegateQueue: nil) let url = URL(string: "https://www.google.com")! var request = URLRequest(url: url) request.assumesHTTP3Capable = true request.httpMethod = "GET" let task = session.dataTask(with: request) { data, response, error in if let error = error { print("Error during URLSession data task: \(error)") return } if let data = data, let responseString = String(data: data, encoding: .utf8) { print("Received data via URLSession: \(responseString)") } else { print("No data received or data is not UTF-8 encoded") } } task.resume() However, after capturing the packets, I found that the ClientHello packet did not include the early_data extension. It seems that enablesEarlyData on URLSessionConfiguration is not being applied. How can I make this work properly?

Is There a Reliable Way to Check Local Network Permission Status in 2025? I've read many similar requests, but I'm posting this in 2025 to ask: Is there any official or reliable method to check the current Local Network permission status on iOS 18.x? We need this to guide or navigate users to the appropriate Settings page when permission is denied. Background Our app is an IoT companion app, and Local Network access is core to our product's functionality. Without this permission, our app cannot communicate with the IoT hardware. Sadly, Apple doesn't provide any official API to check the current status of this permission. This limitation has caused confusion for many users, and we frequently receive bug reports simply because users have accidentally denied the permission and the app can no longer function as expected. Our App High Level Flow: 1. Trigger Permission We attempt to trigger the Local Network permission using Bonjour discovery and browsing methods. (see the implementation) Since there's no direct API to request this permission, we understand that iOS will automatically prompt the user when the app makes its first actual attempt to communicate with a local network device. However, in our case, this creates a problem: The permission prompt appears only at the time of the first real connection attempt (e.g., when sending an HTTP request to the IoT device). This results in a poor user experience, as the request begins before the permission is granted. The first request fails silently in the background while the permission popup appears unexpectedly. We cannot wait for the user's response to proceed, which leads to unreliable behavior and confusing flows. To avoid this issue, we trigger the Local Network permission proactively using Bonjour-based discovery methods. This ensures that the system permission prompt appears before any critical communication with the IoT device occurs. We’ve tried alternative approaches like sending dummy requests, but they were not reliable or consistent across devices or iOS versions. (see the support ticket) 2. Wi-Fi Connection: Once permission is granted, we allow the user to connect to the IoT device’s local Wi-Fi. 3. IoT Device Configuration: After connecting, we send an HTTP request to a known static IP (e.g., 192.168.4.1) on the IoT network to configure the hardware. I assume this pattern is common among all Wi-Fi-based IoT devices and apps. Problem: Even though we present clear app-level instructions when the system prompt appears, some users accidentally deny the Local Network permission. In those cases, there’s no API to check if the permission was denied, so: We can’t display a helpful message. We can’t guide the user to Settings → Privacy & Security → Local Network to re-enable it. The app fails silently or behaves unpredictably. Developer Needs: As app developers, we want to handle negative cases gracefully by: Detecting if the Local Network permission was denied Showing a relevant message or a prompt to go to Settings Preventing silent failures and improving UX So the question is: What is the current, official, or recommended way to determine whether Local Network permission is granted or denied in iOS 18.x (as of 2025)? This permission is critical for a huge category of apps especially IoT and local communication-based products. We hope Apple will offer a better developer experience around this soon. Thanks in advance to anyone who can share updated guidance.

Hello, I’m developing a macOS application signed with a Developer ID (outside the App Store) that includes a Network Extension. The app has been successfully notarized, and the network filter is registered, but the Network Extension itself remains inactive — it does not install or run properly. It seems that the issue might be related to the entitlements configuration between the container app and the Network Extension target. Could you please provide a detailed checklist for: 1.The required entitlements and configurations for the container app, and 2.The required entitlements and configurations for the Network Extension target? Additionally, are there any specific Xcode settings that are mandatory for the Network Extension to be properly installed and activated on macOS when distributed via Developer ID? Thank you in advance for your help.

Hi everyone, I developed an Android version of a VPN app built with Flutter using OpenVPN, and it works perfectly on Android. However, when porting it to iOS, I’ve encountered an issue: the app connects successfully but then automatically disconnects when tested via TestFlight. We’ve already added all the necessary network extensions. Despite this, we decided to submit the app to the App Store. It’s been five days now, and the app is still 'Waiting for Review.' Could anyone share their experience deploying and working on an iOS version of a VPN app? I’d really appreciate your insights!

Hi I am developing the packet tunnel extension on a SIP enabled device. If I build the app and notarize and install it on the device, it works fine. If I modify, build and execute the App (which contains the system extension), it fails with below error. 102.3.1.4 is production build. And 201.202.0.101 is for XCode build. SystemExtension "<<complete name>>.pkttunnel" request for replacement from 102.3.1.4 to 201.202.0.101 Packet Tunnel SystemExtension "<<complete name>>.pkttunnel" activation request did fail: Error Domain=OSSystemExtensionErrorDomain Code=8 "(null)" If SIP is disabled, it works fine. Is there a way the system extension can be developed even if SIP remains enabled?

We're seeing an issue with bonjour services since macOS 15.4 onwards, specifically when running xcuitests on simulators that communicate with an app via bonjour services, the NWListener fails with -65555: NoAuth Interestingly it only fails on subsequent iterations of the test, first iteration always succeeds. The same code works fine on macOS 15.3.1 and earlier, but not 15.4 or 15.5. Is this related to, or the same issue as here? https://developer.apple.com/forums/thread/780655 Also raised in feedback assistant: FB17804120

Hello, I have a peer to peer networking setup in my app that uses Network Framework with Bonjour and QUIC via NWBrowser, NWListener, NWConnection, and NWEndpoint and all works as expected. I watched the videos about the new iOS 26 Networking stuff (NetworkBrowser, NetworkListener, NetworkConnection) and wanted to try and migrate all my code to use the the new APIs (still use Bonjour and NOT use Wi-Fi Aware) but hit some issues. I was following how the Wi-Fi Aware example app was receiving messages for try await messageData in connection.messages { but when I got things setup with QUIC in a similar fashion I got the following compile error Requirement from conditional conformance of '(content: QUIC.ContentType, metadata: QUIC.Metadata)' to 'Copyable' Requirement from conditional conformance of '(content: QUIC.ContentType, metadata: QUIC.Metadata)' to 'Escapable' Requirement from conditional conformance of '(content: QUIC.ContentType, metadata: QUIC.Metadata)' to 'Copyable' Requirement from conditional conformance of '(content: QUIC.ContentType, metadata: QUIC.Metadata)' to 'Escapable' When I asked Cursor about what I was facing its response was as follows: "The connection.messages stream changed in the new Network APIs: it now yields typed (content, metadata) tuples. Iterating with for try await incoming in connection.messages asks the compiler to conform that tuple to Copyable/Escapable; for QUIC the tuple isn’t copyable, so you hit the conditional-conformance error." I am curious if you've been able to use the new iOS 26 network APIs with QUIC? Thank you, Captadoh

Hello Apple Developer Community, We are developing a full-tunnel VPN app for macOS that utilizes a packet tunnel network system extension (via NEPacketTunnelProvider). We're committed to using a system extension for this purpose, as it aligns with our requirements for system-wide tunneling. The app is sandboxed and intended for distribution on the Mac App Store. Here's the workflow: The app (running in user context) downloads a VPN profile from our server. It generates private keys, appends them to the profile, and attempts to save this enhanced profile securely in the keychain. The packet tunnel system extension (running in root context) needs to access this profile, including the private keys, to establish the VPN connection. We've encountered challenges in securely sharing this data across the user-root boundary due to sandbox restrictions and keychain access limitations. Here's what we've tried so far, along with the issues: Writing from the App to the System Keychain: Attempted to store the profile in the system keychain for root access. This fails because the sandboxed app lacks permissions to write to the system keychain. (We're avoiding non-sandboxed approaches for App Store compliance.) Extension Reading Directly from the User Login Keychain: Tried having the extension access the user's login keychain by its path. We manually added the network extension (located in /Library/SystemExtensions//bundle.systemextension) to the keychain item's Access Control List (ACL) via Keychain Access.app for testing. This results in "item not found" errors, likely due to the root context not seamlessly accessing user-keychain items without additional setup. Using Persistent References in NETunnelProviderProtocol: The app stores the profile in the user keychain and saves a persistent reference (as Data) in the NETunnelProviderProtocol's identityReference or similar fields. The extension then attempts to retrieve the item using this reference. We manually added the network extension (located in /Library/SystemExtensions//bundle.systemextension) to the keychain item's Access Control List (ACL) via Keychain Access.app for testing. However, this leads to error -25308 (errSecInteractionNotAllowed) when the extension tries to access it, possibly because of the root-user context mismatch or interaction requirements. Programmatically Adding the Extension to the ACL: Explored using SecAccess and SecACL APIs to add the extension as a trusted application. This requires SecTrustedApplicationCreateFromPath to create a SecTrustedApplicationRef from the extension's path. Issue 1: The sandboxed app can't reliably obtain the installed extension's path (e.g., via scanning /Library/SystemExtensions or systemextensionsctl), as sandbox restrictions block access. Issue 2: SecTrustedApplicationCreateFromPath is deprecated since macOS 10.15, and we're hesitant to rely on it for future compatibility. We've reviewed documentation on keychain sharing, access groups (including com.apple.managed.vpn.shared, but we're not using managed profiles/MDM) as the profiles are download from a server, and alternatives like XPC for on-demand communication, but we're unsure if XPC is suitable for sensitive data like private keys during tunnel creation. And if this is recommended what is going to be the approach here. What is the recommended, modern approach for this scenario? Is there a non-deprecated way to handle ACLs or share persistent references across contexts? Should we pursue a special entitlement for a custom access group, or is there a better pattern using NetworkExtension APIs? Any insights, code snippets, or references to similar implementations would be greatly appreciated. We're targeting macOS 15+. Thanks in advance!

I have few API's written with URLSession. Will they work in Carrier-constrained network / satellite mode ?

I am making a USB attached IoT device that follows the Matter approach to connectivity (IP/mDNS/DHCP). I am having conflicts with it as it appears to MacOS as an Ethernet adapter and this is causing it to be assigned as a "default" route, interfering with routing when my Mac is connected to NAT based WiFi. I'd like to be able to hint to MacOS & iPadOS that this is not a routable private network, the subnet should be respected and a default route should not be assigned to it, otherwise the order of the device connection is used by the IP routing tables and I am concerned my non-routable private network will initialize before Wifi and block NAT based internet connectivity. How can I hint to MacOS/iPadOS "this is not a routable private network, this is not a NAT, do not assign me a default route beyond the subnet I have provided you."

We have a setup where the system uses proxy settings configured via a PAC file. We are investigating how NWConnection behaves inside a Network Extension (NETransparentProxyProvider) with a transparent proxy configuration based on this PAC file. Scenario: The browser makes a connection which the PAC file resolves as "DIRECT" (bypassing the proxy) Our Network Extension intercepts this traffic for analysis The extension creates a new connection using NWConnection to the original remote address. The issue: despite the PAC file’s "DIRECT" decision, NWConnection still respects the system proxy settings and routes the connection through the proxy. Our questions: Is it correct that NWConnection always uses the system proxy if configured ? Does setting preferNoProxies = true guarantee bypassing the system proxy? Additionally: Whitelisting IPs in the Network Extension to avoid interception is not a viable solution because IPs may correspond to multiple services, and the extension only sees IP addresses, not domains (e.g., we want to skip scanning meet.google.com traffic but still scan other Google services on the same IP range). Are there any recommended approaches or best practices to ensure that connections initiated from a Network Extension can truly bypass the proxy (for example, for specific IP ranges or domains)?

Hi everyone, I'm currently experimenting with building a simple DNS filter using Apple's Packet Tunnel framework. Here's the flow I'm trying to implement: Create a TUN interface Set up a UDP socket Read packets via packetFlow.readPackets Parse the raw IP packet Forward the UDP payload through the socket Receive the response from the server Reconstruct the IP packet with the response Write it back to the TUN interface using packetFlow.writePackets Here’s an example of an intercepted IP packet (DNS request): 45 00 00 3c 15 c4 00 00 40 11 93 d1 c0 a8 00 64 08 08 08 08 ed 6e 00 35 00 28 e5 c9 7f da 01 00 00 01 00 00 00 00 00 00 04 74 69 6d 65 05 61 70 70 6c 65 03 63 6f 6d 00 00 01 00 01 And here’s the IP packet I tried writing back into the TUN interface (DNS response): 45 00 00 89 5e 37 40 00 40 11 0b 11 08 08 08 08 c0 a8 00 64 00 35 ed 6e 00 75 91 e8 7f da 81 80 00 01 00 04 00 00 00 00 04 74 69 6d 65 05 61 70 70 6c 65 03 63 6f 6d 00 00 01 00 01 c0 0c 00 05 00 01 00 00 0c fb 00 11 04 74 69 6d 65 01 67 07 61 61 70 6c 69 6d 67 c0 17 c0 2c 00 01 00 01 00 00 03 04 00 04 11 fd 74 fd c0 2c 00 01 00 01 00 00 03 04 00 04 11 fd 74 7d c0 2c 00 01 00 01 00 00 03 04 00 04 11 fd 54 fb Unfortunately, it seems the packet is not being written back correctly to the TUN interface. I'm not seeing any expected DNS response behavior on the device. Also, I noticed that after creating the TUN, the interface address shows up as 0.0.0.0:0 in Xcode. The system log includes this message when connecting the VPN: NWPath does not have valid interface: satisfied (Path is satisfied), interface: utun20[endc_sub6], ipv4, dns, expensive, uses cellular Does anyone know how to properly initialize the TUN so that the system recognizes it with a valid IP configuration? Or why my written-back packet might be getting ignored? Any help would be appreciated!

Hello everyone, I'm trying to figure out how to transmit a UIImage (png or tiff) securely to an application running in my desktop browser (Mac or PC). The desktop application and iOS app would potentially be running on the same local network (iOS hotspot or something) or have no internet connection at all. I'm trying to securely send over an image that the running desktop app could ingest. I was thinking something like a local server securely accepting image data from an iPhone. Any suggestions ideas or where to look for more info would be greatly appreciated! Thank you for your help.