Migration d’un VPN IPsec classique vers un VPN cloud managé

De nombreuses infrastructures s’appuient encore sur un VPN IPsec “classique”, souvent configuré directement sur un firewall ou un routeur : profils statiques, clients lourds, droits très larges (“tout le réseau interne accessible dès que le VPN est connecté”). Migrer vers un VPN cloud managé permet de gagner en souplesse, en visibilité et en granularité, mais impose de bien préparer l’architecture et la transition.

Ce guide propose une approche structurée pour passer d’un VPN IPsec hérité à un VPN cloud managé : inventaire de l’existant, choix du modèle cible, coexistence durant la migration, gestion des routes, DNS, ACL et scénarios de test.

1. Cartographier l’existant : point de départ indispensable

Avant de parler “cloud”, il faut comprendre précisément votre VPN actuel. Un IPsec classique sur firewall/routeur implique souvent :

  • un ou plusieurs profils de clients nomades (clients IPsec, L2TP/IPsec, IKEv1/v2) ;
  • des pools d’adresses attribués aux clients VPN (par ex. 10.250.0.0/24) ;
  • une ou plusieurs plages internes exposées (192.168.0.0/16, 10.0.0.0/8, etc.) ;
  • des règles firewall autorisant le trafic depuis les clients VPN vers ces réseaux ;
  • éventuellement des tunnels site à site vers d’autres sites ou VPC.

Concrètement, il faut documenter :

  • les plages IP des clients VPN (pool) ;
  • les sous-réseaux accessibles via ce VPN (LAN, DMZ, VLAN spécifiques) ;
  • les ports/services réellement utilisés (RDP, SSH, HTTP interne, bases de données, etc.) ;
  • les groupes d’utilisateurs (si existants) ou au contraire un accès “flat” pour tout le monde ;
  • les tunnels site à site existants (peer IP, réseaux annoncés, crypto).

Cette cartographie servira de base pour définir :

  • quels réseaux doivent être exposés dans le VPN cloud managé ;
  • quels utilisateurs / groupes ont vraiment besoin de quels accès ;
  • ce qui doit être abandonné ou segmenté davantage dans le nouveau modèle.

2. Définir la cible : architecture du VPN cloud managé

Migrer ne veut pas dire reproduire à l’identique. L’intérêt d’un VPN cloud managé est justement de passer d’un modèle “un tunnel = tout le réseau” à un modèle plus fin, basé sur des identités et des ACL.

2.1 Réseaux à exposer via le VPN cloud

À partir de la cartographie, identifiez :

  • les sous-réseaux qui doivent être accessibles depuis l’extérieur (ex. 10.0.10.0/24 pour les applis, 10.0.20.0/24 pour les bases) ;
  • les sous-réseaux qui doivent rester strictement internes (par exemple certaines DMZ ou segments admin).

Ces sous-réseaux deviendront, côté VPN cloud :

  • des “sites”, “ressources réseau” ou “segments” associés à des connecteurs ;
  • des cibles possibles dans les ACL (qui a le droit d’y accéder).

2.2 Groupes d’utilisateurs et niveaux d’accès

Profitez de la migration pour définir des groupes cohérents :

  • Administrateurs système : accès complet aux segments serveurs, RDP/SSH, etc.
  • Développeurs : accès aux environnements de test/pré-production, accès limité en production (logs, quelques API).
  • Support / Service client : accès à des outils spécifiques, pas aux bases ni aux équipements sensibles.
  • Partenaires / Freelances : accès très restreint à une ou deux ressources précises.

Chaque groupe sera ensuite mappé sur des profils et des ACL dans le VPN cloud managé.

2.3 Modèle de trafic : full tunnel ou split tunneling

Question clé : les utilisateurs doivent-ils faire passer tout leur trafic Internet via le VPN cloud, ou seulement le trafic vers vos réseaux privés ?

  • Full tunnel :
    • todo

Pour la plupart des déploiements orientés “accès à des ressources internes”, un split tunneling bien maîtrisé (seuls les réseaux privés passent dans le VPN cloud) est suffisant et plus performant.

