Verificar MTU e MSS no Sophos Firewall para problemas de VPN

Um problema típico de MTU ou MSS não se parece com um bloqueio claro: o túnel VPN está conectado e o ping funciona, mas os downloads são interrompidos, o RDP congela ou os logins HTTPS ficam parados. A causa pode ser o menor tamanho utilizável do caminho devido a IPsec, PPPoE, XFRM ou SD-WAN.

Se o túnel não for estabelecido ou não houver uma Security Association, consulte primeiro Resolução de problemas de VPN IPsec no Sophos Firewall. Para tipos de interface e XFRM, consulte Configurar zonas e interfaces no Sophos Firewall.

Diagnóstico rápido: comprovar um problema de MTU ou MSS

No Log Viewer, confirme a Firewall Rule ID esperada e, se o NAT fizer parte do caminho, a NAT Rule ID. Se o tráfego não aparecer ou regras incorretas forem aplicadas, corrija primeiro o roteamento, a zona, o NAT ou o DNS.
Anote Source, Destination, Service, direção, TCP/UDP e o caminho real por LAN, VLAN, WAN, XFRM, RED, SD-WAN ou Remote Access VPN.
Exiba e documente a MTU e a MSS atuais da interface afetada.
Execute um teste DF, um Packet Capture com filtro restrito e o mesmo teste real da aplicação.
Altere um valor somente se houver uma diferença reproduzível entre pacotes pequenos e grandes. Depois, repita exatamente o mesmo teste.

A verificação geral de regras é descrita em Testar uma regra do firewall com Log Viewer, Policy Test e Packet Capture. Se a NAT Rule ID for diferente da esperada, consulte Entender NAT no Sophos Firewall.

Testar o tamanho dos pacotes com o bit DF

No IPv4, são adicionados 20 bytes de cabeçalho IP e 8 bytes de cabeçalho ICMP ao payload ICMP. Portanto, um payload de 1472 corresponde a um pacote de aproximadamente 1500 bytes.

Windows:

ping -f -l 1472 <target-ip>

macOS:

ping -D -s 1472 <target-ip>

Linux:

ping -M do -s 1472 <target-ip>

Se 1472 falhar, reduza gradualmente o payload para 1464, 1452, 1412 ou menos. Documente o tamanho que funciona e o que falha. Filtros ICMP, provedores, gateways na nuvem ou o lado remoto podem distorcer o resultado; portanto, o teste DF não substitui o Packet Capture nem o teste da aplicação.

Avaliar MTU, MSS e o caminho afetado

A MTU é o tamanho máximo do pacote numa interface ou caminho. Os pacotes maiores são fragmentados ou descartados. A MSS limita o payload TCP por segmento. Se permanecer demasiado elevada apesar do overhead da VPN ou do operador, ocorrem retransmissões, interrupções e falhas com volumes de dados maiores.

MTU e MSS não são valores gerais de otimização. O caminho concreto é o que importa:

WAN, PPPoE ou VLAN: o operador, um router ou um cabeçalho adicional podem reduzir o tamanho de pacote utilizável.
XFRM: o IPsec route-based gera overhead; rotas, regras e a interface XFRM determinam o caminho em conjunto.
SD-WAN: um fluxo pode usar uma WAN, MPLS ou VPN diferente da esperada. A seleção do caminho é explicada em Roteamento SD-WAN para Reply Packets e System Traffic.
Lado remoto: a rota de retorno, o firewall remoto, a VPN na nuvem e o MSS clamping devem corresponder à direção testada.
Wi-Fi: desde o SFOS 22.0 MR1, a MTU e a MSS das interfaces Wi-Fi existentes podem ser alteradas com os comandos CLI documentados.

São suspeitos downloads ou uploads grandes, RDP, SMB, HTTPS, backups, ERP, aplicações na nuvem e de conferência ou VoIP que falham apenas em um caminho específico de VPN ou SD-WAN. Muitas retransmissões no iPerf, throughput TCP muito variável ou um erro logo após a troca de provedor, atualização de firmware, alteração de SD-WAN ou migração de VPN também são sinais compatíveis. Se testes pequenos e grandes falharem da mesma forma, é mais provável que a causa seja regra, NAT, roteamento, DNS, sistema de destino ou caminho de retorno.

