Aller au contenu
Avanet

Sophos Firewall : fichier .ovpn absent ou de 0 octet

Lorsque le Sophos Firewall VPN Portal ne fournit pas de fichier .ovpn utilisable, il faut d’abord identifier précisément le symptôme. Trois cas peuvent sembler similaires, mais ont des causes différentes :

  • Le téléchargement est totalement absent : le plus souvent, l’utilisateur n’est affecté à aucune policy SSL VPN adaptée ou l’appartenance au groupe attendue ne s’applique pas.
  • Le téléchargement est visible, mais le fichier fait 0 octet ou ne contient qu’un message d’erreur : la génération ou la mise à disposition du profil a échoué. La génération des certificats, les logs, la version du firmware et, en HA, le nœud actif sont alors à examiner.
  • Le fichier n’est pas vide, mais une connexion existante ne fonctionne plus : il ne s’agit normalement pas d’une erreur de téléchargement. Après une modification de Protocol, SSL server certificate, Override hostname ou Port, un profil actuel doit être importé.

Cette distinction évite des interventions inutiles. Il ne faut notamment ni renouveler la Default CA par simple supposition, ni exécuter d’anciennes commandes de réparation provenant d’articles de la Community.

Classer le symptôme dans le VPN Portal

Pour le premier contrôle, se connecter au VPN Portal avec l’utilisateur concerné et ouvrir VPN > VPN configuration. Documenter ensuite séparément quatre résultats : portail accessible, connexion réussie, entrée SSL VPN visible et taille du fichier téléchargé.

La comparaison avec un utilisateur de référence fonctionnel appartenant à la même policy SSL VPN fournit les informations les plus pertinentes :

  1. Noter l’heure exacte du test et le nom de l’utilisateur concerné.
  2. Vérifier si le téléchargement SSL VPN apparaît sous VPN configuration.
  3. Télécharger le fichier et contrôler sa taille dans le système d’exploitation.
  4. Répéter la même procédure avec un utilisateur dont le fonctionnement est établi.
  5. Noter si l’erreur concerne uniquement un utilisateur, un groupe ou tous les utilisateurs.

Si l’utilisateur de référence fonctionne, la cause se situe plus probablement au niveau de l’affectation à la policy, du groupe, de la User ID ou de la génération du certificat de l’utilisateur concerné. Si le téléchargement échoue pour tous les utilisateurs, le certificat SSL VPN commun, le stockage, les patterns, le firmware et, en HA, le nœud actif deviennent plus vraisemblables.

Un fichier .ovpn peut contenir des certificats et des clés. Son contenu ne doit pas figurer dans des captures d’écran, des e-mails ou des tickets de support. Le nom et la taille du fichier, l’heure et le message d’erreur visible suffisent au diagnostic.

Si l’accès au portail ou la connexion échoue déjà, le problème intervient avant la génération du profil. Vérifier alors Administration > Device access, l’authentification du VPN Portal et vpnportal.log ou access_server.log. Configurer SSL VPN Remote Access décrit la configuration complète du pare-feu.

Lorsque le fichier .ovpn est totalement absent

Le pare-feu n’affiche les configurations SSL VPN qu’aux utilisateurs affectés à une policy Remote Access SSL VPN. Une connexion réussie au portail ne prouve pas à elle seule cette autorisation.

Vérifier la policy et l’appartenance au groupe

  1. Ouvrir Remote access VPN > SSL VPN.
  2. Modifier la policy attendue.
  3. Sous Policy members, vérifier si l’utilisateur ou son groupe réel est répertorié.
  4. Sous Authentication > Users ou Authentication > Groups, contrôler l’appartenance au groupe.
  5. Se reconnecter au VPN Portal avec l’utilisateur concerné et rouvrir VPN configuration.

Un utilisateur peut se connecter correctement grâce à une autre autorisation du portail sans pour autant recevoir de configuration SSL VPN. Les utilisateurs et groupes guest ne sont pas des Policy members valides pour Remote Access SSL VPN. Lorsque des utilisateurs ou groupes directement affectés de manière identique figurent dans plusieurs policies, Sophos Firewall les retire de la policy précédente lors de l’enregistrement de la plus récente. Il faut donc vérifier les Policy members réellement restants et les éventuels chevauchements d’appartenance aux groupes.

