Configure the App ID in the Apple Developer Portal. In the Network Extensions section, the Packet Tunnel section is not displayed How to proceed with the configuration of App ID. In the Network Extensions section: Display the Packet Tunnel section Our account is a China region account

我的完整报错信息： Task <0568A3A0-A40C-42A8-9491-2FC52D71EFFF>.<4> finished with error [-1009] Error Domain=NSURLErrorDomain Code=-1009 "似乎已断开与互联网的连接。" UserInfo={_kCFStreamErrorCodeKey=50, NSUnderlyingError=0x107db5590 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={_kCFStreamErrorDomainKey=1, _kCFStreamErrorCodeKey=50, _NSURLErrorNWResolutionReportKey=Resolved 0 endpoints in 1ms using unknown from cache, _NSURLErrorNWPathKey=unsatisfied (Denied over Wi-Fi interface), interface: en0[802.11], ipv4, dns, uses wifi}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <0568A3A0-A40C-42A8-9491-2FC52D71EFFF>.<4>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <0568A3A0-A40C-42A8-9491-2FC52D71EFFF>.<4>" ), NSLocalizedDescription=似乎已断开与互联网的连接。, NSErrorFailingURLStringKey=https://sharkserver.dypc.top/shark_user/login, NSErrorFailingURLKey=https://sharkserver.dypc.top/shark_user/login, _kCFStreamErrorDomainKey=1} 请求失败：似乎已断开与互联网的连接。 以下是问题的具体描述 我的A手机（15pro max 版本18,6,1） 使用xcode直接在A手机上运行我的程序 尝试发起post请求的时候得到了该报错。 我做了以下尝试 1.检查了A手机网络，一切正常，浏览器和其他app均可正常访问网络 2.检查了A手机上我的app权限，确认我因为为我的程序打开了无线网络和蜂窝流量 3.重启A手机，还原A手机网络设置，还原A手机所有设置，重启mac电脑 以上做法均无效，依旧报上面的错误 4.然后我尝试使用B手机(iPhone13 版本18.5)安装该程序 ，B手机可以正常运行并成功发起post请求，证明我的代码没有问题 5.我将代码上传至testfight 然后使用A手机下载testfight里的该程序 ，程序可以成功发起post请求没有任何错误，我再次使用xcode运行该程序到真机，又得到了Code=-1009错误 无法发起post请求

This is probably a basic question but I wanted to ask your advice for the best way to take consenting users' Watch data from Apple Health Kit and send it to our central server? One idea we had was to create an iOS app that gets the data from Apple's Health SDK on the phone and sends it to our server. Would appreciate any help here, thank you.

We have used ::gethostname to retrieve hostname in our tunnel provider extension and found it returns "localhost" on iOS 17+. So we changed to use [[NSProcessInfo processInfo] hostName]. However it often caused 30+ delay in the extension process on a few devices and always returns "localhost". The sysdiagnose shows a lot of DNS query logs as below: default mDNSResponder 2025-03-19 17:15:12.453769 +0800 75281: 0x11ad501 [R80937] DNSServiceCreateConnection START PID[79767](ACExtension) default mDNSResponder 2025-03-19 17:15:12.453892 +0800 75281: 0x11ad501 [R80938] DNSServiceQueryRecord START -- qname: <mask.hash: 'fNnSAdyuhKXqCny8+neXvw=='>, qtype: PTR, flags: 0x15000, interface index: -1, client pid: 79767 (ACExtension), name hash: 84de01e1 default mDNSResponder 2025-03-19 17:15:12.458395 +0800 75281: 0x11ad501 [R80939] DNSServiceQueryRecord START -- qname: <mask.hash: '2X6qN/YT0yh2psKwrGWokg=='>, qtype: PTR, flags: 0x15000, interface index: 0, client pid: 79767 (ACExtension), name hash: f25c923e default mDNSResponder 2025-03-19 17:15:12.462924 +0800 75281: 0x11ad501 [R80940] DNSServiceQueryRecord START -- qname: <mask.hash: 'peyRWEblLKbNvcOXPjSeMQ=='>, qtype: PTR, flags: 0x15000, interface index: 0, client pid: 79767 (ACExtension), name hash: 83323cc4

Configure the App ID in the Apple Developer Portal. In the Network Extensions section, the Packet Tunnel section is not displayed, as shown in the figure below How to proceed with the configuration of App ID. In the Network Extensions section: Display the Packet Tunnel section Our account is a China region account

When filtering traffic to localhost (127.0.0.1), it causes Maven repository synchronization to fail in IntelliJ IDEA. However, Maven works correctly when local traffic is not filtered. I will provide a minimal code reproduction below. - (void)startFilterWithCompletionHandler:(void (^)(NSError *error))completionHandler { // Add code to initialize the filter NSMutableArray *rules = [NSMutableArray array]; NENetworkRule * rule = [[NENetworkRule alloc] initWithRemoteNetwork:nil remotePrefix:0 localNetwork:nil localPrefix:0 protocol:NENetworkRuleProtocolTCP direction:NETrafficDirectionAny]; [rules addObject:[[NEFilterRule alloc]initWithNetworkRule:rule action:NEFilterActionFilterData]]; rule = [[NENetworkRule alloc] initWithRemoteNetwork:nil remotePrefix:0 localNetwork:nil localPrefix:0 protocol:NENetworkRuleProtocolUDP direction:NETrafficDirectionAny]; [rules addObject:[[NEFilterRule alloc]initWithNetworkRule:rule action:NEFilterActionFilterData]]; NWHostEndpoint *hostEndpointIpv4 = [NWHostEndpoint endpointWithHostname:@"127.0.0.1" port:@"0"]; NENetworkRule *localHostRuleIpv4 = [[NENetworkRule alloc] initWithRemoteNetwork:hostEndpointIpv4 remotePrefix:32 localNetwork:hostEndpointIpv4 localPrefix:32 protocol:NENetworkRuleProtocolAny direction:NETrafficDirectionAny]; [rules addObject:[[NEFilterRule alloc]initWithNetworkRule:localHostRuleIpv4 action:NEFilterActionFilterData]]; NEFilterSettings *filterSetting = [[NEFilterSettings alloc] initWithRules:rules defaultAction:NEFilterActionAllow]; [self applySettings:filterSetting completionHandler:^(NSError * _Nullable error) { if (error) { NSLog(@"Failed to apply filter settring: %@", error.localizedDescription); } completionHandler(error); }]; } Maven Sync error: System Log: 默认 17:35:13.184509+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so 3bb6402f58a82e37 - flags 0x800840 0x80> lport 63166 fport 29735 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:13.184510+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so d6dde374c8cb613b - flags 0x800840 0x80> lport 63165 fport 29735 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:13.529546+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so cc915e74ba29f8cb - flags 0x800840 0x80> lport 63169 fport 39066 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:13.529546+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so 2e15c3e54ebcc45 - flags 0x800840 0x80> lport 63168 fport 39066 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:14.046094+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so 71f6d3a53472131f - flags 0x800840 0x80> lport 63172 fport 53241 laddr 127.0.0.1 faddr 127.0.0.1 默认 17:35:14.046145+0800 kernel cfil_inp_log:6179 <CFIL: outbound TCP data dropped for pre-existing un-filtered flow>: [41046 idea] <TCP out so c88a367c9717185b - flags 0x800840 0x80> lport 63171 fport 53241 laddr 127.0.0.1 faddr 127.0.0.1 Environment Details: Operating System: macOS 15.5 (Sequoia) IDE: IntelliJ IDEA 2025.1 Relevant Technology: NEFilterDataProvider (Network Extension) I have found reports of similar problems online： https://discussionschinese.apple.com/thread/255270330?sortBy=rank https://blog.csdn.net/weixin_42339552/article/details/137402307 They all seem to be caused by network extension。

I would like to understand the behaviour of Network framework when I have established a connection between 2 iOS devices which are connected through LAN and the same Wifi. Assumptions: Enabled includePeerToPeer. Devices are discovered and connected through Bonjour: When the connection establishes for the first time, does it automatically decide which interface to pick? I see some posts which point to Happy Eyeball algorithm but that seem to point more towards ipv4 vs ipv6 rather than Wifi vs LAN vs P2P. In the middle of a connection, if the established connection has issues, does the Network framework automatically switch to the best available interface? If not, I would assume the app will have to handle the switching in betterPathUpdateHandler callback? I’m curious what needs to be done here. Do I just create a new connection and hope that it picks the actual better path? The NWInterface.InterfaceType doesnt have a type for peer to peer wifi. Does that mean that when the interface actually switches to peer to peer, the InterfaceType will be other? It would be great if there is a workflow or example of how this needs to be handled with multiple available Interfaces.

Hi all, I’m developing a companion iOS app that connects to a device-created Wi-Fi hotspot to transfer videos or other files WebSocket. The challenge is: once the iPhone connects to this hotspot, it loses internet access because iOS routes all traffic through Wi-Fi. However, I’d like to keep the iPhone’s cellular data active and usable while staying connected to the local hotspot — so the app can access cloud APIs, or the user can continue using other apps that require internet access. I understand that iOS prioritizes Wi-Fi over cellular, but are there any supported workarounds or patterns (e.g., MFi programs, local-only Wi-Fi access, NEHotspotConfiguration behavior, etc.) that : • Using Wi-Fi only for local communication; • cellular to remain active for internet access. Any insights or Apple-recommended best practices would be greatly appreciated — especially any official references regarding MFi Accessory setup or NEHotspotConfiguration behavior in this context. Thanks in !

I’m developing an app designed for hospital environments, where public internet access may not be available. The app includes two components: the main app and a Local Connectivity Extension. Both rely on persistent TCP socket connections to communicate with a local server. We’re observing a recurring issue where the extension’s socket becomes unresponsive every 1–3 hours, but only when the device is on the lock screen, even if the main app remains in the foreground. When the screen is not locked, the connection is stable and no disconnections occur. ❗ Issue Details: • What’s going on: The extension sends a keep-alive ping packet every second, and the server replies with a pong and a system time packet. • The bug: The server stops receiving keep alive packets from the extension.  • On the server, we detect about 30 second gap on the server, a gap that shows no packets were received by the extension. This was confirmed via server logs and Wireshark).  • On the extension, from our logs there was no gap in sending packets. From it’s perspective, all packets were sent with no error.  • Because no packet are being received by the server, no packets will be sent to the extension. Eventually the server closes the connection due to keep-alive timeout.  • FYI we log when the NEAppPushProvider subclass sleeps and it did NOT go to sleep while we were debugging. 🧾 Example Logs: Extension log: 2025-03-24 18:34:48.808 sendKeepAliveRequest() 2025-03-24 18:34:49.717 sendKeepAliveRequest() 2025-03-24 18:34:50.692 sendKeepAliveRequest() ... // continuous sending of the ping packet to the server, no problems here 2025-03-24 18:35:55.063 sendKeepAliveRequest() 2025-03-24 18:35:55.063 keepAliveTimer IS TIME OUT... in CoreService. // this is triggered because we did not receive any packets from the server 2025-03-24 18:34:16.298 No keep-alive received for 16 seconds... connection ID=95b3... // this shows that there has been no packets being received by the extension ... 2025-03-24 18:34:30.298 Connection timed out on keep-alive. connection ID=95b3... // eventually closes due to no packets being received 2025-03-24 18:34:30.298 Remote Subsystem Disconnected {name=iPhone|Replica-Ext|...} ✅ Observations: • The extension process continues running and logging keep-alive attempts. • However, network traffic stops reaching the server, and no inbound packets are received by the extension. • It looks like the socket becomes silently suspended or frozen, without being properly closed or throwing an error. ❓Questions: • Do you know why this might happen within a Local Connectivity Extension, especially under foreground conditions and locked ? • Is there any known system behavior that might cause the socket to be suspended or blocked in this way after running for a few hours? Any insights or recommendations would be greatly appreciated. Thank you!

I would like to inquire about the feasibility of developing an iOS application with the following requirements: The app must support real-time audio communication based on UDP. It needs to maintain a TCP signaling connection, even when the device is locked. The app will run only on selected devices within a controlled (closed) environment, such as company-managed iPads or iPhones. Could you please clarify the following: Is it technically possible to maintain an active TCP connection when the device is locked? What are the current iOS restrictions or limitations for background execution, particularly related to networking and audio? Are there any recommended APIs or frameworks (such as VoIP, PushKit, or Background Modes) suitable for this type of application?

Greetings I'm trying to get on iPad the SSID from the wifi I'm connected to. For that, I added the wifi entitlement and I'm requesting permission to the user for Location. Once I have it, I'm using the function CNCopySupportedInterfaces to get the interfaces, but I can only receive the en0, which using the method CNCopyCurrentNetworkInfo returns nil. I also tried using the NEHotspotNetwork.fetchCurrent and the SSID keeps being nil. So right now I'm drawing a blank. Is there any way to make it work? Thanks.

Hello, Since the release of iOS 26.0, we are seeing DNS traffic being blocked from within our NEPacketTunnelExtension on some devices. We have not isolated exact reproduction steps, but DNS resolves successfully for a period of time after enabling "iCloud Private Relay" (varying from 1-day to 2-weeks), until it then fails as MDNSResponder then returns: mDNSResponder [Q37046] DetermineUnicastQuerySuppression: Query suppressed for <mask.hash: 'REDACTED'> Addr (blocked by policy) DNS resolution continues to fail for all domains with the above until the device is rebooted. The Packet Tunnel intentionally does not have a DNS server set and this occurs for traffic from the Extension yet off-tunnel, which needs resolution from the system DNS server (and this configuration works perfectly for a period of time before being "blocked by policy"). The following do not resolve the issue once DNS queries are being "blocked by policy" on affected devices: disconnecting then reconnecting the vpn; toggling airplane mode for 10+ seconds; switching connection between WiFi & cellular data; disabling iCloud Private Relay. We have currently only seen this on unmanaged devices running iOS 26.0 or 26.1 beta and with iCloud Private Relay enabled. We did not see this issue on iOS 16,17 nor 18. We also have not yet seen this when iCloud Private Relay is disabled nor on iOS 26.0.1, however we cannot confirm whether they too are also affected. Is there a known a bug with iOS 26.0 & 26.1 Beta 1 that could cause this? How can we prevent DNS requests from NEPacketTunnelExtension being sporadically "blocked by policy" until the device is rebooted? Many thanks in advance.

Hello everyone, Last year I built an application for tvOS and iPadOS that enables device-to-device communication. I based it on Apple’s sample code, available here: https://developer.apple.com/documentation/Network/building-a-custom-peer-to-peer-protocol At that time, everything worked flawlessly. However, this year I had to revisit the project to add new features, and now it no longer works as expected. The first time the app runs it connects fine, but if we relaunch it (on either the iPad, the Apple TV, or both), the connection fails. Most importantly, this is not an issue with my own code — I tested it directly with the original Apple sample code, and the exact same problem occurs there too. Here’s what I see in the logs: nw_endpoint_flow_setup_channel [C1 TicTacToe,65E91B02-890E-4D30-88B8-CE2AB9677BF9 in_progress channel-flow (satisfied (Path is satisfied), viable, interface: utun0, scoped, ipv6)] nexus assignment error Connection refused nw_endpoint_flow_failed_with_error [C1 TicTacToe,65E91B02-890E-4D30-88B8-CE2AB9677BF9 in_progress channel-flow (satisfied (Path is satisfied), viable, interface: utun0, scoped, ipv6)] already failing, returning code-block This happens right after I select the iPad from the device list and try to connect. What’s strange is that the interface being used is utun0. I don’t have a VPN or iCloud Private Relay enabled. I also tried running the app through the iPad’s personal hotspot, but I get the same error. The only workaround I’ve found so far is to restart the Apple TV. Has anyone else run into this problem? Is there any known solution or workaround? Tested on tvOS 18.6 and iPadOS 18.3.2 / 18.6.

I cannot find in the documentation and samples how exactly the Bloom filter is generated. Is there any code sample for that?

I'm able to discover a service with Bonjour, which gets me an nw_browse_result_t from which I can get an nw_endpoint_t and then an nw_connection_t. That's all fine. But this particular service runs on 3 ports. The port numbers of the other 2 ports are in the txt record (but they are well-known and stable anyway). How can I create 2 more nw_connection_t to the same host/IP but on a different port? I already have this working with NSNetService, but am trying to update to Network.framework. I've found nw_endpoint_get_address() but the docs say it returns null "if the endpoint is not of type nw_endpoint_type_address" and indeed nw_browse_result_t gives me an nw_endpoint_type_bonjour_service.

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 there, We are facing some issues regarding TLS connectivity: Starting with iOS 26, the operating system refuses to open TLS sockets to local devices with self-signed certificates over Wi-Fi. In this situation, connection is no longer possible, even if the device is detected on the network with Bonjour. We have not found a workaround for this problem. We've tryied those solutions without success: Added the 'NSAppTransportSecurity' key to the info.plist file, testing all its items, such as "NSAllowsLocalNetworking", "NSExceptionDomains", etc. Various code changes to use properties such as "sec_protocol_options_set_local_identity" and "sec_protocol_options_set_tls_server_name" to no avail. Brutally import the certificate files into the project and load them via, for example, "Bundle.main.url(forResource: "nice_INTERFACE_server_cert", withExtension: "crt")", using methods such as sec_trust_copy_ref and SecCertificateCopyData. Download the .pem or .crt files to the iPhone, install them (now visible under "VPN & Device Management"), and then flag them as trusted by going to "Settings -> General -> Info -> Trust". certificates" The most critical part seems to be the line sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { $2(true) }, queue) whose purpose is to bypass certificate checks and validate all of them (as apps already do). However, on iOS26, if I set a breakpoint on leg$2(true),` it never gets there, while on iOS 18, it does. I'll leave as example the part of the code that was tested the most below. Currently, on iOS26, the handler systematically falls back to .cancelled: func startConnection(host: String, port: UInt16) { self.queue = DispatchQueue(label: "socketQueue") let tlsOptions = NWProtocolTLS.Options() sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { $2(true) }, queue) let parameters = NWParameters(tls: tlsOptions) self.nwConnection = NWConnection(host: .init(host), port: .init(rawValue: port)!, using: parameters) self.nwConnection.stateUpdateHandler = { [weak self] state in switch state { case .setup: break case .waiting(let error): self?.connectionDidFail(error: error) case .preparing: break case .ready: self?.didConnectSubject.onNext(Void()) case .failed(let error): self?.connectionDidFail(error: error) case .cancelled: self?.didDisconnectSubject.onNext(nil) @unknown default: break } } self.setupReceive() self.nwConnection.start(queue: queue) } These are the prints made during the procedure. The ones with the dot are from the app, while the ones without are warnings/info from Xcode: 🔵 INFO WifiNetworkManager.connect():52 - Try to connect onto the interface access point with ssid NiceProView4A9151_AP 🔵 INFO WifiNetworkManager.connect():68 - Connected to NiceProView4A9151_AP tcp_output [C13:2] flags=[R.] seq=215593821, ack=430284980, win=4096 state=CLOSED rcv_nxt=430284980, snd_una=215593821 nw_endpoint_flow_failed_with_error [C13 192.168.0.1:443 in_progress channel-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], dns, uses wifi, LQM: unknown)] already failing, returning nw_connection_copy_protocol_metadata_internal_block_invoke [C13] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C13] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C13] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C13] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C14] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C14] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C14] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C14] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection [C14 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel [C14 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel nw_connection_copy_protocol_metadata_internal_block_invoke [C15] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C15] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C15] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C15] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C16] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C16] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C16] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C16] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection [C16 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel [C16 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel 🔴 ERROR InterfaceDisconnectedViewModel.connect():51 - Sequence timeout.

I created a self signed CA and use it to generate/sign a client cert using openssl. Then I use the self signed client cert to do TLS client authentication with my server (which also uses the self signed CA). The issue I have is when I validate the self signed CA, by calling SecTrustEvaluateAsyncWithError, it always complains this error “'DigiCert Global Root G3' certificate is not trusted". However that CA (DigiCert Global Root G3) is not my self signed CA (my CA is 'MQTTSampleCA' and I attached a dump of the my CA cert in the PR in the end of this post), so I'm confused why the API keeps complaining that CA. After some researching, I see that is a well known CA so I download its cert from https://www.digicert.com/kb/digicert-root-certificates.htm, install and trust it on my iOS device, but that doesn't help and I still get the same error. I provide all the repro steps in this PR: https://github.com/liumiaojq/EmCuTeeTee/pull/1, including how I generate the certs and the source codes of a test app that I used to do cert validation. I appreciate if anyone can share insights how to resolve this error.

I was having a look through the documentation for NEPacketTunnelProvider, and wanted to know if it's possible for startTunnel(..) and stopTunnel(..) to run simultaneously, and thus require synchronization between resources they deal with? For example, if the VPN is toggled rapidly from system settings, could the setup that occurs in my startTunnel() definition (class instantiation and setTunnelNetworkSettings(value)) potentially occur after the tear-down logic (resource cleanup, setTunnelNetworkSettings(nil)), leaving the system in a state where the VPN is deactivated, but the configuration is in place?

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 !