I have check my.app PlugIns dir have PacketTunnel.appex, why nesessionmanager can't load it ?
The most common cause for problems like this is that you haven’t get your entitlements set correctly. I recommend you start by double checking your entitlements using the steps I outlined in Debugging Entitlement Issues.
IMPORTANT The requirement for special entitlements means that Network Extension framework providers are only supported within Mac App Store apps.
1 Xcode build and run, console show this message , need hange Xcode/DerivedData directory setting?
2 run app don't whith Xcode debuger,console message show INSTALLED extension ,but add vpn config fail, How to debug this?
3 trace nesessionmanager process, and found read config file fail,which process write this files?
meet same issue, how it solved at last ? many thanks!
I'm having a similar problem, but only with profiles created by Apple Configurator. I don't think its an entitlements issue because profiles created by my app work fine. Also my Configurator profile works fine on other Macs (all running Sierra 10.12.1).
It looks to me like the OS can't locate my extension in the app. In the past I've seen similar problems with PluginKit where I had to register the path to my extension, but I've tried that here and don't see PluginKit compaining about anything.
This used to work on this machine. Can't remember when I last tested this - I'm pretty sure it was since upgrading to Sierra.
Is there a way to inform nesessionmanager as to where to find my extension?
I’ve helped a bunch of developers with problems like this. One day I’ll get to write this up as a coherent whole but, until that happens, here’s a bunch of random suggestions.
Confirm the problem on a fresh computer. Network Extension depends on Foundation’s NSExtensions which depends on PlugInKit which depends on Launch Services. Launch Services can get confused, which undermines the whole process. That happens occasionally in the field but it’s much more common on development machines, where you’re building and rebuilding your app many times.
So, before heading down the debugging rabbit hole, you should test if this problem is showing up on just your machine. A good way to do that is to install the app on a fresh machine. I use a virtual machine (VM) for this. I take a snapshot just after setting up the VM and then I restore that snapshot and test.
Make sure your deployment targets are set consistently. It’s easy to set up your project such the .appex fails to inherit the deployment target from the project as a whole. You should check this by looking at the built binary, and specifically the LSMinimumSystemVersion property in the Info.plist of both the .app and nested .appex.
Check the entitlements. Again, do this in the built binary of both the .app and the .appex nested within that. For more info, see Debugging Entitlement Issues.
Check that the plug-in is known to PlugInKit. Run pluginkit -m to see that it’s included in the list. If not, run pluginkit -a to add it.
If you’re creating configurations programmatically, check that you’ve set providerBundleIdentifier correctly.
Likewise, if you’re installing configuration profiles, check that the VPNSubType property is set correctly.
If you’re working with per-app VPN via a configuration profile, be aware that this supports both app proxy and packet tunnel flavours. Make sure you set the ProviderType key in the right place. See this post for an import gotcha.
There’s one more gotcha to odd to this list.
If you’re installing a configuration profile on macOS, you must set the ProviderBundleIdentifier property. It’s not optional on that platform.
Also, the documentation for this property is currently wrong (r. 30672175). It states that it should be at the top level of the com.apple.vpn.managed payload, that is, as a peer of VPNType, VPNSubType, and friends. This is not correct. In reality, ProviderBundleIdentifier should be inside the nested VPN dictionary, that is, as a peer of RemoteAddress.
I was helping another developer with this issue today and came across a few other tidbits.
Network Extension providers on the Mac must opt in to the App Sandbox (this is in contrast to iOS, where everything is sandboxed all the time). You should check that your app and provider have the com.apple.security.app-sandbox entitlement. Also, if your provider wants to access the network (which seems likely :-) it will also need the com.apple.security.network.client entitlement.
If you don’t have the App Sandbox entitlement, your provider will fail to register.
You can fix this problem using the App Sandbox slice of the Capabilities editor in Xcode.
Enter “com.apple.PlugInKit” into the search field and hit return.
Pull down the menu associated with the token and select Subsystem.
Enable info and debug messages (Action > Include Info Messages, Action > Include Debug Messages).
Repeat your pluginkit operation and marvel at all the information you see in Console.