Désactivation du VPN SSL SMA 100 de SonicWall : que se passe-t-il ensuite ?

SonicWall a désactivé toutes les appliances de la série SMA 100 le 31 octobre 2025 après l’exploitation répétée de vulnérabilités critiques. Les modèles concernés sont les SMA 200, 210, 400, 410 et 500v. Si vous utilisez toujours l’un de ces appareils ou si vous rencontrez des erreurs de licence VPN SSL sur votre pare-feu SonicWall, trois solutions réalistes s’offrent à vous : migrer au sein de l’écosystème SonicWall (Cloud Secure Edge ou SMA 1000), passer à une plateforme ZTNA/SASE neutre ou transférer temporairement des sessions VPN SSL vers un pare-feu Gen 7 pendant que vous planifiez une migration à plus long terme.

Si vous avez atterri ici parce que votre console SonicWall vient de générer une erreur de licence, vous n’êtes pas seul. Des milliers d’équipes informatiques du marché intermédiaire se sont heurtées à ce mur après que SonicWall a débranché la série SMA 100. Ce billet couvre les détails techniques de la désactivation, explique les erreurs de licence et présente les options qui s’offrent à vous.

Qu’est-il arrivé au VPN SSL SonicWall SMA 100 ?

SonicWall a mis fin au support de l’ensemble de la série SMA 100 le 31 octobre 2025 et a activement désactivé les dispositifs. Après cette date, les appareils ont cessé de fonctionner. La connectivité VPN, les services de sécurité basés sur le cloud et les mises à jour du micrologiciel ont tous cessé simultanément. Il ne s’agissait pas d’une annonce standard de fin de vie avec une réduction progressive sur plusieurs années. SonicWall a accéléré le calendrier après que les chercheurs en sécurité et CISA ont confirmé l’exploitation active de plusieurs vulnérabilités critiques dans la gamme SMA 100.

L’élément déclencheur a été une chaîne de vulnérabilités qui a rendu les appareils indéfendables. CVE-2024-38475, une faille de traversée de chemin dans le module Apache mod_rewrite utilisé par le micrologiciel SMA 100, a un score CVSS de 9.8. Elle permet à des attaquants non authentifiés de lire des fichiers arbitraires sur l’appliance, y compris des jetons de session. Lorsqu’il est associé à CVE-2023-44221 (CVSS 7.2, injection de commande post-authentification), les attaquants parviennent à une exécution complète du code à distance. La CISA a ajouté les deux CVE à son catalogue de vulnérabilités connues et exploitées le 1er mai 2025.

Le groupe de renseignement sur les menaces de Google (GTIG) a attribué l’activité d’exploitation à UNC6148, un groupe de menace lié aux opérations de ransomware de marque Abyss. WatchTowr Labs a publié en mai 2025 une preuve de concept démontrant comment les deux CVE s’enchaînent pour compromettre entièrement le système.

D’autres CVE divulgués en 2024 ont révélé des faiblesses architecturales plus profondes.

Les modèles concernés sont les SMA 200, SMA 210, SMA 400, SMA 410 et SMA 500v. Le programme de remplacement gratuit de SonicWall a pris fin le 1er décembre 2025. En 2026, aucune mise à jour du micrologiciel, aucun support technique et aucun remplacement de matériel n’est disponible pour ces appareils. Les services qui reposaient sur des droits de cloud actifs, notamment Endpoint Control, Botnet Filtering et Geo-IP Filtering, ont cessé de fonctionner à la date EOS.

Pourquoi l’erreur « licence SSLVPN maximale » apparaît-elle ?

Si votre SMA 100 est désactivé et que votre organisation a transféré l’accès à distance vers un pare-feu SonicWall Gen 7, il se peut que vous rencontriez cette erreur :

Maximum SSLVPN license [number] is reached

Ce message signifie que le pare-feu a atteint sa limite de tunnel VPN SSL simultané. Il apparaît lorsque le nombre d’utilisateurs essayant de se connecter via NetExtender est supérieur à ce que le matériel peut supporter, quel que soit le nombre de licences logicielles que vous avez achetées par l’intermédiaire de MySonicWall.

La cause première est une inadéquation entre les droits de licence et la capacité matérielle. Au cours du programme de migration du SMA 100, SonicWall a proposé des licences VPN SSL pour les pare-feux Gen 7 correspondant au nombre d’utilisateurs de l’ancien SMA. Mais chaque modèle de pare-feu a un plafond de tunnels VPN SSL simultanés, et ce plafond est souvent inférieur à ce que le SMA 100 pouvait gérer.

Lorsque vous activez 100 licences sur un TZ270, le 51ème utilisateur qui tente de se connecter verra l’erreur. Les licences sont valides, mais le matériel ne peut pas les servir.

Trois choses à vérifier avant d’escalader le problème. Premièrement, vérifiez dans le portail MySonicWall que les licences sont correctement associées au numéro de série du pare-feu et qu’elles ne sont pas encore liées à l’appliance SMA désactivée. Deuxièmement, assurez-vous que le pare-feu utilise le dernier firmware SonicOS 7.1.x, car les versions antérieures contenaient des bogues dans la gestion des droits SSL VPN. Troisièmement, recherchez les sessions inactives qui conservent des licences ouvertes. En définissant des délais d’inactivité agressifs (10 à 15 minutes), vous récupérez la capacité des sessions pour lesquelles l’utilisateur s’est déconnecté sans se déconnecter.

