Problèmes de connexion SSH à travers un tunnel OpenVPN ("Segment TCP précédent perdu")

J'ai un tunnel VPN vers un serveur OpenVPN. Le VPN est un VPN Sophos qui utilise OpenVPN en arrière-plan. Je ne connais pas la configuration du serveur et je ne peux pas modifier la configuration du serveur. Mon point de terminaison de tunnel est tun sur Win 10 (OpenVPN 2.4.8) et sa configuration ressemble à ceci :

ip-win32 dynamic
client
dev tun
proto tcp
verify-x509-name "[...]"
route remote_host 255.255.255.255 net_gateway
resolv-retry infinite
nobind
persist-key
persist-tun
dev-node "OpenVPN"
pull-filter ignore redirect-gateway
route 192.168.20.0 255.255.255.0 vpn_gateway 3

[...]

[...]

[...]

auth-user-pass
cipher AES-128-CBC
auth SHA256
comp-lzo no
route-delay 4
verb 3
reneg-sec 0
remote [...] 8443

Maintenant j'ai le problème qu'une connexion SSH à travers le tunnel reste bloquée à debug1: SSH2_MSG_KEXINIT sent (il s'agit de ssh WSL) :

$ ssh -vvvv 192.168.20.147
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config ligne 19: Application des options pour *
debug2: résolution de "192.168.20.147" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connexion à 192.168.20.147 [192.168.20.147] port 22 établie.
[...]
debug1: Chaîne de version locale SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: Version de protocole à distance 2.0, version du logiciel à distance OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: correspondance: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH* compat 0x04000000
debug2: fd 3 réglage O_NONBLOCK
[...]
debug3: envoi du paquet: type 20
debug1: SSH2_MSG_KEXINIT sent

Je capture la session avec wireshark et je vois que j'obtiens "Segment TCP précédent perdu" :

No.     Time        Source                Destination           Protocol Info
      4 2.933875    10.81.234.15          192.168.20.147        TCP      54013 > ssh [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=8
      5 3.305435    192.168.20.147        10.81.234.15          TCP      ssh > 54013 [SYN, ACK] Seq=0 Ack=1 Win=64480 Len=0 MSS=1240 WS=9
      6 3.305511    10.81.234.15          192.168.20.147        TCP      54013 > ssh [ACK] Seq=1 Ack=1 Win=65536 Len=0
      7 3.317162    10.81.234.15          192.168.20.147        SSHv2    Client Protocol: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3\r
      8 3.335238    192.168.20.147        10.81.234.15          SSHv2    Server Protocol: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3\r
      9 3.339937    10.81.234.15          192.168.20.147        TCP      [Segment TCP d'un PDU réassemblé]
     10 3.339948    10.81.234.15          192.168.20.147        SSHv2    Client: Échange de clé initié
     11 3.635978    192.168.20.147        10.81.234.15          TCP      ssh > 54013 [ACK] Seq=42 Ack=42 Win=64512 Len=0
     12 3.947955    192.168.20.147        10.81.234.15          TCP      [Segment TCP précédent perdu] ssh > 54013 [ACK] Seq=1122 Ack=1402 Win=64512 Len=0

Je pense que cela pourrait être lié à MTU, donc j'ai essayé de jouer avec le MTU sur le serveur SSH et le point de terminaison du client OpenVPN (différentes valeurs du 1500 par défaut jusqu'à <1000). Aucun changement.

J'ai aussi essayé d'utiliser ping -f -l PKTSIZE 192.168.20.147 et la partie intéressante est que le ping réussit jusqu'à PKTSIZE=71 et pour PKTSIZE > 71 j'obtiens "Délai d'attente de la demande dépassé".

Note : Sur un autre ordinateur avec le client Sophos VPN Endpoint mais sinon le même réseau, tout fonctionne comme prévu.