3. Mettre en place les connecteurs sur l’infrastructure existante

Le pont entre votre réseau et le VPN cloud managé est assuré par des connecteurs (agents ou appliances) que vous déployez sur vos sites ou VPC.

3.1 Choix de l’emplacement des connecteurs

Typiquement, on déploie un connecteur :

  • sur un segment “serveur” ou “infrastructure” capable de joindre tous les sous-réseaux à exposer ;
  • dans un VLAN dédié avec des règles firewall contrôlant précisément ce qu’il peut atteindre ;
  • dans chaque VPC ou datacenter concerné, si les environnements sont séparés.

Les connecteurs doivent avoir :

  • une sortie Internet vers les endpoints du fournisseur VPN cloud (souvent en HTTPS ou sur des ports spécifiques) ;
  • une visibilité routeur sur les sous-réseaux internes ciblés.

3.2 Routes internes et pare-feu

Lorsque le connecteur est en place, il faut :

  • configurer les routes nécessaires pour qu’il puisse atteindre les réseaux déclarés (statique ou via un protocole de routage interne, selon le contexte) ;
  • ajuster le pare-feu interne pour autoriser :
    • le trafic sortant du connecteur vers le fournisseur VPN cloud ;
    • le trafic provenant du connecteur vers les ressources internes autorisées (en filtrant par IP/port si possible).

L’objectif est d’éviter que le connecteur devient une “porte ouverte” vers l’intégralité du LAN : il doit être autorisé uniquement vers ce qui est nécessaire.

4. Organiser la coexistence : ancien VPN IPsec + nouveau VPN cloud

Une migration brutale (extinction du VPN IPsec du jour au lendemain) est rarement une bonne idée. Il est préférable de prévoir une phase de coexistence :

  • les anciens clients IPsec continuent de fonctionner ;
  • un sous-ensemble d’utilisateurs bascule progressivement sur le VPN cloud managé ;
  • les deux accès cohabitent jusqu’à la fin de la migration.

4.1 Gestion du chevauchement d’adressage

Attention aux conflits d’IP :

  • le pool d’adresses attribué par l’ancien VPN IPsec ne doit pas entrer en conflit avec celui utilisé par le VPN cloud ;
  • les routes annoncées par le VPN cloud ne doivent pas casser l’accès des anciens clients aux mêmes réseaux.

Si besoin, vous pouvez :

  • réduire progressivement la portée du VPN IPsec (restreindre certains sous-réseaux) ;
  • utiliser des pools d’IP distincts et bien documentés pour éviter toute confusion.

4.2 Plan de migration par vagues

Une approche courante consiste à migrer :

  • d’abord un petit groupe pilote (administrateurs, utilisateurs avancés) ;
  • puis une équipe métier représentative (par exemple un service complet) ;
  • puis le reste, en ajustant au fur et à mesure les ACL, routes, DNS, etc.

Pendant cette phase, il est crucial de :

  • recueillir les retours sur les performances, les ressources manquantes, les cas d’usage non prévus ;
  • affiner les politiques d’accès pour éviter de “remettre en place” un accès trop large par facilité.

5. DNS, noms internes et résolution

Les anciennes configurations de VPN IPsec s’appuient souvent sur :

  • un ou plusieurs serveurs DNS internes (par exemple pour *.intranet.local) ;
  • des suffixes DNS de recherche (domaines internes).

Lors de la migration vers un VPN cloud managé, il faut :

  • déclarer ces serveurs DNS internes côté VPN cloud si le fournisseur le permet ;
  • ou mettre en place un mécanisme pour que les clients VPN continuent de résoudre les noms internes via les DNS appropriés ;
  • documenter les domaines internes qui doivent être résolus (ex. corp.local, intra.exemple).

Un oubli côté DNS conduit à des situations où :

  • le VPN fonctionne sur le plan IP, mais les noms internes ne se résolvent pas ;
  • les utilisateurs pensent que “le VPN ne marche pas”, alors que c’est un problème de résolution.

