Troubleshooting Always On VPN Error Code 809

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

Always On VPN and IKEv2 Fragmentation

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

Troubleshooting Always On VPN Error Code 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.

Troubleshooting Always On VPN Error Code 809

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.


IKEv2 fragmentation was introduced in Windows 10 1803 and is enabled by default. No client-side configuration is required.


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


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 and IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Hands-On Training Classes

Leave a comment


  1. gatorcritfcorg

     /  August 23, 2019

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

  2. Whatever we’re looking for regarding Microsoft VPN, we always end up here. Great articles!

  3. Matt

     /  November 1, 2019

    Richard – 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!

  4. I had these exact symptoms but it was the “Xbox Live Networking Service” that caused the problem. Stopping it allowed me to connect,

  5. Abe

     /  December 6, 2019

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

  6. Gustav

     /  March 17, 2020

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

    • That’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, 2020

        Thanks 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 mask 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!

  1. Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster | Richard M. Hicks Consulting, Inc.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: