Effectuer un test de vitesse Internet sur Sophos Firewall via SSH

Un test de vitesse Internet dans le navigateur ne montre pas toujours ce que la connexion Internet peut réellement offrir. Le navigateur, le client, le Wi-Fi, le proxy, l’IPS, le filtre Web, l’inspection TLS, le VPN, le NAT et les règles de pare-feu peuvent influencer le résultat. Parfois, un test directement sur le Sophos Firewall est utile pour distinguer la connexion WAN du pare-feu des problèmes de client ou de règles.

Cet article décrit un simple test de téléchargement via SSH sur le Sophos Firewall, la bonne interprétation du résultat et les limites par rapport à iPerf, Log Viewer ou Packet Capture. Il est particulièrement important de faire la distinction en cas de plusieurs connexions WAN : le test mesure le trafic de téléchargement propre au pare-feu, pas automatiquement le même chemin qu’un client derrière le pare-feu.

Quel test de performance convient ?

Un téléchargement directement sur le pare-feu n’est qu’un outil. Selon la question, un autre test peut être plus pertinent :

Vérifier le téléchargement WAN directement sur le pare-feu: Cet article
Mesurer le débit entre deux réseaux définis: Utiliser correctement iPerf derrière Sophos Firewall
Interpréter les valeurs des fiches techniques et la performance réelle de sécurité: Comprendre correctement les données de performance du Sophos Firewall
Vérifier quelle règle ou politique de pare-feu s’applique: Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture
Analyser des paquets individuels, le NAT ou le chemin de retour: Utiliser Packet Capture sur Sophos Firewall de manière ciblée
Le VPN est lent ou instable: Vérifier MTU et MSS en cas de problèmes VPN sur Sophos Firewall
Voir les modèles de trafic et les pics de volume sur les interfaces: Configurer le monitoring sFlow sur Sophos Firewall

Cette séparation évite les mauvaises interprétations. Un téléchargement rapide sur le pare-feu ne prouve pas qu’un chemin client, une connexion VPN ou une règle d’inspection TLS doit également être rapide.

Ce qu’un test de vitesse sur le pare-feu prouve

Un test de vitesse directement sur le pare-feu répond à une question concrète : le pare-feu peut-il lui-même télécharger un fichier depuis Internet à une vitesse attendue via son chemin de routage actuel ?

Cela est utile si l’on souhaite savoir :

si la connexion WAN est fondamentalement assez rapide
si la connexion du fournisseur offre environ le taux de téléchargement attendu
si un problème se situe plutôt avant ou après le pare-feu
si le client, le Wi-Fi, le commutateur, le filtre Web, l’inspection TLS ou le VPN doivent être inclus dans l’analyse

Cependant, le test ne prouve pas automatiquement que les clients derrière le pare-feu doivent atteindre la même vitesse. Le trafic client passe par des règles de pare-feu, le NAT, des politiques de sécurité et, selon la configuration, par l’IPS, la protection Web, le contrôle des applications ou l’inspection TLS. Le téléchargement local sur le pare-feu contourne une partie de ce traitement et convient donc comme distinction, pas comme test complet de bout en bout.

Pour l’interprétation des valeurs des fiches techniques, des fonctionnalités de sécurité et de la performance réelle, il est utile de consulter Comprendre correctement les données de performance du Sophos Firewall.

Prendre en compte plusieurs connexions WAN et SD-WAN

Pour les pare-feux avec plusieurs liens WAN, il est conseillé de clarifier avant le test par quel chemin le pare-feu lui-même accède à Internet. Le téléchargement est généré par le Sophos Firewall. Il s’agit donc de trafic propre au système et ne suit pas nécessairement la même décision qu’un flux client traité par une règle de pare-feu, une règle NAT ou une route SD-WAN.

Hypothèses typiques erronées :

Plusieurs passerelles WAN: Le téléchargement du pare-feu peut passer par une autre passerelle que le trafic client concerné
Routage SD-WAN pour les clients: Les règles SD-WAN client ne prouvent pas automatiquement le chemin pour le trafic propre au pare-feu
Failover ou WAN de secours actif: Le test mesure éventuellement le chemin de secours
Routage basé sur des politiques ou NAT spécial: Un chemin client peut être traité différemment du téléchargement local du pare-feu

Dans de tels cas, il est conseillé de documenter le résultat avec l’heure, le lien WAN actif et la passerelle observée. Si le trafic propre au système, les paquets de réponse ou les décisions SD-WAN sont peu clairs, il est utile de consulter Comprendre le routage SD-WAN, les paquets de réponse et le trafic système sur Sophos Firewall.

Prérequis

Avant le test, les points suivants doivent être remplis :

L’accès SSH ou Advanced Shell est autorisé volontairement, de préférence uniquement depuis un réseau d’administration de confiance.
Le pare-feu a accès à Internet et le DNS fonctionne.
Il y a une fenêtre de maintenance ou au moins un moment non critique.
Il est clair par quelle interface WAN le pare-feu effectue le téléchargement.
Il y a suffisamment d’espace libre pour le fichier de test.
Le fichier de test est supprimé après le test.

Pour un accès SSH sécurisé, consultez Connecter Sophos Firewall via SSH. Dans SFOS, SSH est autorisé sous Administration > Device access via Local service ACL ou, plus précisément, via une Local service ACL exception rule. SSH ne doit pas être autorisé largement depuis les zones WAN ou Wi-Fi et doit être limité au minimum nécessaire après les tâches de dépannage. Sophos Firewall ferme les sessions SSH inactives après 15 minutes.

⚠️ Un test de téléchargement génère un trafic réel et peut saturer la connexion à court terme. Sur les pare-feux en production, ces tests ne doivent pas être effectués pendant les heures de travail critiques ou en parallèle avec des fenêtres de sauvegarde, VoIP ou de maintenance.

Vérifier DNS et le routage avant le téléchargement

Avant de télécharger un gros fichier de test, il faut vérifier brièvement si la résolution de noms et l’accessibilité fonctionnent en principe. Sinon, on risque vite de confondre des problèmes DNS, de routage ou de fournisseur avec un résultat de test de vitesse.

Dans le menu principal de la CLI, ouvrir d’abord 4 Device Console et exécuter des contrôles simples :

dnslookup www.avanet.io
ping www.avanet.io
traceroute www.avanet.io

dnslookup vérifie la résolution de noms, ping fournit un test rapide d’accessibilité et traceroute montre le chemin approximatif vers la cible. Dans Device Console, Sophos prend en charge des paramètres ping supplémentaires comme interface ou sourceip. C’est utile avec plusieurs connexions WAN lorsqu’une source ou une interface précise doit être vérifiée.

Si DNS échoue déjà, le test curl suivant n’est pas parlant. Il faut d’abord vérifier DNS, default route, gateway WAN, décision SD-WAN ou disponibilité du fournisseur.

Effectuer un test de vitesse via SSH

Se connecter à Sophos Firewall via SSH avec admin. Dans le menu principal de la CLI, sélectionner 5 Device Management, puis ouvrir 3 Advanced Shell. Advanced Shell est un shell Linux avec un accès profond aux composants système. Dans cet article, il sert uniquement à télécharger un fichier dans /tmp puis à le supprimer.

Ensuite, téléchargez le fichier de test dans un répertoire temporaire pour éviter qu’il ne reste accidentellement dans un répertoire de travail inapproprié.

cd /tmp
curl -L -o 1GB.bin https://www.avanet.io/1GB.bin

Le serveur de test est situé en Suisse et est destiné à une mesure approximative de la connexion. Pour des tests plus petits, vous pouvez utiliser 100MB.bin au lieu de 1GB.bin :

cd /tmp
curl -L -o 100MB.bin https://www.avanet.io/100MB.bin

Si le DNS ne fonctionne pas, le test échoue déjà lors de la résolution de nom. Dans ce cas, il ne faut pas analyser la vitesse de la connexion, mais d’abord le DNS, le routage et la disponibilité WAN.

Pour les pare-feux avec plusieurs liens WAN, le test ne doit pas être considéré isolément. En parallèle, il est conseillé de vérifier dans le WebAdmin quel lien WAN est actif et s’il y a un failover, un changement SD-WAN ou une panne de fournisseur.

Supprimer le fichier de test

Après le test, le fichier doit être supprimé :

rm /tmp/1GB.bin

Pour un test avec le fichier plus petit :

rm /tmp/100MB.bin

Si le test a été interrompu, vérifiez tout de même s’il existe un fichier partiellement téléchargé :