Pour les organisations dont le plafond matériel du pare-feu est réellement trop bas, une correction du micrologiciel ne sera d’aucune utilité. Les options sont la mise à niveau vers un pare-feu de niveau supérieur ou le passage à une solution d’accès en nuage où les limites de sessions simultanées sont liées à votre nombre de licences plutôt qu’au matériel de l’appareil.

Vos trois options réalistes après la désactivation du SMA 100

Option 1 : rester dans SonicWall (Cloud Secure Edge ou SMA 1000)

La solution recommandée par SonicWall est Cloud Secure Edge (CSE), une solution ZTNA native. CSE supprime la passerelle matérielle publique, s’intègre avec des fournisseurs d’identité tels que Microsoft Entra ID et applique une évaluation continue de la confiance en fonction de l’état de l’appareil. SonicWall a proposé un programme de reprise avec une réduction pouvant aller jusqu’à 52 % sur les licences CSE de trois ans. La fenêtre d’échange gratuit de ce programme a été fermée le 1er décembre 2025, mais des voies de migration payantes restent disponibles.

Pour les organisations ayant des exigences complexes en matière d’héritage, la série SMA 1000 est une alternative. Elle prend en charge des déploiements à plus grande échelle mais ne dispose pas de certaines fonctionnalités du SMA 100, notamment le WAF intégré. L’ajout d’un service WAF externe augmente les coûts et la complexité.

Option 2 : passer à une plateforme ZTNA/SASE indépendante des fournisseurs

Une migration forcée vers un autre fournisseur est l’occasion d’évaluer s’il est judicieux de rester dans le même écosystème. Les plateformes neutres vis-à-vis des fournisseurs, telles que Jimber, Cato Networks et Cloudflare One, fournissent des ZTNA sans vous lier au cycle de licence d’un seul fournisseur de pare-feu. Le changement d’architecture est le même que pour le CSE (basé sur l’identité, accès par application, pas de passerelle publique), mais vous évitez de répéter la dépendance à un seul fournisseur qui a créé cette pression de migration en premier lieu.

La plateforme SASE de Jimber combine ZTNA, Secure Web Gateway, Firewall-as-a-Service et SD-WAN dans une seule console. Pour les équipes du marché intermédiaire qui gèrent entre 50 et 400 utilisateurs, le déploiement s’effectue généralement en quelques jours pour un groupe pilote et en quelques semaines pour un déploiement plus large. La tarification transparente par utilisateur évite les surprises liées au niveau de bande passante que l’on retrouve souvent chez les fournisseurs de SASE d’entreprise.

Option 3 : solution de fortune temporaire (VPN SSL sur un pare-feu Gen 7)

Si vous avez besoin de rétablir l’accès à distance en quelques heures, et non en quelques semaines, la solution la plus rapide consiste à transférer les sessions VPN SSL vers un pare-feu Gen 7 TZ ou NSA. Cette solution résout le problème de connectivité immédiat, mais ne résout pas le problème architectural. Vous exposez toujours une passerelle VPN à l’internet, vous accordez toujours un accès au niveau du réseau après authentification et vous vous heurtez toujours aux limites de capacité matérielle décrites ci-dessus.

Cette option a du sens en tant que pont pour deux à quatre semaines pendant que vous planifiez et pilotez l’une des deux premières options. Au-delà, cette mesure temporaire devient une responsabilité permanente, surtout si vous activez la tunnellisation divisée pour gérer la bande passante, ce qui introduit ses propres risques de conformité avec NIS2.

Les implications pour la sécurité de rester sur le SMA 100

Certaines organisations ont encore des appareils SMA 100 connectés à leur réseau. Si l’appareil conserve une licence VPN perpétuelle, les tunnels peuvent techniquement toujours fonctionner, même sans support. En exécuter un en 2026, c’est accepter un risque documenté et activement exploité.

La chaîne d’exploitation CVE-2024-38475 et CVE-2023-44221 permet aux attaquants non authentifiés d’accéder à l’Internet public et d’exécuter des commandes arbitraires sur l’appareil. Le Threat Intelligence Group de Google a associé cette chaîne à UNC6148, un groupe associé à l’exfiltration de données et aux ransomwares. Même après la date EOS, SonicWall a publié un correctif exceptionnel en décembre 2025 pour CVE-2025-40602 (CVSS 6.6), un jour zéro d’escalade de privilèges, soulignant que de nouvelles vulnérabilités continuent de faire surface dans du matériel qui ne reçoit plus de correctifs réguliers.

Les cyber-assureurs l’ont remarqué. Les souscripteurs analysent régulièrement les périmètres des assurés à l’aide de scanners de vulnérabilité externes. Une interface SonicWall SMA 100 visible sur Internet déclenche un examen immédiat, et certains assureurs ont ajouté les anciennes appliances SonicWall à leurs listes d’exclusion.

Pour les organisations européennes, l’exposition à la conformité est tout aussi concrète. L’article 21 de la NIS2 exige des « mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées » pour gérer les risques liés à la sécurité des réseaux. Il est difficile de défendre le caractère proportionné de l’utilisation d’un dispositif que le fabricant a publiquement déclaré dangereux et désactivé. La tendance générale qui explique pourquoi le ZTNA remplace le VPN en 2026 s’applique doublement lorsque le matériel VPN lui-même a été mis hors service par son fabricant. Les organisations belges confrontées à la vérification de CyberFundamentals (CyFun) en 2026 doivent démontrer que les équipements en fin de vie ont été mis hors service ou isolés. Les auditeurs vérifient spécifiquement la mise hors service des dispositifs réseau non pris en charge dans le cadre des évaluations des niveaux de base et important.

Un calendrier de migration pratique

Que vous choisissiez le Cloud Secure Edge de SonicWall, une plate-forme SASE neutre ou une combinaison des deux, la migration suit un schéma prévisible. Ce calendrier se base sur une entreprise de taille moyenne comptant entre 50 et 300 utilisateurs.

Pour les organisations qui disposent encore d’un pare-feu SonicWall TZ ou NSA gérant le trafic VPN SSL temporaire, ce calendrier se déroule en parallèle. Chaque application publiée via ZTNA réduit la charge sur le pare-feu, éliminant progressivement le goulot d’étranglement de la « licence VPN SSL maximale ». Des plateformes telles que Jimber, qui prennent en charge le déploiement parallèle, vous permettent de maintenir l’accès existant pour les utilisateurs non migrés pendant que la nouvelle architecture gère tout le reste.

Si vous envisagez également de quitter l’écosystème SonicWall au sens large, notre guide de migration SonicWall vers SASE couvre le remplacement complet de la pile, depuis les règles de pare-feu et le filtrage de contenu jusqu’à la connectivité SD-WAN.

Questions fréquemment posées

Mon SonicWall SMA 100 pourra-t-il encore être utilisé en 2026 ?

Non. L’assistance a pris fin le 31 octobre 2025. L’exploitation de plusieurs CVE avec des scores CVSS supérieurs à 9.0 est confirmée dans la nature. L’exécution d’un SMA 100 crée une exposition non corrigée que la plupart des polices d’assurance cybernétique ne couvriront pas.

Puis-je mettre à jour le firmware pour réactiver le VPN SSL sur le SMA 100 ?

La rétrogradation supprime les derniers correctifs et expose l’appareil à toutes les chaînes d’exploitation connues, y compris CVE-2024-38475 et CVE-2023-44221 qui affectent toutes les versions de microprogrammes antérieures à 10.2.1.14-75sv.

L’erreur « licence SSLVPN maximale » signifie-t-elle que mon SMA 100 est cassé ?

Cette erreur apparaît généralement sur les pare-feux Gen 7 (séries TZ ou NSA) lorsque les utilisateurs simultanés dépassent la limite matérielle. Vérifiez la synchronisation des licences dans MySonicWall et supprimez les sessions inactives. Si le plafond matériel est le goulot d’étranglement, le ZTNA en nuage élimine la contrainte.

Quel est le moyen le plus économique de remplacer le SMA 100 SSL VPN ?

Pour moins de 50 utilisateurs distants avec un pare-feu Gen 7 existant, le transfert du VPN SSL vers le pare-feu est le moins cher. Pour tout ce qui est plus important, un abonnement ZTNA par utilisateur permet d’éviter l’investissement en matériel.

La série SMA 1000 est-elle également concernée ?

Le SMA 1000 présentait sa propre vulnérabilité critique (CVE-2025-23006, CVSS 9.8), mais reste pris en charge et corrigé. Il est conçu pour des déploiements plus importants et son prix est celui d’une entreprise, ce qui peut ne pas convenir aux budgets des entreprises de taille moyenne.

Puis-je migrer vers une solution ZTNA non-SonicWall tout en conservant mon pare-feu ?

Oui. Les plateformes ZTNA fonctionnent indépendamment de votre fournisseur de pare-feu. Votre pare-feu SonicWall gère le trafic nord-sud tandis que ZTNA gère la manière dont le VPN SSL est déprécié par les fournisseurs et l’accès au niveau de l’application.

Combien de temps me reste-t-il avant que SonicWall ne mette fin au support SMA 100 ?

Il est déjà terminé. L’assistance a pris fin le 31 octobre 2025. SonicWall a publié un correctif exceptionnel en décembre 2025 pour un jour zéro activement exploité, mais ce correctif était explicitement décrit comme une exception.

La désactivation du SMA 100 a imposé une décision que de nombreuses équipes informatiques avaient repoussée. Le cadre de décision IPsec VPN vs ZTNA peut vous aider à évaluer les compromis au niveau du protocole, et notre guide d’architecture SASE explique comment les composants s’intègrent les uns aux autres. Si vous souhaitez voir comment Jimber gère le remplacement de SonicWall, réservez une démonstration et nous établirons un plan de migration pour votre environnement.