Function stopped working with entitlements: com.apple.developer.networking.networkextension for packet-tunnel-provider-systemextension

Question

Created Aug ’21

Replies 3

Boosts 0

Participants 2

I use a NetworkExtension(packet-tunnel) and its container app to implement VPN on macOS. It's works well in my develop computer. But when I use Developer ID certification to distribute this container app, I have the following error.

Provisioning profile "***" doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement.

I followed an answer on this forum discussion, adding -systemextension to the entitlement. https://developer.apple.com/forums/thread/133296 After that, I could successfully build, archive, upload (for notary service approved), and export. But the VPN app is not working. As far as I see, it is not the reason of VPN app function itself. It is related with environmental & system side issue. The network extension seems to be stopped working.

Here are the entitlements for Release mode of container app and network extension.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.developer.networking.networkextension</key>
	<array>
		<string>packet-tunnel-provider-systemextension</string>
	</array>
	<key>com.apple.security.app-sandbox</key>
	<true/>
	<key>com.apple.security.application-groups</key>
	<array>
		<string>$(DEVELOPMENT_TEAM).group.$(APP_ID_MACOS)</string>
	</array>
	<key>com.apple.security.files.user-selected.read-write</key>
	<true/>
	<key>com.apple.security.network.client</key>
	<true/>
	<key>com.apple.security.network.server</key>
	<true/>
</dict>
</plist>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.developer.networking.networkextension</key>
	<array>
		<string>packet-tunnel-provider-systemextension</string>
	</array>
	<key>com.apple.security.app-sandbox</key>
	<true/>
	<key>com.apple.security.application-groups</key>
	<array>
		<string>$(DEVELOPMENT_TEAM).group.$(APP_ID_MACOS)</string>
	</array>
	<key>com.apple.security.network.client</key>
	<true/>
	<key>com.apple.security.network.server</key>
	<true/>
</dict>
</plist>

Boost

Answer 1

Systems Engineer OP

Apple

Aug ’21

As far as I see, it is not the reason of VPN app function itself. It is related with environmental & system side issue. The network extension seems to be stopped working.

Okay, are there any logs or extra information to provide insight into why you think this or why the Network System Extension might be failing? Also, what version of macOS is this on?

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 2

danny_lin OP

Aug ’21

I tested it on Catalina and BigSur. Here are the log files. The first log file is about successful connection testing on developer computer using Apple Developer certification running on Xcode. The second log file is about the failed connection testing on any macOS devices. Those were distributed using Developer ID certification through Archive, Upload (notary service approved), Export steps.

SkyFort Apple Developer app log

SkyFort Developer ID distributed app log

0

Answer 3

Systems Engineer OP

Apple

Aug ’21

Here is the logs from your Development signed application:

2021-08-10 13:03:28.862009: [APP] startActivation: Success
2021-08-10 13:03:28.927310: [APP] Tunnel 'SkyFort2233' connection status changed to 'connecting'
2021-08-10 13:03:28.928263: [APP] Tunnel 'SkyFort2233' connection status changed to 'connecting'
2021-08-10 13:03:28.988935: [NET] App version: 1.0.13 (24)
2021-08-10 13:03:28.989374: [NET] Starting tunnel from the app
2021-08-10 13:03:29.103552: [NET] DNS64: mapped 144.202.2.45 to itself.
2021-08-10 13:03:29.104695: [NET] Attaching to interface
2021-08-10 13:03:29.106523: [NET] Routine: decryption worker 2 - started
2021-08-10 13:03:29.106633: [NET] Routine: handshake worker 1 - started
2021-08-10 13:03:29.106654: [NET] Routine: handshake worker 2 - started
2021-08-10 13:03:29.106657: [NET] Routine: decryption worker 1 - started
2021-08-10 13:03:29.106676: [NET] Routine: decryption worker 3 - started
2021-08-10 13:03:29.106709: [NET] UAPI: Updating private key
2021-08-10 13:03:29.106714: [NET] Routine: encryption worker 1 - started
2021-08-10 13:03:29.106716: [NET] Routine: decryption worker 6 - started

I do not exactly know the routines performed in your tunnel, but if I had to guess it looks like your are setting up your secure transport above.

Now, here is the logs from the Developer ID signed case:

2021-08-10 12:58:02.398497: [APP] App version: 1.0.0 (002)
2021-08-10 12:58:09.618261: [APP] startActivation: Entering (tunnel: SkyFort2233)
2021-08-10 12:58:09.618901: [APP] startActivation: Starting tunnel
2021-08-10 12:58:09.619013: [APP] startActivation: Will reload tunnel and then try to start it.
2021-08-10 12:58:09.686175: [APP] Tunnel 'SkyFort2233' connection status changed to 'disconnected'
2021-08-10 12:58:09.690151: [APP] startActivation: Tunnel reloaded, invoking startActivation
2021-08-10 12:58:09.690208: [APP] startActivation: Entering (tunnel: SkyFort2233)
2021-08-10 12:58:09.690647: [APP] startActivation: Starting tunnel
2021-08-10 12:58:09.690990: [APP] startActivation: Success
2021-08-10 12:58:09.694699: [APP] Tunnel 'SkyFort2233' connection status changed to 'connecting'
2021-08-10 12:58:10.205270: [APP] Tunnel 'SkyFort2233' connection status changed to 'disconnected'

So, there is a disconnect in your tunnel being able to create the secure transport step, which looks like it's happening at the start of your tunnel, as expected. Typically, if there are signing problems they will present themselves on start of your container app, so the signing of your container app is not the issue here. If you do have signing issues, it could be in how your Packet Tunnel System Extension is signed. I would check your logs again for any sysexd or code signature logs during this time. If you cannot find any issues with your code signing of your Network System Extension then it's time to look at your application logic.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0