VPN Azure : Attention au 30/09/25 !

Peu importe le fournisseur de Cloud choisi, d’anciens services sont régulièrement dépréciés au profit de nouveaux. Ces transitions sont fréquentes et planifiées. Mais, malgré les messages d’information, il est de notre responsabilité de les suivre, de les estimer afin de les traiter. Encore faut-il en comprendre les conséquences pour mesurer leur impact sur les environnements existants.

Comment Microsoft informe des futurs services dépréciés ?

Microsoft communique les dépréciations, changements et nouvelles fonctionnalités Azure par plusieurs canaux officiels. Voici les principaux moyens de rester informé sur ce sujet :

• Azure Updates (Portail officiel)
• Blog Microsoft Azure
• Centre de messages Microsoft 365
• Documentation Azure – pages « Retirement »
• Azure Service Health : Health advisories

Comment savoir si mes ressources Azure seront impactées ?

Azure fournit une méthode directe pour voir quelles ressources dans votre propre tenant seront affectées par une dépréciation :

• Azure Advisor : Services Retirement Workbook

Le classeur Service Retirement fournit une vue unique et centralisée des ressources sur les retraits de services. Il vous aide à évaluer l’impact, les options et à planifier la migration des services et fonctionnalités retirés. Le modèle de classeur est disponible dans la galerie Azure Advisor.

Microsoft Learn

J’aime beaucoup ce classeur, car il affiche une vue simple et rapide des ressources de votre environnement, comme le montre le tableau ci-dessus avec des ressourcées créées il y a une heure à peine.

Concernant les services concernant les VPN Azure, qu’est-ce que Microsoft dépréciera au 30 septembre prochain ?

Microsoft a annoncé la fin de vie de certains services de réseaux Azure au 30/09/2025 :

• Anciens SKU Standard et High Performance pour les Azure VPN Gateway. Dès le 30 septembre 2025, ces modèles ne seront plus supportés. Il est donc fortement recommandé de migrer dès maintenant vers les SKU modernes VpnGw1 ou VpnGw2, qui offrent de meilleures performances, une haute disponibilité via les zones (AZ), et un meilleur rapport qualité/prix.
• Les adresses IP publiques Basic SKU vont disparaître. Dès le 31 mars 2025, il ne sera plus possible d’en créer, et au 30 septembre 2025, toutes les IP Basic encore utilisées seront désactivées. Pensez à les remplacer par des IP Standard SKU, compatibles avec les architectures modernes (zones redondantes, SLA, sécurité).

Microsoft effectuera t-il des migrations automatiquement ?

Oui, mais seulement en partie :

Nous simplifions notre portefeuille de références SKU de passerelle VPN. En raison de l’absence de redondance, de disponibilité inférieure et de coûts potentiels plus élevés associés aux solutions de basculement, nous transférons toutes les références SKU prises en charge par la zone de non-disponibilité (AZ) vers les références SKU prises en charge par AZ.

• À compter du 1er juin 2025 : la création de nouvelles passerelles VPN à l’aide de références SKU VpnGw1-5 (non-AZ) ne sera plus possible. Cette date a été mise à jour à partir de la date initialement annoncée le 1er janvier 2025
• Période de migration : de septembre 2025 à septembre 2026, toutes les passerelles VPN existantes utilisant des références SKU VpnGw1-5 (non-AZ SKU) peuvent être migrées en toute transparence vers des références SKU VpnGw1-5 (AZ).

Cela concerne t-il aussi les VPN Standard et High Performance ?

Pas de panique si vous utilisez encore des SKU Standard ou High Performance pour vos VPN Gateway : aucune action immédiate n’est requise. En attendant, les services existants continuent de fonctionner normalement.

Une communication officielle, accompagnée d’une documentation détaillée, sera envoyée pour guider les administrateurs pas à pas dans cette transition :

Ne pouvant plus créer de passerelle VPN Standard ou High Performance, je ne pourrais pas partager avec vous mon retour d’expérience :

Et qu’en est-il du VPN Basic ?

Pendant plusieurs mois, je pensais que le VPN Basic allait disparaître. Mais j’étais dans l’erreur, et je ne pense pas être le seul :

