We use Packet Tunnel under network extension framework on iOS for traffic forwarding. Deployment is per app vpn through MDM.
When there is captive portal network, we clear all include routes(virtual ip is still there) so that end user can authenticate with captive portal network. But to our surprise, traffic is still coming to virtual ip.
Is this expected? Shouldn't traffic go direct when there is no include routes there?
A per-app VPN is… well… per app. If you enable that, the routingMethod property changes from .destinationIP to .sourceApplication. At that point your routing configuration is irrelevant. You get the packets associated with the flows generated by the app.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
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.
But even then we need to handle the flows. right?
Well, yes and no. You either need to handle the flow or the app sees that as a networking failure.
We dont want to handle traffic in captive networks
Can you explain your rationale here?
Most folks deploying per-app VPN are trying to connect managed apps to servers that only exist on the organisation’s intranet. 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.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
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.
Our users can access on public internet too.
So what does your VPN do?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
So what does your VPN do?
Our VPN provide access to internal resources on public internet too
Our VPN provide access to internal resources on public internet too
I’m sorry but I don’t understand that. How can a resource be both “internal” and “on public internet”?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
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.
Hi Quinn
Any update here please?
It's not available on public internet without our custom protocol tunnel.
Well, that means it’s not available on the public Internet, right? I mean, that’s the canonical role of a VPN. It connects to a VPN server on the public Internet and sets up a custom tunnel such that you can access resources on the intranet ‘behind’ the VPN server.
Regardless, imagine that everything worked as you’d like it to work. What behaviour would the app see when the device is on a captive network?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
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.
App would show its in fail open state (no traffic capturing) as network is (captive) not in desired state.
I’m sorry but I don’t understand that.
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? And what would you like to happen?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
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.
In case of Captive network I dont want this traffic come to us at all.
Right. But what I’m asking about this from the app’s perspective. What behaviour do you want the app to see?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
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.
You mean UI?
No, I mean API. When the app calls a networking API, how do you expect it to behave in each case?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"