Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMasterA recent update to the Kemp LoadMaster load balancer may cause failed connections for Always On VPN connections using IKEv2. SSTP VPN connections are unaffected.

Load Balancing IKEv2

When using the Kemp LoadMaster load balancer to load balance IKEv2, custom configuration is required to ensure proper operation. Specifically, the virtual service must be configured to use “port following” to ensure both the initial request on UDP port 500 and the subsequent request on UDP port 4500 are sent to the same real server. This requires the virtual service to be configured to operate at layer 7. Detailed configuration guidance for load balancing IKEv2 on the Kemp LoadMaster load balancer can be found here.

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Issues with LMOS 7.2.48.0

A recent release of the Load Master Operating System (LMOS) v7.2.48.0 introduced a bug that affects UDP services configured to operate at layer 7, which includes IKEv2. This bug breaks Always On VPN connections using IKEv2, resulting in failed connections. When this occurs, the administrator may encounter an error 809 message for device tunnel or user tunnel.

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Update Available

Administrators who use the Kemp LoadMaster load balancer to load balance Always On VPN IKEv2 connections and have updated to LMOS 7.2.48.0 are encouraged to update to LMOS 7.2.48.1 immediately. This latest update includes a fix that resolves broken IKEv2 load balancing for Always On VPN. Once the LoadMaster has been updated to 7.2.48.1, Always On VPN connections using IKEv2 should complete successfully.

Additional Information

Windows 10 Always On VPN IKEv2 Load Balancing and NAT

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster Load Balancer

Windows 10 Always On VPN SSTP Load Balancing with Kemp LoadMaster Load Balancer

Windows 10 Always On VPN Load Balancing with Kemp LoadMaster in Azure

Windows 10 Always On VPN Load Balancing Deployment Guide for Kemp Load Balancers

Leave a comment

13 Comments

  1. Hi Richard, first off a huge thanks – your blog as been really helpful to me!
    I’m hoping you may have an insight into a problem I am having with clients not reconnecting.
    We have a Kemp vlm-max with the latest updates (as of Mar 22nd), configured using the Kemp template with port following configured. 3 aovpn servers, 2019 with the reg key set for ike fragmentation. Ext firewalls are Palo Altos passing udp 500/4500 to the kemp.
    The issue I see is if a client disconnects (either reboot or manually clicking disconnect) the machine then cannot reconnect. Some machines will, some won’t. Clients are windows 10, mix of 1709 and 1809. Both device tunnels and user tunnels deployed (although only user to 1709)
    If I restart the Kemp, these devices can reconnect again. Pulling my hair out trying to figure out what I’m missing!

    Reply
    • I’m hearing these same reports. Not sure if it is a Kemp-specific issue or not, as others have reported similar issues with F5. If you haven’t done so already, I would suggest configure the Kemp so that it doesn’t perform NAT (turn off “subnet originating requests” and enable transparency on the virtual service). This might introduce some routing issues, so there may be other changes in your environment required to make this work. Ultimately it will make for more reliable IKEv2 load balancing. 🙂

      Reply
  2. Thanks, Richard, we have turned that off now and I am seeing more connections come through, although way more device tunnels than user tunnels, seems to be the user tunnel we are having the most issues with. We have a case open with MS Premiere support, Palo Alto and Kemp, Ill let you know what we find (if anything). From Wireshark, it looks like something is hanging on to a dead connection, I can see packets coming back from the Kemp to the client even when no tunnel is connected. If we clear the session on the FW and reboot the kemp, those users are then able to connect again.

    Reply
  3. Hi Richard. Taking the Kemp out of the equation fixes the issue, MS Support has identified the error we get when load balancing as being related to:
    – VPN server does not allow client connection with error: Max number of established MM SAs to peer exceeded

    – The VPN server has invalidated the main mode SA before the error

    – Not visible in the logs what caused this.

    – Client dropped the informational packet with the error notification from the server sent in clear text to avoid DoS

    So it appears the Kemp/RAS is hanging on to disconnected connections and not allowing the client to reconnect. Waiting on a follow call with MS

    Reply
    • Is your Kemp configured to perform NAT? In Kemp terms that would be “subnet originating requests”? Best practice is to implement the virtual service with transparency enabled so the VPN server sees the client’s original source IP address. This will avoid the maximum number of MM SAs per source IP address issue.

      Reply
      • Ah, that is not configured, Kemp had us turn it off originally. I’ll do some testing tomorrow with it flipped back on – thanks for the info!

      • The critical point here is that the VPN server should see the client’s original IP address. If that is being translated at any point (load balancer or edge firewall) then all of those client sessions appear to come from the same “client” and RRAS objects.

  4. Hi Richard,
    Thanks for the info – I now have the kemps working with transparency turned on and the Ras servers default gateway pointed at the vip address on the Kemp. I have got HA working on the kemps with failover between them working, although I don’t seem to be able to take a ras server down and have the connection re-establish to one of the other servers – the client fails to connect until the downed server is brought back online. I suspect there is a session timeout setting I have missed, but it’s getting late, so will have to wait until the morning – I just wanted to thank you again and add the above info I case it helps anyone else. I plan to write it up fully once working!

    Reply
    • Here are a few Kemp settings that might help with this situation.

      System Configuration/Miscellaneous Options/L7 Configuration :: Select Yes Accept Changes from the Always Check Persist drop-down list
      System Configuration/Miscellaneous Options/L7 Configuration :: Select Drop Connections on RS Failure and Drop at Drain End Time

      The following settings might not work with IKEv2, which uses UDP, but might be worth setting anyway.

      System Configuration/Miscellaneous Options/L7 Configuration :: Enter 60 in the L7 Connection Drain Time (secs) field and click Set Time
      System Configuration/Miscellaneous Options/Network Options :: Enable reset on close

      Let me know how it goes. And definitely share the link to your write up when you’ve published it!

      Reply
      • “System Configuration/Miscellaneous Options/Network Options :: Enable reset on close” Seems to have done the trick! all the other options were already set as suggested, huge thanks for you help – ill try and write this up today 🙂

      • Great to hear! 🙂

  5. Hi Richard, finally got around to writing this up – hope this is of some use to you and others:
    https://www.deviousweb.com/2020/04/03/kemp-loadmaster-config-for-windows-always-on-vpn-with-ikev2/

    Reply

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: