WireGuard is the better default when a VPN app offers both, because it is simpler than IKEv2, with nothing to negotiate, while IKEv2 is the better choice for the VPN client built into Windows, Apple devices or Android, company logins, or rules requiring FIPS-approved cryptography.
Settings may list IKEv2 as “IKEv2” or “IKEv2/IPsec”: IKEv2 sets up the connection and its keys, and IPsec protects the data, while WireGuard does both jobs in one protocol. WireGuard and IKEv2 can both keep the connection when a phone changes network.
TL;DR
- What differs: WireGuard uses one fixed set of algorithms, connects with a one-round-trip handshake and identifies each device by its key. IKEv2 is an IETF standard that negotiates algorithms, comes built into Windows, Apple devices and Android 11 and later, and supports certificate and username logins.
- Which to pick: In a VPN app that offers both, choose WireGuard. Choose IKEv2 for the device’s built-in VPN client when you do not want to install an app, for a company VPN with certificate or username logins, for Always On VPN on a managed iPhone or iPad, or for rules that require FIPS-approved cryptography.
- Speed: Neither protocol is faster on every device; the faster one depends on the device’s processor and on where each protocol runs on that platform. WireGuard’s handshake takes one round trip, while IKEv2’s normally takes two.
- Switching networks and battery: WireGuard and IKEv2 both keep the connection when a phone moves between Wi-Fi and mobile data; IKEv2 does so when both the app and the server support MOBIKE, its mobility extension. No published measurement compares their battery use; what each protocol sends while idle depends on its settings and on NAT.
- Security: Published attacks on encryption or authentication have needed weak or outdated setups or flawed implementations, rather than breaking either design. WireGuard has no algorithm choices to get wrong; IKEv2’s security depends on its settings, so avoid IKEv1, old algorithms and weak shared keys.
- If neither connects: WireGuard and IKEv2 use different ports, so a network can block one and not the other. Try the other protocol first; if both fail, try OpenVPN over TCP port 443 or an obfuscated protocol.
WireGuard vs IKEv2 at a glance
WireGuard and IKEv2 differ most in where each comes built in, how users log in, and what each does on a network that blocks VPNs.
| WireGuard | IKEv2 (with IPsec) | |
|---|---|---|
| Defined by | Its own project’s paper and documentation; no RFC defines it | An IETF standard, RFC 7296 |
| Algorithms | One fixed set, no negotiation | Negotiated; every implementation supports a common set |
| Connection setup | A handshake of one round trip | Normally two round trips; four or more with a username login (EAP) |
| After a few quiet minutes | A new one-round-trip handshake before data, because WireGuard refuses session keys once they are three minutes old | Keys normally last an hour or more, so data resumes without a new exchange |
| Switching networks | The server learns the new address from the next valid packet | MOBIKE moves the connection when the client chooses to move; both ends must support it |
| When idle | Silent by default | Behind NAT, a small keepalive after a quiet spell; liveness checks at intervals each implementation sets |
| Built into | The Linux kernel; an app on Windows, macOS, iOS and Android | Windows, Apple devices, Android 11 and later |
| Logins | A key pair per device | Certificates, a shared key, or a username login (EAP) |
| Network | UDP only, on any port | UDP 500 and 4500, with data as ESP or inside UDP 4500; TCP only if both ends have it configured |
Which should you use: WireGuard or IKEv2?
Use WireGuard in a VPN app unless one of these situations applies:
- A VPN app that offers both, on a phone or computer: choose WireGuard, because it is simpler than IKEv2 and has no algorithms to negotiate.
- iPhone, iPad and Mac: WireGuard and IKEv2 both work, and both can connect automatically on networks you choose. When a company needs Always On VPN, which keeps all of a managed iPhone’s or iPad’s traffic inside the VPN, choose IKEv2: that setting is IKEv2-only. At least one VPN service has removed IKEv2 from its iPhone and iPad app (as of October 2026), so your app may not offer it.
- Android: use WireGuard in a VPN app. Android 11 and later also have a built-in IKEv2 client, which does not need a VPN app running in the background; from Android 12, new built-in profiles can only be IKEv2 types.
- Windows without installing anything: use IKEv2, which Windows has built in; WireGuard needs its app.
- Linux and routers: WireGuard has been part of the Linux kernel since version 5.6, and router firmware such as OpenWrt can add it as a package. IKEv2 on Linux needs a separate key-exchange program such as strongSwan or Libreswan. The guides to setting up a VPN on Linux and on a router cover the steps.
- Moving between Wi-Fi and mobile data: WireGuard and IKEv2 both keep the tunnel running, IKEv2 when both ends support MOBIKE, so switching networks alone is no reason to change protocol.
- A network that blocks both: use OpenVPN over TCP port 443 or an obfuscated protocol instead of either.
- A company VPN: use whichever protocol the company’s gateway runs. IKEv2 supports certificate and username logins and fits setups that require FIPS-approved cryptography.
- Your own server: choose IKEv2 when devices must connect without an app; otherwise either protocol works.
- A connection that keeps dropping or will not start: try the other protocol. WireGuard and IKEv2 use different ports, so a network can block one and not the other, and IKEv2 can also fail on networks that drop fragmented packets.
To compare WireGuard and IKEv2 with other VPN protocols, read the guide to VPN protocols.
How WireGuard and IKEv2 differ in design
WireGuard has one fixed set of algorithms chosen by its project, while IKEv2 lets the connecting side offer the algorithms it supports and the gateway pick one set.
Every WireGuard device uses the same set, so changing an algorithm means updating every device. The WireGuard project’s paper and documentation define the protocol; no RFC defines it.
IKEv2 is an IETF Internet Standard, RFC 7296, updated by later RFCs. In an IKEv2/IPsec VPN, IKEv2 sets up the keys, and ESP, the part of IPsec that encrypts packets, carries the data.
Negotiation carries a risk: when both ends still allow old, weak algorithms, an attacker can trick them into using those algorithms; the NSA calls this a downgrade attack. It also brings a benefit: because every IKEv2 implementation must support a common set of algorithms, products from different vendors can connect, and an organisation can limit its gateways to the algorithms its rules allow.
WireGuard and IKEv2 can both use the ChaCha20-Poly1305 cipher. WireGuard always uses it. Apple’s built-in IKEv2 client can offer it, and its default is AES-256.
IKEv2 can limit a tunnel more narrowly than WireGuard: IKEv2 traffic selectors restrict a tunnel by address range, port range and IP protocol, and the gateway can narrow what the client asks for. WireGuard’s AllowedIPs setting works by address range only.
Switching between Wi-Fi and mobile data
Both WireGuard and IKEv2 support roaming, which means keeping a VPN connection running when a device moves between Wi-Fi and mobile data. The common claim that IKEv2 is better for roaming does not hold as a general rule, and no published test shows either protocol completing the switch faster.
WireGuard needs no extra feature to handle a network change. When a phone changes network, the server learns the phone’s new address from the next valid packet it receives, and the address change itself starts no new handshake. Either side can change address, but the server can reach a moved device only after that device has sent something.
IKEv2 moves a connection with MOBIKE, an extension that both ends must support and agree to use when they set up the connection. The client, not the gateway, decides when to move the connection to a new address. The phone tells the gateway its new address in a protected update, encrypted and authenticated under the existing connection. The gateway normally checks that it can reach the phone at the new address, then sends its traffic there. Apple’s and Android’s built-in clients ask for MOBIKE by default.
Battery use and idle traffic
No published measurement compares WireGuard and IKEv2 battery use; what differs is what each sends while a phone sits idle.
WireGuard sends nothing by default when there is no traffic, apart from at most one short acknowledgement once data arrives. An app can switch on a persistent keepalive; WireGuard’s documentation suggests one every 25 seconds only for a device behind NAT (network address translation, where a router shares one public address among several devices) that must stay reachable.
WireGuard refuses session keys once they are three minutes old, so after a longer quiet spell the next packet waits for a new handshake of one round trip, in which each side sends one message.
Behind NAT, IKEv2 sends a one-byte keepalive whenever the link has been quiet for a set time, 20 seconds by default in the standard; Apple uses 110 seconds on mobile data for Always On VPN. IKEv2 also runs liveness checks when it has not heard from the other side. Each implementation sets how often these checks run; Apple devices run them every 10 minutes by default.
After a quiet spell, IKEv2 normally needs no new exchange before data flows again: with default settings on Apple devices, Android’s built-in client and strongSwan, keys last an hour or more, and one side renews them before they run out. IKEv2 needs a new exchange when one side has closed the idle connection, one side has decided the other is unreachable, or a NAT mapping has lapsed.
To see what your own setup sends, check the app’s keepalive setting. The guide to how much battery a VPN uses covers measured battery costs of VPNs in general.
Speed: what decides which is faster
Neither WireGuard nor IKEv2 is faster on every device. Which one is quicker depends on the device’s processor and on where each protocol runs on that platform.
AES-GCM is fast on processors with AES hardware support, while ChaCha20, the cipher WireGuard uses, is considerably faster than AES when the encryption runs in software alone. IKEv2 can use either cipher.
The kernel is the core of the operating system; user space is where ordinary apps run. WireGuard and IKEv2 also differ in where each encrypts and moves its traffic, by platform:
- Linux: the kernel handles IPsec traffic, and only the key-exchange program runs as a normal program. WireGuard also runs inside the kernel.
- Windows: WireGuard runs inside the kernel.
- iPhone and Mac: the WireGuard app runs as user-space code, outside the kernel.
- Android: the WireGuard app runs in user space unless the phone is rooted, its kernel includes WireGuard and the user turns on the app’s kernel option. The built-in IKEv2 client’s encryption runs in the kernel.
Published server tests that state their method have found IPsec using AES-GCM level with WireGuard or ahead of it in some setups.
Whatever the device, WireGuard’s handshake takes one round trip, while IKEv2 normally takes two round trips, or four or more when the user logs in with a username through EAP (Extensible Authentication Protocol). Each extra round trip adds one more network delay before data can flow.
How to compare WireGuard and IKEv2 on your device
Only a test on your own phone or computer shows which protocol is faster there.
- Find the protocol setting. Open the VPN app’s settings, find the protocol option, and check that it lists both WireGuard and IKEv2.
- Keep everything else the same. Connect to the same server location on the same Wi-Fi or mobile network with each protocol, so that only the protocol changes.
- Run the same speed test several times. Alternate between WireGuard and IKEv2, and compare the typical result for each protocol rather than a single run.
- Note any protocol that fails. If one protocol does not connect, the network may be blocking it.
WireGuard vs IKEv2 security
Published attacks on the encryption or authentication of WireGuard and IKEv2 have needed weak or outdated setups or flawed implementations, rather than breaking either design.
WireGuard devices prove who they are with key pairs, and there is no algorithm to misconfigure. WireGuard has no user logins and no certificate-style revocation: anyone with a copy of a device’s private key, and its pre-shared key if the setup uses one, can connect as that device until the server removes that device’s public key.
IKEv2 is not outdated: it is a current IETF Internet Standard, and the version the IETF deprecated in 2023 is IKEv1. IKEv2’s security depends on its settings. The UK guidance advises against IKEv1 and weak or reused pre-shared keys and strongly recommends certificates, while US government guidance flags old Diffie-Hellman groups. Published attacks on IKE have depended on IKEv1, keys shared with IKEv1, weak shared keys, or weak algorithms left enabled.
IPsec software is larger and more complex than WireGuard’s code because IPsec negotiates algorithms and supports many options. The current revision of WireGuard’s paper puts its Linux kernel code at under 4,000 lines, excluding cryptographic primitives.
Researchers have analysed WireGuard’s protocol design with automated proof tools such as Tamarin and CryptoVerif. Those proofs cover models of the design, not each implementation: a 2026 study that tested eight WireGuard implementations found bugs in some of them.
Privacy
A WireGuard server holds a configured list linking each device’s public key to its internal addresses and records the latest address and port each device sent from, while an IKEv2 gateway can hand out an internal address for each connection. Neither fact says anything about what a VPN provider logs. Providers that build on WireGuard can add their own address handling on top, as NordLynx does.
Post-quantum protection
Neither protocol’s standard key exchange resists a future quantum computer on its own, but both have optional add-ons. WireGuard has a pre-shared key built into its handshake, which its project suggests using as an extra layer of post-quantum resistance. IKEv2 has standard add-ons, RFC 8784 and RFC 9370, which recent Apple systems support through configuration profiles. The IETF has approved a standard for using ML-KEM, NIST’s post-quantum key exchange, with IKEv2, and the standard is awaiting publication as an RFC (as of October 2026).
Blocking and restrictive networks
Networks can block both WireGuard and IKEv2, because neither protocol disguises its traffic.
WireGuard uses UDP only. A WireGuard server can listen on any UDP port. Choosing a different port may get past a filter that blocks particular ports, but it does not disguise the traffic; the WireGuard project leaves that to separate tools. Running WireGuard over TCP needs an extra tool, and the project discourages it.
IKEv2 uses UDP ports 500 and 4500, and it switches to port 4500 behind NAT and whenever both ends support MOBIKE and NAT traversal. The data travels as ESP, which is IP protocol 50, or inside UDP port 4500. IKEv2 can fall back to TCP only if both ends have it configured in advance. Every implementation of this fallback must support TCP port 4500, and carrying TCP traffic inside a TCP tunnel can slow that traffic down.
IKEv2 can also fail to connect on networks that drop fragmented packets, because the login messages that carry certificates can be too big for one packet. When both ends support it, IKEv2’s own message fragmentation prevents this failure.
A WireGuard server gives no reply to anyone who probes it without the right keys, while an IKEv2 server answers the first setup message from anyone.
On a network that blocks both, the options are OpenVPN over TCP port 443, the port HTTPS uses, or an obfuscated protocol such as AmneziaWG, which builds on WireGuard.
Built into the device or installed as an app
IKEv2 comes built into Windows, Apple devices and Android 11 and later, so it can run without a VPN app; WireGuard comes built into Linux and needs an app on Windows, macOS, iOS and Android.
Windows and Apple devices list IKEv2 in their built-in VPN settings; on Android, the option appears only on phones whose maker enables IPsec tunnel support. From Android 12, Android’s own code offers only IKEv2 types when you add a new built-in profile. The Android VPN setup guide covers the steps.
WireGuard has been part of Linux since kernel 5.6, released in March 2020. Windows, macOS, iOS and Android have no WireGuard option in their built-in VPN settings, so you install the WireGuard app or a VPN app that includes it.
A built-in client needs a server that accepts IKEv2, plus the server’s address, an identity, and a password, shared key or certificate.
Some VPN services have removed IKEv2 from their apps (as of October 2026). Proton VPN, for example, no longer supports IKEv2 in its iPhone and iPad app and is removing it from its Mac app, with support ending in February 2027.
On iPhone and iPad, a built-in IKEv2 profile and the WireGuard app can both connect automatically on networks you choose, using On Demand rules. An administrator can add a WireGuard tunnel with a configuration profile, but the device must still have the WireGuard app installed.
Company VPNs and self-hosting
IKEv2 fits company remote access VPNs that need certificate or username logins, revocation checks or FIPS-approved cryptography; WireGuard identifies devices by key only.
Logins. IKEv2 can authenticate with certificates, a shared secret, or a username login through EAP, and with EAP the gateway normally also proves itself with a certificate. Through EAP, a gateway can check usernames against a company’s login server, such as a RADIUS server. Neither protocol defines single sign-on or multi-factor login itself, but EAP often provides single sign-on for IKEv2 logins. For WireGuard, user logins and single sign-on can come from a service built on it, such as a mesh VPN tool that hands sign-in to your identity provider.
Revocation. An IKEv2 gateway can check whether a certificate authority has revoked a certificate, through a revocation list or OCSP (Online Certificate Status Protocol); whether the gateway runs that check depends on its settings. With WireGuard, a device loses access when an administrator removes its public key from the server.
Management. Device management tools can push IKEv2 settings to company devices, for example Intune on Windows and configuration profiles on Apple devices. On Apple devices, the same profiles can add a WireGuard tunnel to the installed app.
Compliance. FIPS 140-3 is the US federal standard for cryptographic modules. Some IPsec products have cryptographic modules with FIPS 140-3 certificates that cover IKEv2; the certificate covers the module, not the whole VPN. WireGuard’s fixed algorithms are not on NIST’s approved lists (as of October 2026), and WireGuard cannot switch to approved algorithms.
Self-hosting. For a self-hosted VPN, a basic strongSwan setup for IKEv2 involves certificates or passwords, identities and connection definitions, while a basic WireGuard setup is a key pair per device plus each peer’s key and addresses. To check a running tunnel, wg show lists WireGuard peers and their latest handshakes, and swanctl --list-sas or ip xfrm state shows the IPsec connections held by strongSwan and the Linux kernel.
Frequently asked questions
Is WireGuard more secure than IKEv2?
No published attack on encryption or authentication has broken WireGuard’s or IKEv2’s design; the difference lies in what each protocol leaves to configure. Known attacks needed weak or outdated settings, keys shared with IKEv1, or implementation flaws. WireGuard leaves no algorithm choices to get wrong, while an IKEv2 connection is only as strong as its gateway’s settings and keys.
Is WireGuard faster than IKEv2?
WireGuard is not always faster. Server tests that state their method have measured IPsec with AES-GCM matching WireGuard, or beating it in some setups. AES-GCM runs fast on processors with built-in AES acceleration, while ChaCha20, WireGuard’s cipher, is faster when encryption runs in software alone. WireGuard’s handshake needs one round trip, while IKEv2’s needs two or more.
Which uses less battery, WireGuard or IKEv2?
No published measurement compares WireGuard and IKEv2 battery use. By default WireGuard sends nothing while idle, while IKEv2 behind NAT sends a small keepalive after each quiet spell and runs occasional liveness checks. An app’s settings can change how much either protocol sends, for example when the app switches on WireGuard’s persistent keepalive.
Is WireGuard or IKEv2 better on iPhone?
Neither protocol is better on every iPhone. When your VPN app offers both, choose WireGuard; choose IKEv2 when you want the iPhone’s built-in client without installing an app, or when your company needs Always On VPN, which supports only IKEv2. WireGuard and IKEv2 can both connect automatically on networks you pick, through iOS On Demand rules.
Do I need an app to use WireGuard?
Yes, on Windows, Mac, iPhone and Android you need an app, because none of them has a WireGuard option in its built-in VPN settings. Linux is the exception, with WireGuard in its kernel. On Apple devices a configuration profile can set up the tunnel, but the tunnel needs the WireGuard app on the device to work.
Why do companies still use IKEv2?
IKEv2 runs on the clients already built into company laptops and phones, supports certificate logins and username logins through EAP, and can check certificates against revocation lists or OCSP responders. Products whose cryptographic modules are FIPS-validated also support it, while WireGuard’s algorithms are not on NIST’s approved lists (as of October 2026).
Can WireGuard and IKEv2 be blocked?
Yes, a network can block either protocol. WireGuard runs over UDP only, so a network that blocks its UDP traffic stops it. IKEv2 uses known UDP ports and ESP packets, and its TCP fallback works only when both ends have it configured beforehand. Neither protocol hides what it is.
Does WireGuard use IPsec?
No, WireGuard does not use IPsec. WireGuard is a separate protocol with its own handshake and its own encryption. IKEv2 works with IPsec: IKEv2 sets up the connection and the keys, and IPsec then encrypts the data. Settings may therefore list the pair as IKEv2/IPsec.