It was the first. I found out that one of the entitlement files wasn't updating correctly when I made changes to the Project's Signing and Capabilities. I added the value manually to the entitlement file directly and relaunched Xcode. I got a bit father but now the error is Failed to register with the XPC network extensions: Couldn’t communicate with a helper application. Again this is seemingly happening at the first step before it actually replaces the network extension with the activation request.

I verified that the bundle identifiers are correct at run time. I commented out everything in my AppDelegate and added a ViewController.swift that matches the Simple Firewall. Without me clicking on one of the buttons I immediately get the error: Failed to register with the XPC network extensions: Couldn’t communicate with a helper application. This is happening in the Network Extension when the app calls to register itself at the line: newConnection.remoteObjectProxyWithErrorHandler() I checked the newConnection variable between the two programs. Nothing looked out of the ordinary other than Apple's SimpleFirewall project has an internal _state of 4 where as my project's internal _state is 0.

It seems like I'm getting the right value from the NEMachServiceName. I noticed that if I use the NEMachServiceName from the Simple Firewall program, $(TeamIdentifierPrefix)com.example.apple-samplecode.SimpleFirewall.SimpleFirewallExtension and the app group to $(TeamIdentifierPrefix)com.example.apple-samplecode.SimpleFirewall everything works. The bundle ids remain something else entirely. It feels like it's reusing the connection from the SimpleFirewall though. Is there some guideline what the values for the AppGroup and NEMachServiceName need to be? I know both need to be prefixed with $(TeamIdentifierPrefix) but beyond that I thought it could be anything. If I do something like $(TeamIdentifierPrefix)bundleid.containerapp.myextension it doesn't seem to work (where containerapp and myextension are the Target names). Also I renamed my Network Extension's Target Name, I can't find any instance of the old name but could that potentially cause issues?

I think we figured out the issue. By removing the App Sandbox capability from both the container app and the network extension, everything is working. The SimpleFirewall example has the App Sandbox capability yet still works, why is that?

So we tried those specific bundle ids, group ids, and NEMachServiceName. When we used those it worked successfully. Thanks for that! When we try to use the existing ones we created with matching permissions it didn't work. Is there an obvious reason these won't work that I'm missing? Contain App Bundle ID: com.example.foo.bar.dev Container App Group: $(TeamIdentifierPrefix)com.example.foo.bar.dev Network Extension Bundle ID: com.example.foo.bar.dev3 Network Extension App Group: $(TeamIdentifierPrefix)com.example.foo.bar.dev Network Extension Info.plist NEMachServiceName: com.example.foo.bar.dev3 I suspect there might be a few reasons this isn't working. Maybe we cannot use numbers or at least end with one. Maybe there's too many reverse URL segments. Maybe the network extension needs to have the container app as an effective prefix (or at least this is a best practice).

We were also looking at the documentation for Packet Tunnel Provider but that seems to be specific to IPSec tunnel mode. Is there support for IPSec transport mode? Our thoughts were that with the filter, we could delay a packet selectively if it matched certain criteria, setup an IPSec connection in transport mode, then allow the packet. We ran into an issue where our delayed packet would pick up right where it left off and traverse without an ESP frame. That's when we came up with the idea to send a copy of that one packet back through the stack.

The easiest way to allow traffic to continue to it's destination is to allow the system to handle the packet and not even to touch NEPacketTunnelFlow. I can see how to do that with networks/routes. How would you do that based on the packet type? Let's say I always want to allow ICMP packets through unmodified.

For example, if the IP Header indicates ICMP, then take that NEPacket and send it over the wire to your packet tunnel server. Is there a way to do this in Transport mode IPsec without a full blown VPN solution? We want a client to client solution without a gateway and without a packet tunnel server. I have been able to parse NEPacket and identify if it is an ICMP protocol but at that point it's already being handled by the tunnel interface. Since there's no option to resume the packet as is, I'm lost as to how to "send it over the wire".