Seuls des utilisateurs nouveaux ou spécifiques sont concernés

Il faut également examiner la User ID interne sous Authentication > Users > Show additional properties. Sophos Firewall ne prend en charge les ID d’utilisateurs et de groupes que jusqu’à 65535. Une ID supérieure peut empêcher le téléchargement ; Limite de User ID de Sophos Firewall décrit le contrôle et le nettoyage en toute sécurité.

Une connexion manifestement réussie au VPN Portal indique que la limite de User ID n’est probablement pas la cause principale. L’ID visible du compte concerné reste toutefois déterminante, et non le nombre d’utilisateurs dans la liste.

Vérifier également si le nom d’utilisateur et les champs Subject du certificat et de la CA contiennent des caractères spéciaux. Pour cette procédure, Sophos recommande des noms d’utilisateur ASCII et aucun caractère UTF-8 dans les champs du certificat ou de la CA. Le nom d’utilisateur est intégré au nom du fichier .ovpn et au certificat généré pour chaque utilisateur. Un utilisateur de test fonctionnel doté d’un nom ASCII simple aide à isoler le problème ; il ne faut pas renommer spontanément des identités AD ou Entra de production pour ce test.

Lorsque le téléchargement fait 0 octet ou n’est pas généré

Un fichier vide signifie que le lien de téléchargement existe, mais que la génération ou la mise à disposition n’a produit aucune configuration utilisable. Sophos cite les configurations incomplètes de certificat ou de CA comme cause possible. Avant toute régénération, sauvegarder les logs et l’état du système.

Sauvegarder les logs à l’heure exacte du test

Sous Diagnostics > Tools > Troubleshooting logs, les fichiers pertinents peuvent être téléchargés sans accéder à l’Advanced Shell. Selon l’étape où l’erreur se produit, les fichiers suivants sont importants :

  • vpnportal.log pour la requête dans le VPN Portal ;
  • access_server.log pour l’authentification normale ;
  • oauth_sso_vpn.log avec Microsoft Entra ID SSO ;
  • peruser_cert_sslvpn.log pour la génération du certificat propre à l’utilisateur ;
  • vpncertificate.log pour les certificats et les Certificate Authorities ;
  • sslvpn.log pour le service SSL VPN.

Filtrer les logs selon l’heure du test et le nom d’utilisateur précédemment notés. Si le portail et l’authentification fonctionnent, mais que peruser_cert_sslvpn.log signale simultanément une erreur, le certificat et la CA constituent le prochain contrôle utile. Si le problème concerne tous les utilisateurs uniquement depuis un upgrade ou un failover HA, documenter également la version du firmware, le nœud actif et l’heure du changement de rôle. Services et logs de Sophos Firewall explique comment classer les autres fichiers.

Vérifier le stockage temporaire

Une partition temporaire pleine peut également empêcher la génération du profil. Après s’être connecté à Sophos Firewall par SSH, ouvrir 5 Device Management > 3 Advanced Shell et afficher l’espace disponible :

df -kh /tmp

Les valeurs pertinentes sont Avail et Use% pour le système de fichiers qui contient /tmp. S’il ne reste pratiquement plus d’espace, ne pas supprimer manuellement des fichiers inconnus. Il faut plutôt sauvegarder les logs et l’état du système, puis déterminer quel processus occupe le stockage. Sophos a déjà corrigé sous NC-142397 un ancien problème dans lequel SSL VPN remplissait la partition /tmp. L’ID du bug constitue donc un indicateur de version, mais pas un diagnostic automatique pour les builds actuels.

Vérifier le certificat SSL VPN et la Signing CA

Sous Remote access VPN > SSL VPN > SSL VPN global settings, le champ SSL server certificate indique le certificat utilisé par le pare-feu pour le tunnel SSL VPN. Ce certificat ne doit pas être confondu avec le certificat HTTPS du VPN Portal sous Administration > Admin and user settings.

