This page provides guidelines for network operators to ensure that consumer and
enterprise virtual private network (VPN) apps provide a good end-user experience
in their networks. Android provides the
VpnManager
class for developers to create VPN solutions, which are used by consumers and
enterprises to encrypt their communications or route them to different networks.
We recommend network operators follow these guidelines:
- Support IPv6 Encapsulating Security Payload (ESP) protocol (Next Header 50) packets on your network, ensuring this traffic has comparable performance to user datagram protocol (UDP) or transmission control protocol (TCP) connections. ESP sessions should be allowed inbound to devices, or set to very high timeouts, and forwarded at line rate.
- Set network address translation (NAT) and stateful firewall timeouts that are a minimum of 600 seconds for UDP connections on port 4500 to ensure VPN solutions can maintain reliable connectivity without incurring excessive power costs.
Support IPv6 ESP protocol (Next Header 50) packets
Encapsulating Security Payload (ESP) is the packet format defined as part of the Internet Protocol Security (IPSec) set of protocols to encrypt and authenticate packets in a VPN solution. The Android OS implements this standard security protocol in its built-in VPN solution.
On IPv6-capable networks, ESP packets are carried directly in IPv6 packets with a Next Header field of 50. If a network doesn’t properly support these types of packets, it can cause a lack of connectivity for VPN solutions that aim to use this protocol without further encapsulation of the packets. The network might drop these packets due to firewall configuration. Or ESP packets might hit slow paths on the network, with severely degraded throughput performance compared to TCP or UDP connections.
The Internet Engineering Task Force (IETF) recommends allowing IPsec through firewalls used by consumer internet access services. For example, see RFC 6092 section 3.2.4. ESP packets can be safely allowed through firewalls in both directions because if a device receives an ESP packet that isn't part of an existing security association, the device drops the packet. As a result, the device doesn't need to send keepalive packets to maintain VPN connectivity, which saves battery life. We recommend that networks either allow ESP packets to devices at all times, or time out ESP sessions only after long periods of inactivity (for example, 30 minutes).
We recommend network operators support ESP protocol packets (IPv6 packets with a Next Header of 50) on their networks and forward those packets in hardware at line rate. This ensures VPN solutions don't encounter connectivity issues and provide performance comparable to UDP or TCP connections.
Set sufficient NAT and stateful firewall timeouts
To maintain connection reliability, a VPN solution needs to maintain a long-lived connection to the VPN server that provides outbound and inbound connectivity (for example, to receive incoming push notifications, chat messages, and audio/video calls). Most IPsec VPN apps use ESP encapsulated in IPv4 UDP packets with destination port 4500, as described in RFC 3948.
To maintain this connection, the device needs to periodically send packets to the server. These packets must be sent at a higher frequency than the NAT and firewall timeouts imposed by the network operator. Frequent keepalives are power intensive on the client side, and have a major impact on battery life. They also generate substantial signaling traffic on the network, even if the device is otherwise idle.
We recommend that operators raise NAT and stateful firewall timeouts high enough to avoid battery impact. The recommended timeout for IPsec UDP encapsulation (port 4500) is 600 seconds or greater.
In mobile networks, UDP NAT timeouts are often kept low because IPv4 address scarcity imposes high port reuse factors. However, when a VPN is established, the device network doesn't need to support long-lived TCP connections, such as those used to deliver inbound notifications. So the number of long-lived connections that the network needs to support is the same or lower when a VPN is running compared to when a VPN isn't running.