ls -lh /tmp/*GB.bin

Les gros fichiers de test ne doivent pas rester sur le pare-feu. Surtout sur les petites appliances ou les partitions déjà remplies, une consommation de mémoire inutile peut entraîner plus tard des problèmes difficiles à comprendre.

Évaluer le test de vitesse

Pendant et après le téléchargement, curl affiche entre autres le taux de téléchargement moyen. Dans l’exemple, la valeur est d’environ 107 MB/s.

Test de vitesse Internet sur Sophos Firewall

L’unité est importante :

MB/s signifie mégaoctets par seconde.
Mbit/s ou Mbps signifie mégabits par seconde.
1 octet équivaut à 8 bits.

Comme conversion approximative :

MB/s x 8 = Mbit/s

107 MB/s correspondent donc à environ 856 Mbit/s. Le surcoût, le comportement TCP, le correspondant, le routage et la charge peuvent influencer la valeur. Il ne faut donc pas utiliser une seule mesure comme preuve définitive.

Il est judicieux de réaliser plusieurs tests à différents moments de la journée. Si les valeurs fluctuent fortement, il est conseillé de vérifier le fournisseur, le lien WAN, le routage SD-WAN, les erreurs d’interface et la charge.

Pour le support ou la documentation interne, il ne suffit pas de noter le chiffre. Un court ensemble de données de mesure aide considérablement par la suite :

Moment: 2026-06-21 10:15
Pare-feu et firmware: XGS 2100, SFOS 22.0 MR1
Fichier de test: 1GB.bin
Taux mesuré: 107 MB/s, environ 856 Mbit/s
Lien WAN actif: WAN1 Fiber
Anomalies: sauvegarde parallèle, failover, CPU élevée, Packet Capture actif

Lorsque plusieurs mesures sont comparées, le fichier de test, la cible, l’heure et le chemin WAN doivent rester aussi constants que possible. Sinon, on compare rapidement l’heure de la journée, le chemin du fournisseur ou le correspondant au lieu de la performance réelle du pare-feu.

Comparer avec des tests clients

L’étape suivante consiste à comparer avec un client derrière le pare-feu. Cela permet de déterminer où la performance est perdue.

Téléchargement directement sur le pare-feu est rapide: La connexion WAN du pare-feu n’est probablement pas le principal goulot d’étranglement
Téléchargement directement sur le pare-feu est lent: Vérifier le fournisseur, le lien WAN, le routage, le DNS ou la connexion du pare-feu
Pare-feu rapide, client lent: Vérifier le client, le Wi-Fi, le commutateur, la règle de pare-feu, le NAT, la politique de sécurité ou l’inspection TLS
Seules certaines applications sont lentes: Vérifier le filtre Web, le contrôle des applications, le DNS, le proxy ou le serveur cible
Seul le VPN est lent: Vérifier le protocole VPN, MTU/MSS, le routage, les règles de pare-feu et le réseau client

Pour des tests de chemin ciblés, iPerf est souvent meilleur qu’un téléchargement public. Avec iPerf, vous pouvez définir où se trouvent le serveur et le client, si le test est TCP ou UDP et quelle bande passante est attendue.

Interprétations erronées typiques

Le test de vitesse du pare-feu est rapide, mais les utilisateurs signalent toujours un Internet lent

Dans ce cas, la connexion WAN n’est pas automatiquement innocente, mais le focus se déplace. Il est conseillé de vérifier le réseau client, le Wi-Fi, le port du commutateur, le DNS, la règle de pare-feu, le NAT, l’IPS, la protection Web, le contrôle des applications et l’inspection TLS. En particulier, l’inspection TLS ou les profils de sécurité agressifs peuvent traiter le trafic client de manière très différente d’un téléchargement directement sur le pare-feu.

Le test de vitesse du navigateur est lent, le test de vitesse du pare-feu est rapide

Cela indique souvent un problème derrière le pare-feu ou dans le chemin client. Cependant, il est conseillé de tester plusieurs navigateurs, un client câblé et une deuxième cible avant de supposer une cause fixe.

Le test de vitesse du pare-feu est lent

Dans ce cas, vérifiez d’abord l’état du WAN, la vitesse du lien, le duplex, le routage SD-WAN, le DNS, les pannes de fournisseur et la charge. Avec plusieurs connexions WAN, il doit être clair par quelle passerelle le téléchargement est effectué.

Seul le téléchargement est lent

Le téléchargement curl décrit ici teste principalement la direction du téléchargement. Pour les tests de téléchargement ou bidirectionnels, iPerf ou une autre configuration de test définie est mieux adaptée.

Dépannage après le test

Si après le test de vitesse, il reste incertain où se situe le problème, il est conseillé de continuer de manière structurée :

Vérifier Device Console : utiliser dnslookup, ping et traceroute avant d’interpréter les valeurs de téléchargement.
Vérifier Log Viewer : Quelle règle de pare-feu rencontre le trafic client ?
Utiliser Policy Test : Vérifier la source, la destination, le service et l’utilisateur attendus.
Démarrer Packet Capture : Peut-on voir les paquets, les paquets de réponse et le NAT ?
Vérifier l’état de l’interface : Évaluer la vitesse du lien, les erreurs, les pertes et la charge.
Vérifier les fonctionnalités de sécurité : IPS, filtre Web, inspection TLS, contrôle des applications.
Effectuer une contre-vérification avec iPerf : Tester le chemin, TCP/UDP et la direction de manière ciblée.

Pour les analyses de règles et de flux de paquets, consultez Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture. Pour les journaux plus approfondis, consultez Dépannage Sophos Firewall : Services et journaux.

Liste de contrôle

Avant le test

Accès SSH ou Advanced Shell autorisé volontairement.
Device Access ou Local Service ACL exception rule limité proprement pour SSH.
DNS et accessibilité vérifiés via Device Console.
Moment du test choisi.
Chemin WAN connu.
Espace mémoire suffisant disponible.
Objectif de la mesure défini : test WAN, comparaison client ou distinction VPN.

Pendant le test

Télécharger le fichier de test dans /tmp.
Noter le taux de téléchargement et l’unité.
En cas d’erreurs, ne pas confondre DNS, routage ou accessibilité avec la vitesse.
Ne pas effectuer de grandes modifications parallèles aux règles de pare-feu ou au SD-WAN.

Après le test

Supprimer le fichier de test.
Convertir le résultat en Mbit/s.
Comparer avec un test client ou iPerf.
En cas de divergences, utiliser Log Viewer, Policy Test et Packet Capture.
Documenter le résultat avec l’heure, le lien WAN et l’objectif du test.

FAQ

Ce test permet-il de mesurer la véritable vitesse Internet ?

Il mesure le taux de téléchargement du pare-feu vers une cible de test spécifique. C’est un bon indicateur de la connexion WAN, mais pas un test complet de bout en bout pour les clients derrière le pare-feu.

Pourquoi un test de vitesse dans le navigateur derrière le pare-feu est-il différent ?

Le trafic client peut être influencé par le Wi-Fi, les commutateurs, les règles de pare-feu, le NAT, l’IPS, la protection Web, l’inspection TLS ou le contrôle des applications. Un téléchargement directement sur le pare-feu n’utilise pas le même chemin de traitement.

Faut-il tester 100 MB ou 1 GB ?

Pour les connexions rapides, 1 GB est plus significatif car le test dure plus longtemps. Pour des vérifications rapides ou des connexions plus petites, 100 MB suffisent souvent. Sur les petits pare-feux ou en cas de mémoire limitée, il est conseillé de tester prudemment et de supprimer ensuite.

iPerf est-il meilleur que curl ?

Pour les analyses de performance ciblées, généralement oui. curl est rapide et simple pour un test de téléchargement WAN. iPerf est meilleur si vous souhaitez contrôler la direction, la cible, TCP/UDP, la durée et la bande passante.

Le test curl est-il un test de vitesse officiel de Sophos ?

Non. Sophos documente l’accès CLI, Device Console et Advanced Shell, mais pas de test de vitesse Internet officiel via curl. Le test est une méthode pratique d’Avanet pour délimiter la connexion WAN et doit être complété par des tests client, des logs ou iPerf.

Pourquoi le fichier de test doit-il être supprimé ?

Le pare-feu n’est pas un serveur de fichiers. Les gros fichiers de test consomment de l’espace mémoire et peuvent causer des problèmes plus tard sur les petites appliances ou les partitions pleines.

Pourquoi le test de vitesse du pare-feu peut-il être différent d'un test client avec plusieurs WAN ?

Le test est généré par le pare-feu lui-même. Il peut donc utiliser un chemin de routage différent du trafic client, qui passe par des règles de pare-feu, le NAT ou des routes SD-WAN. Avec plusieurs liens WAN, le chemin actif doit donc toujours être documenté.