Bien distinguer les durées de validité des certificats publics

La réduction annoncée de la durée de validité des certificats TLS publiquement approuvés jusqu’à 47 jours ne concerne pas automatiquement les certificats X.509 propres à chaque utilisateur intégrés au fichier .ovpn. Par défaut, ils sont signés par la CA interne de SFOS et ne font pas partie de la PKI Web publique. Cela n’impose ni téléchargement mensuel du profil ni passage à une CA publique.

Le certificat HTTPS du VPN Portal et le SSL server certificate du tunnel conservent des rôles distincts. Le certificat du portail doit être renouvelé à temps puisqu’il protège un service accessible par navigateur ; un certificat Let’s Encrypt renouvelé automatiquement peut convenir. Une modification de Protocol, SSL server certificate, Override hostname ou Port ne devient toutefois fiable qu’après un nouveau téléchargement et import du fichier .ovpn. Cette distinction évite de reconstruire inutilement la PKI SSL VPN interne à cause de durées publiques plus courtes.

Vérifier ensuite les points suivants sous Certificates > Certificates et Certificates > Certificate authorities :

  • Le certificat de serveur SSL sélectionné est-il présent et toujours valide ?
  • La CA émettrice est-elle présente et approuvée ?
  • Pour un certificat externe, la chaîne complète des Intermediate CA et Root CA a-t-elle été importée ?
  • L’heure de l’erreur correspond-elle à une modification de certificat, une restauration ou une migration ?

Par défaut, le pare-feu utilise le ApplianceCertificate intégré, signé par la Default CA. Cela explique la dépendance normale, mais ne prouve pas encore quel objet de certificat provoque l’erreur concrète. Une erreur dans peruser_cert_sslvpn.log, en particulier, ne doit pas être automatiquement interprétée comme un ApplianceCertificate défectueux.

Pour un fichier de 0 octet, Sophos recommande de vérifier la Signing CA réellement utilisée et le certificat concerné qu’elle a généré. La réparation précise diffère toutefois selon le certificat :

  • ApplianceCertificate : Sophos ne documente l’action Regenerate sous Certificates > Certificates que pour ce certificat intégré. Elle n’est utilisée que si ApplianceCertificate est sélectionné comme certificat de serveur SSL et si un message de log ou Sophos Support confirme qu’il est concerné.
  • Certificat de serveur SSL externe : vérifier le certificat, la clé privée, l’Intermediate CA et la Root CA comme une chaîne cohérente et, si un message d’erreur probant le justifie, les réimporter de manière contrôlée. Il n’existe pas ici d’étape Regenerate universelle.
  • Certificat SSL VPN propre à l’utilisateur : une erreur dans peruser_cert_sslvpn.log ne concerne pas automatiquement le certificat de serveur SSL. Sophos ne documente actuellement aucune procédure générale dans l’interface pour réinitialiser ce certificat utilisateur. Il faut donc transmettre les logs sauvegardés à Sophos Support et ne pas reprendre d’anciennes instructions pour le shell ou la base de données.

Une fois l’objet concerné clairement identifié, effectuer la réparation de manière contrôlée :

  1. Créer une sauvegarde du pare-feu actuelle.
  2. Documenter le certificat de serveur SSL sélectionné, la CA émettrice, le message de log précis et les services qui l’utilisent.
  3. Effectuer l’action appropriée parmi les trois cas pendant une fenêtre de maintenance ; si le cas n’est pas clair, l’escalader à Sophos Support.
  4. Télécharger un nouveau fichier .ovpn pour un utilisateur pilote, l’importer et tester le tunnel.
  5. Distribuer les nouveaux profils à tous les utilisateurs concernés et vérifier les autres services touchés uniquement après un test pilote réussi.

⚠️ Ne pas modifier la Default CA par simple supposition. Son enregistrement régénère cette CA. Cela peut affecter beaucoup plus de certificats et de relations de confiance que le seul certificat de serveur SSL VPN. Renouveler de manière contrôlée la Default CA de Sophos Firewall explique l’inventaire, la fenêtre de maintenance, la migration des profils et la récupération.

