Hi, This ticket is 1year old. Is there any update on this? I also evaluate NEFilterPacketProvider for our product and see the limitation above are still present. NEFilterPacketProvider is designed for implementing custom firewalls/content filters. How it can be used reliably if all needed to bypass it is a simple VPN installation? Are there any alternative we can use to reliably catch all inbound and outbound packets on all interfaces including utun and loopback?

Hi Matt, Also, keep in mind here that using a Sandbox is a requirement in a Network System Extension whether you are deploying to the App Stor or deploying with Developer ID.  Can you please elaborate on the deploying with "Developer ID" problem you foresee when using Network System Extension without sandbox? I have tried to notarize such an application for MacOS and it worked fine. Does Apple have any plans to enforce this limitation for MacOS in the future? Thank you in advance, Alex

I'm observing a strange behavior based on the nw_connection state. I'm running the client code that exercises the same query code listed below twice - once on nw_connection_state_preparing and the second on nw_connection_state_ready and getting a different source port. nw_path_t path = nw_connection_copy_current_path(m_connection); nw_endpoint_t endpoint = nw_path_copy_effective_local_endpoint(path); uint16_t port = nw_endpoint_get_port(endpoint); Can you please advise why and what is the correct state to get the source port on? The requirement on our side is to know the source port before the remote process accepts the connection.