Goal : Block all outbound connections to a static list of hosts (both In-app requests and WKWebView/Safari). App & both extensions have Network Extension entitlement with content-filter-provider and filter-control-provider What’s working: Safari and WKWebView requests matching the block list are dropped. What’s broken: In-app traffic never reaches the Data Provider—those requests always succeed. Setup: • NEFilterProviderConfiguration with both Data & Control providers, filterBrowsers = true, filterSockets = true • Data Provider implements handleNewFlow for socket/browser flows • Control Provider implements handleNewFlow for browser flows • Enabled via saveToPreferences() and toggled ON in Settings

Hi! My project has the Local Push Connectivity entitlement for a feature we have requiring us to send low-latency critical notifications over a local, private Wi-Fi network. We have our NEAppPushProvider creating a SSE connection using the Network framework with our hardware running a server. The server sends a keep-alive message every second. On an iPhone 16 with iOS 18+, the connection is reliable and remains stable for hours, regardless of whether the iOS app is in the foreground, background, or killed. One of our QA engineers has been testing on an iPhone 13 running iOS 16, and has notice shortly after locking the phone, specifically when not connected to power the device seems to turn off the Wi-Fi radio. So when the server sends a notification, it is not received. About 30s later, it seems to be back on. This happens on regular intervals. When looking at our log data, the provider does seem to be getting stopped, then restarted shortly after. The reason code is NEProviderStopReasonNoNetworkAvailable, which further validates that the network is getting dropped by the device in regular intervals. My questions are: Were there possibly silent changes to the framework between iOS versions that could be the reason we're seeing inconsistent behavior? Is there a connection type we could use, instead of SSE, that would prevent the device from disconnecting and reconnecting to the Wi-Fi network? Is there an alternative approach to allow us to maintain a persistent network connection with the extension or app?