Verificar o fluxo de dados com Log Viewer, Packet Capture e iPerf

Excluir regra, NAT e DNS

Nenhum tráfego no Log Viewer: verifique gateway do cliente, VLAN, rota, logging e fluxo de teste.
Firewall Rule ID incorreta: verifique ordem, zona, Source, Destination, Service e User Matching. Outras causas são descritas em A regra do Sophos Firewall não é aplicada.
NAT Rule ID incorreta: verifique ordem, campos originais, MASQ, SNAT, DNAT e direção.
IP de destino inesperado: verifique DNS, Split DNS, objeto FQDN, CDN e IPv6.

Se uma VPN estiver envolvida, verifique também o status do túnel e os contadores de bytes. Documente TLS Inspection, IPS e Application Control para que os testes antes e depois da alteração comparem realmente o mesmo caminho e as mesmas Security Features.

Avaliar o Packet Capture

Em Diagnostics > Packet capture, abra primeiro Configure e defina um filtro BPF restrito, por exemplo host 192.0.2.10 and host 198.51.100.20 and port 443. Depois, ative Trace On, reproduza exatamente uma chamada HTTPS, transferência ou inicialização da aplicação e pare a captura com Trace Off:

Se os pacotes não chegarem, o problema geralmente está no cliente, gateway, VLAN ou roteamento local.
Se os pacotes entrarem no túnel e não houver respostas, verifique o lado remoto e a rota de retorno.
Pacotes TCP repetidos ou respostas ausentes podem indicar perda de pacotes, MTU/MSS, qualidade da WAN ou sobrecarga. Uma análise fiável de retransmissões requer um ficheiro PCAP e o Wireshark.
Se os testes pequenos funcionarem, mas as transferências grandes não, verifique Path MTU Discovery e fragmentação.

A utilização da ferramenta é explicada em Utilizar o Packet Capture no WebAdmin. O buffer do WebAdmin está limitado a 2048 KB e, sem Wrap capture buffer once full, a captura para automaticamente quando fica cheio. Mantenha as capturas e os logs de debug ativos apenas durante o tempo necessário.

Comparar o iPerf com um teste da aplicação

Um servidor iPerf dedicado no lado remoto é mais significativo do que um servidor público. Teste TCP e UDP separadamente e avalie throughput TCP baixo ou retransmissões junto com a qualidade da WAN, CPU, lado remoto e Security Features. O procedimento completo está em Resolução de problemas no Sophos Firewall com iPerf e Speedtest.

Exibir ou alterar MTU e MSS

WebAdmin e XFRM

Em Network > Interfaces, edite a interface afetada e abra Advanced settings > Interface settings. Aí encontram-se MTU e Override MSS. As interfaces XFRM aparecem por baixo da respetiva interface física de escuta.

Desde o SFOS 22.0, o Sophos Firewall calcula, por predefinição, a MTU da interface XFRM com base na MTU da interface de escuta e no overhead máximo do IPsec. Se a MTU da interface XFRM for alterada manualmente, deverá ser pelo menos 113 bytes menor do que a MTU da interface de escuta. Com 1400 bytes na interface de escuta, a interface XFRM poderá ter, no máximo, 1287 bytes. Esta reserva evita a perda de pacotes durante o offload FastPath quando a desencriptação SSL/TLS é aplicada ao tráfego IPsec. Antes da implementação, siga a preparação da atualização do firmware da Sophos Firewall para verificar a build instalada, o caminho de atualização suportado e as indicações atuais específicas da build.

Verificar os valores na Device Console

Ligue-se por SSH, selecione 4. Device Console no menu principal e introduza o ID da interface:

show mtu-mss Port2

Registe exatamente os valores de MTU e MSS apresentados antes do teste; estes determinam o rollback.

⚠️ Uma alteração afeta o tráfego ativo e pode interromper a ligação SSH ou WebAdmin. Não deve ser efetuada através da única ligação de gestão na interface afetada. Deve estar disponível um acesso local ou out-of-band para recuperação. Port2 é apenas um exemplo e deve ser substituído pelo ID da interface efetivamente verificada.

