OpenVPN or IKEv2: four checks before you pick a protocol

The choice between OpenVPN and IKEv2 usually gets argued as a protocol question, and that framing wastes the decision. What decides it is whether your server and your devices support the same complete profile, and whether that profile survives the way you move between networks. The two stacks do not translate into each other: an OVPN file is not an IKEv2 profile with different syntax. Four checks, run in order, answer the question faster than any feature table.

A missing client ends the discussion

Windows and macOS ship an IKEv2 client, so an IKEv2 profile costs nothing extra to deploy there and inherits the provisioning options the operating system already exposes. OpenVPN on the same machines means a third-party client to install, update and support, and that client has to accept every option the profile uses. Count the platforms you must cover before comparing anything else, because a platform with no working client is not a comparison point at all.

On Windows, one command lists the profiles that already exist and shows what type each one is. The name it prints is the name the later checks use.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

A prompt to install a client is the real answer for the OpenVPN column on those platforms, and it is a deployment task rather than a protocol limitation. Neither arrangement removes trust checks, identity verification or maintenance. Ask how profiles are distributed, how credentials are renewed and how a lost device is removed before you commit. A simple install can still hide a recovery process nobody wants to run at the weekend.

Mobility is a joint setting, not a protocol promise

IKEv2 can use MOBIKE when both ends support and enable it, which lets a client keep its tunnel while its address changes. RFC 4555 defines the extension, and the conditional wording matters: a server that ignores the capability renegotiates instead. The result can look identical for a file transfer and very different for a live call.

Test the transition you actually care about, with something running that you can watch. Keep ping -t <internal-host> going on Windows, or plain ping elsewhere, then switch from Wi-Fi to cellular and watch for gaps. A MOBIKE failure appears as a full re-authentication in the client log rather than a quiet address update. What you are measuring is whether the tunnel survives the change, not whether the protocol advertises support.

OpenVPN clients reconnect according to their own platform behaviour and profile timers, so the same test can produce a different shape of interruption. Compare the event that matters to your users rather than the label on the protocol.

Credentials belong to the service, not the stack

Certificates and other login arrangements belong to the service that terminates the connection. A password prompt in one client says nothing about compatibility with another, and a profile that works against a different gateway says nothing about this one. Keep the server identity rules intact while comparing the two stacks. Switching protocols before you have identified the failure usually produces a second incompatible profile.

Inspect the credential the client will present before blaming either protocol, because an expired or wrongly issued certificate fails the same way on both. The output below shows subject, issuer and validity dates without reading the private key.

openssl x509 -in client.crt -noout -subject -issuer -dates

For a company connection, use the method the company publishes and stop treating the comparison as an experiment. If you are comparing the two for yourself, first check whether both options end at one gateway, since that single detail decides how much of your result is about the protocol. A rejection that names the credential is a credential problem, and no amount of protocol switching will repair it.

Check what the tunnel actually routes

After connecting, confirm that the route you need exists and that names resolve. A profile that exists for internal resources may leave ordinary browsing on the local path by design, and that is a policy decision rather than a fault. What matters is whether the destinations your team uses are reachable through the tunnel.

Two commands cover the route and the name lookup on Windows. The Linux equivalents are ip route show default and resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

A tunnel that comes up and routes nothing useful is a common outcome when a profile was copied between services, and a generic connectivity test will not show it because the interface is up. Test the resource your users open first, not a public address that any path can reach. If the name resolves to a public address while the route points into the tunnel, the DNS answer and the route belong to different decisions and both need fixing.

Weigh maintenance after the checks

Neither protocol is more maintainable in the abstract. Maintenance depends on who operates the gateway, how profiles reach devices and how quickly a lost device loses access. A simple endpoint client can sit in front of a harder server to run, and the reverse also happens. Ask which of the two your team can keep working after the person who built it leaves.

Pick whichever supported connection covers the work, then test it against the access you actually need rather than against a feature list. Record which gateway each option terminates on, because two different gateways make the comparison about routes as much as about protocols. Repeat the four checks on the device you will actually carry, and keep the profile that passes on it.