Vérifier le MTU et le MSS de Sophos Firewall en cas de problèmes VPN

Lorsqu’une connexion VPN est établie mais que certaines applications restent bloquées, on pense souvent d’abord aux règles de pare-feu, au DNS ou à l’autre extrémité. C’est correct, mais pas complet. Pour les gros paquets, le surcoût IPsec, PPPoE, SD-WAN ou les VPN basés sur des routes, le MTU et le MSS peuvent également être la cause.

Un problème typique ne ressemble pas à un blocage clair : le ping fonctionne, les petites pages web se chargent, mais les transferts de fichiers échouent, RDP se fige, les connexions HTTPS restent bloquées ou la VoIP devient instable. Cet article situe les questions de MTU et de MSS sur Sophos Firewall, sans modifier aveuglément les valeurs ou créer des solutions de contournement dangereuses via le shell.

Pour les bases sur les interfaces, les zones et XFRM, commencez par Configurer les zones et interfaces de Sophos Firewall. Si un tunnel IPsec ne s’établit pas du tout ou si aucune association de sécurité n’est installée, Dépannage VPN IPsec de Sophos Firewall est un meilleur point de départ.

MTU et MSS expliqués brièvement

Le MTU décrit la taille maximale qu’un paquet peut avoir sur une interface ou un chemin. Si un paquet est plus grand que ce que le chemin permet, il doit être fragmenté ou il est rejeté. Pour les VPN, c’est particulièrement pertinent car IPsec ajoute des en-têtes supplémentaires.

Le MSS concerne TCP et décrit la taille de la charge utile d’un segment TCP. Si le MSS reste trop élevé, bien que le chemin réel soit plus petit en raison du VPN, PPPoE ou d’autres superpositions, des problèmes TCP typiques apparaissent : retransmissions, blocages, connexions lentes ou interruptions de connexion pour de grandes quantités de données.

Important : le MTU et le MSS ne sont pas des valeurs de réglage à réduire au hasard jusqu’à ce que cela fonctionne. Ces valeurs appartiennent au chemin. Avant de les modifier, il doit être clair quelle interface, quelle direction, quel protocole et quel tunnel sont concernés.

Quand suspecter le MTU ou le MSS

Les problèmes de MTU et de MSS se manifestent souvent uniquement avec certaines applications ou tailles de paquets.

Indices typiques :

Le tunnel VPN est connecté, mais les téléchargements ou téléversements plus importants restent bloqués.
RDP, SMB, HTTPS, sauvegarde, ERP ou applications cloud ne fonctionnent que partiellement.
Les petits tests ICMP fonctionnent, mais pas les transferts de données plus importants.
La VoIP ou les applications de conférence sont instables uniquement sur certains chemins VPN ou SD-WAN.
Le problème ne concerne que PPPoE, un WAN spécifique, un itinéraire IPsec basé sur des routes ou une interface XFRM.
iPerf montre de nombreuses retransmissions ou un débit TCP très variable.
Après un changement de fournisseur, une mise à jour du firmware, une refonte du SD-WAN ou une migration VPN, un nouveau problème apparaît soudainement.

Ces symptômes ne prouvent pas encore un problème de MTU. Cependant, ils sont une bonne raison d’inclure le MTU et le MSS dans l’analyse.

Ne pas confondre avec des problèmes de règles, NAT ou DNS

Le MTU/MSS n’est généralement pas le premier point de vérification. Il faut d’abord s’assurer que le trafic suit fondamentalement le chemin attendu. Sinon, on ajuste les tailles de paquets alors qu’en réalité une règle, un NAT, un DNS ou le chemin de retour est incorrect.

Observation	Plus probable que MTU/MSS au départ
Aucun trafic n’apparaît dans le Log Viewer	Journalisation, passerelle client, VLAN, route ou flux de test incorrect
La mauvaise ID de règle de pare-feu est appliquée	Ordre des règles, zone, source, destination, service ou correspondance utilisateur
L’ID de règle NAT ne correspond pas	Ordre NAT, champs d’origine, MASQ/SNAT/DNAT ou mauvaise direction
Le nom se résout en une IP inattendue	DNS, DNS fractionné, objet FQDN, CDN ou IPv6
Les petits et grands tests échouent de la même manière	Règle, routage, NAT, système cible ou contrepartie
Seuls les transferts importants sont bloqués	Vérifiez MTU/MSS, fragmentation, découverte de MTU de chemin ou surcoût VPN

Pour cette pré-vérification, Vérifier pourquoi une règle de Sophos Firewall ne correspond pas, Utiliser Packet Capture dans WebAdmin et Comprendre le NAT sur Sophos Firewall sont appropriés. Ce n’est que lorsque les règles, NAT, routage et DNS sont plausibles que la piste MTU/MSS vaut vraiment la peine d’être suivie.

Points typiques sur Sophos Firewall

Sur Sophos Firewall, plusieurs zones peuvent être pertinentes. En général, ce n’est pas tout le pare-feu qui est concerné, mais un chemin spécifique.

