Configurer le Traffic Shaping des applications sur Sophos Firewall

Le Traffic Shaping des applications permet à Sophos Firewall de prioriser ou de limiter des applications individuelles telles que Microsoft Teams, VoIP, OneDrive ou les services de sauvegarde. La procédure complète basée sur les applications est la suivante :

1. Sous System services > Traffic shaping, créer une politique avec Policy association > Applications.
2. Sous Applications > Application filter, configurer la détection de l’application souhaitée.
3. Sous Applications > Traffic shaping default, attribuer la politique à l’application ou à la catégorie.
4. Sous Rules and policies > Firewall rules, sélectionner l’Application Filter et activer Apply application-based traffic shaping policy.

Une politique avec Policy association > Rules dans le champ Shape traffic constitue une autre méthode : elle façonne l’ensemble du trafic correspondant à la règle de pare-feu, et pas uniquement l’application sélectionnée dans l’Application Filter.

⚠️ Le Traffic Shaping ne crée pas de bande passante supplémentaire. Il répartit un goulot d’étranglement de manière plus contrôlée. Si la connexion est constamment saturée, il faut tout de même examiner la capacité, les sauvegardes, les synchronisations cloud et les autres sources de charge.

Le Traffic Shaping limite un débit, pas le volume total de données transféré. Pour des crédits de temps ou de données consommables, on utilise plutôt Surfing Quota et Network Traffic Quota.

Planifier les prérequis et la bande passante

Avant la configuration, clarifier les points suivants :

• L’Application Control est nécessaire au shaping basé sur les applications. Il fait partie de Web Protection et est également inclus dans le bundle Standard Protection. Vérifier son état sous System > Administration > Licensing. En revanche, une politique Rules ne nécessite pas la détection d’applications.
• Le pare-feu détecte l’application concernée et le trafic passe par une règle de pare-feu connue.
• La journalisation est activée pour cette règle.
• Il est établi si la contrainte concerne l’upload, le download ou les deux directions, ainsi que la passerelle WAN ou le chemin SD-WAN utilisé.
• L’effet recherché est défini : Guarantee réserve une bande passante minimale et autorise le trafic jusqu’à la limite ; Limit fixe uniquement un plafond.

Sophos affiche les valeurs de shaping en KBps, tandis que les tests de débit utilisent généralement des kbps ou des Mbit/s. 1 KBps équivaut à 8 kbps. Ainsi, 100 Mbit/s correspondent à environ 12 500 KBps et 20 Mbit/s à environ 2 500 KBps.

Il faut se baser sur des mesures stables et non sur le débit annoncé par le fournisseur. Si une connexion nominale de 100/20 Mbit/s ne fournit de manière fiable que 80/15 Mbit/s, il convient de planifier environ 10 000/1 875 KBps. Des valeurs supérieures au goulot d’étranglement réel ne permettent pas de le contrôler efficacement.

Pour les connexions asymétriques, activer Limit upload/download separately. Teams, VoIP, VPN et les sauvegardes cloud sont souvent les premiers à souffrir lorsque l’upload est saturé. Les valeurs globales sous System services > Traffic shaping settings ne s’appliquent qu’au trafic sortant que le pare-feu transfère vers la zone WAN. Les politiques Traffic Shaping individuelles peuvent en revanche s’appliquer au trafic transféré entrant et sortant. La QoS ne s’applique par ailleurs pas au trafic généré par le système du pare-feu, comme les mises à jour de signatures ou les synchronisations de licence.

Configurer le Traffic Shaping basé sur les applications

L’exemple suivant priorise jusqu’à quatre réunions vidéo Teams simultanées sur un petit site disposant d’une connexion stable d’environ 80/15 Mbit/s. Dans ses besoins en bande passante pour Teams, Microsoft recommande environ 2 500 kbps en upload et 4 000 kbps en download par terminal pour une réunion vidéo. Les valeurs de l’exemple réservent ce besoin commun, mais doivent être comparées aux mesures locales et au nombre réel de réunions simultanées.

