Vérifier la MTU et la MSS sur Sophos Firewall pour un VPN

Un problème typique de MTU ou de MSS ne ressemble pas à un blocage évident : le tunnel VPN est connecté et le ping fonctionne, mais les téléchargements échouent, RDP se fige ou les connexions HTTPS restent bloquées. La cause peut être un chemin utilisable plus petit en raison d’IPsec, de PPPoE, de XFRM ou du SD-WAN.

Si le tunnel ne s’établit pas du tout ou si aucune Security Association n’existe, commencez par Dépanner un VPN IPsec sur Sophos Firewall. Pour les types d’interfaces et XFRM, consultez Configurer les zones et les interfaces de Sophos Firewall.

Diagnostic rapide : Confirmer un problème de MTU ou de MSS

Dans Log Viewer, confirmez le Firewall Rule ID attendu et, si le chemin comprend du NAT, le NAT Rule ID. Si aucun trafic n’apparaît ou si les mauvaises règles s’appliquent, corrigez d’abord le routage, la zone, le NAT ou le DNS.
Notez la source, la destination, le service, la direction, TCP/UDP et le chemin réel via LAN, VLAN, WAN, XFRM, RED, SD-WAN ou Remote Access VPN.
Affichez et documentez la MTU et la MSS actuelles sur l’interface concernée.
Effectuez un test DF, un Packet Capture avec un filtre précis et le même test applicatif réel.
Ne modifiez une valeur que si une différence reproductible existe entre les petits et les grands paquets. Répétez ensuite exactement le même test.

Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture décrit la vérification générale des règles. Si le NAT Rule ID diffère de la valeur attendue, consultez Comprendre le NAT sur Sophos Firewall.

Tester la taille des paquets avec le bit DF

Avec IPv4, il faut ajouter à la charge utile ICMP 20 octets d’en-tête IP et 8 octets d’en-tête ICMP. Une charge utile de 1472 correspond donc à un paquet d’environ 1500 octets.

Windows :

ping -f -l 1472 <target-ip>

macOS :

ping -D -s 1472 <target-ip>

Linux :

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

Si 1472 échoue, réduisez progressivement la charge utile à 1464, 1452, 1412 ou moins. Documentez une taille qui fonctionne et une taille qui échoue. Les filtres ICMP, les fournisseurs, les passerelles cloud ou l’extrémité distante peuvent fausser le résultat ; un test DF ne remplace donc ni Packet Capture ni un test applicatif.

Classer la MTU, la MSS et le chemin concerné

La MTU est la taille maximale des paquets sur une interface ou un chemin. Les paquets plus grands sont fragmentés ou rejetés. La MSS limite la charge utile TCP par segment. Si elle reste trop élevée malgré le surcoût du VPN ou du fournisseur, des retransmissions, des blocages et des échecs avec des volumes de données plus importants peuvent se produire.

La MTU et la MSS ne sont pas des valeurs générales de réglage. Le chemin concret est déterminant :

WAN, PPPoE ou VLAN : Le fournisseur, le routeur ou un en-tête supplémentaire peut réduire la taille de paquet utilisable.
XFRM : L’IPsec basé sur des routes ajoute un surcoût ; les routes, les règles et l’interface XFRM déterminent ensemble le chemin.
SD-WAN : Un flux peut utiliser un autre WAN, MPLS ou VPN que prévu. Routage SD-WAN pour les paquets de réponse et le trafic système explique la sélection du chemin.
Extrémité distante : La route de retour, le pare-feu distant, le VPN cloud et le MSS clamping doivent correspondre à la direction testée.
Wi-Fi : Depuis SFOS 22.0 MR1, les commandes CLI documentées permettent de modifier la MTU et la MSS d’interfaces Wi-Fi existantes.

