I have a network extension that hosts a NEFilterDataProvider & NETransparentProxyProvider.
One of the use case that this caters to is : Proxy some flows (depending on originating app) while Content filter is also filtering flows based on business logic.
The issue I am running into happens when
- FilterDataProvider sees a flow & responds with
filterDataVerdict(withFilterInbound: false, peekInboundBytes: 0, filterOutbound: true, peekOutboundBytes:1024
to handleNewFlow(_ flow: NEFilterFlow) [wants to peek more bytes on outbound connection before making a decision]
- TransparentProxyProvider sees the flow & responds with
NO
to handleNewFlow(_ flow: NEAppProxyFlow) as it is not interested in in proxying that flow.
When this occurs, we see connection being dropped by kernel. I wanted to know if this is expected behavior.
Logs when this occurs:
2026-02-06 14:57:09.725854-0600 0x17c918f Default 0x0 569 0 com.test.networkextension: (NetworkExtension) [com.apple.networkextension:] [Extension com.test.network]: provider rejected new flow TCP headless_shell[{length = 20, bytes = 0xe69023e655b6065e1a2f94fa508807fa43f6ac8a}] remote: 100.72.0.3:443 interface utun9
2026-02-06 14:57:09.725874-0600 0x17ca166 Debug 0x0 569 0 com.test.networkextension: (NetworkExtension) [com.apple.networkextension:] New flow verdict for D89B5B5D-793C-4940-D955-37BE33F18005:
drop = NO
remediate = NO
needRules = NO
shouldReport = YES
pause = NO
urlAppendString = NO
filterInbound = NO
peekInboundBytes = 0
filterOutbound = YES
peekOutboundBytes = 1024
statisticsReportFrequency = low
2026-02-06 14:57:09.726009-0600 0x17ca24a Default 0x0 569 0 com.test.networkextension: (libnetworkextension.dylib) [com.apple.networkextension:] (410011084): Closing reads (sending SHUT_WR), closed by plugin (flow error: 0)
2026-02-06 14:57:09.726028-0600 0x17ca24a Default 0x0 569 0 com.test.networkextension: (libnetworkextension.dylib) [com.apple.networkextension:] (410011084): Closing writes, sending SHUT_RD
2026-02-06 14:57:09.726040-0600 0x17ca24a Debug 0x0 569 0 com.test.networkextension: (libnetworkextension.dylib) [com.apple.networkextension:] (410011084): Dropping the director
2026-02-06 14:57:09.726047-0600 0x17ca24a Default 0x0 569 0 com.test.networkextension: (libnetworkextension.dylib) [com.apple.networkextension:] (410011084): Destroying, client tx 0, client rx 0, kernel rx 0, kernel tx 0
I wanted to know how neagent is handling this when for a flow, filterDataProvider wants to look at the traffic while transparentProxy is not interested in handling that flow
I wanted to know if this is expected behavior.
Honestly, I’m not sure that matters. What you’re doing is a reasonable composition of existing APIs, and it should work. Given that, I recommend that you file a bug about this.
Make sure to include a sysdiagnose log, one taken shortly after reproducing the problem on a Mac with extra NE logging enabled. See VPN (Network Extension) on our Bug Reporting > Profiles and Logs page.
Please post your bug number, just for the record.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"