FB15556338 Filed

Another update:- I made sure tunnel2 is behind tunnel1 in plugins folder as they are sorted alphabetically. But still I see on certain occasion tunnel 2 is launched despite second in plugins folder.

Hi Quinn Any way we can push Apple from our side? It's pending for quite some time. OR at least can we have some public documentation from Apple about this behaviour?

Hi Quinn getaddrinfo, at least on Apple platforms, goes out of its way to return IP addresses in a reasonable order. Does this mean there is no option on Apple platforms to change order of getaddrinfo results? Is there any source code for getaddrinfo implementation we can take a look?

Any luck on this? I also want to push an unlisted app through intune.

What behaviour do you want the app to see? You mean UI? If yes, App will show that it's on a captive network and not processing traffic.We show captive network notifications to end user. Extension perspective I already shared that we dont want traffic coming to vpn in that case.

Consider an app that makes an outgoing TCP connection run by either BSD Sockets or NWConnection. What do you see happen with that TCP connection currently? Connection fails with error network unreachable. Sometimes time out too And what would you like to happen? In case of Captive network I dont want this traffic come to us at all. Reason being that captive redirections does not happen to captive authentication page if traffic is handled by vpn.

What behaviour would the app see when the device is on a captive network? App would show its in fail open state(no traffic capturing) as network is(captive) not in desired state.

Hi Quinn Any update here please?

How can a resource be both “internal” and “on public internet”? It's not available on public internet without our custom protocol tunnel. Its internal resource but available through our tunnel.

So what does your VPN do? Our VPN provide access to internal resources on public internet too

Can you explain your rationale here? We cannot connect to VPN servers in Captive network. So , no point in capturing the traffic. Instead we prefer to fail open so that end user can authenticate with Captive without any issue(caused by vpn settings on the device) Most folks deploying per-app VPN are trying to connect managed apps to servers that only exist on the organisation’s intranet. Not in our case. Our users can access on public internet too. If the device is on a captive network there’s no way to do that, and so it’s correct to fail the flow.Sending the traffic directly, in plaintext, seems like a weird choice. On Captive network, we want to get out of the picture so that end user can be navigated to Captive page and they can authenticate. If we handle that traffic some captive networks dont redirect to Captive Page.

Thanks Quinn At that point your routing configuration is irrelevant. You get the packets associated with the flows generated by the app. But even then we need to handle the flows. right? We dont want to handle traffic in captive networks Is there any way we can enforce traffic to go direct over physical interface in per app vpn in scenarios like captive networks? Like we can do over enterprise vpn by removing all include routes.

Are you perhaps thinking of PayloadType? Yes, I am talking about PayloadType AFAIK there isn’t a separate payload type for this, but I’m basically working off the same docs as you are here. Thanks for confirming this.

It works, in which case you know that your provider is working in general and this is a configuration problem specific to per-app mode. Yes, it works on supervised device. Its not working for per-app mode FYI I am using Apple Sample App "SimpleTunnel" for testing