I have a process [command line cpp application] which i want to run always such as it should relaunch after a crash, after device startup etc. I created a launchd Property List File with KeepAlive true and placed under /Library/LaunchDaemons. Problem Statements: I have a bash script to start and stop this process. start using: launchctl bootstrap. stop involve these two steps: send SIGTERM signal and wait untill process stops after doing some cleanups launchctl bootout [It doesn't sends SIGTERM] during steps 1 - Process is getting stop, but also getting immediate relaunch by launchctl during step 2 - it getting stop again. is there a proper way so that we can disable KeepAlive temporarily so that process will not launch during step 1? or suggest other ways to handle this?

We want to ressolve dns for predefined sets of private app domains. We've added this rule: NENetworkRule(destinationHost: NWHostEndpoint(hostname: Private Domain1(example.com), port: 53), protocol: .UDP) As per apple documentation: A rule that matches all DNS queries/responses for hosts in the example.com domain. do you think it will work i.e it will forward DNS requests UDP flow to transparent provider in all the cases? or do you think the text is a bit misleading. it should instead say: "A rule that matches all DNS queries/responses for nameservers in the example.com domain"? This rule that look for port 53 of that domain only works if the system really asks a nameserver of that specific domain, right? So, what if a local DNS server or a different nameserver are taking care of the resolution?

NEAppProxyUDPFlow contains below property: open var localEndpoint: NWEndpoint? { get } Why is localEndpoint not available for NEAppProxyTCPFlow? Is there a way to determine the source port of a flow of type NEAppProxyTCPFlow within the following method of NETransparentProxyProvider? override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool {

As per : TN3120: Expected use cases for Network Extension packet tunnel providers | Apple Developer Documentation It is clear that Packets that are read from NEPacketTunnelFlow are meant to be sent over a tunnel connection to a remote server for injection into a remote network. They are not meant to be dropped or re-injected back into the system. In my usecase: NEPacketTunnelProvider is separate process. which reads the packet using packetFlow.readPacketObjects Send it over to other process i.e privileged helper(Non-bundle/command line tool/non sandboxed) via UDS IPC. Helpers send to to remote tunnel and return back the packet to NEPacketTunnelFlow via same IPC. NEPacketTunnelProvider uses packetFlow.writePacketObjects to inject packets. Things works fine. We don't distribute it via Appstore. We are now attempting to implement a on device bypass mechanism from helper tool side. Could you please suggest if there is any approach I could try, even if it involves proceeding at my own risk?

Hi, I have applied below rule let filterRules = ["0.0.0.0", "::"].map { address -> NEFilterRule in       let localNetwork = NWHostEndpoint(hostname: address, port: "0")       let networkRule = NENetworkRule(remoteNetwork: nil,                           remotePrefix: 0,                           localNetwork: localNetwork,                           localPrefix: 0,                           protocol: .TCP,                           direction: .any)       return NEFilterRule(networkRule: networkRule, action: .filterData)     } I have written below code in method: override func handleInboundData if remoteEndpoint.hostname == "10.207.135.79" { os_log(.debug, log: self.log, "dropping for 10.207.135.79.");         return .drop() } From device 10.207.135.79 i am trying to send TCP as below: 1. ssh userName@10.213.175.1 It is getting drop as expected. kex_exchange_identification: Connection closed by remote host 2. Send via netcat(nc) nc 10.213.175.1 8888 During netcat, it's not getting drop. 3. Send via curl(nc) curl 10.213.175.1:8888 During curl, it's not getting drop. 10.213.175.1 is IP where system extension filter provider running. is this expected behaviour?

Hi, I want to know if i can ask NEPacketTunnelProvider to reroute traffic from virtual utun to physical interface? Let me break it down: As per includedRoutes, Traffic came on NEPacketTunnelProvider virtual interface(utun). After parsing packet if in case for some condition matches (such as port number etc), i want to route it via physical interface. Can we achieve this? Raw Socket can't be opened in System Extension hence i can't go via this route. I don't see any ways in NEPacketTunnelProvider / NEPacketTunnelNetworkSettings to achieve this.

Hi, I am experiencing following crashes intermittently in macOS network extension. Sometime in an hour or two or three. I don't see anywhere references to my project code hence i am unable to understand this crashes. Anyone please point me into right direction from here: Crash Dumps Samples: Process: com.skyhighsecurity.epclient.networkextension [39224] Path: /Library/SystemExtensions/*/com.skyhighsecurity.epclient.networkextension Identifier: com.skyhighsecurity.epclient.networkextension Version: 1.0 (1) Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 0 Date/Time: 2023-03-20 13:46:51.6991 +0530 OS Version: macOS 12.6.3 (21G419) Report Version: 12 Anonymous UUID: 72617D4C-9E91-7141-D71D-9CB5BDADAA25 Sleep/Wake UUID: B462FD28-68B4-4B46-84EB-D16E29760748 Time Awake Since Boot: 32000 seconds Time Since Wake: 5 seconds System Integrity Protection: disabled Crashed Thread: 3 Dispatch queue: NEFilterExtensionProviderContext queue Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x0000000182e26104 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5 Terminating Process: exc handler [39224] Application Specific Information: BUG IN CLIENT OF LIBPLATFORM: os_unfair_lock is corrupt Abort Cause 1949042982 Thread 0: 0 libsystem_kernel.dylib 0x182dd5d70 __sigsuspend_nocancel + 8 1 libdispatch.dylib 0x182c5b5e0 _dispatch_sigsuspend + 48 2 libdispatch.dylib 0x182c5b5b0 _dispatch_sig_thread + 60 Thread 1: 0 libsystem_pthread.dylib 0x182e07078 start_wqthread + 0 Thread 2: 0 libsystem_pthread.dylib 0x182e07078 start_wqthread + 0 Thread 3 Crashed:: Dispatch queue: NEFilterExtensionProviderContext queue 0 libsystem_platform.dylib 0x182e26104 _os_unfair_lock_corruption_abort + 88 1 libsystem_platform.dylib 0x182e21184 _os_unfair_lock_lock_slow + 328 2 libsystem_pthread.dylib 0x182e07640 pthread_mutex_destroy + 64 3 Foundation 0x183d7ac18 -[_NSXPCConnectionClassCache dealloc] + 48 4 libobjc.A.dylib 0x182cb7c58 objc_object::sidetable_release(bool, bool) + 260 5 NetworkExtension 0x19148b798 -[NEFilterSocketFlow .cxx_destruct] + 40 6 libobjc.A.dylib 0x182c9d8e4 object_cxxDestructFromClass(objc_object*, objc_class*) + 116 7 libobjc.A.dylib 0x182c94b0c objc_destructInstance + 80 8 libobjc.A.dylib 0x182c94ab8 _objc_rootDealloc + 80 9 NetworkExtension 0x19148246c -[NEFilterDataExtensionProviderContext handleSocketSourceEventWithSocket:] + 132 10 libdispatch.dylib 0x182c481b4 _dispatch_client_callout + 20 11 libdispatch.dylib 0x182c4b670 _dispatch_continuation_pop + 500 12 libdispatch.dylib 0x182c5e8e0 _dispatch_source_invoke + 1596 13 libdispatch.dylib 0x182c4f784 _dispatch_lane_serial_drain + 376 14 libdispatch.dylib 0x182c50404 _dispatch_lane_invoke + 392 15 libdispatch.dylib 0x182c5ac98 _dispatch_workloop_worker_thread + 648 16 libsystem_pthread.dylib 0x182e08360 _pthread_wqthread + 288 17 libsystem_pthread.dylib 0x182e07080 start_wqthread + 8

Hi, We have following settings for NEPacketTunnelProvider with include rules having all IPv4 network traffic be routed. Exclude rule having 8.8.8.8 & 10.212.24.222. In this case dns request packets are not going out. let settings = NEPacketTunnelNetworkSettings(tunnelRemoteAddress: "xxxxx") settings.ipv4Settings = NEIPv4Settings(addresses: ["10.10.10.10"], subnetMasks: ["255.255.255.255"]) settings.ipv4Settings?.includedRoutes = [NEIPv4Route(destinationAddress: "0.0.0.0", subnetMask: "0.0.0.0")] or the below one settings.ipv4Settings?.includedRoutes = [NEIPv4Route.default()] settings.ipv4Settings?.excludedRoutes = [ NEIPv4Route(destinationAddress: "8.8.8.8", subnetMask: "255.255.255.255"), NEIPv4Route(destinationAddress: "10.212.24.222", subnetMask: "255.255.255.255")] settings.mtu = 1500 If we are changing tunnel settings as below, then dns request packets are coming out in pcap dumps. settings.ipv4Settings?.includedRoutes = [ NEIPv4Route(destinationAddress: "10.0.0.0", subnetMask: "255.0.0.0"), NEIPv4Route(destinationAddress: "8.0.0.0", subnetMask: "255.0.0.0") ] settings.ipv4Settings?.excludedRoutes = [ NEIPv4Route(destinationAddress: "8.8.8.8", subnetMask: "255.255.255.255"), NEIPv4Route(destinationAddress: "10.212.24.222", subnetMask: "255.255.255.255")] Why the former 0.0.0.0 / defaultcase not working? How to include all traffic be routed in packet tunnel by excluding selective traffic?

Hi, we have c++ module inside Network Extension which does rest call. we want to do http rest call in test environment, but it's not responding. status code is 0. https working fine. I tried adding NSAppTransportSecurity -> NSAllowsArbitraryLoads -> true, but it's crashing because of it. how can we make http request from Network Extension in test enviroment?

We gets NEPacket during packetFlow.readPacketObjects. Each packet contains src ip as packet tunnel utun virtual interface address. for example if packet tunnel utun address is 10.10.10.10, then src ip of every packet is 10.10.10.10. Can we configure packet tunnel in such a way that it gives src ip as ip assigned to system via dhcp/static (primary Ethernet interface en0) instead of 10.10.10.10? I want to do this because tunnel server uses this src ip to perform some business logic. What if we assigns primary Ethernet interface en0 address to packet tunnel utun address?

I have an app which hosts network extensions(Packet Tunnel, Filter). I am facing uninstallation issue in scenario 2. Uninstall API: OSSystemExtensionRequest.deactivationRequest Scenarion 1: app version 1.0.0.1, extension inside app bundle version 1.0.0.1 Installed extension -> version 1.0.0.1 Uninstallation works fine. Scenarion 2: app version 1.0.0.2, extension inside app bundle version 1.0.0.2 Installed extension -> version 1.0.0.1 Uninstallation fails with below error: deactivation failed for client: /Applications/Remo Security Endpoint Client/ep-client.app/Contents/MacOS/ep-client, error: Error Domain=OSSystemExtensionErrorDomain Code=4 "(null)" Question 1: is this by design or we can do something to make uninstall works in case application upgraded and tries to uninstall previous extension version. Snippet from Apple Doc for API: OSSystemExtensionRequest.deactivationRequest A deactivation request may require a restart before deactivating the extension. If the request succeeds but requires a restart to complete, the extension may still appear operational until the next restart. Question 2: How do we know if restart needed or not?

On Ventura - We have a network extension(Transparent Proxy) which blocks IPv6 traffic as below. override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool { //Ipv6 gets blocks by below code let error = NSError(domain: "", code: 0, userInfo: [NSLocalizedDescriptionKey : "Connection Refused"]) flow.closeReadWithError(error) flow.closeWriteWithError(error) On IPv6 enabled client machine, when a client application(Browser, curl, Teams etc), try to send HTTP/s requests, first they try to send the request over IPv6 and if it fails, they try with IPv4 (Happy eyeballs Algorithm) In our case, as network extension blocks IPv6 traffic, client applications will fail to establish connection over IPv6 and fallback to IPv4 as per Happy eyeballs Algorithm The above scenario works fine till MacOS Ventura. For Sonoma, this behaviour seems to have changed When our network extension blocks IPv6 traffic, client applications do not fallback to IPv4. They simply fail without trying IPv4. We tested with curl, Google chrome browser, Microsoft Teams. All these fail to load pages on Sonoma and they work fine on Ventura. Note : No change in our network extension code, curl and browser versions. Only change is MacOS version Please find attached screenshots with Ventura and with Sonoma, running curl One other difference seen here is the error code received by client applications with Ventura and Sonoma. On Ventura, when IPv6 is blocked, error is Network is down and client application establishes connection with IPv4. On Sonoma, error code is 22 : Invalid arguments and client application does not retry with IPv4. Curl_Ventura.jpg Curl_Sonoma.png

I want to understand in which API triggers this below popup. 1. This below code always trigger popup after fresh install which make sense: `//manager NETunnelProviderManager manager.connection.startVPNTunnel(options: [:])` 2. This below code sometime triggers popup intermittently. Ideally this shouldn't trigger or always trigger. I tried running this code in loop to check this behaviour, some time around 50th or sometime around 88th execution observed this popup. config.providerBundleIdentifier =“bundleId” config.serverAddress = "Connection managed by app”Name// let manager = NETunnelProviderManager() manager.protocolConfiguration = config manager.localizedDescription = “xyz” manager.saveToPreferences(completionHandler: { (saveError) -> Void in }``` no where startVPNTunnel called in 2nd code sample.

We have a NEFilterDataProvider extension that intercepts all TCP and UDP IPv4/6 traffic. At times just after wakeup from sleep, it causes internet access issues, such as showing "This site can't be reached" when opening websites. The traffic is not being dropped by the extension. According to the logs, the connection is being closed after approximately 4 minutes. During the issue, the flow logs are as follows: Flow 515129771 is connecting New flow: NEFlow type = stream, app = com.google.Chrome.helper... Detaching, ref count = 2 (logged after ~4 minutes) Sending close, how = 2 Removing from group 2, ref count = 2 Destroying, app tx 0, tunnel tx 0, tunnel rx 0 Closing reads, not closed by plugin Closing writes, not sending close Any suggestions on the possible cause and how to further debug it?

I haven’t come across any official documentation regarding the limit on the number of Network Extensions macOS can run. However, I did see some discussions suggesting that Apple might restrict this to 5 extensions in macOS Tahoe. Is there any official confirmation on this?