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.”
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.
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.
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.
Additional Information
Windows 10 Always On VPN IKEv2 Security Configuration
RFC 7383 – IKEv2 Message Fragmentation
Colin
/ February 11, 2019This 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).
Richard M. Hicks
/ February 11, 2019My pleasure! Glad you were able to get things working again! 🙂
Nori
/ February 12, 2019Thank you Richard! Have been dealing with this issue and it looks like this might be the missing piece. Was about to use SSTP only.
Tim
/ February 12, 2019What if Windows Server 2016 is being used?
Richard M. Hicks
/ February 12, 2019IKEv2 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, 2019Does 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?
Richard M. Hicks
/ February 13, 2019It’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.
andychips
/ February 13, 2019Our 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?
Richard M. Hicks
/ February 13, 2019You 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. :/
andychips
/ February 13, 2019Thanks 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.
Richard M. Hicks
/ February 15, 2019My 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. 😉
Anthony Guyon
/ March 12, 2019HI 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?
Richard M. Hicks
/ March 12, 2019Indeed, 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, 2019Sadly – 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.
Richard M. Hicks
/ March 15, 2019Most 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.
Peter Enoch
/ March 22, 2019Hi 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 ?
Richard M. Hicks
/ March 24, 2019Curious 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, 2019The 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.
Richard M. Hicks
/ March 24, 2019I 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!
Richard M. Hicks
/ June 24, 2019Thanks 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.
Nagu
/ May 8, 2019Hello Richard
Regarding the reg value where does the -Force go? Cannot enter it within the DWORD EnableServerFragmentation.
Richard M. Hicks
/ May 8, 2019The -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, 2019OK Richard. I set it up by going down the path in Regedt31, creating the DWORDand entering the value 1.
Richard M. Hicks
/ May 9, 2019That works too. 🙂 Don’t forget to restart the server for the changes to take effect!
Heath Mannering
/ June 11, 2019Hi 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?
Richard M. Hicks
/ June 13, 2019If 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.
Nagu
/ June 27, 2019Hello 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?
Richard M. Hicks
/ June 27, 2019Correct. 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, 2019Hello Richard
Yes please let me know the work around for earlier versions please.
Richard M. Hicks
/ June 27, 2019Reach out to me directly and I’ll share that information with you. Thanks!
Colin
/ June 27, 2019Richard,
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.
Richard M. Hicks
/ June 27, 2019Absolutely. Details here: https://directaccess.richardhicks.com/2019/06/24/always-on-vpn-options-for-azure-deployments/.
Nagu
/ July 1, 2019Hello Richard
I could not find your email so I done contacted you via the web site contact page. Hope you got my message.
Richard M. Hicks
/ July 1, 2019Haven’t seen anything yet. :/ I’ll drop you a note now. 🙂
Alan B
/ September 3, 2019Hi 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.
Al
Richard M. Hicks
/ September 10, 2019Will do. 🙂
Antonio M.
/ October 8, 2020Hi 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.
AM
Richard M. Hicks
/ October 16, 2020The 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.
https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-np-configure#configure-the-eap-payload-size
Josemi
/ August 21, 2019Hi, 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
Richard M. Hicks
/ August 21, 2019My 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.
Karsten Hentrup
/ October 2, 2019Hi 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…
Richard M. Hicks
/ October 7, 2019Sure sounds like IKEv2 fragmentation. Taking a network trace on the client and the server at the same time will certainly confirm that.
Karsten Hentrup
/ November 6, 2019Yop, Server 2019 did the trick! 😉
Richard M. Hicks
/ November 10, 2019Sweet! 😁
jeff jarratt
/ October 17, 2019Thank 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.
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/always-on-vpn-deploy-troubleshooting
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
Richard M. Hicks
/ October 21, 2019Is this a device tunnel or user tunnel?
Lee Humphreys
/ January 17, 2020Hi 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?
Thanks,
Lee
Richard M. Hicks
/ January 17, 2020To 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: https://directaccess.richardhicks.com/2018/11/27/always-on-vpn-and-windows-server-2019-nps-bug/.
Lee Humphreys
/ January 18, 2020Hi 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?
Thanks,
Lee
Richard M. Hicks
/ January 18, 2020This 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, 2020Placing 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.
Thanks,
Lee
Richard M. Hicks
/ January 20, 2020Good to know. Sure bet one of them is probably blocking IP fragments!
trotterd
/ April 28, 2020Hello, 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.
Regards,
Dave
Richard M. Hicks
/ April 28, 2020You will only need to make this change on the VPN server. 🙂
Zack
/ April 9, 2020Will 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?
Richard M. Hicks
/ April 10, 2020Nothing 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, 2020Thank 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.
Richard M. Hicks
/ April 11, 2020Agreed. It’s great to learn from the shared experience of others!
victor bassey
/ May 21, 2020Hello Richard,please which packet capture tool did you use to view this information?
Richard M. Hicks
/ May 21, 2020Microsoft Network Monitor or Wireshark should work. You could even use netsh.exe as described here: https://docs.microsoft.com/en-us/windows/win32/ndf/using-netsh-to-manage-traces. 🙂
Steven
/ June 2, 2020Hi 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.
Richard M. Hicks
/ June 4, 2020There is no specific size you can configure on your side because the MTU could be reduced anywhere along the path.
Panos83
/ July 23, 2020Hello 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
20227—868
20227—809
What can be the problem?
Richard M. Hicks
/ July 23, 2020Not 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).
Rick
/ August 13, 2020Thanks 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!
Richard M. Hicks
/ August 14, 2020Great to hear! 🙂
Volker
/ October 16, 2020Hi, 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.
Richard M. Hicks
/ October 16, 2020That’s quite unusual. Did you change the MTU on the VPN server? Client? Both?
Volker
/ October 18, 2020I only changed the MTU on the Client.
Richard M. Hicks
/ October 19, 2020Ok, good to know! 🙂
Antonio Massara
/ October 19, 2020Hi,
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?
Regards
Antonio
Richard M. Hicks
/ October 19, 2020Not to my knowledge.
Andrew
/ January 26, 2021Hi 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
Richard M. Hicks
/ January 26, 2021VPN 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.
Andrew
/ January 27, 2021Many thanks for quick response, I was also experiencing blue screen memory crash fault when trying to transfer large files e.g 500mb) both on win10 1809 and 1909. I applied the ncsi fix (https://directaccess.richardhicks.com/2019/04/17/always-on-vpn-updates-to-improve-connection-reliability/) since applying that it has made a huge improvement to the transfer speed and has fixed the memory crash issue.
Richard M. Hicks
/ January 27, 2021Good to know. Thanks for the update!
andrew
/ January 28, 2021Hi 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)
Richard M. Hicks
/ January 29, 2021No 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.
Johan Barkhuizen
/ January 30, 2021Enabling 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?
Richard M. Hicks
/ February 5, 2021I’ve not experienced that myself.
Ajay patel
/ March 4, 2021Hi 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 .
Richard M. Hicks
/ March 4, 2021Sorry 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, 2021Hi 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.
ced666
/ March 18, 2021Hello 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
Patrick
Patrick
Richard M. Hicks
/ March 22, 2021There 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.
Loren
/ May 18, 2021Hey 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
and
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.
thanks
Richard M. Hicks
/ May 20, 2021If 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.
Jürgen
/ February 2, 2022Hey 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
Thanks
Jürgen
Richard M. Hicks
/ February 3, 2022Most likely due to a bug in the Windows IKE implementation. Details here: http://gary-nebbett.blogspot.com/2021/07/slow-performance-of-ikev2-built-in.html.