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 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 Progress Kemp LoadMaster the administrator will configure “port following”. On the F5 BIG-IP a custom “persistence profile” must be configured. On the NetScaler ADC 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, including on Windows 11. 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
Always On VPN and IKEv2 Fragmentation
The monitoring of DirectAccess machine and user activity presents some unique challenges for security administrators. All DirectAccess client communication destined for the internal corporate network is translated by the DirectAccess server and appears to originate from the DirectAccess server’s internal IPv4 address. Also, the public IPv4 address for DirectAccess clients using the IP-HTTPS IPv6 transition protocol is 
