We have a VPN app built using PacketTunnelProvider and support per-app VPN on iOS. We're currently investigating an issue specific to per-app VPN configurations that use split tunneling, where some URLs are routed through the VPN tunnel while others are intended to go directly.
Tunneled traffic works as expected. However, for direct traffic, we observe intermittent failures where the browser does not receive an ACK, leading to repeated retransmissions and eventual page load failures.
This issue appears only in per-app VPN scenarios, and we've reproduced it across multiple MDM solutions (Intune, CEM) and multiple managed browsers. It's intermittent but frequently reproducible with common public URLs routed directly.
Key observations:
- writePackets returns true, confirming the VPN app writes packets to the TUN interface.
- Despite that, the browser often fails to acknowledge receipt (no ACK), suggesting it may not receive the packet at all.
- We suspect a possible packet loop, where packets written to TUN are immediately read back by the app. However, due to the intermittent nature of the issue, this is hard to confirm. A consistent loop would likely result in persistent failures, not sporadic ones.
We are attaching: A Wireshark summary - highlighting the missing ACK and retransmission pattern. As we cannot attach the xlsx file or a zip file, we have took the screenshots of the files names as image1, image2, image3, image4 and image5 in sequence.
Dails on the iOS device and MDM environment. NETunnelProviderProtocol configuration that reproduces the issue
Any guidance on how to further debug this, particularly on confirming packet delivery to the browser and identifying potential loops would be greatly appreciated.
Thank you.
e
t
This sounds exactly like the issue discussed in this thread. Is the OP there, akshit_ak, one of your colleagues?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"