IKEv2 VPNs: MOBIKE and Wi-Fi-to-mobile switching

IKEv2 and IPsec do different jobs

IKEv2 is the part that sets up and manages a secure connection: it negotiates keys and establishes the security associations used by the tunnel. IPsec protects the data travelling through that tunnel. For the encrypted data path, IPsec commonly uses ESP, or Encapsulating Security Payload.

That distinction matters when you configure a device. A service may describe its option as “IKEv2”, “IPsec” or “IKEv2/IPsec”; these usually refer to the same VPN setup, not three separate protocols. IKEv2 is specified in RFC 7296 and is a standards-based choice with built-in client support on several major operating systems.

IKEv2 uses a single initial exchange of four messages. You do not need to manage that exchange yourself when using a VPN app or a device’s network settings, but the standards-based design can make IKEv2 a practical option for a laptop or phone that already has a compatible client.

On this page, the table is filtered to VPN plans that support IKEv2/IPsec. Check each plan’s setup instructions before choosing: you may need a server address, account details and a certificate or other authentication information, even if you do not install a separate VPN app.

Native clients: useful, with an Android caveat

IKEv2 is a good fit if you want to configure a connection in your operating system rather than rely on a provider’s app. Native support is available on Windows, iOS and macOS, though the exact menus and profile options differ. On Windows 11, for example, you can add an IKEv2 VPN profile in the built-in VPN settings.

iPhones and iPads can use IKEv2 through their built-in VPN settings, as can Macs. That can be convenient if you want one configuration managed by the operating system. Follow the provider’s instructions closely, especially for the server hostname, authentication method and certificate; a profile with a wrong server name may fail even when the account details are correct.

Android support depends on the device and operating-system version. Native support details vary, so check the VPN provider’s instructions and your phone’s settings instead of assuming a particular Android version will work. If the built-in client does not offer the required options, a dedicated client such as the strongSwan app may be needed.

Linux users commonly configure IKEv2 with strongSwan; LibreSwan is another implementation. On routers, support depends on the firmware and its VPN packages. If you plan to use a router, confirm that it can act as the right kind of IKEv2 client or server, and that you can install and maintain the required certificates.

Network switching depends on MOBIKE

IKEv2 is designed to work with mobility, but a working hand-off is not guaranteed by IKEv2 alone. MOBIKE, defined in RFC 4555, allows the IP addresses associated with an IKE and tunnel-mode IPsec connection to change without rebuilding the entire connection. That is what can help keep a VPN session running as your phone moves from Wi-Fi to 4G or 5G.

Both ends matter. The client and the VPN server or router must support MOBIKE in a way that works for that connection. If the gateway does not support it, or its implementation cannot handle the direction in which the connection was initiated, your tunnel may drop and reconnect when your public IP address changes. That can interrupt a call or pause an upload.

Before relying on hand-offs, check the provider’s documentation for explicit MOBIKE support, or ask its support team how its IKEv2 service behaves when a device changes networks. For a self-managed router, check the firmware documentation and test with your own phone. Some implementations have limited support; the word “IKEv2” in a settings page does not prove that roaming will work.

• Connect on Wi-Fi, then switch Wi-Fi off while using mobile data.
• Check whether the VPN stays connected, reconnects quickly or needs you to start it again.
• Repeat the test in the reverse direction and, if possible, during a call or download.

MOBIKE also has protocol limits. For example, replies need to return through the address and port from which a request arrived, and some address or NAT arrangements can prevent a successful update. A clean test on your own network is more useful than assuming that a client’s mobility feature will work with every gateway.

Choose authentication carefully

IKEv2 can use certificates, pre-shared keys or username-and-password methods, depending on the client and server. Where available, certificate-based authentication is a robust choice. EAP methods can also provide mutual authentication without requiring a certificate on every client, but the server must support the method and give you clear setup details.

A pre-shared key is a shared secret entered by the client and server. It may be convenient for a small setup, but avoid a short or reused passphrase, particularly if the same key is distributed across many devices. Weak IKEv1 pre-shared keys have documented offline-guessing weaknesses. That is a reason to treat shared secrets carefully, not proof that every IKEv2 implementation has the same exposure.

For certificates, check that the certificate’s Subject Alternative Name includes the fully qualified domain name (FQDN) that you enter as the VPN server. A mismatch can cause mobile clients to reject the connection, sometimes without a helpful error. Do not make a habit of overriding certificate warnings: verify the hostname and certificate details with the service or administrator instead.

Ports, firewalls and restrictive networks

IKEv2 normally uses UDP port 500 to establish the connection. When NAT traversal is needed, IKE and ESP traffic can be carried over UDP port 4500. Without NAT traversal, ESP travels as IP protocol 50, which is not a TCP or UDP port. A firewall must allow the traffic required by the connection.

This explains why a setup can work at home but fail on a hotel or office network. The network may block UDP traffic, UDP 4500 or ESP, or impose rules that prevent the tunnel from staying up. If the VPN will not connect, try a different network and check the provider’s troubleshooting steps before changing security settings on your device.

IKEv2 is not a guarantee of bypassing network restrictions. If a network blocks the traffic it needs, choose a VPN protocol that the network allows. OpenVPN over TCP port 443 may be an option if your service supports it, but check the plan’s protocol list and configuration instructions first.

How to choose from this filtered list

The table below contains only plans marked as supporting IKEv2/IPsec. Use its plan details to check the devices you want to connect, the available authentication method and any setup limits. If you need uninterrupted movement between Wi-Fi and mobile data, treat documented MOBIKE support as a separate requirement rather than assuming every listed plan provides it.

Across all 22 plans from 22 providers in our full VPN comparison, prices start at $0.83; those figures describe the full comparison, not this IKEv2-filtered list. We last synced prices on 31 October 2026. Compare the filtered plans’ own terms and setup guidance before making a choice, since protocol availability alone does not tell you how roaming or authentication is implemented.

IKEv2 is especially practical when you want to use a built-in client on an iPhone, Mac or Windows laptop, or connect through a compatible router. It is less suitable if the network you use blocks UDP or ESP, or if you cannot confirm that the gateway supports MOBIKE and you depend on uninterrupted hand-offs.

For a home router, verify both ends of the connection: the router’s IKEv2 implementation and the VPN server’s. If you run your own server on OpenWrt, strongSwan is a common route, but configuration and certificate management are your responsibility. Test reconnection from each network you use regularly before routing all your household traffic through it.