IKEv2 vs OpenVPN: key exchange, built-in support and ports

Two different kinds of thing

RFC 7296, the IETF document that defines IKEv2, describes IKE in its abstract as a component of IPsec, used for mutual authentication and for establishing and maintaining Security Associations (SAs). The document is dated October 2014 and carries the Internet Standard label. It obsoletes RFC 5996, and its header lists six later documents that update it: RFC 8983, 9370, 7427, 7670, 8247 and 9827. Windscribe, a VPN vendor, puts it in plainer terms: IKEv2 is a key exchange that sets up the secure connection, and IPsec does the encryption. That is the vendor’s wording, and it fits the RFC’s description of IKE as a part of IPsec.

OpenVPN is described differently. Its 2.4 manual says it supports encryption with a pre-shared static key or, in SSL/TLS mode, with certificates on both sides; that it is designed for the TUN/TAP virtual network interface; and that it aims to offer many of the key features of IPsec with a lighter footprint. In TLS mode, the manual says, a control channel and a data channel are multiplexed over a single TCP or UDP port: OpenVPN starts a TLS session on the control channel and uses it to exchange the cipher and HMAC keys that protect the data channel. So one project carries its own key exchange and its own encrypted channel, while Windscribe describes IKEv2 handing the encryption to IPsec.

One caution on versions. The manual we read is headed 2.4, and the same site lists 2.5 and 2.6 manuals too, so its statements are the 2.4 ones and not necessarily those of the current release. Our pages on OpenVPN and on WireGuard vs OpenVPN cover the project itself and the third protocol people ask about.

Where each one is built in

Apple’s VPN overview for device deployment, published on 4 November 2025, lists IKEv2 first among the protocols that iOS, iPadOS, macOS, tvOS, visionOS and watchOS support. It says IKEv2 is supported with IPv4 and IPv6, with shared-secret, certificate, EAP-TLS and EAP-MSCHAPv2 authentication, and with extra features that include MOBIKE, IKE fragmentation, server redirect and split tunnel. Devices with iOS 26 and later can be configured to perform additional key exchanges with ML-KEM, which Apple labels quantum security. L2TP over IPsec and Cisco IPsec are listed too, on a narrower set of systems. OpenVPN is not in the list. Apple says that where an organization supports the listed protocols, extra network configuration and third-party apps are not required, and that its Network Extension framework lets developers build custom VPN solutions, with several providers offering companion apps.

For IKEv2 on iOS, iPadOS and visionOS, Apple describes Always On VPN: once its configuration is installed, the tunnel activates with no user interaction and stays activated, including across restarts, until the configuration is uninstalled. On devices with cellular, there is one tunnel for each active IP interface, one for cellular and one for Wi-Fi, and Apple says that if the tunnels are not up, all IP traffic is dropped. Apple Watch pairing is not supported with it. A separate Apple page on IKEv2 settings, published on 24 October 2022, describes a NAT keepalive that offloads the sending of keepalives to hardware while the device sleeps, with a minimum interval of 20 seconds. Our page on turning on a VPN on an iPhone covers the Settings paths.

Microsoft’s VPNv2 CSP page lists the allowed values of NativeProtocolType: PPTP, L2TP, IKEv2, Automatic, SSTP and ProtocolList. OpenVPN is not among them, and the page does not say why. For a device tunnel the page says to use IKEv2 only, while a user tunnel allows any value. ProtocolList takes inbox VPN protocols in priority order, up to four for a user tunnel, and for a device tunnel Microsoft recommends IKEv2 in NativeProtocolType instead. A device tunnel profile that is turned on becomes an always-on profile, does not need a user to be present or logged in, and cannot coexist with another device tunnel on the same machine. The sample native profile on Microsoft’s profile page uses IKEv2.

On Android, the Ikev2VpnProfile class is described as a configuration for the platform setup of IKEv2/IPsec VPNs. Together with VpnManager, it lets apps provision such VPNs without the VPN app running constantly in the background. A companion page explains that platform VPNs use the operating system’s own implementations of the control plane (authentication and key negotiation) and the data plane (per-packet encryption), while VpnService-based VPNs must implement both in each app. The class page marks it as added in API level 30, and we did not check support by Android version beyond that. Our page on setting up a VPN on Android covers the screens.

When the network changes

MOBIKE is defined in RFC 4555, a Standards Track document from June 2006 by P. Eronen. Its abstract says the protocol allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change, so a mobile VPN client can keep the connection with the gateway active while moving from one address to another, and a multihomed host can move traffic to another interface if the one in use stops working. The RFC gives the reason: creating new SAs may require user interaction, such as entering a code from a token card, and often involves expensive calculations and many round-trips. MOBIKE updates only the outer addresses of the IPsec SAs; the addresses and traffic selectors inside the tunnel stay as they were, so the movement can be mostly invisible to applications.

The RFC also lists limits. It supports only tunnel mode IPsec SAs. It provides no rendezvous mechanism for both ends moving at the same time, so it suits cases where at least one endpoint has a relatively stable address that can be found through DNS. Only one pair of addresses is used for an SA at a time, and it does not work over address pairs with one-way connectivity.

