I missed that post, 187 of 280 thanks for pointing it out. What is unclear is if there were specific technical reasons why they chose not to use pf and instead use Network Extension. Perhaps it has something to do with: TN3165: Packet Filter is not API | Apple Developer Documentation which expressly tells VPN provider to use it instead.
Maybe pf will disappear in future versions of MacOS who knows, then we can remove all the VPN providers because they’ll have to use Network Extension.
Apple Developer Documentation
TN3165: Packet Filter is not API | Apple Developer Documentation
Plan your migration from Packet Filter to Network Extension.
Moving off packet filter
If you’re currently shipping a product based on PF, plan to migrate it to a supported API. In most cases that means creating a Network Extension provider:
- If your product is a VPN, create either a packet tunnel or app proxy provider.
- If your product looks at, and potentially blocks, TCP connections or UDP flows, create a content filter provider.
- If your product looks at, and potentially blocks, network packets, create a packet filter provider.
- If your product wants to intercept DNS queries, create a DNS proxy provider.
- If none of these providers meet your specific needs, create a transparent proxy provider.
For information about packaging and OS version constraints, see TN3134: Network Extension provider deployment.
If your product needs to do something that’s not covered by one of these providers, use Feedback Assistant to let us know what’s missing.