Para interfaces físicas e Wi-Fi, a Sophos documenta a seguinte sintaxe de alteração. Ela não é documentada como método para alterar uma interface XFRM; edite XFRM no WebAdmin:

set network mtu-mss <PortID> mtu <number|default> mss <number|default>

Exemplo de cálculo: se a MTU IPv4 comprovada do caminho for de 1492 bytes, sem opções adicionais resultará numa MSS TCP de 1452 bytes (1492 - 20 - 20). Isto não é um valor predefinido geral do SFOS nem uma recomendação geral para a interface PPPoE física.

Se a MSS 1460 tiver sido documentada anteriormente para Port2, durante uma janela de manutenção altere primeiro apenas a MSS para o valor de teste calculado:

set network mtu-mss Port2 mss 1452

Confirme imediatamente o valor com show mtu-mss Port2 e repita os mesmos testes DF e da aplicação. Se o tráfego piorar ou não melhorar, este exemplo repõe o valor original registado:

set network mtu-mss Port2 mss 1460

Se estava ativo um valor MSS diferente antes do teste, utilize esse valor exato em vez de 1460 e confirme-o novamente com show mtu-mss Port2.

Em alternativa, default define os valores predefinidos do produto documentados pela Sophos: MTU 1500 e MSS 1460:

set network mtu-mss Port2 mtu default mss default

Isto só constitui um rollback se esses valores estavam ativos antes da alteração. Caso contrário, reponha explicitamente os valores originais documentados com show mtu-mss.

Validar a alteração

documente a interface afetada, o túnel e os valores originais;
escolha uma janela de manutenção ou um horário de teste controlado;
faça apenas uma alteração por teste;
informe o lado remoto em caso de VPN site-to-site;
após uma alteração ou rollback, use show mtu-mss Port2 para confirmar que os valores esperados estão ativos;
repita os mesmos testes DF, Packet Capture, iPerf e da aplicação;
documente os novos valores, a justificativa e o resultado;
verifique o monitoramento nos dias seguintes.

⚠️ Não use hacks permanentes na Advanced Shell, scripts de inicialização ou regras improvisadas de filtragem de pacotes. Eles são difíceis de manter e podem funcionar incorretamente ou desaparecer após uma atualização, restauração ou failover de HA. Se houver configurações antigas desse tipo, consulte Scripts no Sophos Firewall sem Cronjob: riscos e alternativas.

Não reduza drasticamente a MSS para todas as redes, nunca teste apenas uma direção e não ignore o lado remoto. Se um teste controlado não trouxer melhorias, restaure o valor original documentado.

Resolução de problemas por sintoma

VPN ativa, transferências grandes ficam suspensas: verifique MTU/MSS, caminho de retorno ou Security Feature com Packet Capture e iPerf no mesmo caminho.
Somente a WAN PPPoE é afetada: verifique interface WAN, gateway, dados do provedor e tamanho de pacote utilizável.
VPN route-based instável com pacotes grandes: verifique interface XFRM, conexão IPsec, rota e regra dos 113 bytes.
VoIP instável pela VPN: verifique caminho SIP/RTP, rota SD-WAN, caminho de retorno, perda de pacotes e captura.
TCP muito lento, UDP normal: verifique MSS, retransmissões, janela TCP e perda de pacotes com testes iPerf separados.
Pacotes pequenos funcionam, grandes não: documente o teste DF e verifique Path MTU Discovery, fragmentação e lado remoto.

FAQ

Por que o ping funciona, mas HTTPS ou RDP não?

Um ping normal usa pacotes pequenos. Segmentos TCP maiores ainda podem ser fragmentados ou descartados. Portanto, são necessários testes DF com tamanhos documentados e um teste real da aplicação.

É necessário alterar MTU ou MSS em cada VPN?

Não. Os valores padrão funcionam em muitos ambientes. Uma alteração só faz sentido quando o caminho, os tamanhos dos pacotes e testes reproduzíveis comprovam um problema de MTU ou MSS.