Zone	Pourquoi pertinent
Interface WAN	Le fournisseur, PPPoE, VLAN ou le routeur en amont peuvent réduire la taille de paquet utilisable
Interface XFRM	L’IPsec basé sur des routes génère un surcoût supplémentaire et nécessite un MTU de tunnel approprié
Route SD-WAN	Un chemin peut passer par un autre WAN, MPLS ou VPN que prévu
Règle de pare-feu	Les fonctionnalités de sécurité ou la journalisation aident à délimiter, mais ne sont pas le MTU lui-même
Contrepartie	L’autre pare-feu, VPN cloud ou côté fournisseur doit gérer correctement le même chemin
Interface Wi-Fi	Depuis SFOS 22.0 MR1, Sophos mentionne également les ajustements MTU/MSS pour les interfaces Wi-Fi via CLI

Pour les VPN basés sur des routes, Sophos Firewall crée des interfaces XFRM. Les valeurs MTU XFRM sont calculées à partir de l’interface physique et du surcoût IPsec maximal et peuvent être ajustées si nécessaire. Cela est utile, mais ne remplace pas une vérification propre du chemin réel.

Prouver d’abord le chemin

Avant toute modification, il est important de décrire clairement le flux de données concerné. Sinon, on optimise rapidement sur la mauvaise interface.

Questions pratiques :

Quelle IP source et IP de destination sont concernées ?
Le trafic passe-t-il par LAN, VLAN, WAN, XFRM, RED, SD-WAN ou VPN d’accès à distance ?
Une seule direction est-elle concernée ou les deux ?
Cela concerne-t-il TCP, UDP ou les deux ?
Les petits paquets fonctionnent-ils, mais pas les transferts plus importants ?
La règle de pare-feu attendue est-elle vraiment appliquée ?
Y a-t-il du NAT, MASQ, inspection TLS, IPS ou contrôle d’application sur le chemin ?
La contrepartie a-t-elle une route de retour appropriée ?

Pour la vérification des règles et des chemins, Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture est utile. Pour le NAT ou MASQ, il convient également de vérifier Comprendre le NAT sur Sophos Firewall.

Diagnostic avec Log Viewer, Packet Capture et iPerf

Le Log Viewer montre si le trafic est autorisé ou rejeté. Cependant, il ne prouve pas à lui seul si un paquet est trop grand. Pour cela, il faut également utiliser Packet Capture, des tests reproductibles et une interprétation claire.

Log Viewer

Dans le Log viewer, vérifiez d’abord :

Sélectionnez le module Firewall ou le module de sécurité concerné.
Filtrez par IP source, IP de destination et service.
Vérifiez quelle règle de pare-feu correspond.
Assurez-vous qu’aucune règle de rejet, zone incorrecte ou règle NAT incorrecte n’est le véritable problème.

Si aucun trafic n’est visible, le problème se situe souvent avant le pare-feu, au niveau de la passerelle client, du VLAN, du routage ou de la contrepartie.

Packet Capture

Sous Diagnostics > Tools > Packet capture, vous pouvez affiner le test. Un filtre sur la source et la destination concernées est utile. Ensuite, un test unique est reproduit, par exemple un appel HTTPS, un transfert de fichier ou un démarrage d’application.

L’interprétation est importante :

Observation	Signification
Les paquets n’arrivent pas sur le pare-feu	Vérifiez le client, la passerelle, le VLAN ou le routage local
Les paquets entrent dans le tunnel, les réponses manquent	Vérifiez la contrepartie, la route de retour ou le pare-feu distant
De nombreuses retransmissions avec TCP	Vérifiez la perte de paquets, MTU/MSS, la qualité du WAN ou la surcharge
Les petits tests fonctionnent, les transferts importants sont bloqués	Vérifiez MTU/MSS ou la découverte de MTU de chemin

Pour l’utilisation de l’outil, Utiliser l’outil Packet Capture dans WebAdmin est approprié.

iPerf

iPerf est utile lorsque vous pouvez mesurer un chemin de manière reproductible. Un serveur iPerf propre sur la contrepartie est beaucoup plus significatif qu’un serveur iPerf public. Si le débit TCP est faible et que de nombreuses retransmissions sont visibles, le MTU/MSS doit être vérifié avec la qualité du WAN, le CPU, la contrepartie et les fonctionnalités de sécurité.

La procédure est décrite dans Dépannage de Sophos Firewall avec iPerf et Speedtest.

Modifier les valeurs uniquement de manière ciblée

Si le soupçon est fondé, les modifications doivent rester petites, documentées et réversibles.

Avant une modification :

documenter la valeur actuelle
noter l’interface et le tunnel concernés
choisir une fenêtre de maintenance ou un moment de test contrôlé
ne modifier qu’une seule valeur par test
effectuer un test avant/après avec la même application
informer la contrepartie si un VPN site-à-site est concerné