Créer une politique de Traffic Shaping

Sous System services > Traffic shaping, créer une politique, par exemple avec les valeurs suivantes :

• Name: Teams Guarantee
• Policy association: Applications
• Rule type: Guarantee
• Limit upload/download separately: Enable
• Priority: 1 (priorité la plus élevée)
• Upload Guarantee / Limit: 1 250 / 1 500 KBps
• Download Guarantee / Limit: 2 000 / 5 000 KBps
• Bandwidth usage type: Shared

1 250 KBps correspondent à 10 Mbit/s et 2 000 KBps à 16 Mbit/s. Avec Shared, toutes les applications ou catégories auxquelles cette politique est attribuée partagent le même pool. Individual met la valeur à disposition pour chaque objet attribué. Il ne faut pas répartir des valeurs de garantie élevées sur trop de politiques, car leur somme doit rester compatible avec la bande passante réellement disponible.

Les politiques de Traffic Shaping ne peuvent plus être modifiées après leur création. Si d’autres valeurs sont nécessaires, commencer par documenter toutes les attributions, créer une politique de remplacement sous un nouveau nom et ne migrer d’abord qu’un périmètre limité. Après validation, migrer les autres attributions et ne supprimer l’ancienne politique que lorsqu’aucune référence ne subsiste. Pour revenir en arrière, réattribuer l’ancienne politique ou None.

Créer un Application Filter

Sous Applications > Application filter, créer un filtre qui contient uniquement le trafic souhaité :

1. Saisir un nom tel que Microsoft Teams.
2. Ajouter une règle d’application.
3. Rechercher microsoft teams dans le Smart Filter.
4. Sélectionner les applications Teams correspondantes et les enregistrer avec Allow.

Il ne faut pas traiter Microsoft 365 comme une seule application par défaut. Teams, Exchange, SharePoint et OneDrive génèrent des trafics différents et doivent d’abord être observés séparément. Si l’objectif est la détection et le blocage plutôt que la bande passante, consulter Configurer et tester l’Application Control sur Sophos Firewall.

Attribuer la politique à l’application

Sous Applications > Traffic shaping default, rechercher Microsoft Teams ou la catégorie d’applications correspondante, ouvrir l’entrée et sélectionner Teams Guarantee.

Une politique attribuée à une application individuelle est prioritaire sur une politique attribuée à sa catégorie. Si plusieurs niveaux de shaping correspondent simultanément, Sophos applique cet ordre : application, catégorie d’applications, catégorie web, utilisateur, groupe, puis règle de pare-feu.

Activer la règle de pare-feu

Sous Rules and policies > Firewall rules, ouvrir la règle par laquelle passe réellement le trafic Teams. Dans la section Other security features :

1. Sous Identify and control applications (App control), sélectionner le filtre Microsoft Teams.
2. Activer Apply application-based traffic shaping policy.
3. Enregistrer la règle et générer du trafic.

La politique Applications n’est pas sélectionnée dans le champ Shape traffic ; elle provient de Traffic shaping default. Si plusieurs niveaux de Traffic Shaping correspondent simultanément, l’ordre documenté est le suivant : application, catégorie d’applications, catégorie web, utilisateur, groupe, puis règle de pare-feu. La politique Rules dans Shape traffic a donc la priorité la plus faible. Plusieurs niveaux ne doivent être combinés que délibérément et vérifiés avec du trafic réel.

L’ordre des règles reste déterminant : si le trafic correspond déjà à une règle plus générale placée plus haut, ni le filtre ni le shaping de la règle suivante ne sont appliqués.

Traffic Shaping par règle pour une règle entière

Si tout le trafic d’une règle de pare-feu clairement délimitée doit recevoir les mêmes valeurs, une politique Rules est plus simple :

