Interesting. Alas, I can’t help you with that. There’s a whole bunch of things that you can do with low-level services on macOS that just aren’t supported as APIs by Apple. PF is one example of this. PF is not suitable for use in third-party products because there’s no way to arbitrate the PF rules between the various folks who might be using PF (the system and N third-party products).
The only supported way to build a firewall right now is with an NKE, and that has its own problems. Recent macOS releases have tightly restricted KEXT development in general, and on the NKE front in particular we’ve given notice that we intend to deprecate that technology because it’s incompatible with our user-space networking stack.
IMPORTANT While we’ve announced a general plan here (see WWDC 2017 Session 707 Advances in Networking, Part 1), we’ve not announced a specific timeline.
Ultimately we would like to migrate folks using NKEs to NetworkExtension providers. Feedback since this announcement has made it very clear that the current NE provider architecture is missing important functionality, and this migration can’t happen until that’s resolved.
Such a resolution is in The Future™, and thus I can’t talk about the specifics. The one thing I can say is that, if you’re building a product that integrates with the lower levels of macOS’s networking stack, you should file an enhancement request for a way to achieve your goals using the NE provider architecture. Make sure to include a detailed description of your requirements, so that we can integrate those into our plans.
Please post your bug number, just for the record.
Right now all I can say is that change is coming, and that you should attempt to build isolation layers within your product so that you can more easily adapt to that change.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"