Troubleshooting Tip: Slow SSL VPN full-tunnel performance when DTLS is not negotiated through VIPs
| Description | This article describes how slow SSL VPN performance in full-tunnel deployments can occur when DTLS (UDP) is unintentionally blocked by VIP or firewall policy design, forcing SSL VPN to operate over TCP and creating an inefficient TCP-over-TCP condition. |
| Scope | FortiGate, FortiClient EMS. |
| Solution | This behavior is commonly observed when FortiGate and FortiClient are correctly configured for DTLS, but the SSL VPN service is published through TCP-only Virtual IPs (VIPs). This prevents DTLS from being negotiated and forces SSL VPN to fall back to TCP.
This scenario typically applies to SSL VPN full-tunnel environments, especially where SSL VPN is exposed via VIPs or port forwarding.
In a case where users connected via SSL VPN full-tunnel are experiencing significantly lower internet throughput over SSL VPN than expected, and internal (LAN) access through SSL VPN is performed normally, enabling/disabling DTLS in FortiClient shows no improvement.
When SSL VPN runs over TCP, and the application traffic inside the tunnel is also TCP (web browsing, file transfers, RDP, etc.), this creates a TCP-over-TCP condition. This leads to duplicate retransmissions, conflicting congestion control mechanisms, and throughput collapse under even minor packet loss or latency.
DTLS addresses this by transporting the SSL VPN tunnel over UDP, while the application traffic inside the tunnel continues to use TCP.
Even when DTLS is enabled on both FortiGate and FortiClient, environments that publish SSL VPN using VIPs follow this flow:
Public IP -> VIP -> Internal SSL VPN listener. If the SSL VPN VIPs are defined as TCP 443 only, this means the FortiClient will attempt to establish DTLS using UDP/443, but UDP packets will be dropped at the VIP, and the FortiClient will fall back to TCP/TLS and SSL VPN operated in TCP-over-TCP mode, meaning DTLS was effectively never negotiated, despite being enabled.
To allow DTLS to function as designed, UDP must be permitted through both the VIP and firewall policy:
Example:
Allow both TCP 443 and UDP 443 to the SSL VPN VIP.
Verify via packet capture:
diagnose sniffer packet any 'host <public_ip> and port <ssl_vpn_port>' 6 0 l
UDP packets should be observed.
After allowing UDP/443, DTLS becomes effective, and TCP-over-TCP is eliminated. Only the inner application TCP handles retransmissions and congestion control, while the SSL VPN tunnel no longer introduces duplicate recovery mechanisms. This significantly reduces packet queuing and retransmissions inside the SSL VPN engine, resulting in a noticeable improvement in full-tunnel Internet throughput.
DTLS affects only how the encrypted VPN tunnel is transported. File transfers themselves continue to use TCP and remain fully reliable.
Note: The SSL VPN performance issue was caused by DTLS being blocked by TCP-only VIPs, forcing SSL VPN into inefficient TCP-over-TCP mode. Allowing UDP/443 through the VIP and firewall policy will enable DTLS as designed, eliminating transport inefficiencies and restoring expected performance without impacting file transfer reliability.
Related articles: |