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.

Distinguer les valeurs globales des politiques individuelles

Sous System services > Traffic shaping settings, Total available WAN bandwidth définit la capacité QoS commune à toutes les liaisons WAN. Il faut saisir la somme de la bande passante disponible de manière stable, en KBps, et non seulement le débit contractuel d’une seule liaison. Show bandwidth usage montre comment cette capacité est répartie entre les priorités. Ces valeurs globales n’affectent que le trafic WAN sortant transféré qui ne correspond à aucune politique Traffic Shaping individuelle.

Avec Optimize for real-time (VoIP), SFOS donne toujours la priorité au trafic en temps réel. Lorsque l’option est désactivée, les politiques Guarantee reçoivent d’abord leur bande passante garantie et le trafic en temps réel utilise le reste. Enforce guaranteed bandwidth active pour le trafic sans politique propre les valeurs Guarantee, Limit et Priority de 1 à 7 de la politique par défaut.

Ces options ne doivent pas être activées comme correctif général de performance. Il faut d’abord documenter la bande passante réelle, les garanties existantes et la priorité souhaitée. Sinon, des garanties surdimensionnées se disputent une capacité qui n’existe pas physiquement.

Configurer le Traffic Shaping basé sur les applications

L’exemple suivant donne la priorité au trafic de quatre terminaux vidéo Teams actifs simultanément au maximum 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 terminaux actifs simultanément.

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, en revanche, alloue la valeur uniquement à l’objet auquel la politique est attribuée en premier ; une politique Individual ne doit donc pas servir de modèle réutilisable pour plusieurs objets. 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. Dans cet exemple, les garanties correspondent au besoin total recommandé pour quatre terminaux vidéo Teams. Lorsque de la bande passante est disponible, ils peuvent l’utiliser jusqu’aux limites supérieures. Les limites de 12/40 Mbit/s laissent délibérément de la capacité pour le reste du trafic sur la connexion mesurée à 80/15 Mbit/s. Ce sont des valeurs initiales, pas des exigences Teams universelles.

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. Une catégorie s’ouvre directement avec Edit. Pour une application individuelle, développer d’abord la catégorie avec Expand, puis sélectionner Edit pour l’application. Choisir ensuite Teams Guarantee et confirmer avec Save.

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.

L’attribution sous Traffic shaping default n’active pas à elle seule le shaping basé sur les applications. Si Apply application-based traffic shaping policy reste désactivé dans la règle de pare-feu et qu’une rules policy est sélectionnée sous Shape traffic, cette rules policy remplace l’attribution par défaut. Ce n’est qu’après avoir activé l’option que l’applications policy est évaluée et que l’ordre de priorité indiqué devient pertinent.

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.

Appliquer le Traffic Shaping à d’autres objets

Policy association détermine dès la création où une politique peut être sélectionnée : Applications, Web categories, Users ou Rules. Elle ne peut ensuite plus être convertie vers un autre type. Un Schedule facultatif limite sa période d’activité, mais ne remplace ni l’attribution à l’objet ni le test fonctionnel.

Appliquer le shaping aux catégories web

Pour un site ou une catégorie, créer une politique avec Policy association > Web categories et l’attribuer à la catégorie concernée sous Web > Categories. La catégorie doit figurer dans une Web Policy effective. Dans la règle de pare-feu qui correspond réellement au trafic, sélectionner cette Web Policy et activer Apply web category-based traffic shaping. La seule attribution enregistrée à une catégorie n’applique encore aucun shaping au trafic.

Utilisateurs, groupes et règles WAF

Une politique avec Policy association > Users s’attribue sous Authentication > Users ou Authentication > Groups. La règle de pare-feu doit effectivement identifier l’utilisateur avec Match known users. Pour une règle WAF, attribuer au contraire une politique Rules sous Advanced settings > Traffic shaping dans la règle ayant Action > Protect with web server protection.

Si plusieurs niveaux correspondent simultanément, l’ordre est l’application, la catégorie d’application, la catégorie web, l’utilisateur, le groupe et enfin la règle de pare-feu. Il faut donc utiliser un flux réel, l’utilisateur identifié ou l’Application ID et la règle réellement appliquée pour vérifier quelle politique agit.

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 NC-178197, un défaut susceptible d’interrompre par intermittence le trafic applicatif lorsqu’une politique de bande passante basée sur les applications était appliquée. 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.