SSL VPN Performance (ssl.root mtu size)

[gbollinger]

I'm having a significant performance issues with SSL VPN vs IPSEC VPN. The specific issue is download performance. upload is blazing fast.

What have I done to troubleshoot?

1. Verified client tunnel interface MTU sizes

2. Added TCP MSS size (1240 - This seemed to offer the best download performance) adjustment to the ssl.root interface and policies with ssl interface referenced. Upload performance is 750-800 mbps...

3. Tested across multiple clients (Windows, macOS and Linux). Windows and macOS are running 7.2.1 and Linux is running 7.0.7 since anything later destroys upload and download performance for Linux users.

4. Disabling DTLS on the FW dramatically increased upload speeds across all clients and client OS types.

Now. I know FGT 7.4.1 is supposed to provide DTLS improvements and FCT 7.2.2 is supposed to provide DTLS to all client types. When this occurs TCP MSS size adjustment will be useless. I noticed the ssl.root interface has an MTU of 1500 and the mtu override and mtu adjustment commands are not available for the ssl.root interface. I've enabled ping on the ssl.root interface.

1. Does anyone have any idea how to improve download performance today?

2. How will DTLS (aka UDP traffic) not cause fragmentation issues for downloads when the ssl.root interface is set to 1500? Is there a way to change it and will Path MTU Discovery handle the MTU size for the path as it relates to downloads from over the ssl vpn tunnel aka ssl.root interface?

[pgautam]

Hi @gbollinger

Thank you for posting your query.

SSL VPN encapsulates a TCP connection within another TCP connection.

This can cause interference between timeouts and other issues.

FortiOS Datagram Transport Layer Security (DTLS) allows SSL VPN to encrypt traffic using TLS and uses UDP as the transport layer instead of TCP. This avoids retransmission problems that can occur with TCP-in-TCP.

DTLS also solves the problems surrounding the loss and reordering of packets, while it does not suffer from delays that occur with streaming protocols.

TLS and TCP worry about communicating information slowly but surely whereas UDP and DTLS communicate information rapidly and with a concern for latency-critical applications.

Please check the below RFC section 4.2.3 how DTLS avoids IP fragmentation
https://datatracker.ietf.org/doc/html/rfc6347#page-19

Regards
Priyanka

- Have you found a solution? Then give your helper a "Kudos" and mark the solution

[gbollinger]

The RFC outlines how the DTLS avoids fragmentation for the handshake. How does it handle avoiding fragmentation for the payload? Section 4.1.1. outlines the issue and a solution Path MTU discovery. I'm trying to state is the ssl.root interface on the Fortigate doesn't have an IP address nor supports modifying the MTU for the ssl.root interface. How is the size of the pre-tunnel traffic (payload/packet) supposed to fit into the physical interface's MTU? A 1500 byte pre-tunnel packet will only fit into the WAN interface packet that's 1500 byte by fragmenting the tunnel packet (inside) packet into two packets to fit into the WAN (outside) interfaces MTU.

The ssl.root interface needs to be a layer 3 interface and the ability to adjust the MTU size to allow Path MTU discovery to work.

[Eduardoj]

Hello gbollinger,

Did you find a solution? i have the same situation, usingthe ssl vpn upload is very fast(800Mbps+) but download cant reach more than 20 Mbps.

I've tried some things like DTLS but changed nothing.