Thanks! Here's the bug report: FB9648977.

So when I use a packetHandler as one you gave, it still doesn't get called. I added a logging statement within it and it never fires. Is there a known issue with NEFilterPacketProvider and Parallels VMs? Our packet handlers are getting called within VMWare Fusion VMs. It's the only difference I can think of. Same MDM profiles, same build of my app/binaries, and same macOS installations from scratch.

Have you been able to figure this out? I am running into the same thing. PacketProvider initializes fine, gets startFilter called just fine, but the packetHandler never actually gets called. Nothing in the logs for nesessionmanager, neagent, or sysextd that I can find to see what's going wrong.

I see logs like: nesessionmanager Found 1 (1 active) registrations for com.company.name.Agent (com.apple.networkextension.filter-packet) nesessionmanager NESMFilterSession[AppName:172E3B4C-7A2C-4371-8355-97B653A32390]: Plugin NEFilterPlugin(com.company.appname.App[inactive]) requested a packet filter channel nesessionmanager NESMFilterSession[AppName:172E3B4C-7A2C-4371-8355-97B653A32390] in state NESMFilterSessionStateStarting: plugin NEFilterPlugin(com.company.appname.App[inactive]) status changed to running nesessionmanager <NESMServer: 0x7fcd2850a0f0>: Request to install session: NESMFilterSession[AppName:172E3B4C-7A2C-4371-8355-97B653A32390] (exclusive) nesessionmanager NESMFilterSession[AppName:172E3B4C-7A2C-4371-8355-97B653A32390]: status changed to connected nesessionmanager NESMFilterSession[AppName:172E3B4C-7A2C-4371-8355-97B653A32390]: Updated network agent (active, compulsory, not-user-activiated, not-kernel-activated) Any other log lines I should look for to identify the cause of this problem? By the way, the VM has macOS 11.5 (20G71) on it.

Thank you! I have enabled greater logging and still don't see what could be causing this. I am seeing the init and startFilter happening only once and there are no crash logs generated. scutil --nc list is not showing anything.

One correction: I am seeing the data provider called first and packet provider second in an outbound TCP connection. For inbound, I am actually seeing the packet handler first.