Android leaks keepalive packets past its VPN kill switch

Android’s VPN lockdown does not stop all traffic from leaving the device outside the tunnel. The “Block connections without VPN” setting, paired with an always-on VPN profile, is treated as a hard egress boundary by the people who enable it. It is not one. Under this configuration the device can still emit NAT-T keepalive packets to a remote endpoint on UDP 4500 while lockdown is active. Traffic leaves. The boundary is partial.

The control being relied on is specific. Always-on VPN plus block-without-VPN is the kill switch. The stated purpose is that no packet reaches the network unless it passes through the VPN interface. Users configure it precisely because they do not want the platform making exceptions. The keepalive offload behaviour contradicts that guarantee. A device presenting as fully tunneled continues to send identifiable packets to a destination that is not the VPN server, on a path the lockdown rule does not cover.

Scope discipline matters here. What is confirmed is that keepalive packets on the NAT-T path egress outside the tunnel while lockdown is enabled. Whether this path can carry payload beyond keepalive traffic is not confirmed. The number of packets, their cadence over time, and the total volume are not stated and are treated as not confirmed. None of that changes the position. A boundary that leaks any packet outside the tunnel is not an absolute boundary, regardless of how small the leak is.

With always-on VPN and block-without-VPN both enabled, the observable behaviour is that the device still transmits NAT-T keepalive packets to a remote endpoint. On the wire this appears as UDP traffic on port 4500 leaving the physical network interface rather than the tunnel interface, while lockdown is reported as active. The packets are visible to anything positioned on the local network or upstream: the source address, the destination, and the timing of the keepalive.

These packets originate from the hardware keepalive offload path exposed through the SocketKeepalive mechanism. Once a keepalive is registered, it is emitted by the lower networking stack without the application path having to be active. The observable result is that packets continue to egress even in the state where the lockdown control is supposed to be blocking connections that do not use the VPN. The egress does not wait on the tunnel being up.

The failure is the egress itself, not any single field inside the packet. The lockdown filter permits the keepalive to leave. So a device that looks fully contained still reaches an endpoint outside the VPN, and the metadata that reaches the network is real: source IP, destination, and a repeating signal that marks the device as present and reachable. Whether anything beyond that metadata leaves through this path is not confirmed. What is confirmed is that the packet leaves at all.

The reason this happens is that the enforcement point sits above the path that carries the keepalive. Lockdown applies its filtering at the operating system’s network layer, where application sockets are evaluated against the block-without-VPN rule. The keepalive offload operates below that layer. The packets are generated at a point the lockdown filter does not sit in front of, so the rule that is supposed to block non-VPN egress is never consulted for them.

This is a boundary placed at the wrong layer relative to where the traffic originates. The VPN interface is defined as the only permitted egress. The offload creates a second egress path, and the lockdown rule does not govern that path. Identity of the exit point was assumed to be singular. It is not. A control that assumes one chokepoint does not enforce anything on a path that does not pass through that chokepoint.

The underlying assumption that broke is a trust relationship. Lockdown trusts that every packet flows through the layer where it enforces. The offload path was built for power efficiency, to keep a connection alive without waking the full networking stack, and by design it runs where that enforcement does not reach. If the offload path can send a packet outside the tunnel while lockdown is on, then lockdown is not enforcing on that path. On that path it is not a control. It is a setting that is true for the traffic it can see and false for the traffic it cannot.

The bypass works because VPN lockdown is a single-layer guarantee applied to a device that has more than one path to the network. Lockdown evaluates application sockets at the operating system’s network layer and blocks any that do not route through the VPN interface. The keepalive offload does not present as an application socket at that layer. It is registered once through the SocketKeepalive mechanism and then serviced by the lower networking stack, which emits the packet on the physical interface without the enforcement layer being consulted. The control does what it was built to do on the traffic it can see. The traffic it cannot see leaves anyway.

What this undermines is the guarantee, not the feature. A user enables block-without-VPN to convert egress into an absolute statement: nothing leaves outside the tunnel. The offload path converts that absolute into a conditional. Lockdown holds for socket-layer traffic and does not hold for offload-path traffic. The device reports lockdown active while UDP 4500 egresses to a destination that is not the VPN server. The reported state and the wire state disagree. That disagreement is the exposure. A user reading the device’s own status has no signal that a second path is open.

This is why on-device verification is not enough. The packet originates below the layer where lockdown enforces, so the device’s own view of its egress is incomplete at the one point that matters. The lockdown indicator reflects the enforcement layer, and the enforcement layer never processed the keepalive. Any check that reads state from that layer inherits the same blind spot. The only position that observes the packet is one that watches the wire: the local network segment the device sits on, or a point upstream of it. Verification has to move off the device to the vantage where the packet is actually visible.

The pattern is enforcement placement relative to where traffic originates. A control governs only the paths that pass through the point where it enforces. When traffic can originate below that point or beside it, the control’s scope ends there, whatever the control is called. Lockdown is called a kill switch, which implies total egress control. Its actual scope is the socket layer. The distance between the name and the scope is the entire vulnerability.

The same structure appears wherever a lower or hardware-assisted path emits traffic independent of the software control plane. Hardware keepalive offload exists to hold a connection open without waking the full stack, which means it is built to run where the application path does not. Enforcement sits at one layer, emission happens at another, and the two never meet. The label on the control does not extend its reach into a path it was never positioned in front of. A filter placed at the socket layer does not filter packets that are produced beneath it.

The operator lesson follows from the mechanism, not from anything outside it. Any control that claims total coverage while enforcing at a single layer has a scope boundary, and that boundary is the layer itself. A packet that can be produced outside that layer is outside the control by construction. This is not a configuration defect and it is not a bug for the user to patch. It is the control operating within its real scope while being trusted for a scope it never had.

VPN lockdown on Android is not an absolute egress boundary. It is a socket-layer filter that permits NAT-T keepalive packets to leave on UDP 4500 while it is active. Treat it as partial containment. If your threat model requires that no identifiable packet reaches a non-VPN destination, this configuration does not meet it. The lockdown controls enforce at the socket layer and the offload runs below that layer, so the controls do not reach the path that leaks. Relying on the setting as a hard boundary is relying on a control for coverage it does not provide.

What must now be true is that you verify egress from off the device rather than from the device’s own status. Position a capture on the local network segment or upstream of the handset. Enable the always-on VPN profile and block-without-VPN. Filter for UDP 4500 leaving to any destination that is not your VPN server address. If a keepalive reaches a non-VPN endpoint while lockdown reports active, the boundary is confirmed partial for that device and that build. Do not accept the on-device lockdown indicator as proof. It reads the layer that never saw the packet.

Hold the scope. Whether this path can carry anything beyond keepalive traffic is not confirmed. The cadence, packet count, and total volume are not stated and are not confirmed. Do not wait for those answers before acting. What is confirmed is that metadata leaves: source address, destination, and a repeating signal that marks the device as present and reachable. For anyone whose risk is being observed on a network, tied to a destination, or shown as reachable at a given moment, that metadata is the exposure. Plan for the path being open. If a system allows the packet to leave, it leaves.

---

#ad Contains an affiliate link.