Post not yet marked as solved
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?
Post not yet marked as solved
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?
Post not yet marked as solved
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.
Post not yet marked as solved
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?
Post not yet marked as solved
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?
Post not yet marked as solved
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.
Post not yet marked as solved
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
Post not yet marked as solved
Lovely :-( At least it's easy to work around once it's knownOh, and yes, there is definitely a packet loop...
Post not yet marked as solved
Ok, I've managed to get this working. I needed to do a connect() call. There had been some problems with that earlier. Now I'm seeing something really strange... I'm calling read() in instead of recvfrom(), since it's a connected socket, and some data appears to be getting altered in the packet before it's read off the socket.The value of ip_len in the packet on the wire is 0x0054, or 84 bytes, which is correct.The value of ip_len in the *received* packet, that is read off the socket, is 0x4000. I found an old (2008!) discussion on the net about this, and the consensus seemed to be that the length of the ip header (0x0016) had been subtracted and ip_len had then been converted to little-endian, giving us 0x4000. This seems absurd... Why would this be done? Other than that one difference everything looks fine, but it'd be great if I could prevent this from happening at all rather than having to hack around it in IP parsing code...
Post not yet marked as solved
Thanks Quinn.I'll file some suggestions. It's been on ongoing problem for us that the official cross-platform VPN support has been shaky, so hopefully more of these issues will get addressed. At least Catalina's showing progress.I've been pretty happy with both Catalina & iOS 13 (you guys need names for those releases as well :-) so far, even though it's developer beta.Kevin
Yes, it should have been a separate question: https://forums.developer.apple.com/message/364670#364670
Post not yet marked as solved
I checked this with Xcode 11 beta running on Mojave, and that works fine, so it looks like it's a bug in the Catalina beta.
We moved our macOS NKE-based VPN over to Network Extensions a while back. Although Network Extensions offered us less control over the system traffic it also let us have a single code base for the core functionality on iOS & macOS, as well as offering the possibilty of MDM.The talk on Network Extensions for Modern macOS offered us some of the control back. The includeAllNetworks and excludeLocalNetworks flags are great to see. But- Are they only on macOS, or are the Network Extension parts of that talk also applicable to iOS?- Will those Network Extension flags function if the user is running macOS Mojave? - iOS 12? Or are they only going to work on Cataline/iOS13 and later?Users do tend to upgrade their macOS & iOS versions, but corporate customers upgrade slowly, and they're our market.One abillity of NKEs that we lost with Network Extensions was the ability to do an 'Always On' VPN which made sure that all traffic from the system was tunneled. Because we could make the NKE load at boot time there was no user dependency. It doesn't sound like this is going to be possible even with the current changes.The talk referred to Driver Extensions as user-independent, and providing something available at the system level, but not Network Extensions. Is that the case?Kevin
Post not yet marked as solved
FB6142526We're also seeing weird behavior on iOS 13, but I haven't narrowed the cause down yet.Starting the connection from the VPN application does not work, but starting the connection from Settings opens the application for authentication and succeeds.Kevin
