Always On VPN and IKEv2 Fragmentation

The IKEv2 protocol is a popular choice when designing an Always On VPN solution. When configured correctly it provides the best security compared to other protocols. The protocol is not without some unique challenges, however. IKEv2 is often blocked by firewalls, which can prevent connectivity. Another lesser know issue with IKEv2 is that of fragmentation. This can result in failed connectivity that can be difficult to troubleshoot.

IP Fragmentation

IKEv2 uses UDP for transport, and typically most packets are relatively small. The exception to this is when authentication takes place, especially when using client certificate authentication. The problem is further complicated by long certificate chains and by RSA keys, especially those that are greater than 2048 bit. If the payload exceeds 1500 bytes, the IP packet will have to be broken in to smaller fragments to be sent over the network. If an intermediary device in the path is configured to use a smaller Maximum Transmission Unit (MTU), that device may fragment the IP packets.

IP Fragmentation and Firewalls

Many routers and firewalls are configured to drop IP fragments by default. When this happens, IKEv2 communication may begin initially, but subsequently fail. This typically results in an error code 809 with a message stating the following.

“Can’t connect to [connection name]. The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (e.g. firewalls, NAT, routers, etc.) between your computer and the remote server is not configured to allow VPN connections. Please contact your Administrator or your service provider to determine which device may be causing the problem.”

Always On VPN and IKEv2 Fragmentation

Troubleshooting

When troubleshooting potential IKEv2 fragmentation-related connection failures, a network trace should be taken of the connection attempt on the client. Observe the packet sizes during the conversation, especially IKE_AUTH packets. Packet sizes exceeding the path MTU will have to be fragmented, as shown here.

Always On VPN and IKEv2 Fragmentation

Measuring Path MTU

Measuring the path MTU between the client and server can be helpful when troubleshooting fragmentation related issues. The mtupath.exe utility is an excellent and easy to use tool for this task. The tool can be downloaded here.

Always On VPN and IKEv2 Fragmentation

IKEv2 Fragmentation

To address the challenges with IP fragmentation and potential connectivity issues associated with network devices dropping fragmented packets, the IKEv2 protocol itself can be configured to perform fragmentation at the IKE layer. This eliminates the need for IP layer fragmentation, resulting in better reliability for IKEv2 VPN connections.

Both the server and the client must support IKEv2 fragmentation for this to occur. Many firewall and VPN vendors include support for IKEv2 fragmentation. Consult the vendor’s documentation for configuration guidance. For Windows Server Routing and Remote Access (RRAS) servers, the feature was first introduced in Windows Server 1803 and is supported in Windows Server 2019. Windows 10 clients support IKEv2 fragmentation beginning with Windows 10 1803.

Enabling IKEv2 Fragmentation

Windows 10 clients support IKEv2 fragmentation by default. However, it must be enabled on the server via the registry. The following PowerShell command will enable IKEv2 fragmentation support on Windows Server 1803 and later.

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\” -Name EnableServerFragmentation -PropertyType DWORD -Value 1 -Force

Validation Testing

Once IKEv2 fragmentation is configured on the VPN server, a network capture will reveal the IKE_SA_INIT packet now includes the IKEV2_FRAGMENTATION_SUPPORTED notification message.

Always On VPN and IKEv2 Fragmentation

Additional Information

Windows 10 Always On VPN IKEv2 Security Configuration

RFC 7383 – IKEv2 Message Fragmentation

IEA Software MTU Path Scan Utility

Windows 10 Always On VPN Hands-On Training Classes

Leave a comment