Recently, we have observed that after upgrading to OS 15.4.1, some devices are experiencing network issues. We are using a Network Extension with a transparent app proxy in our product. The user encounters this issue while using our client, but the issue persists even after stopping the client app. This appears to be an OS issue. Below is the sytem logs. In the system logs, it says [C669.1 Hostname#546597df:443 failed transform (unsatisfied (No network route), flow divert agg: 2)] event: transform:children_failed @0.001s In scutil --dns, it says not reachble. DNS configuration 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 We need to restart the system to recover from the issue.

I am developing a VoIP phone application(Our Phoneapp) using APNs VoIP push. I have a question regarding a behavior I discovered during testing of this application. When performing the following operations using an iPhoneSE3 with an sXGP-NW SIM inserted, 0xBAADCA11 occurs upon receiving an APNs VoIP PUSH. Do you have any information regarding this issue? 0xBAADCA11 occurs in operation 8. However, since there were no problems in operation 4 (the app works when Wi-Fi is off), I think there is no issue with the Our Phoneapp. [Configuration of system components] [VoIP Telephone] --Call to iPhone(Phoneapp)--> [Our VoIP PBX Server] -- VoIP PUSH request --> [Apple APNs Server] -- VoIP PUSH --> [Our Phoneapp (iPhoneSE3(with sXGP SIM)] [Operations] (The issue is reproducible 100% by following oparation) iPhoneSE3: Power on (iPhoneSE3 with sXGP SIM) iPhoneSE3: Wi-Fi off, connect to the internet via SIM. VoIP Telephone: Call to Our Phoneapp iPhoneSE3: Receives VoIP PUSH and Phoneapp launches. Successfully answers the call and communication is possible. (Receives VoIP push notification from APNs via sXGP SIM) iPhoneSE3: Wi-Fi is turned ON, connect to the internet via Wi-Fi. iPhoneSE3: Task kill Our Phoneapp. VoIP Telephone: Call to Our Phoneapp iPhoneSE3: iOS does not call the push notification delegate (didReceiveIncomingPushWithPayload). As a result our Phoneapp is unable to detect the incoming call, However, an ips log with 0xBAADCA11 is output. in other words, iOS received the VoIP PUSH, but Our Phoneapp dose not call CallKit, so Our Phoneapp was terminated by iOS.

Hi, Our project is a MacOS SwiftUI GUI application that bundles a System Network Extension, signed with a Developer ID certificate for distribution outside of the app store. The system network extension is used to write a packet tunnel provider. The signing of the app & network extension is handled by XCode (v16.0.0), we do not run codesign ourselves. We have no issues with XPC or the system network extension during normal usage, nor when the application is installed on a user's device for the first time. The problem only arises when the user upgrades the application. I have experienced this issue myself, as have our users. It's been reported on Apple Silicon macbooks running at least macOS 15.3.2. Much like the SimpleFirewall example (which we used as a reference), we use XPC for basic communication of state between the app and NE. These XPC connections stop working when the user installs a new version of the app, with OS logs from the process indicating that the connection is immediately invalidated. Subsequent connection attempts are also immediately invalidated. Toggling the VPN in system settings (or via the app) does not resolve the problem, nor does restarting the app, nor does deleting and reinstalling the app, nor does restarting the device. The only reliable workaround is to delete the system extension in Login Items & Extensions, under Network Extensions. No device restart is necessary to garbage collect the old extension - once the extension is reapproved by the user, the XPC issue resolves itself. This would be an acceptable workaround were it possible to automate the deleting of the system extension, but that appears deliberately not possible, and requiring our users to do this each time they update is unreasonable. When the upgraded app is opened for the first time, the OSSystemExtensionRequest request is sent, and the outcome is that the previously installed system network extension is replaced, as both the CFBundleVersion and CFBundleShortVersionString differ. When this issue is encountered, the output of systemextensionsctl list shows the later version is installed and activated. I've been able to reproduce this bug on my personal laptop, with SIP on and systemextensionsctl developer off, but on my work laptop with SIP off and systemextensionsctl developer on (where the network extension is replaced on each activation request, instead of only when the version strings differ), I do not encounter this issue, which leads me to believe it has something to do with the notarization process. We notarize the pkg using xcrun notarytool, and then staple to the pkg. This is actually the same issue described in: https://developer.apple.com/forums/thread/711713 https://developer.apple.com/forums/thread/667597 https://developer.apple.com/forums/thread/742992 https://developer.apple.com/forums/thread/728063 but it's been a while since any of these threads were updated, and we've made attempts to address it off the suggestions in the threads to no avail. Those suggestions are: Switching to a .pkg installer from a .dmg As part of the .pkg preinstall, doing all of the following: Stopping the VPN (scutil --nc stop), shutting down the app (using osascript 'quit app id'), and deleting the app (which claims to delete the network extension, but not the approval in Login Items & Extensions remains??), by running rm -rf on the bundle in /Applications As part of the .pkg postinstall: Forcing macOS to ingest the App bundle's notarization ticket using spctl --assess. Ensuring NSXPCListener.resume() is called after autoreleasepool { NEProvider.startSystemExtensionMode() } (mentioned in a forum thread above as a fix, did not help.) One thing I'm particularly interested in is the outcome of this feedback assistant ticket, as I can't view it: FB11086599. It was shared on this forum in the first thread above, and supposedly describes the same issue. I almost find it hard to believe that this issue has been around for this many years without a workaround (there's system network extension apps out there that appear to work fine when updating, are they not using XPC?), so I wonder if there's a fix described in that FB ticket. Since I can't view that above feedback ticket, I've created my own: FB17032197

[Q] Has there been a change in macOS 15.3.2 and later that can explain why some UDP traffic is not seen by some Network Extensions when it is in previous macOS minor and major versions?

hi everybody, When I use the following code to connect to WiFi network, an error message of "error=null" or "error='Error Domain=NEHotspotConfigurationErrorDomain Code=11 "" UserInfo={NSLocalizedDescription=}' " will occur. It has been uploaded to Feedback. Feedback ID： FB16819345 (WiFi-无法加入网络) NEHotspotConfiguration *hotspotConfig = [[NEHotspotConfiguration alloc] initWithSSID:ssid passphrase:psk isWEP:NO]; [[NEHotspotConfigurationManager sharedManager] applyConfiguration:hotspotConfig completionHandler:^(NSError * _Nullable error) { }];

Is it possible to directly distribute a macOS app with a Developer ID Certificate that belongs to a different team? I am trying to resolve issues that arise when distributing a macOS app with a Network Extension (Packet Tunnel) outside the App Store using a Developer ID Certificate from a different team than the app’s provisioning profiles and entitlements. I started by attempting Direct Distribution in Xcode with automatic signing. However, it fails with the following message: Provisioning profile "Mac Team Direct Provisioning Profile: ” failed qualification checks: Profile doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement. I suspect the issue is that the provisioning profile allows "packet-tunnel-provider-systemextension", whereas the entitlements generated by Xcode contain "packet-tunnel-provider". When I manually modify the .entitlements file to include the -systemextension suffix, the project fails to build because Xcode does not recognize the modified entitlement. If there is a workaround for this issue, please let me know. Due to these issues, I resorted to manually creating a signed and notarized app. My process is as follows: Export the .app from the Xcode archive. Since the exported .app does not contain the necessary entitlements or provisioning profile for direct distribution, I replace Contents/embedded.provisioningprofile in both the .app and the .appex network extension. Sign the app and its components in the following order: codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Frameworks/<fw>.framework/ codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>"<app>.app/Contents/PlugIns/<netext>.appex/Contents/Frameworks/<fw>.framework/Versions/A/<fw> codesign --force --options runtime --entitlements dist-vpn.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/PlugIns/<netext>.appex/ codesign --force --options runtime --entitlements dist.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app Verify the code signature: codesign --verify --deep --strict --verbose=4 <app>.app - <app>.app: valid on disk - <app>.app: satisfies its Designated Requirement Create a ZIP archive using: ditto -c -k --sequesterRsrc --keepParent <app>.app <app>.zip Notarize the app with notarytool and staple it. The notarization completes successfully with errors: nil. Package the notarized app into a DMG, notarize, and staple the DMG. The app runs successfully on the development machine. However, when moved to another machine and placed in /Applications, it fails to open. Inspecting Console.app reveals Gatekeeper is blocking the launch:
 taskgated-helper <bundleid>: Unsatisfied entitlements: com.apple.developer.networking.networkextension, com.apple.developer.team-identifier taskgated-helper entitlements: { "com.apple.developer.networking.networkextension" = ("packet-tunnel-provider-systemextension"); "com.apple.developer.team-identifier" = <teamid>; } As mentioned earlier, the Developer ID Certificate used for signing belongs to a different team. We are a third-party developer and do not have access to the Developer ID Certificate of the team assigned as the team-identifier. When I changed the bundle identifier (app ID), team, entitlements, and provisioning profiles to match the team associated with the Developer ID Certificate, the app worked. My question is:
 Is this failure caused by using a Developer ID Certificate from a different team, or should it still work if the provisioning profiles and entitlements are correctly set? Could there be an issue elsewhere in the provisioning profiles or entitlements for the original app ID?

When installing a new version the app while a tunnel is connected, seemingly the old packet tunnel process gets stopped but the new one does not come back up. Reportedly, a path monitor is reporting that the device has no connectivity. Is this the expected behavior? When installing an update from TestFlight or the App store, the packet tunnel instance from the old tunnel is stopped, but, due to the profile being on-demand and incldueAllNetworks, the path monitoring believes the device has no connectivity - so the new app is never downloaded. Is this the expected behavior? During development, the old packet tunnel gets stopped, the new app is installed, but the new packet tunnel is never started. To start it, the user has to toggle the VPN twice from the Settings app. The tunnel could be started from the VPN app too, if we chose to not take the path monitor into account, but then the user still needs to attempt to start the tunnel twice - it only works on the second try. As far as we can tell, the first time around, the packet tunnel never gets started, the app receives an update about NEVPNStatus being set to disconnecting yet NEVPNConnection does not throw. The behavior I was naively expecting was that the packet tunnel process would be stopped only when the new app is fully downloaded and when the update is installed, Are we doing something horribly wrong here?

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

Hi, I've encountered a strange behavior in the DNS Proxy Provider extension. Our app implements both DNS Proxy Provider and Content Filter Providers extensions, configured via MDM. When the app is uninstalled, the behavior of the providers differs: For Content Filter Providers (both Filter Control and Filter Data Providers), the providers stop as expected with the stop reason: /** @const NEProviderStopReasonProviderDisabled The provider was disabled. */ case providerDisabled = 5 However, for the DNS Proxy Provider, the provider remains in the "Running" state, even though there is no app available to match the provider's bundle ID in the uploaded configuration profile. When the app is reinstalled: The Content Filter Providers start as expected. The DNS Proxy Provider stops with the stop reason: /** @const NEProviderStopReasonAppUpdate The NEProvider is being updated */ @available(iOS 13.0, *) case appUpdate = 16 At this point, the DNS Proxy Provider remains in an 'Invalid' state. Reinstalling the app a second time seems to resolve the issue, with both the DNS Proxy Provider and Content Filter Providers starting as expected. This issue seems to occur only if some time has passed after the DNS Proxy Provider entered the 'Running' state. It appears as though the system retains a stale configuration for the DNS Proxy Provider, even after the app has been removed. Steps to reproduce: Install the app and configure both DNS Proxy Provider and Content Filter Providers using MDM. Uninstall the app. Content Filter Providers are stopped as expected (NEProviderStopReason.providerDisabled = 5). DNS Proxy Provider remains in the 'Running' state. Reinstall the app. Content Filter Providers start as expected. DNS Proxy Provider stops with NEProviderStopReason.appUpdate (16) and remains 'Invalid'. Reinstall the app again. DNS Proxy Provider now starts as expected. This behavior raises concerns about how the system manages the lifecycle of DNS Proxy Provider, because DNS Proxy Provider is matched with provider bundle id in .mobileconfig file. Has anyone else experienced this issue? Any suggestions on how to address or debug this behavior would be highly appreciated. Thank you!

We use as content filter in our app to monitor flows, we gather data about the flow and block flows deemed suspicious. Our content filter is activated/deactivated by a UI app but the flows are reported via XPC to a separate daemon process for analysis. As of macOS 15, we are seeing cases where flows are missing or flows are not received at all by the content filter. The behaviour is not consistent, some devices seem to receive flows normally but others don't. It appears Intel devices are much less prone to showing the problem, whereas Arm devices routinely exhibit missing flows. On macOS 14 or earlier, there is no sign of missing flows. Testing on earlier beta versions of macOS 15 did not appear to show the problem, however I can't rule out if issue was present but it wasn't spotted. Experimenting with simple examples of using a content filter (e.g. QNE2FilterMac) does not appear to reproduce the issue. Questions, What has changed between macOS 14 and 15 that could be the cause of the lack of flows? Is our approach to using an app activated content filter reporting to a daemon connected via XPC unsupported?

Starting on macOS Sequoia, flows originated in Firefox have an empty sourceAppAuditToken. Other apps contain a valid token. Background: in order to fetch process info for a certain NEFilterFlow, my content filter extension uses sourceAppAuditToken, audit_token_to_pid() and proc_* (as recommended in #126820). When that fails, we use SecCodeCopyGuestWithAttributes, recommended in some other thread as a better alternative. Both approaches break when the sourceAppAuditToken is empty since they need the pid. Debugging: My logging shows audit token is empty for Firefox Typical logs from com.apple.networkextension also indicate it fails to fetch the same info I'm looking for: com.apple.networkextension debug 11:22:07.024588-0300 Fetching appInfo from cache for pid: 948 uuid: 5C40B765-C6C9-3641-A822-2BC44D264361 bundle id: (null) com.apple.networkextension debug 11:22:07.024657-0300 Calling delegate lookup handler with pid: 948, uuid: 5C40B765-C6C9-3641-A822-2BC44D264361, bundleID: (null) com.apple.networkextension debug 11:22:07.025856-0300 Could not look up appInfo for pid: 948 bundle id: (null) uuid: 5C40B765-C6C9-3641-A822-2BC44D264361 com.apple.networkextension error 11:22:07.025897-0300 Could not find app info, return the original flow without filling in app info Handling new flow: identifier = D89B5B5D-793C-4940-D992-4E90F2AD1900 procPID = 953 eprocPID = 948 direction = outbound inBytes = 0 outBytes = 0 signature = {length = 32, bytes = 0x4afeafde b484aa0c c5cb8698 0567343d ... 7cdee33e 135666dd } socketID = 19adf2904e92d9 localEndpoint = 0.0.0.0:0 remoteEndpoint = 17.33.202.170:443 protocol = 6 family = 2 type = 1 procUUID = 0C68E603-967E-3643-B225-378BD2A655F7 eprocUUID = 5C40B765-C6C9-3641-A822-2BC44D264361 Perhaps there's a bug when generating the audit token or could it be something with the Firefox signature? I double-checked Firefox and it seems fine: $ codesign --verify --verbose /Applications/Firefox.app /Applications/Firefox.app: valid on disk /Applications/Firefox.app: satisfies its Designated Requirement Not sure if relevant, but codesign with -dv showed different flags in CodeDirectory when compared to chrome: codesign -dv /Applications/Firefox.app ... CodeDirectory v=20500 size=863 flags=0x10000(runtime) hashes=18+5 ... Versus chrome CodeDirectory v=20500 size=1821 flags=0x12a00(kill,restrict,library-validation,runtime) hashes=46+7 location=embedded

There could be a case where-in multiple transparent proxies might exist in the system (for ex., Cisco AnyConnect, GlobalProtect, etc). We want to know if there is a way to order transparent proxies so that the desired transparent proxy gets the request first. During our research, we found a resource which talks about ordering transparent proxies through MDM. https://developer.apple.com/documentation/devicemanagement/vpn/transparentproxy Using this reference, we tried to create a profile and push it through JAMF. Below is the profile that we created and pushed with JAMF. Property List - &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;TransparentProxy&lt;/key&gt; &lt;array&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.paloaltonetworks.GlobalProtect.client.extension&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;1&lt;/string&gt; &lt;/dict&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.cisco.anyconnect.macos.acsockext&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;2&lt;/string&gt; &lt;/dict&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.mydomain.transparentproxy&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;3&lt;/string&gt; &lt;/dict&gt; &lt;/array&gt; We are not sure if this is the right way to create the profile, though JAMF is not throwing any error while pushing this profile. We see this profile on the local machine as "/Library/Managed Preferences/com.apple.networking.vpn-transparent-list.plist". Is there a way to know if the profile took effect and the order of transparent proxies has changed. Thanks in advance.

Hello, I am writing a NetworkExtension VPN using custom protocol and our client would like to able to use 5G network slice on the VPN, is this possible at all? From Apple's documentation, I found the following statement: If both network slicing and VPN are configured for an app or device, the VPN connection takes precedence over the network slice, rendering the network slice unused. Is it possible to assign a network slice on a NetworkExtension-based VPN and let the VPN traffic uses the assign network slice? Many thanks

I am in the middle of investigating an issue arising in the call to setsockopt syscall where it returns an undocumented and unexpected errno. As part of that, I'm looking for a way to list any socket content filters or any such extensions are in play on the system where this happens. To do that, I ran: systemextensionsctl list That retuns the following output: 0 extension(s) which seems to indicate there's no filters or extensions in play. However, when I do: netstat -s among other things, it shows: net_api: 2 interface filters currently attached 2 interface filters currently attached by OS 2 interface filters attached since boot 2 interface filters attached since boot by OS ... 4 socket filters currently attached 4 socket filters currently attached by OS 4 socket filters attached since boot 4 socket filters attached since boot by OS What would be the right command/tool/options that I could use to list all the socket filters/extensions (and their details) that are in use and applicable when a call to setsockopt is made from an application on that system? Edit: This is on a macosx-aarch64 with various different OS versions - 13.6.7, 14.3.1 and even 14.4.1.

When a VPN is active, RCS messaging does not work on iOS 18. I work on an iOS VPN app, and we were very appreciative of the excludeCellularServices network flag that was released during the iOS 16 cycle. It's a great solution to ensure the VPN doesn't interfere with cellular network features from the cellular provider. Separately - As a user, I'm excited that iOS 18 includes RCS messaging. Unfortunately, RCS messaging is not working when our VPN is active (when checking on the iOS 18 release candidate). My guess is that RCS is not excluded from the VPN tunnel, even when excludeCellularServices is true. It seems like RCS should be added in this situation, as it is a cell provider service. Can RCS be added as a service that is excluded from the VPN tunnel when excludeCellularServices is true? (I've also sent this via feedback assistant, as 15094270.)

Network is not working when over 50MB size file upload smb using NEFilterDataProvider in macOS The event received through NEFilterDataProvider is returned immediately without doing any other work. override func handleNewFlow(_ flow: NEFilterFlow) -> NEFilterNewFlowVerdict { guard let socketFlow = flow as? NEFilterSocketFlow, let auditToken = socketFlow.sourceAppAuditToken, let remoteEndpoint = socketFlow.remoteEndpoint as? NWHostEndpoint, let localEndpoint = socketFlow.localEndpoint as? NWHostEndpoint else { return .allow() } return .filterDataVerdict(withFilterInbound: true, peekInboundBytes: Int.max, filterOutbound: true, peekOutboundBytes: Int.max) } override func handleInboundData(from flow: NEFilterFlow, readBytesStartOffset offset: Int, readBytes: Data) -> NEFilterDataVerdict { guard let socketFlow = flow as? NEFilterSocketFlow, let auditToken = socketFlow.sourceAppAuditToken, let remoteEndpoint = socketFlow.remoteEndpoint as? NWHostEndpoint, let localEndpoint = socketFlow.localEndpoint as? NWHostEndpoint else { return .allow() } return NEFilterDataVerdict(passBytes: readBytes.count, peekBytes: Int.max) } override func handleOutboundData(from flow: NEFilterFlow, readBytesStartOffset offset: Int, readBytes: Data) -> NEFilterDataVerdict { guard let socketFlow = flow as? NEFilterSocketFlow, let auditToken = socketFlow.sourceAppAuditToken, let remoteEndpoint = socketFlow.remoteEndpoint as? NWHostEndpoint, let localEndpoint = socketFlow.localEndpoint as? NWHostEndpoint else { return .allow() } return NEFilterDataVerdict(passBytes: readBytes.count, peekBytes: Int.max) } override func handleInboundDataComplete(for flow: NEFilterFlow) -> NEFilterDataVerdict { guard let socketFlow = flow as? NEFilterSocketFlow, let auditToken = socketFlow.sourceAppAuditToken, let remoteEndpoint = socketFlow.remoteEndpoint as? NWHostEndpoint, let localEndpoint = socketFlow.localEndpoint as? NWHostEndpoint else { return .allow() } return .allow() } override func handleOutboundDataComplete(for flow: NEFilterFlow) -> NEFilterDataVerdict { guard let socketFlow = flow as? NEFilterSocketFlow, let auditToken = socketFlow.sourceAppAuditToken, let remoteEndpoint = socketFlow.remoteEndpoint as? NWHostEndpoint, let localEndpoint = socketFlow.localEndpoint as? NWHostEndpoint else { return .allow() } return .allow() } how can i fix it?

We're encountering an issue with our Network Extension (utilizing NEPacketTunnelProvider and NETransparentProxy) on macOS 14.5 (23F79). On some systems, the VPN fails to automatically start after a reboot despite calling startVPNTunnel(). There are no error messages. Our code attempts to start the tunnel: ....... do { try manager.connection.startVPNTunnel() Logger.default("Started tunnel successfully") } catch { Logger.error("Failed to launch tunnel") } ...... System log analysis reveals the tunnel stopping due to userLogout (NEProviderStopReason(rawValue: 12)) during reboot. However, the Transparent Proxy stops due to userInitiated (NEProviderStopReason(rawValue: 1)) for the same reboot. We need to understand: Why the VPNTunnel isn't starting automatically. Why the userLogout reason is triggered during reboot. Additional Context: We have manually started the VPN from System Settings before reboot.

Hello, We are facing what we believe is a compatibility issue with two networking APIs. If the Network extension VPN configuration has includeAllNetworks flag enabled and the NEHotspotHelper is registered. The user has internet connection but it is blocked, and there user will get internet back only after restarting the device. VPN Configuration is as below while connecting to VPN, { localizedDescription = WLVPN WireGuard Configuration enabled = YES protocolConfiguration = { serverAddress = <18-char-str> passwordReference = {length = 20, bytes = 0x67656e70ed0d05c06b1b4896bf4fef2031e1a92d} disconnectOnSleep = NO includeAllNetworks = YES excludeLocalNetworks = YES excludeCellularServices = YES excludeAPNs = YES excludeDeviceCommunication = YES enforceRoutes = NO providerBundleIdentifier = com.wlvpn.ios.consumervpn.network-extension } onDemandEnabled = NO onDemandRules = () } After running the code shown below. Regardless if the VPN is connected or not, the user needs to restart his device to regain internet access. private let neHelperQueue = DispatchQueue(label: "com.wlvpn.ios.consumervpn.hotspot", attributes: DispatchQueue.Attributes.concurrent) let options: [String: NSObject] = [kNEHotspotHelperOptionDisplayName : "" as NSObject] let status = NEHotspotHelper.register(options: nil, queue: neHelperQueue) { cmd in NSLog("Received command: \(cmd.commandType.rawValue)") } We need to use the includeAllNetworks flag to prevent the novel "Tunnel vision" vulnerability. Can we please have some help getting confirmation if both functionalities are compatible or if there's a way to enable them at the same time?