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

      • Antonio M.

         /  October 8, 2020

        Hi Richard, I read this article and related thread very carefully due to we’re experiencing same problem in our IKEV2 vpn on Windows server 2016. Please can you explain me the work around for earlier version than 1809?
        Thanks very much for your clear suggestion on this investigation.

      • The workaround involves setting the Framed-MTU attribute to 1344 bytes. However, feedback has been generally negative. It doesn’t seem to provide any relief in most cases, unfortunately.

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

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

    • There is no specific size you can configure on your side because the MTU could be reduced anywhere along the path.

  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!

  19. Volker

     /  October 16, 2020

    Hi, had a problem with the Device Tunnel I want to share. VPN was connected but not everything was working, mostly because some communication probems with the domain controllers. Reboot took 9 minutes and logon another 9 minutes. Client could not athenticate new user. VPN was classified as public network…
    In the end it was a problem with mtu size. I reduced mtu for ethernet to 1300 so device tunnel was 1200 and now everything is working as expected. Took me some hours to find, since I thought with enabled fragmentation this would not be neccesary.

  20. Antonio Massara

     /  October 19, 2020

    Richard using your suggestion we resolved fragmentation issue on a widows server 2016 RRAS server, but still experiencing frequent disconnections.
    We identified one of the cause in a high latency packet on isakmp packet and particularly this schema:
    All works fine:
    – Server send to the client informational responder request
    – Client send to the server informational initiator response with latency 1sec

    Is there any way to increase this latency limit or force the server to send the Delete after more than 1 slow packet?


  21. Hi once again many thanks to everyone who contributes here , I have noticed that when copying files from network over the vpn seems to be slow, i can access everything without issues. Our current cisco anyconnect appears much faster, eg if i copy a 500mb file it is twice the speed on cisco. At the moment I am the only user on the alwayson I have tried both IKE and SSTP (sstp actually appears slower) can anyone recommend any tips / tricks / tweaks to the server that may help increase the speed.

    many thanks

    • VPN throughput complaints when using RRAS are common, unfortunately. It could be anything, really. Most commonly it is network configuration for the VPN server or even resources (e.g. not enough CPU or memory). Always challenging to troubleshoot too.

    • Hi Richard

      I have deployed device tunnel which connects to certain DC’s for authentication, I also then have the user tunnel to access the internal resources

      My device profile has the routes to the DC;s I also have these routes in the user tunnel , is this likely to cause issues and should i just keep the dc’s route in the device profile only and remove from user tunnel?

      many thanks (almost there)

      • No issues at all. You’ll have some overlap between the two, but Windows prefers the more specific route when making a choice. If the routes are the same, then Windows prefers the route with the lowest metric.

  22. Johan Barkhuizen

     /  January 30, 2021

    Enabling RAS adapter fragmentation caused annoying lags on streams and pings. Completely disabled all checking on adapters and problems went away. Was wondering if anyone else experienced the same?

  23. Ajay patel

     /  March 4, 2021

    Hi Richard . We have a somewhat similar issue where we are using IKEv2 and Always on worked a treat until about mid December 2020 when users on a certain broadband provider couldn’t connect anymore .
    we have tried many things including disabling ipv6 on the home routers to changing mtu sizes to no avail , we still get the dreaded 809 error .
    is there anything else you think we could try ? I have been in touch with the broadband supplier and there back end engineers have had a look and told me is was now resolved but its not . It works with all other big broadband suppliers ok eg BT .. Virgin .

    • Sorry to hear about this. I can only suggest that you take a network trace on the client and the server and watch for evidence of dropped communcation. Typically this happens during the switch from UDP 500 to 4500. For example, you’ll see the initial handshake start on UDP 500, then you’ll likely see the client send packets on UDP 4500 and the server won’t see them. If that’s the case, you’ll know something in the middle is dropping them. You can use this to demonstrate to the ISP they aren’t allowing the requests.

      • Ajay patel

         /  March 5, 2021

        Hi Richard , thanks for your quick reply . We solved the issue last night by upgrading the RAS server from windows server 2016 to 2019 and we can all connect again regardless of broadband provider.
        it was down to one of your suggestions to someone else that made us think of it so thank you very much . You have saved us from a big headache.

  24. ced666

     /  March 18, 2021

    Hello Richard,

    Hello Richard,

    By default under WIndows 10, what is the size of an IKE fragment?

    Although IKE fragmentation is enabled by default since Windows 10 1803, can IKE fragmentation be disabled (this is only for testing)?

    thank you very much



    • There is no default size. Without IKE fragmentation support eanbled, IKE could send more data than the IP MTU allows, resulting in fragmentation at the IP layer. With IKE fragmentation support enabled, IKE looks at the MTU and knows when the data it wants to send will exceed this value. It then performs the fragmentation at the IKE layer, preventing IP fragmentation.

  25. Loren

     /  May 18, 2021

    Hey Richard

    This is kind of a repeat question, but can you confirm that the IKEv2_FRAGMENTATION_SUPPORTED has to be in both the

    IKE_SA_INIT MID=00 Initiator Request
    IKE_SA_INIT MID=00 Initiator Response

    I am only see it in the Request packet captured on my client machine. Not in the Response packet from the VPN server. The registry key is in place.


    • If the response packet does not include IKEv2_FRAGMENTATION_SUPPORTED then it is not enabled. Make sure you configure the registry key and restart the server (restarting the service is not sufficient). Also, make sure you are running Windows Server 2019 or later. This option is not supported in Windows Server 2016 and earlier servers.

  26. Jürgen

     /  February 2, 2022

    Hey Richard,

    thanks for all the Allways On information.

    I have a user sitting in Phoenix/USA.

    He uses a Windows 10 client with AOVPN to our location in Germany.
    We use a Edge firewall and a Windows 2019 Always On Server.

    All users in Germany have no problems.

    Only the user in Phoenix can´t access the file server properly (it´s slow, really slow. about 2-20KB/s).

    ike fragmentation is enabled and verified at client side here in Germany.

    Do you have any idea, why it´s so slow?

    I disabled IPS protection in the firewall for the connection.

    MTU pathscan give us MTU of 1399

    We tried 512,1000,1230,1350,1400 with no difference in speed.
    He has fibre line with 400/200 and he tested at different locations (Home Office, Public WiFi, University).

    File Server is Windows 2016



  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.
  6. Always On VPN IPsec Root Certificate Configuration Issue | Richard M. Hicks Consulting, Inc.

Leave a Reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading