The 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.
Firewalls
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.
Fragmentation
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:
- Always On VPN IKEv2 Load Balancing with Kemp LoadMaster
- Always On VPN IKEv2 Load Balancing with F5 BIG-IP
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
Andy Chips
/ May 14, 2019I 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.
Richard M. Hicks
/ May 14, 2019Agreed, 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, 2019Thanks 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.
Richard M. Hicks
/ May 14, 2019I hear you there… 🙂
Michael Leeming
/ August 12, 2019Should 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)
Richard M. Hicks
/ August 13, 2019If 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.
Richard M. Hicks
/ August 13, 2019Also, for clarification UDP 1701 is definitely not required for IKEv2. That’s only required for L2TP. 🙂
Ferry
/ April 15, 2021We have allowed protocol 50, but I don’t see any clients hitting the firewall with ESP (proto 50) at all.
Seems the IKEv2 client only uses udp/500 and udp/4500.
Richard M. Hicks
/ April 17, 2021You likely won’t. IP protocol 50 is only used when both hosts can communicate without NAT. If there’s a NAT device inline anywhere, IKEv2 will encapsulate ESP traffic (protocol 50) in UDP 4500.
aventador06
/ June 7, 2020Dear 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
Richard M. Hicks
/ June 8, 2020I 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, 2020Thanks. 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
Luca
/ October 22, 2020Hi Richard,
in a standard Always On deployment, do you think it’s better to use a new DHCP pool or we can also use a IP range of the Internal DMZ network where the RRAS server belongs to?
Thanks,
Luca
Richard M. Hicks
/ October 24, 2020That’s a design decision that is entirely up to you. You can use either, and there are advantages and disadvantages to both. I prefer using static pool assignment with a dedicated and unique IP subnet for VPN clients. I find that it makes it easier to firewall if that’s required.
Luca Parazza
/ November 10, 2020Thanks Richard. Your help is always appreciated.
shrimoutlookcom
/ November 2, 2020Hello Team
Is there is a solution, where we can disconnect from end users after certain hours via NPS policy or Any other policy.
When I tried via NPS network policy from Constraints session time out and it did disconnect the session and will not reconnect afterwards.
Please advise
Shri
Richard M. Hicks
/ November 2, 2020Not natively. You can restrict *new* connections using NPS policy, but NPS doesn’t proactively terminate sessions at certain times. You could easily write a script to do this on the VPN server though.
shrimoutlookcom
/ November 2, 2020Thank you Richard.
Can you please provide me the script that will do that.
Thank you in advance.
Shri
Richard M. Hicks
/ November 6, 2020https://github.com/richardhicks/aovpn/blob/master/Remove-VpnConnections.ps1
shrimoutlookcom
/ November 4, 2020Thank you Richard..I really appreciate for your kind reply.
Can you please share the PowerShell to do the trick to disconnect.
Shri
Richard M. Hicks
/ November 6, 2020https://github.com/richardhicks/aovpn/blob/master/Remove-VpnConnections.ps1
Ferry
/ April 15, 2021Hey Richard,
got some reports from users that seem unable to connect with IKEv2. This mostly seems to happen when there’s another user behind the same NAT router with the same VPN.
Tried looking with netstat (can’t access their routers) and it would seem the IKEv2 client uses 500/4500 as source ports as well.
UDP not having a session of sorts it would seem to me the only way NAT tables can track is would be by use of different source ports. Since both the client seems to use the same source ports and destination IP/ports it seems the router gets confused and only the first user to start will get a VPN.
Have you seen this before?
Richard M. Hicks
/ April 17, 2021I’m hearing a lot of complaints like this. Unfortunately, there’s no option to use ephemeral ports for source ports. :/
Kirsty Wilson
/ June 28, 2021Hi Richard. Do you know how to increase the connection attempts of the W10 client?
We’re using IKEv2 User tunnel.
On failover tests the client disconnects but only has 3 retries to connect to a live VPN server. Sometimes the load balancer isn’t quick enough and hasn’t picked up that a server is down & to redirect traffic so the connection times out.
Do you know how or if we can increase the client connection attempts?
Richard M. Hicks
/ July 6, 2021I’m not aware of any way to change the default reconnection attempts, unfortunately. :/
Dan S
/ October 18, 2021Hi Richard, I’ve been noticing that some of my Always On users on IKEv2 run into connectivity issues on very slow networks and cell hotspots. Switching them to SSTP seems to help. Do you know of any sort of minimum bandwidth requirements for IKEv2?
Richard M. Hicks
/ October 20, 2021I’m not aware of any specific bandwidth requirements for IKEv2. Interestingly though, I’ve had the same experience as you with regard to performance. Not sure why that is, but SSTP does seem to perform better than IKEv2 in general, especially over unreliable connections.
VICTOR HERRERA
/ November 11, 2021Hi Richard,
Do you know if Microsoft will support IKEv2 over TCP?
Richard M. Hicks
/ November 16, 2021I would guess unlikely. I’ve not heard anything of the sort.