We were told by a customer that Apple told *them* that only App Proxy providers were supported for User Enrollment.Our understanding was that Tunnel Providers would work as long as the VPN was a per-App VPN, not a device-level VPN. I.e., the VPN type was the issue, not the provider type.Is there somewhere that this question is explicitly addressed?

Yes, I was on that thread already. The lack of response was why I opened this thread.I'm assuming that this means there are no known issues with User Enrollment and certificate-based VPN authentication? Or has anyone been using this successfully in the wild?

Hi Quinn. Yes, we have access to that keychain.Our app works fine with MDMs in general, and can access the distributed certificates for per-App VPN configurations that specify certificate based authentication when the device is enrolled normally.The problem is specifically with MDMs doing User Enrollment.I've verified that there are Managed Apple IDs set up on the devices showing the problem.SecItemCopyMatching() shows no matching items in any keychains, but since one feature of User Enrollment is separate keychains I'm wondering whether SecItemCopyMatching() is searching the right keychain in this case.

My current suspicion is that this is related to the separation between the Managed Apple ID resources and the regular Apple ID resources. The stuff I've seen says that there are separate keychains for the two, and since the cert is on the system under the managed profile, and yet not in the keychains we're allowed access to, this seems likely to be related.The problem here is that the system should be handling this for us--we're just a lowly Network Extension provider, and know nothing about Apple IDs of any sort...Has anyone succeeded in running in this configuration? Did you have to do anything special?

We're seeing this same behavior with NETunnelProvider per-App VPN. Everything works well in Device Enrollment, but with User Enrollment the cert isn't found.Looking at the confguration pushed by the MDM we can see the required certificate, but it's not found by SecItemCopyMatching.Did you ever find a solution?

No, the keyboard is definitely visible when it's failing. Oddly I've found that I can call the keys directly and the text does show up, so:app.keys["a"].tap()enters an 'a' andapp.keyboards.buttons["shift"].tap()hits the shift key.This means that I can probably work around it by essentially re-implementing typeText() with my own individual key strokes...But what a pain. The built-in function failing says that there's *something* wrong on the device and I don't know how that could impact other tests.

We're running into another problem related to this that could be a catch-22 with the binding issue.When we send an ICMP packet to 172.20.10.3, it gets sent out the wrong interface. There are two active interfaces on the system:- 10.83.38.96/32- 172.20.10.1/240The packet gets sent out 10.83.38.96, even though it's destined for a local subnet.I'm going to see if bind()-ing a specific address works for this, as opposed to bind()-ing with 0 and letting the system fill in the details. Is there any other way to force the packet to go out the correct interface? I'd expect it to be automatic, but I've got the packet traces to prove that wrong...Kevin