Ouvrir un ticket Sophos : préparation et portail

Un ticket Sophos est plus vite utile lorsque les informations importantes sont préparées proprement dès l’ouverture. Pour Sophos Firewall, cela concerne surtout le numéro de série, le modèle, la version du firmware, l’état de la licence, l’heure de l’erreur, la fonction concernée, les journaux, les captures d’écran et les contrôles déjà effectués.

Ce guide explique quand un Sophos Support Case est pertinent, quelles informations préparer et comment ouvrir le ticket de façon traçable dans le Sophos Support Portal. Pour situer les différents accès Sophos, voir aussi Portails Sophos : SophosID, Central, support et accès firewall.

Quand un ticket Sophos est pertinent

Un ticket Sophos est pertinent lorsqu’un problème ne peut plus être clarifié localement uniquement avec la configuration, les journaux ou les procédures d’exploitation connues.

Cas typiques :

• défaut matériel, RMA ou suspicion d’appliance défectueuse
• problème de licence ou de compte avec un numéro de série concret
• problème de firmware, hotfix ou mise à niveau
• crash récurrent d’un service ou état système inexpliqué
• problème VPN, WAF, HA, RED ou de routage après une première analyse interne
• erreur qui ressemble à un problème produit après contrôle des journaux et reproduction
• demande de support nécessitant l’accès de Sophos à des données d’analyse internes

Avant d’ouvrir un ticket, il faut effectuer les vérifications locales évidentes. Pour Sophos Firewall, cela ne signifie pas que tout doit déjà être résolu. Mais plus le contexte initial, la fenêtre horaire et la fonction concernée sont décrits précisément, moins il y aura de questions en retour.

Ce que Sophos Support ne remplace pas

Enhanced Support n’est pas un service de configuration gratuit. Un ticket Sophos doit être ouvert lorsqu’une fonction du firewall ne fonctionne plus correctement ou lorsqu’un défaut produit, licence, matériel ou logiciel concret est suspecté.

Un ticket Sophos n’est pas approprié lorsqu’il manque seulement les connaissances nécessaires pour une configuration souhaitée. Exemples typiques :

• planifier une nouvelle topologie VPN
• structurer proprement des règles firewall
• configurer NAT ou WAF pour un nouveau service
• vérifier une conception HA
• évaluer un concept de routage ou une architecture VLAN
• transformer une configuration existante selon les bonnes pratiques

Dans ces cas, Avanet Support est le meilleur interlocuteur. Le firewall peut alors être vérifié, planifié ou configuré selon les besoins dans le cadre des conditions de support Avanet. Sophos Support aide principalement dans les cas techniques produit où une fonction ne marche pas malgré une configuration correcte, ou lorsqu’une appliance, une licence ou une attribution cloud pose problème.

Enhanced Support, Incident Levels et délais cibles

Enhanced Support améliore le droit au support et les objectifs de réponse, mais ne remplace pas une description propre du problème. Les délais cibles sont des objectifs de réponse, pas des délais de résolution garantis. Un problème VPN, HA ou de routage complexe peut durer plus longtemps malgré une première réponse rapide si les journaux, la reproduction ou l’accès à distance manquent.

Les valeurs suivantes servent d’orientation pour Enhanced Support :

• P1: panne totale en production ou incident de sécurité majeur sans contournement praticable. 30 minutes
• P2: fort impact en production, plusieurs utilisateurs ou services critiques touchés. 2 heures
• P3: problème technique à impact limité ou avec contournement existant. 4 heures
• P4: faible impact, question technique générale ou problème non urgent. 24 heures

Sophos utilise aussi des niveaux de Severity dans le processus de support. Selon la région, le droit au support et le type de cas, ces libellés et objectifs peuvent apparaître différemment dans le portail :

• Critical: panne grave en production, pas de contournement, traitement immédiat requis. 4 heures, avec traitement 24/7 lorsque disponible
• High: perturbation importante de systèmes de production. 8 heures ouvrées
• Medium: fonction limitée, contournement possible ou impact limité. 24 heures ouvrées
• Low: faible impact, question générale ou sujet de planification. 24 heures ouvrées

La Severity doit être choisie honnêtement selon l’impact réel. Une classification trop élevée sans impact correspondant aide rarement, car Sophos demandera dans le ticket l’impact, la reproductibilité et les services touchés. Si le cas est critique pour l’entreprise, la description doit le prouver clairement : sites concernés, nombre d’utilisateurs, absence de contournement, moment, état de la redondance et contrôles déjà réalisés.

Conditions préalables

Pour un ticket de support technique, il faut généralement :

• SophosID pour le Support Portal
• licence valide ou droit au support actif
• numéro de série concerné ou attribution de compte
• pour les cas partenaires : attribution client et licence ou numéro de série pertinent
• produit et modèle, par exemple Sophos Firewall XGS ou firewall virtuel
• version du firmware et build
• courte description de l’erreur avec impact
• fenêtre horaire du problème avec fuseau horaire
• journaux, captures d’écran ou messages d’erreur disponibles

Sophos vérifie l’attribution de la licence et du numéro de série dans les cas de support. Sans licence ou numéro de série correspondant, un case peut partir chez Customer Care pour validation. Cela retarde le traitement technique. Si un partenaire ouvre le case pour un client, l’attribution client et la licence ou le numéro de série concernés doivent aussi être indiqués clairement. Si Avanet doit gérer des cas de support au nom d’un client, le client doit autoriser l’accès partenaire correspondant à Avanet.

Le numéro de série du firewall se trouve directement dans le tableau de bord SFOS. La procédure est décrite dans Trouver le numéro de série de Sophos Firewall.

Si la demande concerne un défaut matériel, l’article Que faire en cas de défaut technique du matériel Sophos ? doit également être consulté.

Classer les canaux de support

Sophos propose plusieurs canaux de support. Tous ne conviennent pas aussi bien au même usage.

• Sophos Support Portal: Support Cases techniques traçables, pièces jointes, RMA, analyse longue
• Téléphone: relance urgente avec numéro de ticket existant ou contact en cas de problème d’accès
• Digital Chat: orientation rapide, questions de portail ou questions générales de support
• Sophos Community: questions non confidentielles, symptômes connus, échange avec d’autres administrateurs
• Sophos TechVids et Docs: sujets how-to, configuration et procédures connues

Pour les cas techniques liés au firewall, le Support Portal est généralement le meilleur point d’entrée, car le numéro de ticket, l’historique et les pièces jointes y restent traçables. Le téléphone ou le chat sont surtout utiles lorsqu’un ticket existant doit être priorisé d’urgence ou qu’un problème de portail doit être clarifié.

Les canaux de contact et numéros de téléphone actuels se trouvent sur la page officielle Sophos Support contact. La vue générale reste disponible sous Sophos Support.

Préparer le compte et l’accès partenaire

Un SophosID est nécessaire pour le Support Portal. Le compte doit correspondre à l’entreprise, à la licence ou au tenant Sophos Central afin que les produits concernés soient visibles. Si le firewall est suivi par un partenaire, il faut clarifier avant le cas de support si ce partenaire peut gérer les cases.

Si Avanet doit accompagner un case au nom d’un client ou communiquer avec Sophos, l’accès à l’attribution client doit être autorisé dans le Sophos Support Portal. Sophos décrit cette étape sous Allow a Sophos Partner to manage your account.

Concrètement :

1. Vérifier le SophosID.
2. Préparer la licence ou le numéro de série concerné.
3. Si Avanet doit aider, préparer l’accès partenaire dans le portail Sophos.
4. Si Sophos a besoin d’un accès à distance, préparer Support Access sur le firewall.

Préparer avant le ticket

Un Support Case doit être formulé de manière à ce que le support puisse classer le problème sans deviner.

Données techniques clés

Pour Sophos Firewall, ces informations doivent être disponibles :

• numéro de série
• modèle ou plateforme
• version du firmware et build
• état de la licence ou plan de support, si pertinent
• état HA, si le firewall fait partie d’un cluster
• fonction concernée, par exemple IPsec, SSL VPN, WAF, RED, Web Protection ou Reporting
• heure exacte de l’erreur avec fuseau horaire
• utilisateurs, réseaux, sites ou services concernés
• derniers changements avant le problème

Pour les clusters HA, les deux noeuds doivent être documentés clairement. Pour classer les rôles, numéros de série et l’exploitation HA, voir Variantes et exploitation du cluster HA Sophos Firewall.

Reproduction et impact

La description ne doit pas seulement dire que quelque chose ne fonctionne pas. Une présentation courte et vérifiable est préférable :

• Qu’est-ce qui était attendu ?
• Que se passe-t-il à la place ?
• Depuis quand le problème apparaît-il ?
• Le problème est-il permanent ou sporadique ?
• Comment peut-il être reproduit ?
• Quels utilisateurs ou services sont concernés ?
• Existe-t-il un contournement ?
• Quelle est la criticité de l’impact sur l’exploitation ?

Si un ticket se compose seulement d’une capture d’écran et d’une phrase, le support devra presque forcément poser des questions. Cela coûte du temps, surtout pour les problèmes VPN, de routage ou HA.

Journaux et pièces jointes

