Odd issue with FTPS over OpenZiti Overlay

Ziti Overlay
6

After various enhanced logging and packet captures, it does appear to be ProFTPd that is failing to conplete the TLS handshake and instead sends a TCP RST - though it's not clear why even with max logging with ProFTPD. It ONLY happens while connected to OpenZiti, so perhaps there is a latency issue that OpenSSL on the server side runs into because of traffic going over the overlay.
Packet capture server side on the lo (127.0.0.1) network during failure:

image
image1685×816 60 KB

FileZilla max debug logging during failure:

Trace: CControlSocket::SendNextCommand()
Trace: CFtpRawTransferOpData::Send() in state 4
Trace: Binding data connection source IP to control connection source IP 100.64.0.1
Trace: tls_layer_impl::client_handshake()
Trace: Trying to resume existing TLS session.
Command: MLSD
Trace: tls_layer_impl::continue_handshake()
Trace: tls_layer_impl::continue_handshake()
Error: GnuTLS error -15: An unexpected TLS packet was received.
Error: The data connection could not be established: ECONNABORTED - Connection aborted
Trace: CTransferSocket::TransferEnd(3)
Trace: CFtpControlSocket::TransferEnd()

According to Gemini:
Therefore, the most consistent explanation across all evidence (both client/server captures and FileZilla logs) is:

  1. Client attempts data connection TLS handshake, explicitly trying session resumption.
  2. Server (ProFTPD) receives Client Hello.
  3. Server (ProFTPD) fails internally while processing the Client Hello / session resumption attempt under Ziti's latency conditions.
  4. Server (ProFTPD) sends TCP RST on the data channel almost immediately.
  5. Client's GnuTLS receives the RST unexpectedly -> reports GnuTLS error -15.
  6. FileZilla sees the TLS error -> reports ECONNABORTED.
  7. FileZilla/Client OS then cleans up the connections (sending FINs on control/data channels, etc., which might appear interleaved with the server RST/responses in captures depending on timing).