Firstly, I'm completely new to native Swift/iOS Development so apologies if this is a simple question that I'm seemingly misunderstanding. I have an app which has the Multicast Networking entitlement and works fine on my own iPhone, however it only has one interface when I list them (en0) The multicast networking, however, fails entirely on another test iPhone but this also appears to have one or more 'ipsecX' interfaces both with the IP 192.0.0.6 - I'm guessing but I wonder if this is related to a connection to Apple Watch as I've noticed two devices that have these additional interfaces, and both of them are connected to Apple Watch (with no VPNs configured) and that's the only thing that differentiates them from my own iPhone. I can reproduce the symptoms on my own iPhone by connecting to a VPN which creates a utunX interface (but in my case disconnecting from the VPN removes this interface and it works as expected) I expect a solution would be to bind my Multicast Group to the WiFi IP but I've tried a few things without success; Setting params.requiredInterfaceType = .wifi Looping through each interface to try and 'find' en0 and bind this way; let queue = DispatchQueue(label: "En0MonitorQueue") monitor.pathUpdateHandler = { [weak self] path in // Find the en0 interface if let en0 = path.availableInterfaces.first(where: { $0.name == "en0" }) { monitor.cancel() // Stop monitoring once found let params = NWParameters.udp params.allowLocalEndpointReuse = true params.requiredInterface = en0 guard let multicast = try? NWMulticastGroup(for: [ .hostPort( host: NWEndpoint.Host(self?.settings.multicastIP ?? "224.224.0.77"), port: NWEndpoint.Port(rawValue: UInt16(self?.settings.multicastPort ?? 23019)) ) ]) else { print("Failed to Start Multicast Group") return } let group = NWConnectionGroup(with: multicast, using: params) // previous multicast stuff is here } else { print("en0 interface not found, waiting...") } } monitor.start(queue: queue) Neither seems to work. I feel I must be missing something simple, because it should not be the case that simply enabling a VPN (or having another interface created by something else) breaks Multicast on en0/WiFi. That said, I also don't want to limit the user to en0 as they may wish to use Ethernet interfaces, but for now it would be good to make it work to confirm this is the problem.

iOS 18.4 introduced some requirements on the Key Usage of 802.1x server certificates, as described here. https://support.apple.com/en-us/121158 When using TLS_ECDHE_RSA or TLS_DHE_RSA cipher suites, 802.1X server certificates containing a Key Usage extension must have Digital Signature key usage set. When using the TLS_RSA cipher suite, 802.1X server certificates containing a Key Usage extension must have Key Encipherment key usage set. It reads like the change is supposed to affect 802.1x only. However, we have found out that the new restrictions are actually imposed on all TLS connections using the Network framework, including in Safari. Unlike other certificate errors which can be either ignored by users (as in Safari) or by code (via sec_protocol_options_set_verify_block), these new ones can't. Even if passing completion(true) in the TLS verification block, the connection still ends up in waiting state with error -9830: illegal parameter. I understand that these requirements are valid ones but as a generic TLS library I also expect that Network framework could at least allow overriding the behavior. The current treatment is not consistent with those on other certificate errors. Since I can't upload certificates, here is how to reproduce a certificate that fails. Create a OpenSSL config file test.cnf [ req ] default_bits = 2048 distinguished_name = dn x509_extensions = v3_ca prompt = no [ dn ] CN = example.com [ v3_ca ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = CA:TRUE keyUsage = critical, keyCertSign, cRLSign Generate certificate and private key openssl req -x509 -new -nodes -keyout key.pem -out cert.pem -days 365 -config test.cnf And here is the client code to test. // Target server and port let host = NWEndpoint.Host("example.com") let port = NWEndpoint.Port("443")! // Configure insecure TLS options let tlsOptions = NWProtocolTLS.Options() sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { _, _, completion in // Always trust completion(true) }, DispatchQueue.global()) let params = NWParameters(tls: tlsOptions) let connection = NWConnection(host: .init(host), port: .init(rawValue: port)!, using: params) connection.stateUpdateHandler = { newState in switch newState { case .ready: print("TLS connection established") case .failed(let error): print("Connection failed: \(error)") case .cancelled: print("Connection canceled") case .preparing: print("Connection preparing") case .waiting(let error): print("Connection waiting: \(error)") case .setup: print("Connection setup") default: break } } connection.start(queue: .global()) Output Connection preparing Connection waiting: -9830: illegal parameter Previously reported as FB17099740

I'm running a Node.js server on my MacBook with Apple M4 Pro chip, macOS Sequoia 15.4, and Node.js v23.10.0. The server starts normally on port 5000 and logs show that it's listening correctly. However, when I try to access it via browser or Postman (http://localhost:5000/api/...), I get a 403 Forbidden error. After checking with lsof -i :5000, I noticed that the ControlCenter process is listening on port 5000 under the name commplex-main. Interestingly, this doesn't happen on M3 Pro machines. On those devices, Node.js runs fine on port 5000 and can be accessed from Postman and browsers. Is port 5000 now internally reserved by macOS or used by some system-level service in Sequoia or Apple Silicon (M4 Pro)? Should I avoid using this port going forward? Any official clarification would be appreciated.

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?

ios構成プロファイルの制限のallowCloudPrivateRelayのプライベートリレーの制御とRelayペイロードの機能は関係がありますか？ それとも別々の機能でしょうか？ ↓ s there a relationship between the private relay control in the iOS configuration profile restriction allowCloudPrivateRelay and the functionality of the Relay payload? Or are they separate features?

Are the network relays introduced in 2023 and https://developer.apple.com/videos/play/wwdc2023/10002/ the same thing as the Private Relay introduced in 2021? https://developer.apple.com/videos/play/wwdc2021/10096/ We are considering verifying the relay function, but we are not sure whether they are the same function or different functions. https://developer.apple.com/documentation/devicemanagement/relay?language=objc

Every now and again folks notice that Network framework seems to create an unexpected number of connections on the wire. This post explains why that happens and what you should do about it. If you have questions or comments, put them in a new thread here on the forums. Use the App & System Services > Networking topic area and the Network tag. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Understanding Also-Ran Connections Network framework implements the Happy Eyeballs algorithm. That might create more on-the-wire connections than you expect. There are two common places where folks notice this: When looking at a packet trace When implementing a listener Imagine that you’ve implemented a TCP server using NWListener and you connect to it from a client using NWConnection. In many situations there are multiple network paths between the client and the server. For example, on a local network there’s always at least two paths: the link-local IPv6 path and either an infrastructure IPv4 path or the link-local IPv4 path. When you start your NWConnection, Network framework’s Happy Eyeballs algorithm might [1] start a TCP connection for each of these paths. It then races those connections. The one that connects first is the ‘winner’, and Network framework uses that connection for your traffic. Once it has a winner, the other connections, the also-ran connections, are redundant, and Network framework just closes them. You can observe this behaviour on the client side by looking in the system log. Many Network framework log entries (subsystem com.apple.network) contain a connection identifier. For example C8 is the eighth connection started by this process. Each connection may have child connections (C8.1, C8.2, …) and grandchild connections (C8.1.1, C8.1.2, …), and so on. You’ll see state transitions for these child connections occurring in parallel. For example, the following log entries show that C8 is racing the connection of two grandchild connections, C8.1.1 and C8.1.2: type: debug time: 12:22:26.825331+0100 process: TestAlsoRanConnections subsystem: com.apple.network category: connection message: nw_socket_connect [C8.1.1:1] Calling connectx(…) type: debug time: 12:22:26.964150+0100 process: TestAlsoRanConnections subsystem: com.apple.network category: connection message: nw_socket_connect [C8.1.2:1] Calling connectx(…) Note For more information about accessing the system log, see Your Friend the System Log. You also see this on the server side, but in this case each connection is visible to your code. When you connect from the client, Network framework calls your listener’s new connection handler with multiple connections. One of those is the winning connection and you’ll receive traffic on it. The others are the also-ran connections, and they close promptly. IMPORTANT Depending on network conditions there may be no also-ran connections. Or there may be lots of them. If you want to test the also-ran connection case, use Network Link Conditioner to add a bunch of delay to your packets. You don’t need to write special code to handle also-ran connections. From the perspective of your listener, these are simply connections that open and then immediately close. There’s no difference between an also-ran connection and, say, a connection from a client that immediately crashes. Or a connection generated by someone doing a port scan. Your server must be resilient to such things. However, the presence of these also-ran connections can be confusing, especially if you’re just getting started with Network framework, and hence this post. [1] This is “might” because the exact behaviour depends on network conditions. More on that below.

I am trying to connect to an accessory's WiFi network using the below code and I always see the message "connection succeded" even if I provide an incorrect passphrase. I tried with different accessories and see the same behavior. hotspotConfigurationManager.joinAccessoryHotspot(accessory, passphrase: passphrase) { error in if let error = error { print("connection failed: \(error.localizedDescription)") } else { print("connection succeeded") } }

Hi~ I implemented network filtering on iOS using NEFilterControlProvider and NEFilterDataProvider. However, I found that their usage is restricted when distributing through the App Store. Does ADEP-based distribution allow the use of NEFilterControlProvider and NEFilterDataProvider? In TN3134, it states that NEPacketTunnelProvider requires MDM. Should I assume that NEFilterControlProvider and NEFilterDataProvider also require MDM in the same way? Thanks

Hello, I am in a very similar situation as described in the thread: https://developer.apple.com/forums/thread/655183 Context: I am working on an app that receives data from a hardware device through its Wifi network, and the hardware is not connected to the internet. Now, I would need to call some API while still connected to hardware so I would need to use the cellular data. As mentioned on the thread, I can achieve this via Network framework, using the requiredInterfaceType property. But Is there any other way I can achieve this? I can also do some suggestion on the hardware if that's helpful. Thank you!

Hello, A quick background: I am developing an App that receives a data stream from a device through its Wi-Fi network. The device itself is not connected to the internet, so the app won't be either. Now, I am adding a new feature to the App that would require internet connection during the data stream. Consequently, my users would need to use their cellular data. On later versions of iPhone, the phone would occasionally detect the lack of internet connection and asks the user via a pop-up if they want to use their cellular data. However, this behavior is not consistent. So my question is- can we programmatically invoke this pop-up so the user can connect to the internet? Or even better- can we program the App to use cellular data while still being connected to a Wi-Fi network? Note: I have seen mixed answers on the internet whether this is doable or not, and I know that users are able do it themselves by manually configuring their IP in their WiFi settings page, but I doubt this operation can be done through the App for security reasons. Thanks!

你好，是这样的，目的我使用的是mac mini进行软件测试，我目前测试的软件会通过本地回环地址127.0.0.1进行数据传输，这种数据传输不是网络请求，所以用网络抓包的手段，没法测试。所以，我目前的想法是修改您macOS的本地回环地址优先级，定向到我自己的代理服务器，进行数据测试和请求检测。我对liunx系统的作比较了解，但是对于macos上面这方面设置的修改不太清楚。 希望您可以解答！

Hi~ I implemented network filtering on iOS using NEFilterControlProvider and NEFilterDataProvider. However, I found that their usage is restricted when distributing in the App Store. Does ADEP-based distribution allow the use of NEFilterControlProvider and NEFilterDataProvider? In TN3134, it states that NEPacketTunnelProvider requires MDM. Should I assume that NEFilterControlProvider and NEFilterDataProvider also require MDM in the same way? thanks.

Hi, DNS resolution using libresolv (res_nquery) fails in 15.4 when connected to VPN. The same is working fine for 15.3 and lower and this happens for all the domains. The method returns -1 and res->res_h_errno is set to 2. In wireshark we can see that the DNS request is sent and server also returns the response successfully. The same works fine if we use TCP instead of UDP by setting the following option res->options |= RES_USEVC;

There is a problem with the Apple local network setting api, iOS18 system, you turn off the local network permissions of the APP, uninstall the APP, and then re-install, the local network permissions even if opened, there is no effect, only restart the phone is useful

Feedback Ticket: FB13812251 Problem Statement: We are currently facing internet connectivity issue with our VPN application where we try to disconnect the VPN from the Packet Tunnel Network Extension using - (void)cancelTunnelWithError:(nullable NSError *)error. Which API to use to disconnect the VPN from Packet Tunnel as VPN app is not running such that device retains its internet connectivity as soon as VPN disconnects. Configuration: We have configured PacketTunnelProvider with the following settings: (NETunnelProviderManager *)tunnelProvider.protocolConfiguration.includeAllNetworks = YES; (NETunnelProviderManager *)tunnelProvider.protocolConfiguration.excludeLocalNetworks = NO; (NETunnelProviderManager *)tunnelProvider.protocolConfiguration.enforceRoutes = NO; These settings are applied from the VPN app and allow us to successfully establish a VPN connection, with all traffic being routed through the tunnel as expected.We are setting above properties to address local net attack. Issue we are facing: However, we encounter a problem when we attempt to disconnect the VPN from. When we call the following method from PacketTunnel network extension: (void)cancelTunnelWithError:(nullable NSError *)error Upon calling this method, the VPN disconnects as expected, but the device loses all internet connectivity and is unable to access any resources. This is not the desired behavior. Observation : Interestingly, when we call the following method from the app side. The VPN disconnects and the device retains its internet connectivity. [enabledConfig.connection stopVPNTunnel]; We would like to achieve the same behavior when disconnecting the VPN from the Network Extension. So we are looking for an API that could be called from NE without causing any internet connectivity issue. Any guidance on how to resolve this issue would be greatly appreciated.

Title: Loss of Internet Connectivity on iOS Device When Packet Tunnel Crashes Feedback ticket: https://feedbackassistant.apple.com/feedback/14162605 Product: iPhone 12 Version: iOS - 17.5.1 Configuration: NETunnelProviderManager Configuration Description: We are developing an iOS VPN client and have configured our packet tunnel provider according to Apple's guidelines. The configuration is as follows: includeAllNetworks = YES excludeLocalNetworks = NO enforceRoutes = NO This setup works as expected when the VPN successfully connects. However, we encounter a blocker issue where the device loses internet connectivity if the packet tunnel crashes. Steps to Reproduce: Configure the NETunnelProviderManager with the above settings. Connect the VPN, which successfully establishes a connection. Verify that resources are accessible and internet connectivity is functional. Packet tunnel to crash unexpectedly.Observe that the NE process (Packet Tunnel) restarts automatically, as expected and attempts to reconnect the VPN; however, the device now lacks internet connectivity, preventing VPN reconnection. Try accessing resources using Safari or any other internet-dependent app, resulting in an error indicating the device is not connected to the internet. Actual Results: The device loses internet connectivity after the packet tunnel crashes and fails to regain it automatically, preventing the VPN from reconnecting. Expected Results: The device should maintain internet connectivity or recover connectivity to allow the VPN to reconnect successfully after the packet tunnel process restarts. Workaround - iPhone device needs a restart to regain internet connectivity .

I'm looking for help with a network extension filtering issue. Specifically, we have a subclass of NEFilterDataProvider that is used to filter flows based upon a set of rules, including source IP and destination IP. We've run into an issue where the source IP is frequently 0.0.0.0 (or the IPv6 equivalent) on outgoing flows. This has made it so rules based upon source IP don't work. This is also an issue as we report these connections, but we're lacking critical data. We were able to work around the issue somewhat by keeping a list of flows that we allow that we periodically check to see if the source IP is available, and then report after it becomes available. We also considered doing a "peekBytes" to allow a bit of data to flow and then recheck the flow, but we don't want to allow data leakage on connections that should be blocked because of the source IP. Is there a way to force the operating system or network extension frameworks to determine the source IP for an outbound flow without allowing any bytes to flow to the network? STEPS TO REPRODUCE Create a network filtering extension for filtering flows using NEFilterDataProvider See that when handleNewFlow: is called, the outgoing flow lacks the source IP (is 0.0.0.0) in most cases There is this post that is discussing a similar question, though for a slightly different reason. I imagine the answer to this and the other post will be related, at least as far as NEFilterDataProvider:handleNewFlow not having source IP is considered. Thanks!

Hello, Our app uses Network Extension / Packet Tunnel Provider to establish VPN connections on macOS and iOS. We have observed that after creating a utun device and adding any IPv4 routes (NEPacketTunnelNetworkSettings.IPv4Settings), the OS automatically adds several host routes via utun to services such as Akamai, Apple Push, etc. These routes appear to correspond to TCP flows that were active at the moment the VPN connection was established. When a particular TCP flow ends, the corresponding host route is deleted. We understand this is likely intended to avoid breaking existing TCP connections. However, we find the behavior of migrating existing TCP flows to the new utun interface simply because any IPv4 route is added somewhat questionable. This approach would make sense in a "full-tunnel" scenario — for example, when all IPv4 traffic (e.g., 0.0.0.0/0) is routed through the tunnel — but not necessarily in a "split-tunnel" configuration where only specific IPv4 routes are added. Is there any way to control or influence this behavior? Would it be possible for FlowDivert to differentiate between full-tunnel and split-tunnel cases, and only preserve existing TCP flows via utun in the full-tunnel scenario? Thank you.

Here's what the documentation says https://developer.apple.com/documentation/networkextension/maintaining-a-reliable-network-connection Confirm that your NEAppPushProvider implementation doesn’t create a retain cycle with itself. After you call the completionHandler that the system passes to stop(with:completionHandler:), the Network Extension framework releases your NEAppPushProvider instance. This instance typically deallocates from memory when released, but if the instance has a retain cycle with itself, it fails to deallocate and wastes memory. Failure to deallocate can also cause the system to have two or more instances of your push provider, leading to inconsistent behavior. Use Instruments or add a logging statement to deinit to verify that your NEAppPushProvider deinitializes when expected. I observe that when I turn off the wifi, the AppPushProvider subclass fully deinitializes. But when I call removeFromPreferences on the NEAppPushManager from the app, it calls stop() on my AppPushProvider subclass, but it does not initialize. Should I be alarmed by this behavior? Will this cause a memory leak? Will this cause multiple Extension/AppPushProviders to be operating concurrently? For testing, I've removed everything except for logs and some singleton calls. No closures capturing self, and no strong references of self being passed anywhere. I am also not using the debugger, and am using the console to debug.