Any hints on the error?neagent Signature is valid and has the correct designated requirementneagent Provider is signed with a Developer ID certificateneagent Rejecting app extension provider BUNDLEID because it is signed with a Developer ID certificateSeeing the same thing.

I did everything as described by eskimo one more time, from scratch.I've been trying with the previously existing app and sysex IDs we had by just regenerating the provisioning profiles after modifying app entitlements and it didn't work. Now I tried using freshly generated ones, still seeing the same issue."neagent Rejecting app extension provider REDACTED.macos2.worker because it is signed with a Developer ID certificate"So what I have now is this:1. AppThe code signature contains entitlements. Sandbox entitlements: User-selected files, read access: YES. Allow outgoing network connections: YES. Team identifier: “[TEAM]”. Application groups: “group.[ID]”. Application identifier: “[TEAM].[ID].macos2”. Other entitlements: keychain-access-groups: “[TEAM].keychain.[ID]”. com.apple.developer.system-extension.install: YES. com.apple.developer.networking.networkextension: “packet-tunnel-provider-systemextension”.2. SysexThe code signature contains entitlements. Sandbox entitlements: Allow outgoing network connections: YES. Team identifier: “[TEAM]”. Allow incoming network connections: YES. Application groups: “group.[ID]”. Application identifier: “[TEAM].[ID].macos2.worker”. Other entitlements: keychain-access-groups: “[TEAM].keychain.[ID]”. com.apple.developer.networking.networkextension: “packet-tunnel-provider-systemextension”.Are these entitlements OK?I also verified that the profile has all com.apple.developer.networking.networkextension entitlements listed for both App and Sysex:Profile:<key>Entitlements</key><dict><key>com.apple.developer.networking.networkextension</key><array><string>packet-tunnel-provider-systemextension</string><string>app-proxy-provider-systemextension</string><string>content-filter-provider-systemextension</string><string>dns-proxy-systemextension</string></array>Code signature claimed entitlements:<key>com.apple.developer.networking.networkextension</key><array><string>packet-tunnel-provider-systemextension</string></array>

@Matt: thanks for looking into this. We did some further testing and tried making a local DNS query from the main app process after declining the privacy permission prompt on iOS 14. When we did that, the lib we've used to test it was unable to query the local DNS resolver. It appears that the container app itself is affected by the decision made by the user in the local network privacy prompt, but it does not affect the appex binary. My question is at this point is - is that an expected behaviour or should we assume that this will change in one of the iOS 14 betas?

Thank you. I've filed a bug report under: FB8382522 (iOS 14 network privacy prompt doesn't affect Network Extenstion). Will update the thread when anything new comes in.

(posted at the end of the thread)

We're seeing a similar issue in another app. This appears to be happening on iOS 13 and iOS 14 only. Before we send data, we check the state of NWUDPSession (we expect it to be "ready" and viable): func send(_ datagram: Data) -> Void { 				queuedDatagrams.append(datagram) 				guard let currentSession = session else { 						Log.info("cannot send packet; session does not exist") 						return 				} 				guard currentSession.state == .ready, currentSession.isViable else { 						Log.info("\(address(of: currentSession)) cannot send packet; state: \(currentSession.state), viable: \(currentSession.isViable)") 						return 				} 				currentSession.writeMultipleDatagrams(queuedDatagrams) { [weak self] (error) in 						Log.error(error) 						if let error = error { 								self?.handleError(error) 						} 				} 				queuedDatagrams = [] 		} but even with this check, we're still seeing this crash happen a lot.

A quick update on this - I haven't received any official feedback on radar 37609606.

Hi, I'm seeing the same thing. Is there a way to make sure that the connection is never made directly? So if the proxy is down, the connection is actually dropped instead of being made directly?

I've decided to file a radar (FB9650785) for this one, as it seems to behave incorrectly.

Using NEAppProxyProvider would work only for supervised devices, which is a major limitation. What if the proxy (or proxies) reside on an IP destination(s) that are routed through the tunnel set up using the VPN APIs? So there's an active VPN tunnel and we have cache/filtering proxy on the remote network that should be always used for certain connections.

I've raised this issue in radar 9650785 and I believe this is an incorrect behavior of the OS. @Quinn: I understand your point, but the PAC standard is pretty explicit in these terms, and the current way iOS is handling it is not in line with what is expected by sys admins and also works differently than essentially all other browsers and operating systems I know of. It should be up to the PAC author to decide how the connection behaves when the proxy fails. If I want the request to work at all cost and skip the proxy when it's offline: findProxyForURL() returns "PROXY X.Y.Z; DIRECT". If I want it to fail when X.Y.Z isn't working, findProxyForURL() returns "PROXY X.Y.Z". I don't see why iOS changed the behavior to assume "DIRECT" to be a default fallback for every connection.

Thanks @meaton. And what if an app is using NWParameters.PrivacyContext to require encrypted DNS while Network Extension uses Do53?

@eskimo, @meaton any realistic chance this will get fixed in iOS 16? I've raised this issue through Feedback Assistant almost a year ago (24 Sep 2021) in rdar 9650785, with no success or actually any definitive answer. I still have users affected by this and complaining with no real way to provide a meaningful answer. IMO this doesn't fall far from the VPN issue https://protonvpn.com/blog/apple-ios-vulnerability-disclosure/