Thank you for your response Matt. Apologies I believe my question may have caused confusion. What happens if the verdict I give in my extension (that contains 2 providers that will give the same answer) disagrees with another third party system extension that's installed on the machine by a different application ?

Alternatively if its not possible to monitor tunnel traffic via PacketProvider, how to do stop tunnel connections in the middle of a flow ?

Hi Matt, thank you for replying however I believe there is a misunderstanding here. I don't have NEPacketTunnelProvider, I only have a NEFilterDataProvider and NEFilterPacketProvider. The tunnel interface that I speak of is created by third party software which is a VPN client. I create a security product which must be able to filter the traffic on this interface. I would like to monitor, and filter the traffic coming through this, already existing, tunnel interface. I only see flows at the beginning of a connection. I never see packets through NEFilterPacketProvider. I would like the ability to stop connection at any point in this tunnel, which is currently not possible because we can only provide a verdict at the beginning of the flow. Best Regards, Rob

I've tested this with my product started both before and after the tunnel is created by the thirdparty VPN and the results are the same in both cases. You only see the start of a connection and so you can't filter existing connections. Is there any other way to filter traffic through tunnels ? If not, this is a major security flaw and should be addressed in a future update.

Apple Engineer, please respond. How can I uninstall a system extension via the command line ? Uninstalling the parent app via the normal method, leaves the system extension lying around, then theres no way to get rid of it!

The concern here is stopping a potentially malicious connection after its already started, one may have to analyze part of the connection before determining whether or not to stop it. This can be done in part by deferring the verdict by a certain number of bytes. But this isn't ideal for potentially long connections that stay open for a time before starting to act suspiciously. Additionally: Please look at https://developer.apple.com/forums/thread/132992

Has this been resolved yet ? I'm experiencing the same problem. It seems completely broken

I've found that completely uninstalling and reinstalling the system extension allows us to provide a flow verdict for existing connections. This is most likely because when installing a new system extension is temporarily causes network outage and requires all existing connections to attempt to reconnect. So in this case "existing" is a misnomer. Uninstalling and re-installing is a no-go since it causes UI popups. In my testing, it seems to only way to provide a verdict for existing connections is to force all existing connections to re-connect by forcing a network outage, thereby allowing us to place a verdict on these "new" connections. Please can you confirm there is no better approach for allowing an NEFilter to provide a verdict on existing connections, when these connects are going down a VPN tunnel ?

For anyone stumbling upon this question, I've found what I believe to be the answer. In the NEFilterDataProvider class, there is a method : @available(macOS 10.15.4, *)   open func update(_ flow: NEFilterSocketFlow, using verdict: NEFilterDataVerdict, for direction: NETrafficDirection) In an initial test demo, this appeared to be what I'm looking for. NEFilterFlow objects from handleNewFlow can be cached and this update method can be used to change a verdict at a later date. No idea when this method was added to the system extension framework SDK as it definitely didn't exist when this problem initially arose. Few other comments: it appears that trying to update a flow thats finished doesn't seem to cause harm I believe all flow operations take place on the extensions main dispatchqueue. If the new flow object doesn't contain the full 5 tuple information, peeking 1 byte will allow the information to become available in the cached NEFilterSocketFlow object.