Visiblement, Microsoft ne classe plus le VPN Basic comme un SKU Legacy :

Cette personne travaillant chez Microsoft donne du crédit à ce raisonnement :

Mais même certaines intelligences artificielles se trompent encore !

Microsoft met également fin au support du SKU VPN Basic, souvent utilisé dans les déploiements de test ou à faible coût. À partir du 30 septembre 2025, les passerelles VPN Basic ne fonctionneront plus du tout. Il est impératif de migrer vers un SKU plus récent, comme VpnGw1, pour garantir la continuité de service.

ChatGPT

En regardant au plus près la documentation Microsoft, voici la réponse à notre question :

Donc il n’y aura rien à faire pour les liaisons VPN Basic ?

Cela n’est pas tout à faire juste :

L’information de taille à prendre en compte concerne les adresses IP Basic. Celles-ci sont utilisées dans différents services Azure comme :

• VPN Basic
• VPN Standard
• Machine virtuelle
• Équilibreur de charge

Concernant le VPN Basic Azure, au travers d’une autre page de la documentation Microsoft, on y apprend que l’on va devoir gérer le processus de migration manuellement. Ce qui entraînera mécaniquement un downtime :

Et qu’en plus, l’adresse IP publique aura changé après cette migration manuelle :

Une fois ces choses dites, je vous propose de tester cela depuis un environnement de démonstration afin de voir ce qu’il est actuellement possible de faire ou de ne pas faire de nôtre côté :

• Etape 0 – Rappel des prérequis
• Test I – Migration d’une IP publique basique statique
• Test II – Migration d’une IP publique basique statique attachée
• Test III – Migration d’une IP publique basique dynamique attachée

Maintenant, il nous reste plus qu’à tester tout cela 😎

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

• Un abonnement Azure valide
• Un tenant Microsoft
• Un réseau virtuel Azure

Test I – Migration d’une IP publique basique statique :

J’ai souhaité commencé au plus simple en créant simplement une adresse IP publique basique et statique.

J’ai créé cette ressource Azure au moyen d’une seule commande CLI depuis Azure Cloud Shell :

az network public-ip create \
  --name myPublicIP0 \
  --resource-group vpn-rg \
  --sku Basic \
  --allocation-method static \
  --location uksouth

Une fois l’adresse IP publique créée, je suis allé sur la page de cette ressource, et j’ai constaté le message d’information suivant :

J’ai cliqué sur ce message d’information, puis j’ai confirmé mon choix de migration :

A peine une seconde plus tard, la notification Azure suivante est apparue :

De retour sur la page de la ressource, j’ai pu confirmer la réussite de la migration de mon IP vers le SKU Standard, ainsi que la conservation de mon adresse IP publique :

Cette migration du SKU basique vers le SKU standard est donc très simple et rapide et conserve la même adresse IP publique

Test II – Migration d’une IP publique basique statique attachée :

Continuons les tests, toujours avec une adresse IP publique basique et statique :

az network public-ip create \
  --name myPublicIP4 \
  --resource-group vpn-rg \
  --sku Basic \
  --allocation-method static \
  --location uksouth

Une fois l’adresse IP publique créée, je suis allé sur la page de cette ressource :

J’ai rattaché cette adresse IP publique à une machine virtuelle Azure :

Comme mon adresse IP publique est rattachée, la fonction de migration vers le SKU standard précédemment utilisé ne me permet plus de le faire :

Azure confirme cela dans la page de configuration :

Il est nécessaire de désassocier l’adresse IP de la carte réseau de la machine virtuelle :

Une fois l’adresse IP publique désassociée, j’ai recliqué sur le message d’information :

Mais j’ai cette fois confirmé mon choix :

De retour sur la page de la ressource, j’ai pu confirmer la réussite de la migration de mon IP vers le SKU Standard :

Par la suite, il m’a fallu résassocier l’adresse IP publique à la carte réseau :

A la carte réseau de la machine virtuelle :

De retour sur la page de la machine virtuelle, j’ai pu confirmer la réussite de la migration de mon IP publique vers le SKU Standard, ainsi que la conservation de l’adresse publique :

Ces deux premiers tests nous montre que lorsque l’adresse publique est basique et de type statique, alors la migration vers le SKU standard ne pose alors aucun souci.