Pour les VPN basés sur des routes, l’interface XFRM et la connexion IPsec associée doivent être vérifiées en premier. Pour PPPoE ou les superpositions de fournisseurs, l’interface WAN ou le chemin du fournisseur est souvent le point décisif. Pour le SD-WAN, il doit également être clair quel chemin de passerelle ou de VPN est réellement utilisé. L’article Routage SD-WAN pour les paquets de réponse et le trafic système aide à situer les chemins SD-WAN.

⚠️ Ne pas utiliser de hacks Shell permanents. La manipulation directe de paquets via Advanced Shell, les scripts de démarrage non documentés ou les règles de filtrage de paquets spontanées ne sont pas une solution propre pour les pare-feux en production. Les fonctions prises en charge par Sophos Firewall doivent être vérifiées en premier.

Ce qu’il faut éviter

Ces pratiques causent plus de dommages que de bénéfices dans la pratique :

Réduire de manière générale le MSS pour tous les réseaux.
Modifier les valeurs MTU sans test avant/après.
Tester une seule direction et en déduire tout le chemin VPN.
Utiliser des solutions de contournement Shell au lieu des fonctions WebAdmin ou de la console de l’appareil documentées.
Ignorer la contrepartie, bien que le chemin de retour ou son serrage MSS puisse être impliqué.
Supposer que le MTU/MSS est la cause, bien que la règle de pare-feu, le NAT, le routage ou le DNS n’aient pas été vérifiés.
Laisser les journaux de débogage ou les captures de paquets fonctionner longtemps et remplir l’espace de stockage.

Si des scripts locaux ou des manipulations de paquets existent déjà, il est conseillé de lire d’abord Scripts Sophos Firewall sans Cronjob : risques et alternatives et de documenter proprement les anciens problèmes.

Tableau de dépannage

Symptôme	Zone probable	Prochaine vérification
VPN vert, transferts importants bloqués	MTU/MSS, chemin de retour, fonctionnalité de sécurité	Packet Capture et iPerf avec le même chemin
Seul le WAN PPPoE est concerné	Chemin du fournisseur ou MTU WAN	Vérifiez l’interface WAN, la passerelle et les informations du fournisseur
VPN basé sur des routes instable avec de gros paquets	MTU XFRM ou chemin SD-WAN	Vérifiez l’interface XFRM, la connexion IPsec et la route
VoIP sur VPN seulement partiellement stable	SD-WAN, chemin de retour, perte de paquets, MTU	Vérifiez le chemin SIP/RTP, la route SD-WAN et la capture
TCP très lent, UDP normal	MSS, retransmissions, fenêtre TCP, perte de paquets	Testez iPerf TCP/UDP séparément
Les petits paquets fonctionnent, les gros non	Découverte de MTU de chemin ou fragmentation	Testez consciemment les tailles de paquets et vérifiez la contrepartie

Liste de contrôle

À vérifier immédiatement :

Source, destination, service et direction concernés documentés.
Règle de pare-feu et règle NAT confirmées dans le Log Viewer.
Packet Capture effectué avec un filtre étroit.
Statut IPsec et compteur d’octets vérifiés si un VPN est impliqué.
Contrepartie et chemin de retour vérifiés.

Si le MTU/MSS est probable :

interface ou point XFRM concerné identifié.
valeur actuelle MTU/MSS documentée.
une seule modification par test planifiée.
application de test et valeur de comparaison définies.
modification coordonnée avec la contrepartie si un VPN site-à-site est concerné.

Après la modification :

tester à nouveau la même application.
comparer Log Viewer, Packet Capture ou iPerf.
documenter les nouvelles valeurs et la justification.
vérifier la surveillance dans les jours suivants.

FAQ

Le MTU est-il la même chose que le MSS ?

Non. Le MTU concerne la taille maximale des paquets sur une interface ou un chemin. Le MSS concerne la charge utile TCP par segment. Les deux sont liés, mais ne sont pas identiques.

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

Les petits tests peuvent fonctionner, bien que des segments TCP plus importants causent des problèmes plus tard. C’est pourquoi un simple ping ne suffit pas à prouver que tout le chemin est sain.

Faut-il modifier le MTU pour chaque VPN ?

Non. De nombreux VPN fonctionnent correctement avec les valeurs par défaut. Une modification n’est pertinente que si le chemin concerné et le problème le justifient.

Qu'est-ce qui est particulier aux interfaces XFRM ?

Les interfaces XFRM appartiennent aux VPN IPsec basés sur des routes. Sophos Firewall les crée automatiquement dans le contexte de la connexion IPsec. Pour les VPN basés sur des routes, les routes, les règles de pare-feu et l’interface XFRM déterminent ensemble où le trafic circule.

Devrait-on forcer le MSS via le Shell ?

Pour le fonctionnement normal, non. La manipulation de paquets basée sur le Shell est difficile à maintenir et peut disparaître ou mal fonctionner après des mises à jour, une restauration ou un basculement HA. Les fonctions de pare-feu prises en charge sont préférables.