We are developing a consumer digital wellbeing app and are evaluating an optional feature that deliberately slows network traffic when explicitly enabled by the user.
The proposed architecture is:
NEPacketTunnelProvider device wide traffic no MDM or per-app VPN no remote VPN server packet processing/forwarding performed locally on device no application layer inspection no traffic profiling or advertising use no network data uploaded to our servers bounded latency/bandwidth shaping only user can disable it immediately
The goal is user controlled “intentional bandwidth” rather than security, privacy filtering, circumvention, or remote VPN access.
I’d like to clarify:
Is NEPacketTunnelProvider an appropriate public API for this kind of local device wide bandwidth pacing? Is it supported to consume packets via packetFlow, process/forward them locally, and send them to the public Internet without a remote VPN endpoint? Is intentional bandwidth/latency shaping considered an acceptable use of the Network Extension entitlement? Would this still be treated as a “VPN service” for App Review purposes even though no traffic is routed through a remote VPN service? If so, would the organization-enrollment requirement for VPN apps apply? Is there another public API Apple recommends for this use case?
I understand that the App Review questions may ultimately need to be answered by App Review rather than the forums. My main goal here is to validate whether this is a supported NetworkExtension architecture before investing in the packet processing implementation.
Is it supported to consume packets … send them to the public Internet without a remote VPN endpoint
No. Packet tunnel providers are intended to be used for VPN and, by definition, that involves a VPN server. While it may be possible to do what you’re trying to do [1], DTS doesn’t support that. See TN3120 Expected use cases for Network Extension packet tunnel providers.
Note This is a DTS policy. I don’t work for App Review and can’t comment on their policies.
I suspect you’re on iOS, in which case your alternative options are limited. If you happen to be targeting macOS, you can do this sort of thing using a transparent proxy. TN3134 Network Extension provider deployment has more info about the distribution limitations for the various NE provider types.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] I’ve seen deeply approaches used:
- Re-inject packets via the packet flow object — I’ve seen folks do this, but I’ve never been able to get it to work myself O-:
- Re-assemble flows — You can run a TCP/IP stack in your provider, use that to turn the TCP packets back into a TCP streams (and likewise for UDP) and then use standard TCP APIs to proxy those flows.
- Deeply unsupported stuff — You’ll find code on the ’net that rummages around in the internals of
NEPacketTunnelFlow. Don’t do that. Such code has broken in the past and it wouldn’t surprise me if it broke again in the future.