Pour les problèmes firewall, les journaux sont souvent plus importants que de longues suppositions. Si le problème est reproductible, il faut noter la fenêtre d’erreur aussi précisément que possible, puis sauvegarder les journaux adaptés.

Selon le problème, les éléments suivants sont utiles :

• capture d’écran du message d’erreur
• capture d’écran du Log Viewer avec filtre
• journaux de service pertinents
• Packet Capture ou tcpdump si le flux de paquets n’est pas clair
• capture d’écran firmware ou licence
• bref schéma réseau ou adresses IP concernées si le routage est impliqué
• description des règles, objets NAT ou paramètres VPN déjà vérifiés

Pour les archives complètes de journaux, Sauvegarder les journaux Sophos Firewall pour le support et l’analyse est la procédure adaptée. L’article Attribuer correctement les journaux de service Sophos Firewall résume quel fichier journal appartient à quel module.

Toutes les pièces jointes ne répondent pas à la même question :

• Quelle règle ou quel module a pris la décision ?: export Log Viewer, Rule ID, NAT ID, période concernée
• Quel service signale des erreurs ?: journaux de service pertinents ou archive /log complète
• Le trafic arrive-t-il et continue-t-il ?: Packet Capture dans WebAdmin
• Le support a-t-il besoin d’un fichier PCAP ?: capture tcpdump ciblée, séparée de l’archive de journaux
• Un changement a-t-il déclenché le problème ?: audit trail, heure du changement, objets concernés

Une large archive de journaux sans heure d’erreur est souvent moins utile qu’un paquet de données plus petit avec heure exacte, reproduction claire et capture adaptée. Pour les problèmes de flux de paquets, le fichier PCAP doit être traité séparément de l’archive de journaux afin que le ticket indique clairement quel fichier contient les journaux de service et quel fichier contient les paquets réseau.

⚠️ Les journaux, captures d’écran et Packet Captures peuvent contenir des adresses IP internes, des IP publiques, des noms d’utilisateurs, des noms d’hôtes, des détails de certificats ou d’autres informations confidentielles. Avant le téléversement, il faut savoir qui reçoit les données et si elles doivent être nettoyées auparavant.

Consolidated Troubleshooting Report

Pour les problèmes d’appareil ou de système, Sophos peut demander un Consolidated Troubleshooting Report. Dans le firewall, il se trouve sous Diagnostics > Tools. Le rapport collecte des informations de diagnostic et des données de journaux pertinentes dans une archive compressée.

Un tel rapport est particulièrement utile en cas de :

• crashs de services
• états système inexpliqués
• erreurs récurrentes après des mises à jour
• problèmes que Sophos ne peut pas évaluer avec une simple capture d’écran
• cas de support où plusieurs modules pourraient être concernés

Le rapport ne remplace toutefois pas une bonne description de l’erreur. L’heure, le fuseau horaire, la fonction concernée et les étapes de reproduction doivent tout de même figurer dans le ticket.

Support Access et Remote Assistance ID

Pour les cas firewall, Sophos peut demander une Remote Assistance ID ou l’activation de Support Access. Cela permet à Sophos d’accéder au firewall pour une durée limitée si l’analyse l’exige.

Support Access ne doit être activé que s’il est nécessaire pour le cas concret. Après la clôture du cas, l’accès doit être désactivé ou au moins vérifié. Pour la procédure pratique, voir Autoriser Sophos Firewall Support Access pour Avanet. La documentation officielle Sophos décrit la procédure générale sous Support access.

Le ticket doit indiquer :

• si Support Access est déjà actif
• Remote Assistance ID, si disponible
• pour combien de temps l’accès a été autorisé
• si MFA ou des règles ACL influencent l’accès
• s’il existe une fenêtre de maintenance pour les tests

Ouvrir le ticket dans le Sophos Support Portal

Le Sophos Support Portal est accessible ici :

➜ Sophos Support Portal

Se connecter avec le SophosID. Selon la version du portail, l’interface peut être légèrement différente, mais l’idée de base reste la même : créer un nouveau Technical Support Case, sélectionner le produit, décrire le problème et téléverser les pièces jointes.

La procédure est généralement :

1. Se connecter au Support Portal.
2. Ouvrir Support Cases.
3. Créer un nouveau Technical Support Case.
4. Sélectionner l’account, le contact, la Severity, le sujet et la catégorie de produit.
5. Décrire le problème et l’impact.
6. Répondre aux questions spécifiques au produit.
7. Indiquer le numéro de série ou le numéro de licence.
8. Joindre les journaux, captures d’écran, CTR ou fichiers PCAP.
9. Soumettre le case et documenter le numéro de ticket en interne.

Dans le formulaire, le problème doit être décrit brièvement mais complètement. Un sujet explicite est important. Un sujet comme IPsec VPN fails after SFOS 22.0 MR1 upgrade on XGS 2100 est nettement meilleur que VPN problem.