6. Traduire les règles firewall IPsec en ACL VPN cloud

Sur un VPN IPsec historique, le firewall contient souvent :

  • une règle “grosse maille” : autoriser le pool VPN vers un ou plusieurs réseaux internes sur un large éventail de ports ;
  • éventuellement quelques règles plus fines pour certains services.

Dans un VPN cloud managé, l’idée est d’inverser la logique :

  • les ACL sont définies par groupe d’utilisateurs et par ressources ;
  • le trafic non explicitement autorisé est refusé par défaut.

Pour migrer proprement :

  • reprenez les règles actuelles pour comprendre ce que les utilisateurs utilisent vraiment (log firewall, outils de monitoring) ;
  • créez des ACL “minimales suffisantes” pour chaque groupe ciblé ;
  • ajustez ensuite en fonction des erreurs d’accès légitimes (logs d’accès refusés).

7. Scénarios de test avant extinction du VPN IPsec

Avant de couper définitivement l’ancien VPN, il faut valider plusieurs scénarios clés :

7.1 Tests d’accès fonctionnels

Sur un échantillon représentatif d’utilisateurs :

  • connexion au VPN cloud ;
  • accès aux applications internes nécessaires (web, RDP, SSH, bases, etc.) ;
  • résolution des noms internes ;
  • accès aux ressources partagées (fichiers, imprimantes, services d’entreprise).

7.2 Tests de non-accès (contrôles négatifs)

Il est tout aussi important de vérifier que :

  • les utilisateurs n’ont pas accès à des segments qu’ils ne devraient pas voir ;
  • les ports sensibles (admin, supervision, bases critiques) ne sont pas exposés au-delà des groupes autorisés.

Ces tests se font à la fois :

  • du point de vue utilisateur (tentative de connexion) ;
  • et via les logs (refus d’accès, alertes éventuelles).

7.3 Performance et stabilité

Sur la période de coexistence, surveillez :

  • la latence moyenne avec et sans VPN cloud ;
  • le comportement aux heures de pointe ;
  • les éventuelles déconnexions intempestives ou reconnections fréquentes.

Si nécessaire, ajustez le choix de nœuds, le routage et les options de tunnel (full vs split) avant d’éteindre le VPN IPsec.

8. Extinction progressive de l’ancien VPN IPsec

Lorsque les tests sont concluants et que la majorité des utilisateurs a basculé :

  • désactiver la création de nouveaux profils IPsec ;
  • prévenir les derniers utilisateurs encore dessus et les accompagner vers le VPN cloud ;
  • désactiver progressivement les règles firewall associées au pool IPsec ;
  • archiver la configuration IPsec (sauvegarde, documentation) avant suppression définitive.

L’objectif est de garantir qu’aucune dépendance non identifiée ne repose encore sur l’ancien VPN (scripts, intégrations oubliées, etc.).

Conclusion

Migrer d’un VPN IPsec classique vers un VPN cloud managé ne consiste pas à “changer de tunnel”, mais à changer de modèle :

  • on passe d’une approche centrée sur le réseau (pool d’IP, accès global) à une approche centrée sur l’identité et les ressources (utilisateurs, groupes, ACL) ;
  • on externalise l’infrastructure (serveurs, scalabilité, mises à jour) tout en gardant la main sur la politique d’accès ;
  • on introduit une granularité plus fine, mais au prix d’un travail initial de cartographie et de conception.

Une migration réussie repose sur :

  • une vision claire de l’existant (réseaux, usages, règles actuelles) ;
  • une cible bien définie (groupes, ACL, ressources exposées) ;
  • une phase de coexistence contrôlée, avec des tests sérieux et des ajustements continus.

Une fois cette transition achevée, le VPN cloud managé devient un levier pour aller plus loin :

  • intégration avec les identités d’entreprise (SSO, MFA) ;
  • meilleure visibilité sur qui accède à quoi ;
  • évolution progressive vers des modèles d’accès plus proches du “least privilege” et d’une logique Zero Trust.