Les téléchargements ou téléversements volumineux, RDP, SMB, HTTPS, les sauvegardes, ERP, les applications cloud et de conférence ou la VoIP qui échouent uniquement sur un chemin VPN ou SD-WAN précis sont suspects. De nombreuses retransmissions iPerf, un débit TCP fortement fluctuant ou un problème qui apparaît directement après un changement de fournisseur, une mise à niveau du firmware, une refonte du SD-WAN ou une migration VPN correspondent également à ce profil. Si les petits et les grands tests échouent de la même manière, une règle, le NAT, le routage, le DNS, le système cible ou le chemin de retour sont plus probablement en cause.

Vérifier le flux avec Log Viewer, Packet Capture et iPerf

Exclure les problèmes de règles, de NAT et de DNS

Aucun trafic dans Log Viewer : Vérifiez la passerelle du client, le VLAN, la route, la journalisation et le flux de test.
Firewall Rule ID incorrect : Vérifiez l’ordre, la zone, la source, la destination, le service et User Matching. La règle Sophos Firewall ne correspond pas présente d’autres causes.
NAT Rule ID incorrect : Vérifiez l’ordre, les champs d’origine, MASQ, SNAT, DNAT et la direction.
IP de destination inattendue : Vérifiez le DNS, le Split DNS, l’objet FQDN, le CDN et IPv6.

Si un VPN est impliqué, vérifiez également l’état du tunnel et les compteurs d’octets. Documentez TLS Inspection, IPS et Application Control afin que les tests avant et après comparent réellement le même chemin et les mêmes Security Features.

Évaluer Packet Capture

Sous Diagnostics > Tools > Packet capture, filtrez la source et la destination concernées et reproduisez exactement une requête HTTPS, un transfert ou le démarrage d’une application :

Si les paquets n’arrivent pas, le problème se situe généralement au niveau du client, de la passerelle, du VLAN ou du routage local.
Si les paquets entrent dans le tunnel mais qu’aucune réponse ne revient, vérifiez l’extrémité distante et la route de retour.
De nombreuses retransmissions TCP indiquent une perte de paquets, un problème de MTU/MSS, la qualité du WAN ou une surcharge.
Si les petits tests fonctionnent mais que les transferts importants échouent, vérifiez Path MTU Discovery et la fragmentation.

Utiliser Packet Capture dans WebAdmin décrit l’outil. Ne laissez les captures et les debug logs activés que pendant la durée nécessaire afin qu’ils n’occupent pas inutilement l’espace de stockage.

Comparer iPerf avec un test applicatif

Un serveur iPerf dédié à l’extrémité distante est plus pertinent qu’un serveur public. Testez TCP et UDP séparément et évaluez un faible débit TCP ou les retransmissions avec la qualité du WAN, le CPU, l’extrémité distante et les Security Features. Dépanner Sophos Firewall avec iPerf et Speedtest décrit la procédure complète.

Afficher ou modifier la MTU et la MSS

WebAdmin et XFRM

Sous Network > Interfaces, modifiez l’interface concernée et ouvrez Advanced settings > Interface settings. Les paramètres MTU et Override MSS s’y trouvent. Les interfaces XFRM apparaissent sous leur interface d’écoute physique.

Par défaut, Sophos Firewall calcule la MTU XFRM à partir de la MTU de l’interface d’écoute et du surcoût IPsec maximal. Si la MTU XFRM est modifiée manuellement, elle doit être inférieure d’au moins 113 octets à la MTU de l’interface d’écoute. Avec 1400 octets sur l’interface d’écoute, la MTU XFRM ne doit pas dépasser 1287 octets. Cette marge évite la perte de paquets pendant l’offload FastPath lorsque le déchiffrement SSL/TLS est appliqué au trafic IPsec.

Vérifier les valeurs dans Device Console

Connectez-vous par SSH, sélectionnez 4. Device Console dans le menu principal et saisissez l’ID de l’interface :

show mtu-mss Port2

Sophos documente la syntaxe de modification suivante pour les interfaces physiques :

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

Exemple de calcul : si la MTU vérifiée du chemin IPv4 est de 1492 octets, la MSS TCP sans option supplémentaire est de 1452 octets (1492 - 20 - 20). Il ne s’agit ni d’une valeur par défaut générale de SFOS ni d’une recommandation globale pour l’interface PPPoE physique.

⚠️ Une modification affecte le trafic actif et peut interrompre la connexion SSH ou WebAdmin. Elle ne doit pas être effectuée via l’unique connexion d’administration de l’interface concernée. Une solution de secours locale ou hors bande doit être disponible. Port2 n’est qu’un exemple et doit être remplacé par l’ID de l’interface réellement vérifiée.

Enregistrez d’abord les valeurs affichées. default applique les valeurs par défaut du produit documentées par Sophos : MTU 1500 et MSS 1460 :

set network mtu-mss Port2 mtu default mss default

Il ne s’agit d’un rollback que si ces valeurs étaient actives avant la modification. Sinon, restaurez explicitement les valeurs d’origine documentées avec show mtu-mss.

Valider la modification

Documentez l’interface concernée, le tunnel et les valeurs d’origine.
Choisissez une fenêtre de maintenance ou une période de test contrôlée.
N’effectuez qu’une seule modification par test.
Informez l’extrémité distante pour un VPN site-à-site.
Après la modification et le rollback, utilisez show mtu-mss Port2 pour confirmer que les valeurs attendues sont actives.
Répétez les mêmes tests DF, de capture, iPerf et applicatifs.
Documentez les nouvelles valeurs, leur justification et le résultat.
Vérifiez la supervision au cours des jours suivants.

⚠️ N’utilisez pas de hacks permanents dans Advanced Shell, de scripts de démarrage ou de règles improvisées de filtrage de paquets. Ils sont difficiles à maintenir et peuvent mal fonctionner ou disparaître après une mise à jour, une restauration ou un basculement HA. Si de telles modifications héritées existent, consultez Scripts Sophos Firewall sans Cronjob : risques et alternatives.

Ne réduisez pas fortement la MSS pour tous les réseaux, ne testez pas une seule direction et n’ignorez pas l’extrémité distante. Si un test contrôlé n’apporte aucune amélioration, restaurez la valeur d’origine documentée.

Dépannage par symptôme

Le VPN est actif, mais les transferts importants se bloquent : Vérifiez la MTU/MSS, le chemin de retour ou une Security Feature avec Packet Capture et iPerf sur le même chemin.
Seul le WAN PPPoE est concerné : Vérifiez l’interface WAN, la passerelle, les informations du fournisseur et la taille de paquet utilisable.
Le VPN basé sur des routes est instable avec de gros paquets : Vérifiez l’interface XFRM, la connexion IPsec, la route et la règle des 113 octets.
La VoIP sur VPN est instable : Vérifiez le chemin SIP/RTP, la route SD-WAN, le chemin de retour, la perte de paquets et la capture.
TCP est très lent et UDP est normal : Vérifiez la MSS, les retransmissions, la fenêtre TCP et la perte de paquets avec des tests iPerf séparés.
Les petits paquets fonctionnent, mais pas les grands : Documentez le test DF et vérifiez Path MTU Discovery, la fragmentation et l’extrémité distante.

FAQ

Pourquoi le ping fonctionne-t-il, mais pas HTTPS ou RDP ?

Un ping normal utilise de petits paquets. Les segments TCP plus grands peuvent malgré tout être fragmentés ou rejetés. Des tests DF avec des tailles documentées et un véritable test applicatif sont donc nécessaires.

Faut-il modifier la MTU ou la MSS pour chaque VPN ?

Non. Les valeurs par défaut fonctionnent dans de nombreux environnements. Une modification n’est utile que si le chemin, les tailles de paquets et des tests reproductibles démontrent un problème de MTU ou de MSS.