Em uma vida passada, corrigimos problemas de transferência de arquivos (especificamente sobre VPN) reduzindo o MTU. Testes de ping usando tamanhos de pacote ao redor dos limites de MTU não eram úteis; É verdade que você descarta buracos negros, mas se você tivesse um buraco negro, provavelmente não seria capaz de fazer nada de útil através da VPN.
Nossos problemas foram especificamente com transferências de arquivos SMB, acredito que devido à fragmentação de pacotes. Reduzir o MTU para o intervalo 1400-1420 ajudou significativamente. Lembre-se, o encapsulamento VPN adiciona mais cabeçalhos a cada pacote (já faz um tempo, então esqueço os detalhes e estou com preguiça de pesquisar no Google hoje à noite), mas a Ethernet 1472 + ESP + AH + é muito superior a 1500 (supondo que você esteja usando IPSec / ESP + AH). Pela minha experiência, a fragmentação excessiva não é um problema preto ou branco; só porque certos testes passam em determinados momentos não significa que você pode descartá-lo mais tarde.
Como o servidor está enviando os dados nesse caso, você pode ver se pode definir a MTU no servidor. É também o ponto comum ao qual todos os clientes SMB se conectam, portanto, alterar o MTU uma vez pode eliminar a necessidade de configurar o MTU em todos os clientes (como o MTU do caminho é negociado entre os pontos finais).
Além disso, para aqueles que dizem para ele usar o wireshark - o que especificamente você diria a ele para procurar? Não tenho certeza se esse é um 'erro de protocolo' - provavelmente o SMB está redefinindo sua conexão devido à latência subjacente e / ou quedas de pacotes, portanto, tecnicamente o SMB está fazendo seu trabalho (é apenas um protocolo frágil) - e Não tenho certeza se o tcpdump / sniffer / wireshark vai apontá-los para uma solução. Eu adoro traçar conversas de rede de rede tanto quanto o próximo CCNP, mas nas mãos erradas um bisturi é inútil / perigoso. Ele já disse que não é um administrador de rede ...