Internet Key Exchange version 2 (IKEv2) is an IPsec-based VPN protocol with configurable security parameters that allows administrators to ensure the highest level of security for Windows 10 Always On VPN clients. It is the protocol of choice for deployments that require the best possible protection for communication between remote clients and the VPN server. IKEv2 has some unique requirements when it comes to load balancing, however. Because it uses UDP on multiple ports, configuring the load balancer requires some additional steps for proper operation. This article demonstrates how to enable IKEv2 load balancing using the Kemp LoadMaster load balancer.
IKEv2 and NAT
IKEv2 VPN security associations (SAs) begin with a connection to the VPN server that uses UDP port 500. During this initial exchange, if it is determined that the client, server, or both are behind a device performing Network Address Translation (NAT), the connection switches to UDP port 4500 and the connection establishment process continues.
IKEv2 Load Balancing Challenges
Since UDP is connectionless, there’s no guarantee that when the conversation switches from UDP 500 to UDP 4500 that the load balancer will forward the request to the same VPN server on the back end. If the load balancer forwards the UDP 500 session from a VPN client to one real server, then forwards the UDP 4500 session to a different VPN server, the connection will fail. The load balancer must be configured to ensure that both UDP 500 and 4500 from the same VPN client are always forwarded to the same real server to ensure proper operation.
Port Following
To meet this unique requirement for IKEv2 load balancing, it is necessary to use a feature on the KEMP LoadMaster load balancer called “port following”. Enabling this feature will ensure that a VPN client using IKEv2 will always have their UDP 500 and 4500 sessions forwarded to the same real server.
Load Balancing IKEv2
Open the web-based management console and perform the following steps to enable load balancing of IKEv2 traffic on the KEMP LoadMaster load balancer.
Create the Virtual Server
- Expand Virtual Services.
- Click Add New.
- Enter the IP address to be used by the virtual server in the Virtual Address field.
- Enter 500 in the Port field.
- Select UDP from the Protocol drop-down list.
- Click Add this Virtual Service.
Add Real Servers
- Expand Real Servers.
- Click Add New.
- Enter the IP address of the VPN server in the Real Server Address field.
- Click Add This Real Server.
- Repeat the steps above for each VPN server in the cluster.
Repeat all the steps above to create another virtual server using UDP port 4500.
Enable Layer 7 Operation
- Click View/Modify Services below Virtual Services in the navigation tree.
- Select the first virtual server and click Modify.
- Expand Standard Options.
- Uncheck Force L4.
- Check Transparency (additional configuration may be required – details here).
- Select Source IP Address from the Persistence Options drop-down list.
- Choose an appropriate value from the Timeout drop-down list.
- Choose an appropriate setting from the Scheduling Method drop-down list.
- Click Back.
- Repeat these steps on the second virtual server.
Enable Port Following
- Click View/Modify Services below Virtual Services in the navigation tree.
- Select the first virtual server and click Modify.
- Expand Advanced Properties.
- Select the virtual server using UDP 500 from the Port Following drop-down list.
- Click Back.
- Repeat these steps on the second virtual server.
Demonstration Video
The following video demonstrates how to enable IKEv2 load balancing for Windows 10 Always On VPN using the KEMP LoadMaster Load Balancer.
Summary
With the KEMP LoadMaster load balancer configured to use port following, Windows 10 Always On VPN clients using IKEv2 will be assured that their connections will always be delivered to the same back end VPN server, resulting in reliable load balancing for IKEv2 connections.
Additional Information
Windows 10 Always On VPN Certificate Requirements for IKEv2
Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS
Dhana
/ September 24, 2019Great post, really helps. A quick question – in this guidance, the VPN servers may not see the actual client IP address. Is this the best approach, or can we configure the LBs without replacing the actual client IPs?
Richard M. Hicks
/ October 7, 2019Great observation. Indeed, in this case the load balancer appears as the source IP address to the VPN server, which might be problematic. You can always disable Subnet Originating Reqeusts and enable Transparency on the LoadMaster, which will result in the real IP address being presented as the source IP address to the VPN server. You just need to be mindful of routing and firewall configuration to ensure traffic is handled correctly in this scenario.
Luca
/ March 31, 2020Hi Richard,
I would like to report my last experience with a AlwaysON environment with a custom load balancer who doesn’t support “Transparency”.
On both (2) RRAS nodes, all the clients (Device Tunnel) were saw with the load balancer IP address. The users were experiencing a lot of issues and the customer opened a ticket to Microsoft Support.
Microsoft specialist has applied a change to a registry key (on the RRAS servers) in order to bypass the client IP address problem, as a workaround. Now the situation it seems to be more stable.
Do you think that the workaround could cause other issues?
Thanks in advance.
Richard M. Hicks
/ March 31, 2020I’m assuming the registry key you made changes to was HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IkeNumEstablishedForInitialQuery, correct? FYI, I have a PowerShell script that configures this setting here: https://github.com/richardhicks/aovpn/blob/master/Set-IKEv2LoadBalancingParameters.ps1.
While this setting can provide some stability for Always On VPN IKEv2 connections behind a load balancer or firewall performing NAT, it is not a complete solution. There are other settings in Windows that are hard coded that can present issues as well. The best way to resolve this is to ensure that the RRAS server sees the real client IP address.
To answer your question though, I don’t believe enabling this workaround will cause any other issues.
Luca
/ April 2, 2020Than you Richard, I completely agree with you.
Matthew Rawles
/ November 3, 2019Hi Richard,
(i’ve also commented under you BIG-IP Load balancing section)
I’ve been testing a KEMP Loadmaster with always-on over the last few days and i’m seeing some 809 errors after the Loadmaster has had clients connecting sucessfully for a few days.
When I orginally reached out I thought the errors were down to the number of IKE ports the real servers had, but they now have 1000s so thats not the issue.
I’ve been testing with 40 virtual clients and a couple of real users, the virtual clients i’ve moved about (changing the source IP and therefore the real server they get directed to). For 2 days had no issues, managed to load up the clients with a file copy to push 800Mbps through them collectively (something that crashed our orginal Jet Nexus load balancer).
Then this evening I was unable to connect one of the test laptops with IKE (user was ok). Rebootind the real servers didnt resolve this, rebooting the Load Master fixed it immedaitely.
The Load Master is configured single-arm, with it’s interface in the same VLAN as the external interfaces of the RRAS servers.
I’ll go back to Kemp tomorrow, see if they have any ideas, they already made me downgrade to version 7.2.45.2 as the current version 7.2.48 wouldnt allow any UDP VPNs to work!
I would go back and try the BIG-IP from F5 but that is so poorly documented online, there is no step by step guide to the working always-on setup I can find.
Regards
Matthew Rawles
Richard M. Hicks
/ November 4, 2019Yes, I’ve found that the latest LMOS release is causing problems for IKEv2 connections. I’ve made Kemp aware of the issue, so hopefully they’ll be addressing soon!
Julien Potier
/ November 14, 2019Hi Richard. Thanks for your article. I spoke to you about a year ago when i was deploying OAVPN for a customer i look after. Back then i was trying to bring some resilience into the design which AOVPN fundamentally lacks. I can’t remember if i tried Kemp but i know i tried a couple of solutions and each time the encrypted throughput when proxied was disappointing. At best i’d get 30-40Mbps max from a single connection whereas i got several hundred Mbps when targeting the server directly. Have you tried doing some throughput test with Kemp ?
Richard M. Hicks
/ November 14, 2019I’ve done some basic performance testing for the Kemp and F5 load balancers and never really noticed a significant drop off in performance. No question any load balancer (the Kemp and F5 included) do impede throughput a little bit, not not substantially in my limited testing. The most impactful in terms of performance is firewalls. Depending on which security features are enabled I’ve seen dramatic reduction in performance.
Matthew Rawles
/ November 14, 2019Hi Julien,
I have been testing a KEMP loadmaster this last few weeks and have had the loadmaster up to 800Mbps using multiple clients running looping file copy tasks (the clients are all located in a test virtual environment with >1gb ethernet access to the loadmaster). This was only IKE device VPNs which do seem to perform better.
It is worth talking to KEMP , they have a number of tweaks to the loadmaster even after you use the template to create the VS (we for example have the IP persistence timeout set to a very large value, currently 8 hours, considering making that 24 hours as we get occasional issues with persistence on test clients).
Its better to have a more realistic load with multiple clients than one massive client.
Regards
Matthew
Richard M. Hicks
/ November 16, 2019Thanks for the tips Matt!
RKast
/ November 21, 2019Hi sir,
Can we use Windows NLB on 2 RRAS servers in a cluster in Multicast for always on vpn nlb ? What are recommedations for windows nlb and affinity, single ? I have set this up and if i initiate a vpn and get connected to RAS1 then disconnect then turn of RAS1 and initiate VPN again i cannot connect, any idea? I have set udp 500 4500 and 443 in nlb ports am i missing ports?
Thanks for your reply.
Richard M. Hicks
/ November 21, 2019I don’t have much experience with NLB, so I don’t have a lot of guidance to offer you unfortunately. I would suggest that you use Unicast mode unless you have a very specific reason to use Multicast (for example you’re running in VMware). Other than that, I would think single affinity should work.
Luca
/ March 17, 2020Hi Richard, based on your experience, which is the correct value for persistence timeout?
Thanks in advance,
Luca
Richard M. Hicks
/ March 18, 2020There is no correct value, really. It can be set to whatever you like, really. I typically recommend 5 minutes, but you can set it lower or higher if that better suits your needs! 🙂
Luca
/ March 25, 2020Thanks for your reply. 👍🏼
Andrew
/ March 27, 2020Thank you for the very helpful article!
How would IPSec (e.g. ESP, IP protocol 50, and AH, IP protocol 51) be directed to the correct VPN server by LoadMaster in the case where IKE does not detect NAT?
Richard M. Hicks
/ March 27, 2020I’m not sure. The only options for virtual server configuration on the Kemp are TCP and UDP. Doesn’t appear to support IP protocols. :/
Stan Ley
/ August 13, 2020It may be worth for people that are using Kemp to load balance IKEv2 Always On VPN, to look at the below link. The port following when configured through the GUI was not working before Firmware 7.2.51
https://support.kemptechnologies.com/hc/en-us/articles/360044549191-Port-Following-with-Generic-Virtual-Services
Richard M. Hicks
/ August 13, 2020Indeed. I also documented that here: https://directaccess.richardhicks.com/2019/11/18/always-on-vpn-ikev2-load-balancing-issue-with-kemp-loadmaster/. 🙂
primethirty7
/ April 21, 2021Really good article, we are looking at deploying this behind a pair of A10 devices. I notice you have other articles for F5’s etc, any plans for an A10 write up ?
Thanks.
Richard M. Hicks
/ April 23, 2021No plans, but I’m not opposed. Is there a virtual appliance I could download that includes a free evaluation? If so, I’d be happy to write something up. 🙂
primethirty7
/ June 8, 2021In case it helps yourself or others, this is the config that we now have running on our A10’s.
Front end Virtual Server IP of 192.168.98.1
The two RAS servers, 192.168.99.8 & 192.168.99.9
!
slb server S-MS-AoVPN-RAS1 192.168.99.8
port 500 udp
health-check-disable
port 4500 udp
health-check-disable
!
slb server S-MS-AoVPN-RAS2 192.168.99.9
port 500 udp
health-check-disable
port 4500 udp
health-check-disable
!
slb service-group SG-MS-AoVPN-UDP-4500 udp
template port template_delsessiondown
member S-MS-AoVPN-RAS1 4500
member S-MS-AoVPN-RAS2 4500
!
slb service-group SG-MS-AoVPN-UDP-500 udp
template port template_delsessiondown
member S-MS-AoVPN-RAS1 500
member S-MS-AoVPN-RAS2 500
!
slb template persist source-ip T-MS-AoVPN-SRC-IP
match-type server
!
slb template udp template_reselectifdown
re-select-if-server-down
!
slb virtual-server VS-MS-AoVPN 192.168.98.1 /32
disable-when-all-ports-down
port 500 udp
service-group SG-MS-AoVPN-UDP-500
template persist source-ip T-MS-AoVPN-SRC-IP
template udp template_reselectifdown
port 4500 udp
service-group SG-MS-AoVPN-UDP-4500
template persist source-ip T-MS-AoVPN-SRC-IP
template udp template_reselectifdown
!
Richard M. Hicks
/ June 8, 2021Awesome. Thanks for sharing!
Nathan
/ July 9, 2021Hi Richard, great article it was really helpful in getting the Kemp to a semi-working state for us recently! We’re just finding a really strange issue since moving all of our users over to the solution.
So we currently have 3 RRAS servers in the DMZ and the Kemp LoadMaster sitting in front of them and we have the Clients using a Device Tunnel locked down to specific network resources (DC’s, File Servers and Management servers), User Tunnel then allowing access to all of our subnets on SSTP. When sending everyone through the Kemp we’re seeing over 50% packet loss when pinging any internal servers, users are having trouble connecting etc. If we disconnect the Device tunnel from a connected client and ping the same server the ping responds more consistently and doesnt seem to drop many packets if at all.
If we take the Kemp out of the equation and send all AOVPN traffic to one of the RRAS server’s the ping starts behaving and is absolutely solid with both Device and User tunnels connected. Its making me think the Kemp doesnt like the IKEv2 packets and is dropping them for whatever reason.
When we piloted the solution with a handful of users it seemed fine, now we’ve increased the usage we’re seeing these odd problems, the servers arent being hammered when looking at resources, link utilization is low. Just wondered if you may have seen this before at all?
Thanks.
Richard M. Hicks
/ July 9, 2021That’s quite unusual. There is a known issue with the Kemp load balancer right now they are working to address, but it is related to persistence and connection failures. It doesn’t seem to cause the problems you describe. That said, if you aren’t on the latest release, it would be a good idea to upgrade and test again. Also, there could be something else in the configuration that’s causing this problem too. Engaging with Kemp support might a good idea to have them look things over with you.
Nathan
/ July 9, 2021Thanks, we are hoping to get some time with their engineers early next week but just wanted to check on the very slight off chance you may have seen this previously as my brain wont let it go all weekend 🙂
Have a good one!
Richard M. Hicks
/ July 9, 2021No, I haven’t seen this particular issue myself yet. Let me know what you learn from Kemp support!
Nathan
/ July 14, 2021Hey Richard, just an update on this issue. Turns out its not the Kemp at fault but it was our new Firewall blocking the amount of connections at any one time due to its DDOS prevention. New Data Centre, New Firewall, Still working it out but increasing the threshold to those servers has now made the connection absolutely solid again.Panic over!
Richard M. Hicks
/ July 15, 2021Great to hear. Thanks for the update!
Ajay
/ September 20, 2021Hi Richard
we have recently deployed Kemps Loadmaster and it seems to be working well on the whole , however , we have a few Windows 10 clients who now don’t connect to Always On immediately , if the device is left alone it will connect after approx 30 mins . After a reboot or shut down though this will occur again . The strange thing is that this is not affecting everyone. Have you come across this before ?
we are load balancing across 2 RAS servers using IKEv2.
Richard M. Hicks
/ September 20, 2021There’s a known issue with the Kemp LoadMaster with IKEv2 that could be causing the issue. Try setting the persistence for the IKEv2 virtual services to 1 day and see if that helps. 🙂
Ajay
/ September 23, 2021Thanks Richard , that worked and we are now successfully load balancing .