38 Comments

  1. Colin

     /  February 11, 2019

    This is what allowed us to even move forward with AlwaysOn VPN. Prior to this information from Richard, I was using Server 2016 which doesn’t support IKEv2 fragmentation.. after tons of troubleshooting with network equipment, ISP, Microsoft support.. we saw that the packet being shipped was too large and fragmentation was not working.

    Moving to server 2019 and adding the registry key to enable IKEv2 fragmentation allowed us to proceed. Messing with the MTU on certain devices prior to this move had no impact and it seemed to be limited somewhere out of our control.

    Thank you again Richard for pointing this out to me earlier (P.S. Microsoft support couldn’t figure this out).

    Reply
  2. Nori

     /  February 12, 2019

    Thank you Richard! Have been dealing with this issue and it looks like this might be the missing piece. Was about to use SSTP only.

    Reply
  3. Tim

     /  February 12, 2019

    What if Windows Server 2016 is being used?

    Reply
    • IKEv2 fragmentation is not supported on Windows Server 2016. You’ll have to deploy Windows Server 1803 or newer, or Windows Server 2019 to get IKEv2 fragmentation support in RRAS.

      Reply
      • timbo01

         /  February 13, 2019

        Does that mean that IKEv2 connections will not work? I am seeing SSTP connections work fine but IKEv2 connections failing on a new NLB RRAS setup using Windows 2016 Servers. The RasClient Event ID error on the client is: 1913 and the error is the same as this screenshot https://social.technet.microsoft.com/Forums/getfile/1382726

        On the NPS Server the user looks to be authenticated OK, the client just never shows “Connected” – Although I am getting a lot of 6275 event IDs saying “Network Policy Server discarded the accounting request for a user.” but it seems to be doing this for all connections (even SSTP)

        Could this be IP Fragmentation? But it worked on a test server (non-NLB setup with Server 2016. Any ideas?

      • It’s entirely possible. Only way to tell is to take a network trace on both sides (server and client) when the connection fails and compare the results. Also, for testing purposes you could put a client on the same subnet as the external interface of your VPN server and see if you can connect. If you can connect there but not from a remote subnet, it might be a fragmentation issue.

  4. Our company doesn’t have software assurance for Server 2019 so that’s not an option unfortunately. So, how do I prevent fragmentation? Is it as simple as by manually adjusting the MTU on the server and clients?

    Reply
    • You don’t, unfortunately. The problem is typically caused by large UDP packets that have to be fragmented at the IP layer. Also, this can be caused by any intermediary device along the path, so you may not have control over it anyway. Only way to definitively resolve the issue is to implement Windows Server 2019 and enable IKEv2 fragmentation. Otherwise you’ll just have to accept that some connections may fail. :/

      Reply
      • Thanks Richard. I always appreciate your diligence in replying indivdually to these messages.
        It’s a shame all these little niggles only seem to appear once the project is up and running and people are using the system – despite months of what I believed to be rigorous testing.
        Microsoft seem to love pushing these new technologies before they’re mature. I sometimes wish I’d stayed with DirectAccess. At least that was solid.

      • My pleasure, really. 🙂 It is too bad that Microsoft is still struggling with stability issues given that Always On VPN has been with us for more than two years now. Perhaps it is related to the new “Windows as a Service” model, or as I like to call it, “perpetual beta”. 😛 I now have many customers getting frustrated and looking to non-Microsoft solutions for mobility. It used to be that DirectAccess was displacing third-parties, now it’s seems to be swinging back the other way. 😉

  5. Anthony Guyon

     /  March 12, 2019

    HI Richard, firstly, thank you for this excellent post! I am just wondering if you have deciphered why a 1607 server (not supporting fragmentation) successfully authenticates a Windows 10 1803 client over VPN IkeV2 (with EAP set to smart card or other certificate) but not an 1809 client with an identical configuration. Comparing network traces look identical, but the server returns a fragmented packet (identical to your screen shot) when establishing with 1809, but not in 1803. The solution is likely to use an 1803 / 9 server (both supporting fragmentation), but it doesn’t seem to make sense. I would have expected the client to initiate fragmentation?

    Reply
    • Indeed, you’d expect the behavior to be the same in both cases, assuming the client and server are configured identically. 🙂 Why that’s happening I don’t know. However, I know after looking at many traces it can be different on the same client and server at different times, so it must not be out of the ordinary. I suspect it might have something to do with network paths. Perhaps a client makes a connection from a location with a lower Path MTU (PTMTU) in one scenario which causes IP fragmentation. From another location maybe the PMTU is larger so IP fragmentation doesn’t occur. That’s the only thing I can think of, really.

      Reply
      • Anthony

         /  March 14, 2019

        Sadly – I managed to get the fragmentation issue and the lack of an IP address issue fixed in 1809 and it still doesn’t work. I downgraded the strength of the certs in use from CNG EDCH512 to legacy key storage and it works. So the issue is that the Win10 1809 client does not correctly transmit authentication material to the 2019 VPN server. Its the same rig, the same client – with two certs. Just disabling and then enabling the certificate purposes makes the client select the only cert available. So I can swap between the new type and old type easily. So Its pretty conclusive, unfortunately.

      • Most interesting. Can you try reducing the Framed-MTU to 1344 on your NPS server and see if that helps? Details here: https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-np-configure#configure-the-eap-payload-size.

  6. Peter Enoch

     /  March 22, 2019

    Hi Richard / everyone. We’ve a Windows 2016 NPS/Always ON VPN installation and the VPN performance is VERY bad. Between 50-5000 KBps (10-650 KB/s). We’re only using User tunnels (we don’t have Win. Enterprise editions). We’re tried both with IKEv2 and SSTP. Is there anything to tweak or troubleshoot?

    What about Windows 2019, any news for Always ON ?

    Reply
    • Curious to know if you put the client on the same subnet as the VPN server if you have the same diminished performance? If so that might indicate that an intermediary device (router, firewall, etc.) could be impacting performance. Also, common things to look for (in physical environments especially) is port speed/duplex mismatches. I’d suggest taking a network trace on the client to look for signs of packet loss, queuing (QoS somewhere in the path misconfigured?) or heavy fragmentation. All of those could cause poor network performance.

      Reply
      • Pete Enoch

         /  March 24, 2019

        The clients get IP in same subnet as the VPN server / other servers. I think I found the “problem” yesterday. It seems our “old” DirectAccess installation (not same server as AlwaysOn) was still installed. After removing the DirectAccess Server Config and remove the roles everything runs a lot better. I got 100 Mbit performance using SSTP be Always On VPN using Wifi!. Maybe the old DirectAccess GPO still did something about the IPv6 tunneling that had very BAD performance when using DirectAccess.

      • I was suggesting to put the VPN client on the same subnet as the VPN server when testing to eliminate any firewalls or routers that might have been causing the problem. Glad you were able to get it sorted though. 🙂

    • rance

       /  June 24, 2019

      @ Peter Enoch
      We had high latency because of our Kemp load balancer
      https://support.kemptechnologies.com/hc/en-us/articles/360017832571-LoadMaster-7-2-43-Release-Notes
      PD-11441
      latency issues were experienced on UDP Virtual Services.
      Firmware upgrade sorted the problem.

      Now we have other problems with Always On VPN ;-(
      Hoping Windows 2019 and regedit sort ikev2 connections problems. Thanks for the info.

      @ Richard you have a few different websites with problems with Always on VPN, maybe send to MS, things to fix in 1908 build 😉

      Thank you for your time and help to the community!

      Reply
      • Thanks for the update! Using Windows Server 2019 is crucial if you’re planning to use IKEv2, so definitely recommend upgrading there. As for issues with 1903, while I’ve not had any troubles others have been reporting issues. I’ve forwarded them to my contacts at Microsoft for review. I will definitely post something if I learn more.

  7. Nagu

     /  May 8, 2019

    Hello Richard
    Regarding the reg value where does the -Force go? Cannot enter it within the DWORD EnableServerFragmentation.

    Reply
    • The -Force switch should go at the end of the command.

      New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\” -Name EnableServerFragmentation -PropertyType DWORD -Value 1 -Force

      Reply
      • Nagu

         /  May 8, 2019

        OK Richard. I set it up by going down the path in Regedt31, creating the DWORDand entering the value 1.

      • That works too. 🙂 Don’t forget to restart the server for the changes to take effect!

  8. Heath Mannering

     /  June 11, 2019

    Hi Richard,
    We have followed this information here, which is great BTW, and we have confirmed in the IKE_SA_INIT Initiator Request there is IKEV2_FRAGMENTATION_SUPPORTED but do not see this correspondingly in the IKE_SA_INIT Responder Response.

    Is this expected behaviour our should we see the notify message returned in the Response as well?

    NAT_DETECTION_SOURCE_IP & NAT_DETECTION_DESTINATION_IP for example are Request’d and Respond’d equally in the IKE_SA_INIT packets.

    Could you perhaps confirm either way what your real world traces actually show?

    Reply
    • If you’ve enabled IKEv2 fragmentation on the server, you should definitely see the IKEV2_FRAGMENTATION_SUPPORTED option in the network trace. If it isn’t there, verify the registry key is set and make sure you restart the server (not just the Routing and Remote Access service) for the change to take effect.

      Reply
  9. Nagu

     /  June 27, 2019

    Hello Richard
    just been reading the discussion. So is it the case that IKE2 fragmentation does not work on servers below 2019? After seeing your article on Always on VPN and IKE2 fragmentation and it needs 2016 to work so we tried a 2016 server but still does not work. We have a long standing call open with Microsoft but they have not come back to say we need a 2019 server for it to work. We have provided numerous packet captures to them but they do not know why it is not working still. Is it for sure it will work with 2019?

    Reply
    • Correct. Support for IKEv2 fragmentation in Windows Server wasn’t added until 1803 (semi-annual channel) and Windows Server 2019 (long term channel). It is not support in Windows Server 2016. If you are certain you have an IKEv2 fragmentation issue then moving to Windows Server 2019 and enabling this feature is definitely recommended. There is a possible workaround for earlier versions of Windows Server but it’s not something I’ve ever tested. Drop me an email and I can provide you with more details.

      Reply
  1. Troubleshooting Always On VPN Error Code 809 | Richard M. Hicks Consulting, Inc.
  2. Always On VPN IKEv2 Load Balancing with F5 BIG-IP | Richard M. Hicks Consulting, Inc.
  3. Always On VPN IKEv2 Features and Limitations | Richard M. Hicks Consulting, Inc.

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: