Thanks for the update but this creates a lot of friction for our users, and have them support the previous options. They can't just go around removing previously supported options without any warnings or heads-up.

Created https://feedbackassistant.apple.com/feedback/24067672 ticket.

Thanks for the update. However, this change creates significant friction for our users. Could you please restore support for the previously available options? Removing supported functionality without advance notice or a clear deprecation period will be highly disruptive.

This issue is still not fixed. Even in Golden Gate Beta 4 we are seeing this issue.

Link for apple feedback ticket: https://feedbackassistant.apple.com/feedback/21810618

Attached the files to https://feedbackassistant.apple.com/feedback/21464147 ticket.

Yes, the issue is reproducible only in Mac OS Tahoe. We noticed that this leads to a crash issue when we stop and start the transparent proxy extension. The RC for the crash is, startProxy completionHandler being called multiple times for the same PID. We tried adding the flag check and NSLock/Dispatch Queue to not to call the startProxy completionHandler for second time, but this leads to some unpredictable behaviour like entire network functionality is broken until restarting of the machine. If we call the completionHandler for startProxy all the time, it leads to an over-resume of an object crash when startProxy is being called more than once. Collected the crash report, sysdiagnose for further investigation. (Unable to attach the files, attachments is not enabled for these files) How can I send the crash report and sysdiagnose zip files?

Finally we could resolve the VPN connectivity issue when we insert the order key to VPN/TransparentProxy payload in MDM. Noticed that for some of the distribution profile, if we provide other than network extension identifier in ProviderDesignatedRequirement field, then it fails to establish the VPN connection without logging any error. ProviderDesignatedRequirement identifier "com.digitalguardian.webproxy" and anchor apple generic

Whenever it does not establishes the VPN connection, in the system log we could see below errors: 25-09-11 14:08:00.750332+0530 0x4e84 Default 0x239eb 144 0 nesessionmanager: (NetworkExtension) [com.apple.networkextension:] Signature check failed: code failed to satisfy specified code requirement(s) 2025-09-11 14:08:00.750427+0530 0x4d6b Activity 0x23e36 122 0 mds: (CoreDuetContext) Duet: ClientContext objectForContextualKeyPath: 2025-09-11 14:08:00.750452+0530 0x4a64 Info 0x23f85 134 0 opendirectoryd: [com.apple.opendirectoryd:session] ODNodeCreateWithNameAndOptions completed 2025-09-11 14:08:00.750452+0530 0x4e84 Error 0x239eb 144 0 nesessionmanager: [com.apple.networkextension:] Rejecting agent com.digitalguardian.networkextensionmanager because it does not satisfy the code signature requirements 2025-09-11 14:08:00.750454+0530 0x4e84 Error 0x239eb 144 0 nesessionmanager: [com.apple.networkextension:] Failed to launch com.digitalguardian.networkextensionmanager 2025-09-11 14:08:00.750510+0530 0x4bab Activity 0x23f86 143 0 locationd: (CFOpenDirectory) Querying records from directories 2025-09-11 14:08:00.750577+0530 0x4e84 Default 0x239eb 144 0 nesessionmanager: [com.apple.networkextension:] NESMTransparentProxySession[Primary Tunnel:DGWebProxy:CEF7FD7D-3106-4F46-A8CF-4DEDB64CF7D9:(null)] in state NESMVPNSessionStateStarting: plugin NEFlowDivertPlugin(com.digitalguardian.networkextensionmanager[inactive]) started with PID 0 error Error Domain=NEAgentErrorDomain Code=2 "(null)" 2025-09-11 14:08:00.750580+0530 0x4e84 Info 0x239eb 144 0 nesessionmanager: [com.apple.networkextension:] Setting last stop reason to 6 One of the other team in our company is also having transparent proxy extension. With their binary it establishes the VPN connection when they deploy the product with MDM profile having Transparent Proxy payload with order, with distribution profile which was created using one of their old developer ID. When they deploy the agent with their new distribution profile created using new developer ID it fails to establish the VPN connection. When we compared both the distribution profiles, we could see two additional entries (‘url-filter-provider’ and ‘hotspot-provider’) for entitlement ‘com.apple.developer.networking.networkextension. Will this extra attributes under com.apple.developer.networking.networkextension entitlement can cause this issue? Attached the screenshots for reference.

Yes, with the same binary and distribution provisioning profile, if I just remove the order key attribute from com.apple.vpn.managed payload, it establishes the VPN tunnel. As the order field is not there its not retaining the order when it receives the network traffic.

I created a test app and with test provisioning profiles, it establishes the VPN connection. It retains the order we specified in the Transparent Proxy payload in MDM profile. The issue we are facing is, if we use distribution provisioning profile with order key attribute in Transparent Proxy payload in MDM profile, the transparent proxy extension is not establishing the VPN connection. From the application log and system logs we could not get any valuable errors. connection.startVPNTunnel() API does not return any error and in UI the VPN tunnel is in disabled state. When we retrieve the connection status it's coming as disconnected. Any idea why VPN tunnel is not establishing if we use Transparent Proxy payload with order key attribute in MDM profile and use Mac Distribution Provisioning profiles?

If I install the Transparent Proxy or VPN payload MDM profile first and then on installing the container app, the extension already installed via MDM gets mapped with the extension from container app. (Note that when we install the MDM profile, it will just add the extension under Network -> VPN & Filters section in a disabled state and when we install the container app, if the profile payload matches then the same extension gets activated and enabled) Attaching the MDM profile which is created using iMazing Profile Editor having 2 Transparent Proxy payloads without order field. (DGWebProxy and Forcepoint F1E) DGWebProxy_Forcepoint_TP_iMazing_WithoutOrder If I add the Order key value pairs to the same profile, while installing the container app, the extension does not get mapped and it will show 2 entries for each extension under VPN & Filters section. Also the added order field in the MDM profile is not having any impact in receiving the network traffic. Also while installing the extension, save to preferences fails with "Error in saving TP configuration in updateOnDemandRule permission denied" error.

Followed the above mentioned steps with 2 different transparent proxy extensions. Here are the observations: The System Preferences -> Network -> VPN & Filters section shows duplicate entries for both the extensions. One from the container app and another from the MDM profile. Order field in the MDM installed extension is not having any impact in receiving the traffic. Could you please provide the working example of MDM payload with order?

This is how our container app is installed at Customer: Customer triggers a script via MDM that installs a pkg, and the pkg-installer copies the container app over to /Applications/. Is this the right way to install the container app? If this is NOT the right way to install the container app, could you please explain how it should be installed instead?

So if customer needs more than one transparent proxy and if they configure all the transparent proxies using MDM with transparent proxy payload with order, it should work right? In a single profile they need to create multiple Transparent proxy payloads right? The current problem is, if we add the Order attribute to the VPN/TransparentProxy payload, while installing the extension, the save to preferences fails with "Error in saving TP configuration in updateOnDemandRule permission denied" error. Dynamically in the code, once we load the preferences, we need to call saveToPreferences, other wise the VPN tunnel won't be established. How can we fix this issue?