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

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 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?

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?

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.

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?

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?

main.m is the same also. Calls NSApplicationMain(argc,argv) to kick things off.

Once upon a time, in the long ago when the app was just coming into being, a plist value was set that told the OS that it was an agent app. It shouldn’t normally be visible, and we didn’t want a dock icon for it. Eons later, when there were bugs filed about the lack of a dock item, the problem was fixed not by removing that plist value but by adding code that forced a dock icon, and forced the app to the foreground. A side effect of this code was that the menus were not usable until the app went to the background and came back the to foreground. So basically removing the LSUIElement value and all the extra code above fixed the issue. I think that whoever added the code was unaware that it was the plist value causing the problem in the first place.

Yes, I've seen the list. No, there's no feedback #. Back at the beginning of the beta I read that some things would continue to be enabled during the beta, so I didn't think it odd that the KEXT still loaded. We don't use a lot of calls to the sock_* interfaces--we're basically an interface filter--but for example we do use: sock_socket(PF_SYSTEM, SOCK_RAW, SYSPROTO_EVENT, . . .) to open a system control socket. Works fine. Expected behavior if not supported: KEXT fails to load. Actual behavior: KEXT loads & runs. I'll see about filing feedback from one of the beta systems.

Thanks Quinn. That looks like what I needed. I'll check it out.

The Feedback number is FB8895731

There appear to be some problems with that. Is there any sample code that demonstrates the transition from URLSessionDataTask to URLSessionStreamTask with reads & writes afterwards? What I'm seeing is that in     func urlSession(_ session: URLSession,                     dataTask: URLSessionDataTask,                     didBecome streamTask: URLSessionStreamTask) everything looks fine. Stream task is suspended initially. I call resume() on the stream task. That seems to be Ok. But, when I try to call func readData(ofMinLength minBytes: Int, 		maxLength maxBytes: Int, 			timeout: TimeInterval, completionHandler: @escaping (Data?, Bool, Error?) -> Void) on that task I immediately see a call to func urlSession(_ session: URLSession, readClosedFor streamTask: URLSessionStreamTask) In that delegate call I see that the task is now in the NSURLSessionTaskStateRunning state, with nothing pending, but according to the docs it looks like that call means no more reads can be done. Similarly when I call: func write(_ data: Data, 	 timeout: TimeInterval, completionHandler: @escaping (Error?) -> Void) it never returns, and no data is written. Looking at network traces on the peer, everything looks normal--it just doesn't see any more traffic.

Well, I still don't know why I wasn't seeing the cookies properly in the response I was tracing, but it looks like my case is Ok at this point. There was also a redirect issue, where the URLSession was following redirects because I wasn't returning the right value from     func urlSession(_ session: URLSession,                     task: URLSessionTask,                     willPerformHTTPRedirection response: HTTPURLResponse,                     newRequest request: URLRequest, completionHandler: @escaping (URLRequest?) -> Void) When I broke in that function to see what was going on I saw all of the cookies... The "Set-Cookie" value was an array of header values, and when I blocked the redirects I started seeing the correctly formatted Set-Cookie in the HTTPURLResponse. So although I don't know why the behavior was wrong in the first case I was seeing, the case I need it OK.

Hi Matt. I see the initial steps (manually allowing app to run), but once it's approved we can see that the binary is loaded The class initializer for PacketTunnelProvider runs. There's log output from the class initializer, so we know that the VPN extension has been loaded successfully The entry point (startTunnelWithOptions:completionHandler:) is never called The VPN extension exits There's no crash log I'd think that a signing problem would result in the binary not being loaded, right?