Intéressons-nous maintenant aux adresses IP basiques dynamiques.

Test III – Migration d’une IP publique basique dynamique attachée :

Dans ce test, j’ai souhaité voir s’il était possible de migrer une IP basique rattachée à une passerelle VPN basique.

Microsoft a restreint la création de nouvelles passerelles VPN Basic ainsi que l’utilisation de nouvelles adresses IP publiques Basic SKU statiques, j’ai dû partir sur une adresse IP dynamique :

az network public-ip create \
  --name myPublicIP \
  --resource-group vpn-rg \
  --sku Basic \
  --allocation-method Dynamic \
  --location switzerlandnorth

Pour cela, j’ai donc commencé par ajouter un sous-réseau dédié à ma passerelle :

Et comme il n’est plus possible de créer une passerelle VPN depuis le portail Azure, j’ai créé la ressource depuis Azure Cloud Shell :

az network vnet-gateway create \
  --name myVpnGateway \
  --resource-group vpn-rg \
  --location switzerlandnorth \
  --public-ip-addresses myPublicIP \
  --vnet vnet-vpn \
  --gateway-type Vpn \
  --vpn-type RouteBased \
  --sku Basic \
  --no-wait

Voici le groupe de ressources avec tous les éléments nécessaires à ma connexion VPN :

Le SKU de ma passerelle VPN créée est bien basique :

Une connexion depuis cette passerelle VPN est bien active :

Le SKU de mon adresse IP publique est bien basique :

Là aussi, j’ai cliqué sur le message d’information suivant :

Comme mon adresse IP publique est rattachée, la fonction de migration ne me permet pas de le faire :

Il m’est donc nécessaire de commencer par désassocier l’adresse IP, mais cela est impossible pour une passerelle VPN :

Je commence donc par supprimer la connexion de ma passerelle VPN :

Je confirme mon choix en cliquant sur Oui :

Puis je supprime ma passerelle VPN :

La suppression de la passerelle VPN prend plusieurs minutes :

Une fois l’adresse IP publique désassociée, j’ai recliqué sur le message d’information :

Mon adresse IP publique n’est plus rattachée, mais la fonction de migration refuse toujours de le faire car l’adresse IP publique est dynamique et non statique :

Je n’ai d’autres choix que de supprimer l’adresse IP publique dynamique :

Et je confirme mon choix en cliquant sur Oui :

Je créé donc une seconde adresse IP publique depuis le portail Azure :

Mais cette fois, je la créé avec le SKU de type standard :

Voici le SKU et l’adresse IP publique une fois la ressource Azure créée :

Cette adresse IP est bien redondante entre plusieurs zones Azure :

Je continue en créant la passerelle VPN de type basique via la commande CLI suivante :

az network vnet-gateway create \
  --name myVpnGatewaygood \
  --resource-group vpn-rg \
  --location switzerlandnorth \
  --public-ip-addresses myPublicIPgood \
  --vnet vnet-vpn \
  --gateway-type Vpn \
  --vpn-type RouteBased \
  --sku Basic \
  --no-wait

J’attends quelques minutes la fin de la création de la passerelle VPN

Je recréé à nouveau ma connexion VPN :

Ce test nous a monté que la migration d’une passerelle VPN basique avec une adresse IP dynamique n’est pas automatique. Nous avons dû supprimer et recréer les ressources, comme la documentation Microsoft nous l’indiquait :

Et qu’en plus, l’adresse IP publique a changé :

Conclusion

La dépréciation annoncée des anciens SKU VPN Gateway et des adresses IP Basic dans Azure n’est pas un simple changement cosmétique : elle implique une révision proactive de vos architectures réseau. Comme nous l’avons vu, certaines migrations sont simples et automatiques, d’autres nécessitent des manipulations plus lourdes, incluant la suppression et la recréation de ressources critiques.

Il est essentiel d’anticiper ces évolutions, non seulement pour assurer la continuité de service, mais aussi pour aligner votre environnement sur les meilleures pratiques Azure : haute disponibilité, sécurité, et scalabilité.

Le 30 septembre 2025 est une échéance technique mais surtout stratégique. N’attendez pas l’automne pour agir : identifiez, planifiez, migrez.