1. Sous System services > Traffic shaping, créer une politique avec Policy association > Rules.
2. Sous Rules and policies > Firewall rules, ouvrir la règle concernée.
3. Sous Shape traffic, sélectionner la politique Rules.
4. Ne pas activer Apply application-based traffic shaping policy, sauf si des politiques Applications supplémentaires sont utilisées.

Un Application Filter ne limite pas automatiquement une politique Rules à cette application. Il faut soit restreindre la règle de pare-feu elle-même par la source, la destination et les services, soit utiliser la procédure basée sur les applications. Le DSCP marking ne remplace pas non plus le shaping : DSCP marque les paquets pour les équipements en aval, tandis que la politique de shaping du pare-feu garantit ou limite la bande passante.

Vérifier l’effet et ajuster la politique en toute sécurité

Après la modification, ne pas se fier uniquement à un test de débit. Vérifier si :

• Le trafic correspond à la règle de pare-feu attendue.
• Les journaux Application Control affichent l’application ou l’Application ID attendue.
• Les rapports comme Top Applications et les compteurs de règles confirment l’attribution attendue.
• La direction concernée est réellement saturée pendant le test.
• La bande passante, la latence, la perte de paquets ou la qualité des appels évoluent comme prévu.
• Le test utilise la même passerelle WAN et le même chemin SD-WAN que le trafic de production.
• Les retours des utilisateurs de services en temps réel confirment également les mesures techniques en pratique.

Pour une comparaison avant/après fiable, utiliser la même source, la même destination, la même direction et, si possible, la même période. Le guide Tester les performances de Sophos Firewall avec iPerf et Speedtest présente des méthodes de mesure adaptées. Avec plusieurs connexions, consulter également Vérifier le routage SD-WAN de Sophos Firewall pour les Reply Packets et le System Traffic.

Comme la politique n’est pas modifiable, créer une nouvelle version avec des valeurs ajustées de manière prudente. L’attribuer d’abord à une application, une catégorie ou une règle limitée, surveiller les journaux et les retours des utilisateurs, puis ne supprimer l’ancienne politique qu’après une validation réussie. Documenter l’objectif, la règle concernée, les valeurs, le responsable et la date de révision.

Lorsque le Traffic Shaping ne fonctionne pas comme prévu

L’application n’est pas détectée

Vérifier d’abord que le bon Application Filter est sélectionné dans la règle de pare-feu réellement utilisée par le trafic. Pour les services cloud étendus ou chiffrés, confirmer la classification dans le journal Application Control à l’aide de l’Application ID détectée.

Le shaping ne produit aucune différence

Si la connexion n’est pas saturée pendant le test, aucun goulot d’étranglement visible ne peut être contrôlé. Parmi les autres causes fréquentes figurent des valeurs supérieures à la bande passante réelle, la mauvaise direction, une règle de pare-feu plus générale placée plus haut ou un autre chemin SD-WAN.

Le shaping basé sur les applications exige également que les trois attributions soient correctes : une politique avec Applications, son attribution sous Traffic shaping default et l’option activée dans la règle de pare-feu. L’option seule n’attribue aucune bande passante.

Le trafic applicatif s’interrompt par intermittence

SFOS 22.0 MR2 Build 546 corrige avec NC-178197 un problème qui pouvait interrompre par intermittence le trafic applicatif lors de l’application d’une politique de bande passante basée sur les applications. Si ce symptôme apparaît sous SFOS 22.0 GA ou MR1, vérifier la version du firmware avant de remanier les politiques et effectuer la mise à jour vers MR2 ou une version ultérieure approuvée.

Microsoft 365 ou le réseau invité reste problématique

Évaluer séparément Teams, Exchange, SharePoint et OneDrive au lieu de garantir ou de limiter aveuglément toute la catégorie Microsoft 365. Pour le réseau invité, vérifier que son trafic correspond bien à la règle prévue et que l’upload comme le download sont limités lorsque cela est nécessaire.