@DTS Engineer we are manually importing it using keychain access, taking care to make sure that it's imported into the System keychain.

Did the DR actually change? What does it look like if you dump the DR of your old appex and the DR of your new sysex? I believe this clued me in on the reason. The issue is that when we create a configuration profile in our app, it takes the designated requirement of that app. We would then install a TestFlight build, and that would have a different designated requirement. Since it's signed by the TestFlight signing cert vs the App Store signing cert. I was able to verify that a configuration profile created in a TestFlight app extension build would work on a TestFlight system extension build, since their DRs would be the same for both. But a profile created on an AppStore build would not work on a TestFlight build. I obviously can't verify from AppStore -> AppStore easily. But I believe that the fact that this works TestFlight -> TestFlight proves the hypothesis.

Why are you trying to do that? Hi @eskimo, we are doing this so that we can ship outside of the app store.

It's out!

Hi Matt making matchDomains = nil fixes the issue.

I have filed FB9224983 for iOS, and FB9224605 for macOS. Thank you.

Hi Matt, When we disable DoH/DoT configurations, our Packet Tunnel gets DNS traffic, so we believe this to be a bug. I can file it as such, let me know if you need anything else. Thanks

I am developing for macOS and iOS. I've seen this occur on both iOS 14, and macOS 10.15, and macOS 11. I've filed FB9091299

We are running a Packet Tunnel Provider. The users of our application are running NSURL requests in their applications. We have no control over those NSURL requests. We are seeing their previously working applications breaking due to this.

When running the same tests on an iOS 12 device and any macOS device, we do not see the problem described. We see it on iOS 13 and iOS 14. So I'm wondering if this behavior change is intended, or if there is a bug that should be filed.

@Matt Eaton We are not changing the IP address on the interface. I've attatched a more detailed log of what we are seeing. console log of failure - https://developer.apple.com/forums/content/attachment/5856dfcd-686d-4c15-93a4-724199d06f1f