@Matt
We want to know the identity of the VPN adapter before it's configured with its address. We haven't determined a way to identify which of the UTUN adapters correspond to the VPN adapter because there are multiple of them, each with similar or common attributes.
The connection exists in a network extension that we developed.
Post
Replies
Boosts
Views
Activity
@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
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.
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.
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
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 have filed FB9224983 for iOS, and FB9224605 for macOS.
Thank you.
Hi Matt making matchDomains = nil fixes the issue.
It's out!
Why are you trying to do that?
Hi @eskimo, we are doing this so that we can ship outside of the app store.
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.