Si un champ ne peut pas être renseigné, Not Applicable est souvent préférable à un champ vide. Les champs obligatoires vides entraînent sinon rapidement des questions ou retardent l’attribution.

Ce que la description doit contenir

Une bonne description est assez courte pour être lue et assez concrète pour travailler.

Modèle pratique :

Product:
Serial number:
License number:
Model:
Firmware version:
Support plan:
Impact:
Start time and time zone:
Affected users/sites/services:
Recent changes:
Expected behavior:
Actual behavior:
Steps to reproduce:
Checks already performed:
Remote Assistance ID:
Attachments:

Pour les problèmes de règles firewall, NAT ou VPN, il faut aussi indiquer :

• réseaux source et destination
• service ou port concerné
• règle firewall attendue
• règle NAT, si impliquée
• tunnel VPN ou profil Remote Access
• résultat du Log Viewer
• Packet Capture ou PCAP tcpdump si le flux de paquets est pertinent
• Support Access ID si Sophos a besoin d’un accès à distance

Pour l’analyse de règles, Tester une règle firewall avec Log Viewer, Policy Test et Packet Capture peut aider avant l’ouverture du Support Case.

RMA et défaut matériel

Pour les défauts matériels, Sophos a besoin d’informations supplémentaires pour le traitement RMA. Il ne s’agit pas seulement de la description de l’erreur et du numéro de série, mais aussi du modèle, de la révision, du firmware, de la licence, de l’état HA et des informations d’expédition.

À préparer :

• produit et modèle défectueux
• numéro de série de l’appareil concerné
• version du firmware
• numéro de licence ou attribution de licence
• symptôme et points déjà vérifiés
• Dead on arrival si l’appareil est concerné directement après livraison
• cluster HA : oui ou non
• adresse de livraison et personne de contact
• numéro de téléphone et adresse e-mail
• instructions d’expédition particulières

Pour les firewalls, il faut aussi vérifier s’il existe une sauvegarde actuelle et comment le firewall de remplacement sera restauré. Pour backup et restore, voir Backup et restore sur Sophos Firewall.

Pour les cas RMA, il faut se baser sur le Sophos Support Portal actuel et sur la réponse dans le ticket. Les posts de communauté ou anciennes descriptions de procédure peuvent paraître utiles, mais ils ne font pas foi si Sophos demande d’autres informations dans le case concret.

Relancer et escalader

Après l’ouverture, une confirmation avec numéro de ticket doit arriver par e-mail. Ce numéro de ticket doit figurer dans toute communication ultérieure.

Si un cas critique n’avance pas assez vite, il ne faut pas ouvrir un deuxième ticket. Les doublons créent davantage de coordination et peuvent plutôt ralentir le traitement.

Mieux vaut :

1. préparer le numéro de ticket existant
2. décrire concrètement l’impact et l’urgence
3. fournir les journaux ou réponses manquants
4. relancer par téléphone ou Digital Chat avec le numéro de ticket
5. escalader dans le case existant si un objectif n’a pas été respecté
6. documenter en interne qui a donné quel retour

Une escalade doit être justifiée. Les raisons utiles sont par exemple :

• le délai de réponse cible a été dépassé.
• la panne en production persiste.
• aucune réaction malgré les informations ajoutées.
• mauvaise attribution ou catégorie de produit inadaptée.
• le case bloque un processus de restauration ou de maintenance planifié.

L’escalade doit toujours décrire l’impact métier actuel. Une phrase comme We need an update est plus faible qu’une formulation concrète telle que The main site-to-site VPN between headquarters and production is still down, 80 users cannot access ERP, no workaround is available.

En cas d’incident de sécurité grave ou de panne majeure, il faut aussi vérifier si d’autres processus de support ou d’incident response s’appliquent. Un ticket technique normal n’est pas automatiquement un processus d’incident response complet.

Checklist

• Le SophosID fonctionne.
• La licence et le droit au support sont clarifiés.
• Le numéro de série, le modèle et la version du firmware sont documentés.
• L’heure de l’erreur avec fuseau horaire est connue.
• L’impact sur les utilisateurs, services ou site est décrit.
• Les derniers changements ont été notés.
• La reproduction ou le symptôme est traçable.
• Les journaux et captures d’écran pertinents sont préparés.
• Packet Capture ou PCAP tcpdump est préparé uniquement pour les problèmes de flux de paquets.
• Les données confidentielles dans les pièces jointes ont été vérifiées.
• Pour RMA : les informations d’expédition et l’état HA sont préparés.
• Le numéro de ticket est documenté en interne.

FAQ