VPN development resources

Android exposes VPN functionality through VpnService. An application that holds the required permission can establish a virtual network interface, configure the addresses and routes assigned to it, and then read outgoing IP packets from that interface.

Those packets are what the application exchanges with a remote endpoint through whatever tunnel the product uses; packets received back are written into the interface so the platform networking stack delivers them to the original application.

VpnService.Builder is also where app-level routing is expressed: applications can be allowed or disallowed, which is how per-app routing behaviour is implemented on Android.

Apple platforms provide the Network Extension framework. Two paths matter for product work: Personal VPN, which configures the built-in IPsec/IKEv2 support, and Packet Tunnel Provider, which is used for packet-oriented custom protocols.

A packet tunnel provider works through a virtual interface whose settings the provider supplies: virtual IP, included and excluded routes, DNS configuration, and MTU. Those settings are the routing policy.

Per-app VPN contexts are also part of the framework, which makes app-scoped routing a configuration concern rather than something the tunnel itself has to infer.

On Windows the central design decision is split tunnel versus force tunnel. In a force tunnel arrangement, traffic is directed through the VPN interface; in a split tunnel arrangement only the routes the profile defines go through it, and the rest stays on the physical interface.

Because this is expressed as routing policy and profile configuration, the same product can behave very differently depending on how routes are declared — which is why it is worth deciding explicitly rather than inheriting a default.

Full tunnel carries all eligible traffic through the VPN interface. It is simpler to reason about and easier to support, because there is one answer to the question of where traffic went.

Split tunnel carries only selected traffic and leaves the rest on the physical interface. It needs a clear rule set, a defined fallback when no rule matches, and consistent behaviour across platforms whose APIs express those rules differently.

The data plane is the tunnel itself: the path the packets take. The control plane is everything that decides what the client should do — authentication, account and device state, configuration delivery, the directory of available regions and resources, and plan state.

Keeping the two separate matters in product engineering. Control-plane changes such as adding a region or rolling out a configuration should not require a client release, and a client release should not require a control-plane migration.

A connectivity product is judged by how it behaves when the network misbehaves. Connection state and error reporting, and diagnostics that a support conversation can actually use, are therefore product features rather than internal tooling.

On the delivery side, each platform has its own distribution path, so an automated build and release pipeline plus cross-platform compatibility testing is what keeps a multi-platform product shippable at the same time on every target.