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


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

A PowerShell script to implement IKEv2 fragmentation can be found on my GitHub here.

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


  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).

  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.

  3. Tim

     /  February 12, 2019

    What if Windows Server 2016 is being used?

    • 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.

      • 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

        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?

    • 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. :/

      • 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?

    • 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.

      • 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:

  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 ?

    • 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.

      • 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
      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!

      • 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.

    • 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

      • 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?

    • 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.

  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?

    • 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.

      • Nagu

         /  June 27, 2019

        Hello Richard
        Yes please let me know the work around for earlier versions please.

      • Reach out to me directly and I’ll share that information with you. Thanks!

      • Colin

         /  June 27, 2019


        I was wondering, do you have any experience or documentation with using Always On VPN with Azure? Either 3rd party services or possibly point to site VPN’s directly in Azure?

        With RRAS not officially supported in Azure, I’m wondering what options there are for client AOVPN to Azure.

      • Nagu

         /  July 1, 2019

        Hello Richard
        I could not find your email so I done contacted you via the web site contact page. Hope you got my message.

      • Haven’t seen anything yet. :/ I’ll drop you a note now. 🙂

      • Alan B

         /  September 3, 2019

        Hi Richard, thanks for the brilliant articles. Really great and helpful. I am troubleshooting something similar with 2016 and wondering if you wouldn’t mind sharing the steps to fragment with earlier versions than 2019.. I think my issue might be slightly different but definitely worth trying I think. I couldn’t find your email but would appreciate if you could drop me a note too?
        Many thanks in advance.

      • Will do. 🙂

  10. Josemi

     /  August 21, 2019

    Hi, thank you for the post, Richard, very useful. From mtupath tool to registry key and the instructions to solve the issue.
    I did an in-place upgrade to WS2019, because I think that WS2016 1803 or newer are only in core (without GUI), and after adding the registry key, the Notify for IKEv2_FRAGMENTATION_SUPPORTED is now sent from server to client. I will test this afternoon the connection from my home in which I have the router that produces this behaviour.
    Thank you again. Regards

    • My pleasure! And yes, you are correct, support for IKEv2 fragmentation was first introduced in Windows Server 1803. That is a semi-annual channel (SAC) release and does not have a GUI. Windows Server 2019 is the first version of Windows Server with a GUI that supports this important feature.

  11. Hi Richard,

    perhaps you saw this in some environment? And perhaps this is IKEv2-Fragmentation related?
    I have a customer who only likes to use the device tunnel (IKEv2, Splittunnel).
    Clients are Win10 Enterprise 1809, fully patched.
    Server is Windows 2016 RRAS.

    One Client @Home is placed behind his router, and no matter if in WIFI oder connected via cable to his router,
    Always On is connected (can see an IP with ipconfig) bin in ncpa.cpl behind the Device Tunnel connection stands: not authenticated.
    Accessing internal ressources is not comfortable, errors and timeouts do appear.
    Switching to a tethered connection via Smartphone leads directly to a normal connection (no authentication error) and Always On is working finde).

    Any ideas to this issue? We now set up an unbranded client with Win 10 1909 an do a router reset @Home.
    Afterwards we will replace the Windows Server 2016 with Windows Server 2019.

    Greets, Karsten…

  12. jeff jarratt

     /  October 17, 2019

    Thank you Richard,

    Using your guide, I was able to determine that IKEv2 fragmentation was happening, I enabled it on my server via the registry key method, and confirmed that the problem is now resolved.

    My Windows 10 clients still cannot connect, however. I am on Server 2019. I am getting error 13801. I have ran through all of the solutions here and am at a dead end.

    Its worth mentioning that I am running a single nic on my RAS server, against the recommendation of the guide. I am using my firewall to NAT the traffic, and i see in my clients network trace that i am getting IKE response packets, so i believe the networking is sorted.

    On my RAS server, i see the following error in the event log:
    Event 20255
    The following error occurred in the Point to Point Protocol module on port: VPN2-69, UserName: . Negotiation timed out

  13. Lee Humphreys

     /  January 17, 2020

    Hi Richard,

    After yet again no mention of the above in the official MS documentation, I have been able to get my Client to connect and resolve the IKEv2 Fragmentation issue – I had to upgrade the RRAS Server to 2019 and apply the Registry Key.

    I’m still getting Fragmentation further down the line which I think is breaking NPS. My Client can connect fine when set to use only Machine Certs (Authentication done on the RRAS Server), but when set to EAP and User Certs, the Client connection fails with Error 812.

    Capturing the RADIUS traffic between the RRAS Server (DMZ) and the NPS Server (Core Network) I can see that the RADIUS traffic is being Fragmented. I’m assuming this is causing the Client failure? I have triple checked all settings in NPS, RRAS and Client. I have set the Framed-MTU value on the NPS Connection Policy, but I’m assuming this is being ignored because it is the RRAS Server that is initiating the RADIUS request?

    I can’t find any official MS docs on this issue – is this something that you have come across or are aware of any other ways to prevent the RADIUS Fragmentation?


    • To be clear, IP fragmentation is not itself the problem. The problem is firewalls blocking IP fragments. Have a close look at the firewall between your VPN server and NPS server and see if that’s the case.

      As for the 812 error, do you see this logged in the NPS server’s application log in the event viewer? Which rule processed the request? It should give some indication as to why the authentication request was rejected. If you don’t see anything at all and you are running Windows Server 2019 NPS, there’s a known issue with the firewall that prevents inbound RADIUS requests. Details here:

      • Lee Humphreys

         /  January 18, 2020

        Hi Richard,

        The 812 Error is logged by the RasClient on the Windows 10 Client. There are no entries logged on the NPS Server, however I can see from the DTS Log on the NPS Server that it is receiving the request and responds with Error 0 (which I believe is Success). The Wireshark capture shows traffic flowing between the NPS and RRAS Server, but many Fragmented packets – similar to the IKEv2 issue above. The Policy that processes this on the NPS Server is “Virtual Private Network (VPN) Connections”. NPS Server is 2016.

        The main error is on the RRAS Server, which logs 2 events – Event 20271 “The connection was prevented because of a policy configured on your RAS/VPN Server…” and this is for my User Account with the Cert and in the correct AD Group. This is then followed up immediately with Event 20255 “The following error occurred in the Point to Point Protocol module on port: VPN2-127, UserName: . The connection was prevented…”. If I then disable all Protocols on the RRAS Server except for IKEv2, I then get the same Event 20271 logged, but then followed up with Event 20255 “The following error occurred in the Point to Point Protocol module on port: VPN2-127, UserName: . Negotiation timed out”.

        I can use any other Protocol on the Client and NPS Server which connect fine, such as EAP with Username & Password – as soon as I try and use PEAP with Certs the above happens. In working Captures, you can clearly see the RADIUS Accept packet being sent and received – but not when using EAP with Certs, just constant Request Response.

        It would appear that connectivity between the RRAS and NPS Servers is the issue, so as a test I will next install NPS directly on the RRAS Server and have this perform RADIUS locally, and see what happens.

        Failing that I will then upgrade the NPS Server to 2019. Surprised that I appear to be the only one here who has encountered this issue?


      • This sure does seem like IKEv2 fragmentation, but if you’re running Windows Server 2019 and have enabled the registry setting, that shouldn’t be the issue. Do you see a RADIUS accept message sent from NPS to the VPN server in your network traces? If you take a network trace simultaneously on the client and server, do you see any evidence of packets being dropped? Same thing for NPS/VPN server communication, any evidence of packets being blocked between them?

      • Lee Humphreys

         /  January 20, 2020

        Placing NPS on the same RRAS Server works fine. Can fully connect using IKEv2, and PEAP with User Cert. So off to work with the Network Team to find where the packets are being dropped between the original NPS Server (Core Network) and RRAS Server (DMZ).

        It has been revealed that my RADIUS traffic is actually traversing 2 Firewalls (not 1 as I first believed) so we are starting the investigations there.


      • Good to know. Sure bet one of them is probably blocking IP fragments!

    • Hello, I hope you are well.

      Out of interest, when enabling IKEv2 fragmentation support on Windows Server 2019 via the registry key, should we be enabling his support on the NPS server as well as the RRAS servers even if the NPS server is separate to the RRAS servers?

      Just curious as I have enabled this setting on the RRAS serves and its fixed some connection issues, but we still have a lot of people with a similar error.



  14. Zack

     /  April 9, 2020

    Will enabling the registry setting for EnableServerFragmentation on the server have any adverse effects if running a mix of 1709 and 1809 clients, or will 1809 clients simply use the feature while 1709 will not?

    • Nothing to worry about here. If you have clients that don’t support it they’ll simply ignore it and proceed as usual without IKE fragmentation.

      • Zack

         /  April 10, 2020

        Thank you sir. I did a packet capture and saw that it was already enabled by default on my 2019 server.

        I get just as much value from the comments as your blog postings.

      • Agreed. It’s great to learn from the shared experience of others!

  15. victor bassey

     /  May 21, 2020

    Hello Richard,please which packet capture tool did you use to view this information?

  16. Steven

     /  June 2, 2020

    Hi Richard, We are having issues with what we believe is fragmentation. Is there a definitive packet size that you have to allow on edge Firewall. We believe our Firewall is dropping packets.

  17. Panos83

     /  July 23, 2020

    Hello i have a device tunnel always on vpn with rras 2016 server.I receive disconnects from clients and reconnections.I can identify the following on server side
    [2520] 10:51:42: RasLineGetCallInfo: The needed size (0x290) for LINECALLINFO is more than the allocated size (0x158)
    [2520] 10:51:42: ProcessEvent: Setting media mode to 0x0
    [2520] 07-23 10:51:42:053: RasTapicallback: msg=2 , param1=2l , param2=0l
    [2520] 07-23 10:51:42:053: RasTapicallback: linecallstate=0x2
    and on client side
    What can be the problem?

    • Not certain, but it could be related to IP fragmentation. Unfortunately Windows Server 2016 does not support fragmentation at the IKE layer. You’ll have to migrate to Windows Server 1803 or later (Windows Server 2019 being the first server with GUI to support it).

  18. Rick

     /  August 13, 2020

    Thanks for all your posts Richard, we use a Device Tunnel only and enabling IKE Fragmentation improved stability tenfold. We also referenced many of your other articles to improve stability and performance keep it up!

  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.
  4. Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC | Richard M. Hicks Consulting, Inc.
  5. Always On VPN Device Tunnel and Custom Cryptography Native Support Now in Intune | 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: