When testing an Always On VPN connection, the administrator may encounter a scenario where the VPN client fails to connect to the VPN server. On the Windows 10 client the error message states 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.”
In addition, the Application event log records an error message with Event ID 20227 from the RasClient source. The error message states the following.
“The User [username] dialed a connection named [connection name] with has failed. The error code returned on failure is 809.”
Connection Timeout
The error code 809 indicates a VPN timeout, meaning the VPN server failed to respond. Often this is related directly to network connectivity, but sometimes other factors can come in to play.
Troubleshooting VPN Error Code 809
When troubleshooting VPN error code 809 the following items should be carefully checked.
- Name Resolution – Ensure the VPN server’s public hostname resolves to the correct IP address.
- Firewall Configuration – Confirm the edge firewall is configured properly. Inbound TCP port 443 is required for the Secure Socket Tunneling Protocol (SSTP) and inbound UDP ports 500 and 4500 are required for the Internet Key Exchange version 2 (IKEv2) protocol. Make sure that any NAT rules are forwarding traffic to the correct server.
- Load Balancer Configuration – If VPN servers are located behind a load balancer, make certain that virtual IP address and ports are configured correctly and that health checks are passing. For IKEv2 specifically, it is crucial that UDP ports 500 and 4500 be delivered to the same backend server. This commonly requires custom configuration. For example, on the KEMP LoadMaster the administrator will configure “port following”. On the F5 BIG-IP a custom “persistence profile” must be configured. On the Citrix NetScaler a “persistency group” must be defined.
IKEv2 Fragmentation
VPN error code 809 can also be caused by IKE fragmentation when using the IKEv2 VPN protocol. During IKEv2 connection establishment, payload sizes may exceed the IP Maximum Transmission Unit (MTU) for the network path between the client and server. This causes the IP packets to be fragmented. However, it is not uncommon for intermediary devices (routers, NAT devices, or firewalls) to block IP fragments. When this occurs, a VPN connection cannot be established. However, looking at a network trace of the connection attempt, the administrator will see that the connection begins but subsequently fails.
Enable IKEv2 Fragmentation Support
The IKEv2 protocol includes support for fragmenting packets at the IKE layer. This eliminates the need for fragmenting packets at the IP layer. IKEv2 fragmentation must be configured on both the client and server.
Client
IKEv2 fragmentation was introduced in Windows 10 1803 and is enabled by default. No client-side configuration is required.
Server
IKEv2 is commonly supported on many firewall and VPN devices. Consult the vendor’s documentation for configuration guidance. For Windows Server Routing and Remote Access (RRAS) servers, IKEv2 fragmentation was introduced in Windows Server 1803 and is also supported in Windows Server 2019. It is enabled via a registry key. The following PowerShell command can be used to enable IKEv2 fragmentation on supported servers.
New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\” -Name EnableServerFragmentation -PropertyType DWORD -Value 1 -Force
Validation
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 and IKEv2 Fragmentation
gatorcritfcorg
/ August 23, 2019Your fix appears to have fixed the very frustrating problem I was having with IKEv2 on a W2016 VPN proof of concept I am testing. It worked internally, but failed from the i-net. I could see port 500 traffic coming across the firewall, but no 4500, a real head scratcher and time waster. And then I came upon this IKE fragmentation article, which offered a way forward from a highly qualified source no less. I proceeded to download a copy of W2019, configure it as a VPN server and walla! Connected. Thank you very much!
Richard M. Hicks
/ August 24, 2019Another satisfied customer! Glad I was able to help. 🙂
ivarson
/ September 18, 2019Whatever we’re looking for regarding Microsoft VPN, we always end up here. Great articles!
Richard M. Hicks
/ September 18, 2019Great to hear! Thanks for visiting! 🙂
Matt
/ November 1, 2019Richard – Thank you for always providing amazing articles on DirectAccess/Always On VPN.
We were battling with the IKEv2 Fragmentation issue for a while. I regularly checked your site for new information on the issue and as I hoped you have provided a solution!
Richard M. Hicks
/ November 1, 2019My pleasure! 😁
Russell Cozens (@RJCozens)
/ November 3, 2019I had these exact symptoms but it was the “Xbox Live Networking Service” that caused the problem. Stopping it allowed me to connect,
Abe
/ December 6, 2019I’ve also ran into this error and it’s ended up being the workstations Internet connection. I often test the VPN using my Samsung S8 Verizon hot spot and occasionally I get the 809 error. Usually rebooting my phone resolves it, or just waiting for Verizon to fix their network problems.Thanks Richard, all of your articles are always AMAZING.
Gustav
/ March 17, 2020Hello VPN-master Rickard! Thank you for your blog and all the help that we’ve been getting thanks to it.
We’re running a Windows Server 2019 RAS / AOV solution that’s been working for a while. Recently we had to change IP-scope to a bigger one and after that we’re seeing some strange issues.
I found this blog when I was searching on Rasclient event ID 20227 + failure 809. We’re seeing the exact symptoms although IKEv2 Fragmentation is activated on server (and by default on Win 10 1909 clients). I just wanted to double check with you that we actually have IKEv2 Fragmentation issues:
1. Network capture from client shows one frame sent to RAS without “IKEV2_FRAGMENTATION_SUPPORTED”.
2. Network capture from RAS shows three identical frames without “IKEV2_FRAGMENTATION_SUPPORTED”.
Does this mean that IKEV2_Fragmentation isn’t working?
Thanks in advance!
Richard M. Hicks
/ March 18, 2020That’s unusual. During the initial IKEv2 handshake your client should indicate it supports IKEv2 fragmentation. If it doesn’t do that, it must be disabled. How that happened I have no idea because it is supposed to be enabled by default. Check that registry key on the client and make sure it wasn’t somehow disabled that way.
Gustav
/ March 19, 2020Thanks for answering! Yes, it’s really strange. And the timing for unusual VPN-problems is far from the best..
When comparing route print on previous working config with current I found that we were missing a default route to gateway on public facing interface. After adding it (as persistant) I can see more IKE-responds from RAS. Also new traffic on protocol TEREDO “Tunneling IPv6 over UDP through NATs, Malformed Packet”. And client failure 809 is gone!
route add -p 0.0.0.0 mask 0.0.0.0 if
Now we’re moving on to new error, failure 812 but I’ve already found your other threads regarding that and started investigating problems with our NPS.
Thank you for this (almost lifesaving) site and all the times you’ve helped us since we deployed Windows Server 2019 VPN + AOV.
Have a great day Rickard!
Paddy Berger
/ April 29, 2020Hi Richard, I have a weird problem which I have now noticed a few times and wanted to know if you have come across this. I have a fully working aovpn solution across two sites, I have noticed that you can be working on the vpn but then all of a sudden no user can reconnect and they get the error 809/network connection between computer and vpn could not be established. A reboot of the server and all start to connect again. This has happened on both sites I have and not sure what the underlying issue maybe. It is random in that the connection could be stable for days and then stop accepting connections.
Any ideas?
Paddy Berger
/ April 29, 2020Also to add, this wont happen to both sites at the same time, so we can still failover and work normally on the other vpn server if one seems to stop accepting connections.
Richard M. Hicks
/ April 29, 2020What VPN protocol are you using? And are the servers in each site behind a load balancer?
Paddy Berger
/ April 30, 2020I am using IKEv2 for both device and user tunnel. Setup is domain name to azure traffic manager to either domain name site, which then sends the connection traffic to citrix NetScaler and then to the vpn server. Same setup for both sites.
Richard M. Hicks
/ April 30, 2020The issue has to do with the way your load balancer is configured. It is most likely performing NAT, which causes a problem for IKEv2. Best way to resolve it is to configure the NetScaler to pass the client’s original IP address to the VPN server. Details here: https://directaccess.richardhicks.com/2020/04/13/always-on-vpn-ikev2-load-balancing-and-nat/.
If for some reason you can’t make this change, consider implementing the registry entry in the above referenced post.
Spyros Ioakeim (@sioakeim)
/ May 1, 2020My solution was this:
https://support.microsoft.com/en-us/help/926179/how-to-configure-an-l2tp-ipsec-server-behind-a-nat-t-device-in-windows
Windows 10 Client
Windows 2019 Server for RRAS on private IP (single-NIC)
Firewall: PFsense
victor bassey
/ October 9, 2020Hell Spyros, did you use registry value 1 or 2? Were you using IKEv2 protocol? And did the Changes help?
Reason I ask, I have similar setup as yours but with SonicWall firewall. I’m having different experience with different home users. At some time the RRAS server just stops accepting connection from certain users and generating error 809. I have IKEv2 fragmentation enabled. Rebooting the customers home router most times allow the connection to be made, but issue re-occurs randomly again after a whille.
Gustav
/ May 13, 2020Hello Mr Hicks and thank you for this much well-needed blog.
My organization is having some problems with AOV and event ID 20227 error code 809. We have ~70 locations spread around the country with different ISP’s but identical Cisco network devices. AOV works for every site except one..
When running Network Monitor capture we can see that requests from this site is reaching the RAS, three IKE_SA_INIT with Flags = Initiator but there’s no Flags = Responder coming from the RAS back to the client as we can see with all other connection requests from other sites.
Client hardware/OS (Windows 10 1909) is identical on all sites. RAS running Windows Server 2019.
EnableServerFragmentation registry key on RAS (although we’re not seeing IKEV2_FRAGMENTATION_SUPPORTED in packets using
Microsoft Network Monitor 3.4, neither on successfull or failed connection attempts)
UDP port 500/4500 should be open everywhere
Tried AssumeUDPEncapsulationContextOnSendRule (not needed on all other working clients/sites)
Xbox Live Networking Services is not existing in Services on clients
Do you have any idea why our RAS isn’t sending any IKE_SA_INIT with Flags = Responder to one of our 70 sites?
Richard M. Hicks
/ May 14, 2020As long as the server is running Windows Server 2019 and the registry key is in place it should work. If you aren’t seeing the server respond with IKEV2_FRAGMENTATION_SUPPORTED I’d assume the registry key is misconfigured or missing entirely, or the server is not Windows Server 2019.
Gustav
/ May 14, 2020Thanks for answering Richard!
RAS is running Windows Server 2019 version 1809 (OS Build 17763.107).
Registry key is triple checked:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IKEV2\EnableServerFragmentation
DWORD = 1
We’ve checked alot of IKE_SA_INIT packets (both successful and the ones resulting in 809) and there’s no “IKEV2_FRAGMENTATION_SUPPORTED” when checking with Microsoft Network Monitor 3.4. Which program do you use?
But the fact that we have 69 working sites with a total of around 600 devices tells me IKEV2 Fragmentation actually works. What are the odds that only one of 70 ISP’s block IP fragments?
Is it possible to see some log or something why RAS just seems to drop the Initiator packets that it’s receiving from this specific site?
Richard M. Hicks
/ May 15, 2020IKEv2 is support in Windows Server 1803 and later, so you should be good there. Quite unusual that you won’t see the server respond with IKE fragmentation support indicated in the initial handshake though. I don’t have an answer for you why that’s happening. I use Wireshark, but Network Monitor should work as well. Are you taking the trace from the client or the server? I’d suggest doing both at the same time and comparing. If it is fragmentation-related you’ll see the server respond but the client won’t see it.
Gustav
/ June 10, 2020Hello again Mr Hicks.
(There was no reply button to your last reply)
Sorry for the late response. I’ve been swamped with work.
I tried Wireshark instead and can actually see the IKEV2_FRAGMENTATION_SUPPORTED when tracing (both on client/server and on working/non-working site).
We’re seeing the IKE_SA_INIT MID=00 Initiator Request from the non-working client/site but not Responder Response coming from the RAS.
I’ve tried comparing the Initiator Requests on RAS from working and non-working site line by line but I can’t see any differences. If you’d want to take a look at the traces I would gladly send them to you.
Richard M. Hicks
/ June 13, 2020Happy to look at them if you like. Send me an email and I’ll see what I can find. 🙂
Gustav
/ June 14, 2020Nice! I’ve just sent you an email from “Contact” tab.
Richard M. Hicks
/ June 18, 2020Received. I’ll have a look when time permits and get back to you!
Gustav
/ July 6, 2020Hello again!
I just wanted to let you know that we finally solved it.
We were on our way to test with a new Cisco ASA on the site but when configuring the new one we found a miss in the configuration. All 70 sites are configured with script but somehow we had a static NAT instead of a port NAT configured on this site.. Ie, changing an “s” to a “p” in the configuration and everything started working.
Thanks for the help and have a great summer! 🙂
Richard M. Hicks
/ July 7, 2020Thanks for the update!
c3rberus
/ May 29, 2020I came on here to say thank you for this tip. In our R&D of AOVPN (IKEv2) I was manually disconnecting/re-connecting to IKEv2 and noticed the first attempt works, the other attempts fail. If I reboot the client, same thing (first attempt works, other attempts fail). If i have SSTP setup as fallback, it will fallback from IKEv2 to SSTP. The RRAS is on Windows 2019 and after adding this key, I can re-connect IKEv2 all day long without issues or fallback to SSTP. Thank you!!!
Richard M. Hicks
/ May 29, 2020Thanks, and glad to hear things are working well for you now! 🙂
Joseph Failla
/ June 23, 2020Hey Richard, I’ve got another weird thing happening with my AOVPN (IKEv2). We have 30% of our user accounts that are getting an 809 error but the other 70% connect with no issue. It is specific to their user, we tested from multiple computers and internet connections. Its an all or nothing thing that we can’t find any details on. The NPS server authorizes the login but then the RAS never responds back to the client. Any ideas??? We have been working with Microsoft support for 2 months and they have given us nothing.
Richard M. Hicks
/ June 23, 2020If your VPN server is behind a NAT device that could be the source of the problem. It’s ok to NAT the destination address (that’s common) but if you are also translating the source address that could be the issue. RRAS doesn’t like it when it can’t see the client’s original IP address. Have a close look at that and hopefully that helps. 🙂
Joseph Failla
/ June 23, 2020Thanks but could that cause specific users to not be able to connect? We have tried a working user and a nonworking user on the same device, same internet connection. We run into the same issue. I would think NAT would cause everyone to fail or it not be user specific.
Thanks for you help!
Richard M. Hicks
/ June 24, 2020Yes. It has to do with how many connections the VPN server will accept from a single address. However, if it is user-specific, meaning if UserA cannot log on to a device in a specific location but UserB can, that’s quite unusual and I would suspect it is something else.
Colin Stkes
/ December 30, 2021We are seeing this issue as well with a particular user, no matter the computer or environment we use he cannot connect via User Tunnel where if another user profile on the same machine in the same environment and it connects with no issue, This error shows every time the user attempts to connect. I know this may not be something Richard has a solution but wondering if the OP can share if they had any success with the solution.
Richard M. Hicks
/ December 30, 2021So this is related to the user? The same user gets 809 errors on different devices from different locations on the user tunnel?
Colin Stokes
/ December 30, 2021Yes that is correct. And there is no difference in how the machine is set up than any of our other users using same hardware same environment and connect with no issue. Device tunnel does connect with no issue. User tunnel will go to verifying connection have a drop down to select cert and then after about 15-30 seconds will display the 809 error. And as i stated above if another user logs on that same machine the user tunnel does connect. I was drawing blank until I saw this post on your site and it looked similar to my experience.
Richard M. Hicks
/ December 30, 2021Wow, that’s really strange. Does the user tunnel connect if you remove the device tunnel first? Not just disable it, but remove the profile completely.
Germier
/ July 17, 2023Hi Richard
we are having the same issue.
The VPN is working, the whole company is using it, only this spesific User still getting this error.
I have already try all this, also with the Mini WAN Adapters….. but no success.
The Other Users can establish the Connection on His PC, but him… he can’t, that’s make me crazy. I need to be something with his Account, but What?
have you ever resolve this?
BR
Richard M. Hicks
/ July 19, 2023That’s quite unusual. I have no idea why only one user on the device would have issues like that. I’m assuming you’ve also tried deleting the VPN profile and reinstalling, right? Also, can the user connect successfully on another device?
The only other thing I can suggest is to delete their user profile and see if that helps. I know that’s sometimes painful.
choops
/ September 9, 2020As an FYI, the Default Switch on Hyper-V may also produce 809 errors on the client side. Just spent half the day scratching my head as to why I was able to connect from my Win10 host on VIrtual Box but not Hyper-V. Fixed this by creating a new virtual switch. Been testing AO Device Tunnel with IKEv2 for the purpose of remote hybrid join (Autopilot). Looking the goods!
G74
/ July 9, 2021Hi choops, What did you change on your hyper-v set up exactly. I’m having the exact same 809 error on a w10 client on hyper v. I’ve created a new external switch that uses an ethernet connection but still no joy
sysadminjames
/ September 30, 2020Have you seen any error 809 with;
Failure Information:
Failure Point: Local computer
Failure Reason: Negotiation timed out
State: EAP payload sent
Initiator Cookie: 4fa1669d52dcb7bd
Responder Cookie: 122da5507bae859b
I seem to get these intermittently but cannot pinpoint what is the cause, the issue can go away after a few minutes or hours.
User Tunnel going through KEMP and with my test server that is direct.
Richard M. Hicks
/ September 30, 2020Not uncommon. Often consumer network devices (home routers and firewalls) will interfere with IKEv2 operation.
sysadminjames
/ September 30, 2020Gutted to hear that! I don’t currently have SSTP fall-back. In your experience having this will make it seem to the user more reliable? Getting 3-10 tickets a week about these errors.
Richard M. Hicks
/ October 1, 2020Yes, the general consensus is that SSTP is much less problematic in that regard. Just seems to work everywhere. 🙂
Alistair
/ October 7, 2020Very informative post Richard and hopefully backs up my theory that IKEv2 fragmentation is the problem. I had initially enabled the registry key on the server not knowing it was only supported on Server 2016 1803 and above. We only see this issue intermittently, usually at startup of the device. I used mtupath of the client, found the optimal MTU size and set on the VPN profile interface and this has been pretty solid since. In your view could IKEv2 fragmentation cause the intermittent issues at startup? The error messages are identical and it will usually connect manually 1st or second time after startup if it fails to auto connect (Without the mtu size reduction).
Richard M. Hicks
/ October 13, 2020It’s possible. If you are still running Windows Server 2016 it would be best to get to 2019 as soon as you can. It is definitely more reliable for IKEv2 connections for sure. However, I’ve seen countless times where the users home router caused problems for IKEv2. Not a lot you can do in those scenarios.
Nagu Sittampalam
/ November 4, 2020Hello Richard
I am finding every morning I get error 809 trying to establish device tunnel. If I wait a period of time and then try to connect it connects. User tunnel is sstp so that connects no problem. I have the same thing with Some of our other users, but for some people it does not connect at all. Looking in their event log I see the following
EI – 20221
CoId={58B9BC5E-2D77-458D-812E-984258C38967}: The user CORP\Xxxx has started dialing a VPN connection using a all-user connection profile named SCC SSTP AOVPN – Device v4. The connection settings are:
Dial-in User =
VpnStrategy = IKEv2
DataEncryption = Require
PrerequisiteEntry =
AutoLogon = No
UseRasCredentials = Yes
Authentication Type = Machine Certificate
Ipv4DefaultGateway = No
Ipv4AddressAssignment = By Server
Ipv4DNSServerAssignment = By Server
Ipv6DefaultGateway = No
Ipv6AddressAssignment = By Server
Ipv6DNSServerAssignment = By Server
IpDnsFlags = Register primary domain suffix
IpNBTEnabled = Yes
UseFlags = Private Connection
ConnectOnWinlogon = No
Ipv6AddressAssignment = By Server
Ipv6DNSServerAssignment = By Server
IpDnsFlags = Register primary domain suffix
IpNBTEnabled = Yes
UseFlags = Private Connection
ConnectOnWinlogon = No
Mobility enabled for IKEv2 = Yes.
EI- 20222
CoId={58B9BC5E-2D77-458D-812E-984258C38967}: The user CORP\Xxxx is trying to establish a link to the Remote Access Server for the connection named SCC SSTP AOVPN – Device v4 using the following device:
Server address/Phone Number = xxx.xxx.xxx.xxx
Device = WAN Miniport (IKEv2)
Port = VPN2-1
MediaType = VPN.
EI – 20223
CoId={58B9BC5E-2D77-458D-812E-984258C38967}: The user CORP\Xxxx has successfully established a link to the Remote Access Server using the following device:
Server address/Phone Number = xxx.xxx.xxx.xxx
Device = WAN Miniport (IKEv2)
Port = VPN2-1
MediaType = VPN.
EI – 20224
CoId={58B9BC5E-2D77-458D-812E-984258C38967}: The link to the Remote Access Server has been established by user CORP\Xxxx.
EI – 20227
CoId={58B9BC5E-2D77-458D-812E-984258C38967}: The user CORP\xxxx dialed a connection named SCC SSTP AOVPN – Device v4 which has failed. The error code returned on failure is 809.
Do you have any idea what is causing this issue for some users? Any suggestions would be most welcome.
Richard M. Hicks
/ November 6, 2020This is pretty common with IKEv2. It could be caused by a number of things, but the most common is load balancer configuration. If you are performing NAT and the server isn’t being passed the clients original source IP address, it is possible that IKEv2 connections could be dropped. Have a look at this post for more details: https://directaccess.richardhicks.com/2020/04/13/always-on-vpn-ikev2-load-balancing-and-nat/.
Ryan
/ January 12, 2021I have just had exactly the same issue as the post above (Nagu Sittampalam). Pretty much the same series of logs on the client. The connection seems to go through using IKEv2 and machine certificate and then fails. It so far only seems to have happened on one users laptop. I’ve been slowly rolling out the always on VPN to replace our old DirectAccess server.
The user had been previously connected the day before without issue. Suddenly today it wasn’t having it. I also restarted the VPN server just to see if that made any difference but no joy.
I got the user to restart multiple times, no chance, and in the end asked them to restart their home router and BAM it connected without issue.
We aren’t using a Load Balancer and I believe the NATing is setup correctly as other users weren’t having a problem. I also enabled IKEv2 fragmentation on the server when I set it up.
It was almost like the VPN server was rejecting connections from that users public IP address. I have also added in the reg entry you explained here:
https://directaccess.richardhicks.com/2020/04/13/always-on-vpn-ikev2-load-balancing-and-nat/
Any thoughts or ideas would be very welcome!
Richard M. Hicks
/ January 18, 2021It seems that some consumer networking equipment (firewalls, routes, modems, etc.) just doesn’t play nice with IKEv2. I’m hearing a lot of reports like this. No rhyme or reason unfortunately. :/
sukafun
/ August 22, 2021Do you know by chance the F5 persistence profile timeout values?
I’ve logged a ticket with F5 and they are clueless about RRAS timeout values which I can’t find documented.
francisadu1
/ September 15, 2021Hi Richard, Hope all is well.
We are currently running device tunnel AOV
For the last couple of months we have had at least 2 users a week getting 809 error message (The network connection between your computer and the VPN server could not be established because the remote server is not responding.) When this happens, the only fix is to either rebuild their laptop or remove and re add AOV. Any ideas on what will be causing this ? we are on 2016 device tunnel. Going through this article and comments, we are considering an in-place upgrade from 2016 to 2019 hoping to will fix Fragmentation issue, if that is what is causing the issue. Is there anything we should be worried about when performing in-place upgrade to windows 2019? I came across this forum where users has issue with DHCP replay after upgrade. https://social.technet.microsoft.com/Forums/ie/en-US/0270d377-be3a-4b63-82a0-9df076c5e3b3/upgrade-from-2016-to-2019-breaks-dhcp-relay-agent-when-using-rras?forum=ws2019. any advise on how to avoid that?
Many thanks in advance.
thanks
Richard M. Hicks
/ September 17, 2021I would discourage performing an in-place upgrade. It is best to build a new server clean, then import your configuration after that. I do understand there’s a bug in Windows RRAS that prevents DHCP from working, but I typically avoid using DHCP as much as possible. However, if you must use DHCP for VPN client IP addressing in Windows Server 2019, you’ll need to run the following command on the VPN server and reboot.
reg.exe add “HKLM\SYSTEM\CurrentControlSet\Services\Dhcp” /v RequiredPrivileges /d “SeChangeNotifyPrivilege”\0″SeCreateGlobalPrivilege”\0″SeImpersonatePrivilege”\0 /t REG_MULTI_SZ /f
Kirsty Wilson
/ February 23, 2022We have a similar issue to those listed above. RRAS/NPS built on 2019. All recommendations done for fragmentation etc. No Load balancer on this setup yet.
VPN client profile delivered via Intune so everyone has the same profile.
Only using User tunnel as devices are AAD joined.
Using IKEv2
95% of users connect with no issues.
These problem users get the 809 error. Tried to tether via phone to rule out the ISP.
Users are home based.
Build a test machine as the user & VPN connects – engineers are at home
Rebuild their machine again and VPN doesn’t connect!
Stumped with this one & its driving us crazy.
Any ideas anyone?
Richard M. Hicks
/ February 28, 2022While this issue is more common when load balancers are configured, it can happen without them. I’d suggest disabling IKE mobility on the endpoint to see if that helps. Also, it might be an issue with NAT on-premises too.
Andy Chips
/ April 4, 2023I’ve seen this several times but in rare cases you may need to uninstall and re-add all your WAN Miniport adapters.
This has cured the 809 error for me on several occasions.
Instructions in short:
1. Right-click on Start in the bottom left of your Windows taskbar.
2. Select Device Manager
3. Go to Network Adapters and expand the selection
4. Right click on the WAN Miniport that you want to uninstall and select Uninstall device.
5. Check with your VPN if you are confused about which ones to delete. However, most people who have this problem find they can fix it by uninstalling either: WAN Miniport (IP), WAN Miniport (IPv6) and WAN Miniport (PPTP), and WAN Miniport (SSTP). Also include IKEv2 if you use a device tunnel.
6. Once you have uninstalled the WAN Miniports, click on Action > Scan for hardware changes
7. The WAN Miniports that you need should now return to the menu.
8. Try connecting to your VPN to see if this has resolved your connection problems.
Richard M. Hicks
/ April 4, 2023I’ve had the same experience. Not common at all, but I have used this technique a few times over the years to resolve odd behavior like this. 🙂
Eshaq Choudhury
/ October 26, 2023Does enabling ike fragmentation make you more vulnerable to attacks?
Richard M. Hicks
/ October 26, 2023No, not at all. This setting just controls where the fragmentation takes place.
Eshaq Choudhury
/ October 27, 2023Is there some kind of preconception that fragmentation allows more attacks? The reason I ask is because someone I spoke to claims that is the case when enabling fragmentation. I couldn’t find anything to support their case but wanted to double check.
Richard M. Hicks
/ October 30, 2023There are attacks that leverage network-layer (IP) fragmentation, yes. It’s for this reason that many security administrators block IP fragments. That’s precisely why we enable IKE fragmentation in Windows, though. Doing so pushes the fragmentation up the networking stack, breaking up packets at the IKE layer so they don’t have to be fragmented at the IP layer. This allows the traffic to flow correctly on networks where IP fragmentation is blocked. To be clear, it is quite common for IKE communication to involve large amounts of data, especially during the authentication phase, which will almost always exceed the path MTU. So, this traffic must be fragmented somewhere. It’s done at the IP layer by default, but again, that’s often blocked. So, doing it at the IKE layer is advantageous. It does not introduce additional security risk.