Vérifier les patterns, le firmware et HA

Sous Backup & firmware > Pattern updates, les composants installés automatiquement doivent afficher un horodatage actuel et Success. Une seule récupération manuelle avec Update pattern now est utile lorsqu’une erreur de pattern est visible ; les clics répétés ne remplacent pas un diagnostic. Configurer et vérifier les Pattern Updates décrit la procédure complète.

Le build exact du firmware fait également partie de l’analyse. Sophos répertorie NC-149642 — les utilisateurs ne pouvaient pas télécharger la configuration SSL VPN depuis le VPN Portal — parmi les problèmes résolus dans SFOS 21.0 MR2 Build 349 et SFOS 22.0 GA Build 411. D’autres correctifs plus anciens concernaient les téléchargements après des upgrades ou des failovers HA. L’ID d’un bug historique ne prouve pas la cause actuelle, mais explique pourquoi un build obsolète doit être comparé aux release notes avant des réparations plus approfondies. Un update doit être planifié et non improvisé pendant le diagnostic en cours ; voir Mettre à jour le firmware SFOS de Sophos Firewall.

Dans un cluster HA, noter le rôle, le nœud actif et l’heure du dernier failover. Si l’erreur n’est apparue qu’après un changement de rôle, sauvegarder les logs VPN et HA du nœud concerné. Ne pas réparer manuellement des répertoires internes, des entrées de base de données ou des liens symboliques sous /content/sslvpn. De telles interventions doivent être escaladées à Sophos Support avec le symptôme documenté.

Lorsque le fichier existe, mais est obsolète

Un fichier .ovpn non vide peut avoir été généré correctement sans plus correspondre à l’état actuel du pare-feu. Après une modification de Protocol, SSL server certificate, Override hostname ou Port, il faut télécharger de nouveau le fichier et le réimporter dans le client. Si Override hostname est vide, les adresses des interfaces activées peuvent figurer dans le profil ; dans ce cas également, un profil modifié doit être récupéré de nouveau.

Les modifications de Policy members ou Permitted network resources, en revanche, ne nécessitent normalement qu’une nouvelle connexion. Un fichier de provisioning .pro télécharge automatiquement la configuration disponible ; pendant le diagnostic, il faut néanmoins vérifier séparément si le téléchargement manuel du .ovpn fonctionne.

Avec Microsoft Entra ID SSO, sélectionner le même serveur Entra ID sous Authentication > Services pour VPN portal authentication methods et SSL VPN authentication methods. Télécharger ensuite de nouveau le .ovpn. Si un fichier .pro provisionne également IPsec, vérifier aussi VPN (IPsec/dial-in/L2TP/PPTP) authentication methods avec le même serveur. Microsoft Entra ID SSO pour Sophos Connect et VPN Portal décrit l’ensemble de cette dépendance.

Vérifier le résultat et escalader proprement

L’erreur n’est résolue que lorsque la même procédure fonctionne entièrement avec un utilisateur pilote normal :

  1. La connexion au VPN Portal réussit.
  2. L’entrée SSL VPN attendue est visible sous VPN configuration.
  3. Le fichier .ovpn téléchargé n’est pas vide et ne contient aucun message d’erreur.
  4. Le nouveau profil peut être importé dans le client prévu.
  5. Le tunnel s’établit et reçoit une adresse du pool SSL VPN attendu.
  6. Une destination interne autorisée fonctionne par adresse IP et par nom d’hôte.
  7. Une destination volontairement non autorisée reste bloquée.

Si la génération continue d’échouer avec une version actuelle du firmware, le dossier de support doit comprendre au minimum le modèle, le build du firmware, le rôle HA, l’heure de l’erreur, l’utilisateur et le groupe, la policy concernée, la taille du fichier, le message d’erreur visible, les dernières modifications ainsi que les logs mentionnés. Ne pas joindre le fichier .ovpn lui-même. Pour un cas reproductible, ces éléments sont plus utiles que des modifications risquées de fichiers internes.