Always On VPN IKEv2 Features and Limitations

Always On VPN IKEv2 Features and LimitationsThe Internet Key Exchange version 2 (IKEv2) VPN protocol is a popular choice for Windows 10 Always On VPN deployments. IKEv2 is a standards-based IPsec VPN protocol with customizable security parameters that allows administrators to provide the highest level of protection for remote clients. In addition, it provides important interoperability with a variety of VPN devices, including Microsoft Windows Server Routing and Remote Access Service (RRAS) and non-Microsoft platforms such as Cisco, Checkpoint, Palo Alto, and others.

IKEv2 Limitations

IKEv2 is clearly the protocol of choice in terms of security. It supports modern cryptography and is highly resistant to interception. It’s not without some operational challenges, however. Consider the following.


IKEv2 uses UDP ports 500 and 4500 for communication. Unfortunately, these ports are not always open. Often, they are blocked by network administrators to prevent users from bypassing security controls or attackers from exfiltrating data.


IKEv2 packets can become quite large at times, especially when using client certificate authentication with the Protected Extensible Authentication Protocol (PEAP). This can result in fragmentation occurring at the network layer. Unfortunately, many firewalls and network devices are configured to block IP fragments by default. This can result in failed connection attempts from some locations but not others.

Load Balancing

Load balancing IKEv2 connections is not entirely straightforward. Without special configuration, load balancers can cause intermittent connectivity issues for Always On VPN connections. Guidance for configuring IKEv2 load balancing on the Kemp LoadMaster and the F5 BIG-IP can be found here:

IKEv2 Fragmentation

IKEv2 fragmentation can be enabled to avoid IP fragmentation and restore reliable connectivity. IKEv2 fragmentation is supported in Windows 10 and Windows Server beginning with v1803. Guidance for enabling IKEv2 fragmentation on Windows Server RRAS can be found here. Support for IKEv2 fragmentation on non-Microsoft firewall/VPN devices is vendor-specific. Consult with your device manufacturer for more information.

IKEv2 Security and RRAS

Be advised that the default security settings for IKEv2 on Windows Server RRAS are very poor. The minimum recommended security settings and guidelines for implementing them can be found here.

IKEv2 or TLS?

IKEv2 is recommend for deployments where the highest level of security and protection is required for remote connections. In these scenarios, the sacrifice of ubiquitous availability in favor of ultimate security might be desired.

SSTP or another TLS-based VPN protocol is recommended if reliable operation and connectivity are desired. SSTP and TLS VPNs can be configured to provide very good security by following the security and implementation guidelines found here.

IKEv2 with TLS Fallback

In theory, preferring IKEv2 and falling back to the Secure Socket Tunneling Protocol (SSTP) or another TLS-based VPN protocol when IKEv2 is unavailable would seem like a logical choice. This would ensure the highest level of protection, while still providing reliable connectivity. Unfortunately, the Windows VPN client doesn’t work this way in practice. Details here.

Additional Information

Windows 10 Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster

Windows 10 Always On VPN IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 and SSTP Fallback

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

Leave a comment


  1. I concur with you Richard.
    Even though I can’t prove that IKEv2 fragmentation is causing problems with our set up (I don’t have full diagnostic access to all the routers in the chain of connection), I have found that using TLS/SSTP instead is far more reliable.
    The other problem I’ve found with the supposed client auto-failover from IKEv2 to SSTP it doesn’t happen that way. Almost always IKEv2 will establish a connection, only for it to then partially fail but crucially NOT fail over to SSTP. In other words, the client doesn’t consider a flaky IKEv2 connection to have failed.
    So, all I’ve done is to fix the connection type to SSTP. All problems have now gone.

    • Agreed, IKEv2 to SSTP failover is definitely broken if the IKEv2 connection is partially established. SSTP failover only occurs if the IKEv2 connection fails initially. IKEv2 fragmentation often fails during the authentication phase, so the initial connection is successful and Windows never tries SSTP in that scenario.

      It is possible to diagnose IKEv2 fragmentation without having access to all network devices in the path. To do this, take a network trace on the server and the client at the same time the problem occurs. Typically what you see is the client and server communicating on UDP port 500, but when it switches to UDP port 4500 and tries to authenticate, the packets are too big and they are dropped. You’ll see in the traces that the client sends this traffic, but it is never received on the server. You may not know which device is dropping it, but you’ll at least have proof it is happening.

      • Andy Chips

         /  May 14, 2019

        Thanks Richard – those are really useful tips. The problem I have is that the more SSTP continues to work well for us, the less inclined I am to revisit IKEv2 problems 🙂 – but I do appreciate your advice.

      • I hear you there… 🙂

  2. Michael Leeming

     /  August 12, 2019

    Should windows firewall and firewall in front of a Micosoft RRAS server using IKEv2 not allow ESP? (IP Protocol TYPE 50) or is UDP 500 and 4500 enough? (some even say UDP 1701 could be necessary for IKEv2)

    • If your VPN server has a public IP address you can allow inbound IP protocol 50 to support native (non-encapsulated) ESP traffic. That’s not common when using Windows Server and RRAS, but more common if you are using a dedicated security/VPN device.

    • Also, for clarification UDP 1701 is definitely not required for IKEv2. That’s only required for L2TP. 🙂

  3. aventador06

     /  June 7, 2020

    Dear Richard,
    Have you ever done a configuration with a CISCO Radius instead of a NPS server?
    Is it doable (as AOVPN is not related to a specific vendor)?
    If yes, could you share an example of what the user profile looks like in this kind of environment?
    Thanks for your replies

    • I have not personally, but it is certainly possible. RADIUS is an open standard so I would expect most non-Microsoft RADIUS servers to work just as well as NPS.

      • aventador06

         /  June 8, 2020

        Thanks. I really appreciate you take a moment to reply. We’ve decided to go for MS NPS at first. We need to set this up by the end of the month so we are not going to improvise something for which we cannot find any doc. Have a nice day

  1. Always On VPN Options for Azure Deployments | Richard M. Hicks Consulting, Inc.
  2. Always On VPN IKEv2 Policy Mismatch Error | Richard M. Hicks Consulting, Inc.
  3. Always On VPN Device Tunnel with Azure VPN Gateway | Richard M. Hicks Consulting, Inc.
  4. Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC | Richard M. Hicks Consulting, Inc.
  5. Always On VPN Device Tunnel Only Deployment Considerations | Richard M. Hicks Consulting, Inc.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: