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

1. 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.
2. 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.
3. Affichez et documentez la MTU et la MSS actuelles sur l’interface concernée.
4. Effectuez un test DF, un Packet Capture avec un filtre précis et le même test applicatif réel.
5. 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 > Packet capture, ouvrez d’abord Configure et définissez un filtre BPF précis, par exemple host 192.0.2.10 and host 198.51.100.20 and port 443. Activez ensuite Trace On, reproduisez exactement une requête HTTPS, un transfert ou le démarrage d’une application, puis arrêtez la capture avec Trace Off :

• 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.
• Des paquets TCP répétés ou l’absence de réponses peuvent indiquer une perte de paquets, un problème de MTU/MSS, la qualité du WAN ou une surcharge. Une analyse fiable des retransmissions nécessite un fichier PCAP et Wireshark.
• 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. Le buffer WebAdmin est limité à 2048 Ko et, sans Wrap capture buffer once full, la capture s’arrête automatiquement lorsqu’il est plein. Ne laissez les captures et les debug logs activés que pendant la durée nécessaire.

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.

Pour une interface XFRM à laquelle une adresse peut être attribuée, vérifiez d’abord sous Administration > Device access que IPsec est activé pour la zone WAN. Pour une connexion IPv4 ou IPv6, les sous-réseaux locaux et distants doivent être définis sur Any ; avec IP version: Dual, aucun sélecteur de trafic n’est spécifié. La connexion IPsec basée sur des routes crée automatiquement l’interface. Ne passez pas un tunnel opérationnel à Any uniquement pour tester la MTU : les routes et les règles de pare-feu doivent toujours limiter précisément le trafic autorisé.

Cette distinction est importante : les connexions basées sur des routes avec des sélecteurs de trafic spécifiques peuvent aussi avoir des interfaces XFRM, mais on ne peut leur attribuer ni adresse IP ni routes personnalisées. Affirmer que des sous-réseaux spécifiques empêchent toujours XFRM n’est donc pas un diagnostic sûr. Si l’interface adressable attendue manque, vérifiez le type de connexion, la sélection des sous-réseaux et l’interface d’écoute au lieu de modifier le port WAN physique.

⚠️ Ne modifiez les paramètres qu’après avoir noté les valeurs d’origine et prévu un accès de secours local ou hors bande. Enregistrer des modifications sur l’interface XFRM peut aussi affecter le trafic actif et l’accès d’administration.

1. Sous Network > Interfaces, ouvrez la ligne de l’interface d’écoute physique, sélectionnez son interface XFRM et saisissez un nom.
2. Hardware affiche le nom de l’enregistrement ; IPsec connection affiche la connexion associée. Les deux sont attribués automatiquement. Network zone reste toujours VPN, et non WAN ou LAN.
3. Si nécessaire, saisissez l’adresse de tunnel et le sous-réseau prévus sous IPv4/netmask, ou l’adresse IPv6 et le préfixe sous IPv6/prefix. Ne changez pas une adresse de tunnel en production uniquement pour un test de MTU. Seule la version IP sélectionnée dans la connexion IPsec s’applique ; renseigner l’autre version ne l’active pas. Dual applique les deux versions.
4. Notez les valeurs d’origine, y compris Override MSS. Sous Advanced settings > Interface settings, conservez la MTU par défaut sauf si les tests justifient une modification. Activez Override MSS et saisissez la MSS déterminée uniquement si le besoin a été démontré.
5. Cliquez sur Save, rouvrez l’interface XFRM et vérifiez les valeurs enregistrées. Vérifiez ensuite l’état du tunnel, les routes, les règles de la zone VPN et le même test applicatif dans les deux sens. Si le résultat se dégrade, rétablissez les valeurs notées, y compris l’état initial d’Override, puis vérifiez à nouveau ; le rollback CLI pour Port2 ci-dessous ne s’applique pas à XFRM.

Dans SFOS 22.0 MR1 et 23.0, Sophos Firewall calcule par défaut 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. Avant le déploiement, suivez la préparation de la mise à jour du firmware Sophos Firewall pour vérifier le build installé, le chemin de mise à niveau pris en charge et les remarques actuelles propres au build.

Vérifier les valeurs dans Device Console

Les références Network pour SFOS 22.0 et 23.0 documentent set network mtu-mss, mais pas l’exemple de lecture avec show ci-dessous. Cela ne signifie pas que la commande de consultation n’existe pas. Ne l’utilisez pour relever les valeurs initiales et effectuer les contrôles ultérieurs que si sa disponibilité, sa syntaxe et la signification de sa sortie sont confirmées pour le build installé par la documentation Sophos applicable ou par Sophos Support. Cette condition s’applique à toutes les utilisations suivantes de show mtu-mss, y compris après une modification et un rollback.

Si cette méthode de vérification n’est pas confirmée, relevez les valeurs MTU et MSS réellement actives, y compris les réglages personnalisés, dans l’affichage WebAdmin confirmé pour le type d’interface et le build, ou selon une procédure confirmée par Sophos Support. Après la modification et le rollback, relisez les valeurs à cet endroit et comparez-les aux valeurs attendues à chaque étape. Si les valeurs initiales réelles, leur restauration exacte ou le contrôle ultérieur ne peuvent pas être établis de manière fiable, n’effectuez aucune modification via la CLI ; clarifiez d’abord ces points avec Sophos Support. Les valeurs par défaut du produit ne remplacent pas un état initial enregistré.

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

show mtu-mss Port2

Enregistrez exactement les valeurs MTU et MSS affichées avant le test ; elles déterminent le rollback.

⚠️ 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.

Sophos documente la syntaxe de modification suivante pour les interfaces physiques et Wi-Fi. Elle n’est pas documentée comme méthode de modification d’une interface XFRM ; modifiez XFRM dans WebAdmin :

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.

Si la MSS 1460 a été documentée auparavant pour Port2, ne modifiez d’abord que la MSS avec la valeur de test calculée pendant une fenêtre de maintenance :

set network mtu-mss Port2 mss 1452

Confirmez immédiatement la valeur avec show mtu-mss Port2, puis répétez les mêmes tests DF et applicatifs. Si le trafic se dégrade ou ne s’améliore pas, cet exemple restaure la valeur d’origine enregistrée :

set network mtu-mss Port2 mss 1460

Si une autre valeur MSS était active avant le test, utilisez cette valeur exacte à la place de 1460, puis confirmez-la de nouveau avec show mtu-mss Port2.

Sinon, 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