strongSwan’s documentation for version 6.1 says it implements MOBIKE by watching interfaces, addresses and routes; when the configuration changes, it looks for a better path and, if needed, changes it with an UPDATE_SA_ADDRESS message. MOBIKE is on by default and can be turned off per connection with mobike = no in swanctl.conf. The page adds that, as initiator with MOBIKE on, strongSwan moves to UDP port 4500 from the IKE_INTERMEDIATE or IKE_AUTH request even when no NAT was detected, because MOBIKE support is only exchanged in IKE_AUTH, and it advises opening UDP 4500 on any firewalls involved.

The strongSwan app for Android shows what happens without MOBIKE. Its release notes for version 2.5.4, dated 27 February 2025, list a fix for reauthentication and roaming between networks when MOBIKE is not available, made by disabling make-before-break reauthentication, and another note mentions break-before-make reauthentication used if MOBIKE is not supported. The app’s known limitations include that only IKEv2 is supported. Read together, the notes say that in that app a network change without MOBIKE goes through reauthentication.

The OpenVPN 2.4 manual does not mention MOBIKE. It describes --float, which lets the remote peer change its IP address or port: if packets arrive from a new address and pass all authentication tests, the new address takes control of the session. It also describes --ping-restart, which triggers a restart after a set number of seconds without a ping or other packet from the remote; in client mode it defaults to 120 seconds until the client pulls a replacement value from the server. Windscribe says OpenVPN is more likely to give a short pause while it reconnects, and the page we read does not give a measurement for that, so it stays the vendor’s claim. Rublon, also a vendor, says IKEv2 can re-establish a connection after a loss of signal thanks to MOBIKE. For what a kill switch is for, see our page on the kill switch.

Ports and firewalls

RFC 7296 says IKE normally listens and sends on UDP port 500, though messages may also be received on UDP port 4500 with a slightly different format. For NAT traversal, it says an initiator that finds the addresses do not match must tunnel all future IKE and ESP packets for that IKE SA over UDP port 4500. strongSwan adds the MOBIKE case above, where 4500 is used even without a NAT. The vendors differ in detail: Rublon’s page says IKEv2 usually runs on UDP port 500 and does not mention 4500, while Windscribe says typically UDP 500 and 4500.

OpenVPN’s manual says the default protocol is UDP, with tcp-client and tcp-server as alternatives, and the default port is 1194, the IANA assignment, in use since version 2.0-beta17; earlier versions used 5000. One manual example defines connection profiles that try UDP on port 1194 first, then TCP on port 443, then TCP on 443 through an HTTP proxy. The Access Server FAQ says OpenVPN uses UDP for optimal performance and supports TCP for compatibility with restrictive networks, and that TCP 443 is used to mimic HTTPS traffic, which is often allowed through firewalls. Rublon agrees that OpenVPN can use any port, naming 1194 for UDP and 443 for TCP, and says port 443 is harder to block without also blocking HTTPS traffic.

Windscribe goes further. It says IKEv2 relies on specific ports, mainly UDP 500 and 4500, that its packet structure is easy to recognize even off the default port, and that raw OpenVPN on port 443 is a fallback and not a guarantee against fingerprinting. Those are the vendor’s claims about restrictive networks, and the IETF and OpenVPN pages we read do not address them. The pages do agree on the direction: the IKEv2 pages name UDP 500 (and 4500), and the OpenVPN pages describe a choice of port and transport; only Windscribe calls the IKEv2 ports fixed.

Speed and overhead, without a league table

The OpenVPN 2.4 manual says OpenVPN is designed to operate optimally over UDP and that TCP is provided for situations where UDP cannot be used. It adds that TCP will tend to be somewhat less efficient and less robust than UDP over unreliable or congested networks, and it links an article on the problems of tunneling IP over TCP. It also names cases where TCP may be advantageous, such as tunneling non-IP or application-level UDP protocols. The Access Server FAQ entry on TCP meltdown says it occurs when TCP traffic is tunneled over TCP, causing performance issues through overcompensating retransmissions, and advises UDP for the tunnel.

Data Channel Offload, or DCO, is documented by OpenVPN for Access Server. Without it, packets arrive in the kernel, are copied to user space, encrypted or decrypted there and copied back; with it, packets are processed directly in the kernel, which the page says reduces memory copies and context switching and lowers CPU overhead. Access Server 3.2.0 and newer use the ovpn module aligned with Linux kernel 6.16 and newer, and the page says that for best performance both the server and the VPN clients should use DCO. That page is about Access Server, and we do not carry it over to every OpenVPN client. Windscribe says DCO arrived with OpenVPN 2.6 in 2023 and moves data-channel encryption into the kernel on Linux and Windows.

On which one is faster, the pages we read that answer are vendors. Rublon says IKEv2 is generally faster than OpenVPN. Windscribe says IKEv2 is still faster on average but not by much since DCO, and that hardware, server distance and routing matter more than the protocol; the page itself says Windscribe offers both. The IETF, Apple, Microsoft and Android pages we read do not compare the two on speed, and we took no measurement, so this page gives no table of winners. For what speed costs when a router runs the tunnel, see our VPN router page.

What we did not use

This page sets side by side what the documents say. The Rublon and Windscribe blog posts were read in full and are used only for statements we attribute to them. The Microsoft pages do not say why OpenVPN is missing from NativeProtocolType, and the Android Developers pages we read cover the Ikev2VpnProfile class from API level 30, not later changes. The Apple, Microsoft, Android, strongSwan and OpenVPN pages each describe their own product, so the page reports them side by side without ranking them.