VPN basé sur les politiques vs basé sur les routes : que choisir en 2026 sans se brûler

Introduction : pourquoi le choix du routage VPN fait la moitié du succès

De quoi s'agit-il : policy-based contre route-based

Soyons honnêtes : lorsque vous déployez un VPN d’entreprise, la décision la plus importante ne se limite pas au choix des algorithmes de chiffrement ou du fournisseur. Le vrai enjeu est ailleurs. Comment allons-nous acheminer le trafic ? Par politiques ou par routes. Policy-based et route-based représentent deux approches, deux philosophies. La première repose sur des règles qui définissent quel trafic chiffrer et où l’envoyer. La seconde construit des interfaces virtuelles et fait confiance au routeur. Simple en théorie ? Sur le papier oui, mais en production c’est une question de chance.

En 2026, les enjeux sont majeurs : clouds hybrides, SASE et SD-WAN, segments IPv6-only et demandes accrues d’observabilité. Le trafic oscille entre succursales, clouds, partenaires et télétravailleurs. Il nous faut un choix capable de soutenir la croissance, la conformité et les mises à jour nocturnes sans dégrader le SLA. Et clairement, pas de bidouilles qui forcent les techniciens à remonter un avion en vol.

Dans cet article, avec honnêteté et exemples à l’appui, nous décortiquerons les types de routage VPN, comparerons policy-based et route-based, montrerons où l’un fonctionne mieux que l’autre et où cela peut causer des douleurs. On proposera aussi des recettes pratiques de configuration sur les plateformes populaires et des checklists pour que vous réussissiez du premier coup.

Pourquoi c’est crucial maintenant

Tendance 2026 : unification de la fabric réseau. Les organisations harmonisent WAN, VPC/VNet cloud et campus sous une même politique de routage, d’observabilité et d’automatisation. Dans ce puzzle, le policy-based IPsec peine parfois à suivre la dynamique : télémétrie E2E, ECMP, BFD, interception du trafic pour inspection, multi-cloud avec BGP over IPsec — tout cela est plus naturel en architecture route-based. Mais ! Pour les tunnels par application, où la sécurité prime sur la flexibilité, le policy-based reste roi. On ne choisit pas une foi, mais un pragmatisme mixte.

D’autre part, la montée en puissance de WireGuard et des tunnels QUIC pousse les fournisseurs vers des modèles centrés sur les interfaces. Même les piliers classiques IPsec cèdent du terrain : VTI, route-based, fabric SD-WAN — c’est la nouvelle norme. Donc, un bon ingénieur doit maîtriser les deux approches et savoir les combiner élégamment selon le contexte.

Trois erreurs fréquentes qui donnent des migraines

Premièrement, vouloir faire rentrer un carré dans un rond : on force du policy-based sur des designs qui demandent du routage dynamique. Deuxièmement, le « triangle de tunnels » — on construit des dizaines de liens statiques alors que BGP aurait réglé la moitié des soucis en une soirée. Et enfin, troisièmement — on sous-estime MTU et MSS. VPN vit à la charge finale : une mauvaise config du bit DF peut transformer les visioconférences du CEO en diaporama. Oui, le diable est dans les détails. Toujours.

Théorie de base : comment IPsec s’entend avec le routage

IKE, SA et sélecteurs de trafic

IPsec s’appuie sur deux blocs majeurs : IKE (phase d’échange de clés) et les SA (Security Associations) qui protègent le trafic. Avec IKEv2, on négocie chiffrement, authentification, durée de vie. Puis on crée des paires de SA pour chaque côté. En policy-based, le sélecteur SA est un triplet « source, destination, protocole/port ». Là réside un défi : plus il y a de paires uniques et d’applis, plus le nombre de SA explose, et la complexité aussi.

En route-based, la donne change : le sélecteur devient souvent « any-to-any » dans le tunnel, le trafic est filtré et dirigé par des politiques firewall sur les interfaces. Cela offre une grande flexibilité, surtout avec routage dynamique et multipath. Les sélecteurs ne sont plus un casse-tête et vous n’avez plus à jongler avec des dizaines d’ACL pour chaque service.

SPD, SAD et politiques de chiffrement

Pour décider ce qui passe dans le VPN, l’équipement consulte la SPD (Security Policy Database). Elle contient les règles de correspondance trafic/action : chiffrer avec tel profil ou laisser en clair. La SAD (Security Association Database) stocke les SA actives — tunnels avec leurs SPI, clés, durée de vie. En policy-based, la SPD est la colle qui tient la structure, tandis qu’en route-based elle est simplifiée car tout trafic sur l’interface tunnel est chiffré par défaut.

Ça semble un avantage net pour le route-based ? Presque. Si vous avez besoin d’isoler strictement et que seules certaines sous-réseaux doivent passer par le tunnel, policy-based reste plus explicite. En route-based, vous faites cela via des filtres et ACL sur interface, voire VRF si nécessaire.

VTI, GRE over IPsec et pourquoi les interfaces dominent

En 2026, la plupart des fournisseurs supportent VTI — des interfaces tunnel virtuelles point à point. IP assigné, OSPF ou BGP activé, et roule. GRE over IPsec ajoute une encapsulation GRE pour multi-protocoles et facilite certains cas comme le multicast, mais ça alourdit et demande plus d’attention au MTU. Souvent, si vous n’avez pas absolument besoin de GRE, VTI suffit amplement. Votre stack est plus simple, la surveillance claire et l’automatisation plus efficace.

VPN policy-based : principes, atouts et limites

Construction de la politique : ACL, crypto map et sélecteurs

Le VPN policy-based repose sur le principe « si le trafic correspond à la règle, on chiffre ». Concrètement : des ACL décrivent les sous-réseaux sources et destinations, parfois ports et protocoles. Ces règles sont associées à un profil cryptographique via crypto map ou équivalent. Chaque règle correspond souvent à un SA distinct.

Points forts : isolation nette et claire. Pas besoin d’interface dédiée, pas d’IP tunnel, moins de complexité visible. Limite : la montée en charge. Dès que vous voulez passer des dizaines d’applis, zones, et routes asymétriques vers le cloud, les ajustements deviennent un casse-tête indésirable en production. Les règles pullulent et chaque changement devient un exercice sans marge d’erreur.

Quand le policy-based brille

Certains cas d’usage sont naturellement bien adaptés. Par exemple, échange point à point avec un partenaire : une ou deux sous-réseaux, frontières claires, peu de dynamique. Ou si vous avez un firewall en périmètre qui inspecte principalement les applis, et le tunnel n’est qu’un support. Autre cas : zones hyper sécurisées où on minimise la surface d’attaque — pas d’interfaces supplémentaires, tout contrôlé par des sélecteurs stricts.

Sur certains anciens gateways cloud, le policy-based reste préféré quand le fournisseur supporte uniquement les sélecteurs. Ce n’est pas tout, mais ces cas existent notamment chez certains providers MPLS/VPN où le policy-based est plus stable dans leur infra.

Écueils et contraintes

Le principal point faible : la flexibilité. Si vous voulez routage dynamique, ECMP, BFD ou basculement rapide d’un cloud à l’autre selon SLA, le policy-based montre ses limites. Quelques fournisseurs ont des solutions semi-dynamiques sur policy-based, mais ce sont des compromis, pas un chemin fluide.

Autre difficulté : NAT et asymétrie. NAT avant IPsec risque de désynchroniser les sélecteurs. Ajoutez des MTU variables sur différents liens, et vous aurez des « freezes » d’applis. Sans parler de la télémétrie. Surveiller un tunnel via une interface est plus simple que compiler métriques indirectes sur SA et ACL. Dans les grandes architectures, ça se ressent vite.

VPN route-based : interfaces, dynamisme et échelle

La magie des interfaces tunnel virtuelles

Le VPN route-based se base sur une interface tunnel : on attribue une IP à chaque extrémité et on fait du routage classique. OSPF ? Bien sûr. BGP ? Facile. Plusieurs chemins, répartition de charge ? ECMP, policy routing, PBR sur l’interface. Le principe : tout trafic entrant sur l’interface tunnel est chiffré. Les sélecteurs ne sont plus le centre du monde.

Grand avantage : outils de diagnostic standard. Ping, traceroute, SNMP, télémétrie en flux, SLA réaliste. Vous arrêtez de faire du dépannage à l’aveugle et vous devenez un vrai ingénieur réseau : si l’interface flanche, on cherche la cause, notifications vers le NOC et SIEM.

Routage : statique, OSPF, BGP

Les routes statiques restent fréquentes pour les petites topologies. Mais en 2026, dès que vous dépassez 5 à 10 sites et un cloud, BGP over IPsec devient quasi un standard. Pourquoi pas OSPF ? Utile aussi, surtout dans des designs hub-and-spoke simples. Mais BGP est plus flexible aux frontières d’autonomie, plus simple pour gérer annonces et chemins, plus stable avec les changements fréquents. Sans oublier la forte compatibilité BGP chez les cloud providers majeurs.

La dynamique n’est pas une coquetterie. Elle assure une convergence rapide en cas de panne, une intégration aisée de nouvelles sous-réseaux sans interventions manuelles, une visibilité claire sur les préférences de chemins. Ce n’est plus un luxe, c’est un socle SLO/SLA indispensable pour le business.

Performance et regards vers le futur

Les routeurs et NGFW en 2026 accélèrent matériellement AES-GCM, beaucoup supportent ChaCha20-Poly1305 pour les plates-formes sans AES-NI, un vrai pas en avant. En route-based, il est plus simple d’ajouter des tunnels pour la migration, d’appliquer QoS sur interface et d’implémenter des contrôles SLA par tunnel. Le SD-WAN est généralement conçu sur route-based : gestion centralisée, segmentation, steering selon règles métier. Le policy-based le permet aussi, mais au prix d’efforts et de stress, surtout en environnement mixte.

Comparaison policy-based vs route-based : critères de choix

Complexité et montée en charge

Pour deux bureaux et trois serveurs, probablement policy-based est plus simple à configurer et gérer. Mais dès que la taille grandit, route-based l’emporte. Vous ne jonglez plus avec des centaines de sélecteurs, mais avec interfaces, routes et politiques. Le risque d’erreur humaine chute. L’automatisation devient accessible. Moins d’urgences nocturnes.

Règle d’or : avec un cloud, deux fournisseurs ou plus, des besoins de télémétrie et convergence rapide — route-based. Pour échanges point à point très stricts — policy-based.

Sécurité et transparence

Policy-based est intrinsèquement restrictif. Il chiffre uniquement ce qui est décrit. Cela rassure les auditeurs et facilite certains standards. Route-based est tout aussi sûr, mais la méthode change : filtrage sur interfaces, zones, VRF, ACL. Si votre équipe maîtrise bien les politiques firewall et la segmentation, route-based leur offrira un contrôle équivalent avec un bonus de scalabilité.

Compatibilité et multi-fournisseurs

Sur réseaux hétérogènes, route-based est souvent plus prévisible. Les interprétations des sélecteurs varient, les extensions IKE aussi. L’approche par interface lisse les angles, surtout face à IPv6-only et BGP over IPsec. Néanmoins, il existe des contraintes legacy et fournisseurs où policy-based reste la seule option viable. Là, bon sens et pilotes sont clés.

Cas d’usage et architectures 2026

Succursale à succursale : du simple à la maturité

Niveau basique : policy-based entre deux points avec une ou deux sous-réseaux. Simple, économique, clair. Niveau moyen : hub-and-spoke avec tunnels des succursales vers le centre. Ici, route-based triomphe : ajoutez une succursale, la dynamique démarre, annonces propagées, politiques sur hub réglées. Niveau mature : deux hubs dans différentes régions, ECMP, BFD, SLA sur tunnel, interception pour inspection, QoS. Presque du SD-WAN, où route-based est incontesté.

Cloud hybride : AWS, Azure, GCP

Les clouds publics préfèrent route-based. AWS VGW et Accelerated GW, Azure VPN Gateway, GCP Cloud VPN — tous gèrent bien BGP. Vous créez VTI, configurez ASN, publiez des préfixes, terminé. Il existe des modes policy-based, surtout en SKU basiques ou quand les plates-formes limitent l’interopérabilité, mais route-based est plus flexible pour DR et multi-cloud. En 2026, beaucoup adoptent IPv6 dans les VPC/VNet cloud, et BGP est une bouée pour les annonces contrôlées.

SD-WAN, SASE et ZTNA

Les contrôleurs SD-WAN construisent quasiment toujours des overlays sur des tunnels route-based, que ce soit en protocole natif ou IPsec dessous. SASE, quand il s’intègre à votre périmètre, repose aussi sur des tunnels avec interfaces : collecte des métriques, équilibrage de charge, application de politiques métiers — tout cela est plus simple via VTI. ZTNA est différent, mais dans les architectures hybrides, il nécessite un backhaul vers vos réseaux ; là aussi, les interfaces facilitent la mise en œuvre. La recette : mixez. Trafic sensible et risqué — policy-based, masse et gestion — route-based.

Interopérabilité multi-fournisseurs et fusions-acquisitions

Lors de fusions, on doit souvent connecter rapidement les réseaux respectifs. Si les parties utilisent différents fournisseurs et politiques, route-based accélère l’intégration. Plus simple de créer un VTI, lancer BGP, appliquer filtrage et étendre petit à petit le périmètre. Si la sécurité exige du tranchant (« scalpel » plus que « ciseaux »), employez temporairement policy-based pour des liens critiques, puis migrez vers une approche interface quand la poussière retombe.

Pratique de configuration : plateformes populaires

Cisco : ASA/FTD et IOS-XE

Historique : ASA/FTD privilégient policy-based via crypto map et ACL. Mais depuis des versions récentes, VTI est supporté pour route-based, même si ASA présente des particularités en diag et gestion. Pour beaucoup de succursales et BGP, préférez IOS-XE (ISR/ASR/Catalyst). Là, VTI, profils IPsec, DMVPN ou FlexVPN sont natifs. Pratique : gardez policy-based pour cas ponctuels partenaires sur ASA, et basez le réseau principal sur IOS-XE avec VTI et dynamique.

Étapes générales : définir politique IKEv2 et chiffrement, configurer IPsec transform-set/profil, ajouter VTI avec IP, activer IGP ou BGP, appliquer ACL/firewall zone-based sur l’interface tunnel. N’oubliez pas clamp MSS et PMTUD.

Juniper SRX et Fortinet FortiGate

SRX est un champion du route-based avec interfaces st0, intégration fine OSPF/BGP, et riche boîte à outils de politique. FortiGate aussi avec VTI et BGP over IPsec, plus des assistants GUI pratiques pour les soirées longues. Policy-based est supporté sur les deux, mais recommandé uniquement quand pertinent — sélecteurs limités, échanges partenaires, petits projets. Pour les grandes infrastructures, c’est routes et interfaces sans hésiter.

Astuce pratique : sur FortiGate, définissez phase2 selectors en 0.0.0.0/0 en route-based pour lever les limites trafic, et filtrez via politiques. Sur SRX, surveillez zones de sécurité et politiques vers/depuis st0 pour éviter les trous. Activez DPD.

MikroTik, pfSense/OPNsense, StrongSwan

MikroTik RouterOS v7 a bien amélioré IPsec et BGP : route-based viable, malgré quelques subtilités d’interfaces et monitoring. pfSense/OPNsense avec StrongSwan proposent les deux : policy-based via Phase 2 avec sous-réseaux spécifiques, route-based via VTI. Conseil : en cas de cloud ou croissance, optez pour VTI ; sinon, la migration future sera compliquée.

Sur StrongSwan Linux, route-based est presque la norme : création d’une interface tunnel (ex. xfrm ou vti), routes statiques ou BGP (FRRouting), filtrage iptables/nftables. Pour protection par application et réduction de surface, gardez instances distinctes de configs et sélecteurs policy-based, mais usage ciblé.

Cloud : AWS, Azure, GCP

— AWS : pour dynamique, préférez AWS Site-to-Site VPN avec BGP. Pour haute performance, VPN accéléré ou Transit Gateway, où route-based et BGP sont la base. Policy-based possible, mais cas anciens. — Azure : VPN Gateway (RouteBased) avec IKEv2, BGP et mode actif-actif. SKU PolicyBased spécifique et limité. — GCP : HA VPN avec BGP est standard, Classic VPN en legacy. À tous niveaux : vérifiez MTU end-to-end, filtrez annonces, assurez uptime via tunnels redondants et ECMP.

Performance, MTU et QoS

MTU, MSS et PMTUD : détails critiques

IPsec ajoute de l’overhead. VTI, GRE over IPsec encore plus. En pratique, cela réduit la MTU réelle sur le chemin. Mauvaise gestion du bit DF et blocage ICMP Frag Needed tue souvent les gros paquets. Solution : activer PMTUD, autoriser ICMP pertinent, configurer clamp MSS autour de 1360–1380 pour TCP avec overhead tunnel, mesurer MTU sûre réelle. Vérifiez des deux côtés, sinon asynchronies.

Bonne habitude : documenter valeurs MTU/MSS à côté de la config tunnel pour éviter de radoter six mois plus tard. Gardez des templates de test gros paquets pour chaque modification.

Cryptographie et accélération

En 2026, l’accélération matérielle AES-GCM est quasi universelle. ChaCha20-Poly1305 est une excellente alternative sur les devices sans AES-NI. Le choix des chiffrement impac­te latence et débit. Voyez les benchmarks réels : passer de AES-CBC+SHA1 à AES-GCM gagne souvent 20–40 %. Moins de CPU, moins de jitter, meilleurs voix et vidéo.

N’oubliez pas PFS (Perfect Forward Secrecy) : ce n’est pas une simple case à cocher, mais une garantie cruciale. IKEv2 face à IKEv1 : choix évident. Réglez des durées de vie raisonnables : plus courtes = plus sûres, mais sans tomber dans la paranoïa de surchauffe CPU pour regen.

QoS et priorisation

En route-based, QoS peut s’appliquer directement sur l’interface tunnel, avec conservation ou réécriture du DSCP, shaping par classe. En policy-based, c’est plus complexe et dépend du fournisseur. Si vous passez voix/vidéo via VPN — QoS est indispensable. N’hésitez pas à faire des politiques par tunnel avec SLA : si perte paquets dépasse seuil, bascule vers autre lien. C’est de l’ingénierie normale, pas de la parano.

Haute disponibilité et monitoring

DPD, SLA et BFD : regards et réactions rapides

Dead Peer Detection vous informe si le pair est vivant. Mais pour vraie rapidité en route-based, ajoutez BFD sur tunnel avec intégration IGP/BGP. Vous obtenez convergence en centaines de millisecondes, pas en dizaines de secondes. IP SLA ou équivalents mesurent qualité réelle du lien : latence, jitter, pertes. Le routage se base sur métriques, pas supputations.

Conseil : mettez en place des profils standards de timing et seuils pour types de liens. Automatisez les réactions. L’humain reste pour l’analyse, pas pour courir à 3 h du mat.

Active-active, ECMP et multipath

Si le provider le permet, montez deux tunnels vers points d’entrée différents. ECMP par SLA est une pratique standard. Pour services critiques, cela élimine un point de défaillance. En policy-based, ce genre de schémas est possible mais souvent peu élégant. En route-based, c’est naturel : plusieurs interfaces, poids, sondes, profils de charge.

Observabilité : logs, flux et télémétrie

En 2026, nous sommes dans l’ère du networking observable. Logs IKE/IPsec vers SIEM, NetFlow/IPFIX tunnel vers analytics, métriques interfaces vers monitoring. Ce n’est pas optionnel. Alertes sur dégradation SLA et flapping tunnel indispensables. Et oui, créez de beaux dashboards : quand il faut expliquer vite à la direction où ça coince, la visualisation sauve la mise.

Sécurité et conformité

Chiffrement moderne et agilité crypto

Choisissez IKEv2, PFS, chiffres AES-GCM ou ChaCha20-Poly1305. Abandonnez les algos obsolètes. Mettez à jour les profils selon recommandations fournisseurs. La crypto-agilité — capacité à migrer rapidement vers un nouveau set de chiffrement — est désormais une exigence de conformité. Documentez, testez à l’avance, maintenez un plan de switch.

Certificats plutôt que pré-partagés se généralisent en moyens et grands réseaux. PKI peut s’automatiser via ACME ou intégration CA corporate. Cela structure ingénieurs et processus.

Segmentation, VRF et micro-isolation

En route-based, VRF fait merveille. Vous pouvez séparer tunnels par VRF, appliquer politiques différentes, limiter les routes. Ainsi, une attaque sur un segment ne déborde pas sur un autre. En policy-based, effet similaire via règles complexes, mais VRF est plus simple à gérer et expliquer. Ajoutez micro-segmentation au niveau NGFW et vous obtenez un modèle sain de « moindre privilège ».

Audit et rétrospectives

Faites des revues régulières : quels sélecteurs sont encore utiles, quelles routes sont redondantes, où les politiques se sont élargies. Croisez logs IKE, IPsec, firewall et BGP pour une vision unifiée. Les incidents aiment le silence. Ne leur faites pas ce plaisir. Après chaque gros changement, faites une rétrospective et consignez en playbook.

Tests, diagnostics et erreurs fréquentes

Points de vérification tunnel

Processus simple : IKE SA active ? Parfait. IPsec SA aussi ? Sélecteurs/SPD vérifiés ? Ping via interface tunnel ? Traceroute et visibilité des routes ? En policy-based, confirmez exactitude ACL et que NAT ne casse pas les sélecteurs. En route-based, vérifiez ACL entrantes/sortantes sur interface et voisinages IGP/BGP.

Passez ensuite aux tests applicatifs. À la couche 7, surprises possibles : MTU, timeouts, reconnexions. Préparez un « script test » avec pings, curl, iperf, paquets variés. Moins d’impro, moins de risques d’omission de détails critiques.

MTU, fragmentation et bit DF

Erreur classique : bloquer ICMP ou ignorer le bit DF, gros paquets tombés à l’eau en silence. Solution : activer PMTUD, autoriser ICMP type 3 code 4, configurer clamp MSS. Surveillez les deux côtés. Souvenez-vous de l’asymétrie : aller à 1476, retour 1454 = comportement application instable. Ce n’est pas magie, c’est physique.

NAT-Traversal et routage asymétrique

NAT-T sauve quand un pair est derrière NAT. Mais cela engendre complexités : ports identiques, dérive sessions, bugs rares firmware. Maintenez firmwares à jour, activez diag détaillée IKE/IPsec. Le routage asymétrique est une autre plaie : moitié du flux passe par un tunnel, moitié du retour par un autre, firewall stateful rejette la réponse. Solution : concevez symétrie, utilisez politiques par tunnel ou synchronisation de sessions en cluster.

Automatisation et IaC pour VPN

Terraform, Ansible et GitOps

Terraform pour clouds et certains fournisseurs, Ansible pour configs réseau, Git comme source unique de vérité. En route-based, l’automatisation est plus naturelle : parametrage interfaces tunnel, ASN, listes d’annonces, SLA. En policy-based aussi possible, mais gestion de nombreux sélecteurs et ACL demande rigueur et templates.

Approche GitOps : tous changements passent par PR, contrôle politique avec linters, tests automatiques en lab, déploiement programmé hors heures de pointe. Non, ce n’est pas « trop compliqué ». C’est moins cher qu’une grande panne.

Tests et vérification

Patron « validate-before-merge » : avant prod, tests exécutés. Tunnel temporaire levé en lab, sessions BGP testées, ping, MTU, marquages QoS validés. Pour policy-based : conformité sélecteurs, absence conflits, gestion NAT correcte. Pour route-based : routes correctes, pas de fuites VRF, politique respectée.

Secrets et sécurité de l'automatisation

Gardez PSK et certifs dans coffre-forts (Vault, KMS, secrets Kubernetes si CNI). N’exposez jamais clés en clair dans repo. Enregistrez qui et quand a modifié la politique crypto. Surtout, planifiez rotation clés comme processus régulier, pas comme « un jour peut-être ».

Économie et choix

Licences, performance et hardware

Soyez clair : certains fournisseurs facturent tunnels VPN, débit ou accélération crypto. Route-based utilise souvent plus d’entités interfaces, mais pas forcément plus cher — dépend plateforme. L’accélération matérielle AES-GCM économise CPU et coûts : moins de matériel pour le même SLA. En policy-based avec beaucoup de SA, plateformes économiques saturent vite.

Coûts opérationnels

La vie, c’est la maintenance. Route-based coûte moins cher en environnements changeants : topologie mouvante, réseaux ajoutés, clouds croissants. Monitoring, automation, templates homogènes sont vos alliés. Policy-based gagne sur petits cas fixes. Ce n’est pas une question de foi, mais un tableau Excel avec risques et objectifs.

Conséquences d’un mauvais choix

Cas classique : entreprise triple en taille avec 100 tunnels policy-based et ACL détaillées chacun. Chaque changement est un champ de mines. Migration route-based inévitable, faite sous pression la nuit. Des mois de gagné si VTI et dynamique avaient été prévus. Inverse : tout en route-based, puis partenaire n’acceptant que sous-réseaux précis obligeant complexification locale ACL. Règle d’or : concevez un mix pragmatique.

Checklists et bonnes pratiques

Choix d’architecture

• Vous avez un cloud et une croissance prévue ? Optez pour route-based, VTI, BGP.
• Échange point à point avec partenaire ? Policy-based avec sélecteurs précis.
• SLA tunnel nécessaire ? Route-based avec IP SLA/BFD.
• Exigences fortes en segmentation ? VRF + firewall interface ou sélecteurs ciblés.

Mise en œuvre

• Définissez politique crypto : IKEv2, PFS, AES-GCM/ChaCha20.
• Vérifiez MTU end-to-end, activez PMTUD et clamp MSS.
• Pour route-based : planifiez ASN, filtrage préfixes, attributs BGP.
• Pour policy-based : minimisez sélecteurs, évitez règles port-spécifiques inutiles.

Exploitation

• Logs IKE/IPsec vers SIEM, métriques interfaces vers monitoring, alertes dégradation.
• Rotation périodique clés et certificats, mises à jour firmware.
• Tests automatiques après changements, rétrospective incidents et mise à jour playbooks.
• Audit trimestriel routes et politiques d’accès.

Cas réels et modèles de solutions

Cas 1 : passage de 20 à 60 succursales en un an

Entreprise débutant en policy-based : deux fournisseurs, trois partenaires, simple. En un an, 40 sites supplémentaires et deux régions cloud. Migration vers route-based. Deux VTI par site, BGP avec communities, ECMP, priorisation VoIP. Résultat : convergence sous 1 seconde, ajout souple de sous-réseaux, -30 % incidents NOC.

Cas 2 : partenaire avec contraintes réglementaires

Partenaire n’accepte que policy-based avec sélecteurs stricts et paramètres IKE. Solution : garder policy-based pour ce lien, route-based pour le reste des flux intersites. Au périmètre, translation DSCP et double inspection NGFW. Monitoring SLA commun, tests charge réussis. Tous satisfaits, standards inchangés.

Cas 3 : migration d’IPv4 uniquement vers un hybride IPv6

Clouds et succursales activent IPv6. Sur route-based VTI, lancement de BGP multi-familles d’adresses, annonces précises, QoS et télémétrie préservées. Pour services paresseux sur gros paquets, ajustement MSS. Transition sans interruption, car approche interface permet coexistence de deux époques.

Pièges courants et comment les éviter

Trop de sélecteurs

En policy-based, si la liste de règles grossit plus vite que le playbook, vous êtes en danger. Solution : grouper sous-réseaux, déployer tunnels interface, déplacer filtrage vers firewall. Migration progressive : d’abord canal parallèle route-based, puis bascule routes.

Zone aveugle en monitoring

Policy-based n’a pas d’interface — pas de métriques claires. Ne négligez pas cela. Détectez télémétrie dédiée SA, utilisez logs syst IKE/IPsec, collectez NetFlow avant/après tunnel. Ou migrez vers route-based où interface est votre alliée observabilité.

« Ça marchait puis ça a cassé »

Fréquemment : rekey côté pair et bug firmware autre côté, ou NAT-T fatigué. Mettez à jour firmwares, activez diag détaillée, comparez profils crypto et durée vie. Tenez une matrice compatibilité vendeurs/versions. Peu fun, mais ça sauve nuits blanches.

Plan de migration : du policy-based au route-based sans douleur

Migrer étape par étape

Créez VTI parallèles, montez routes statiques avec distance administrative plus élevée. Faites des tests, activez télémétrie. Passez ensuite une partie des préfixes sous BGP avec faible risque. Vérifiez ACL interfaces alignées avec politique sécurité. Éteignez progressivement sélecteurs policy-based, évitez les coupures brusques.

Contrôle qualité

Fixez SLO : latence, perte, jitter. Définissez surveillance des dégradations. Activez BFD si supporté. Testez basculement volontaire : coupez un lien, vérifiez convergence, alertes, comportement applis. Ce crash-test unique sauve des dizaines d’heures stressantes.

Communication et documentation

Documentez l’architecture, préfixes, ASN, politique crypto, MTU/MSS, commandes de contrôle. Partagez schéma et checklist avec support. Fixez fenêtre de changement et plan de repli — c’est souvent ce qui différencie migration contrôlée du chaos.

FAQ

Réponses rapides, partie 1

• Question : Que choisir pour un petit bureau sans cloud ? Réponse : Policy-based si peu de sous-réseaux et peu de changements. Plus simple et économique à configurer.
• Question : Que choisir pour cloud hybride en croissance ? Réponse : Route-based avec VTI et BGP. Offre flexibilité, télémétrie et automatisation facilitée.
• Question : Peut-on mélanger les approches ? Réponse : Oui, et c’est courant. Policy-based pour partenaires et intégrations ponctuelles, route-based pour périmètre principal.

Réponses rapides, partie 2

• Question : QoS dans IPsec, c’est comment ? Réponse : Conservation DSCP et politique sur interface mieux en route-based. Policy-based dépend fournisseur et est plus complexe.
• Question : Comment gérer les gros paquets qui bloquent ? Réponse : Activez PMTUD, autorisez ICMP Frag Needed, clamp MSS. Vérifiez MTU dans les deux sens.
• Question : IKEv2 est-il indispensable ? Réponse : Oui. Plus stable, flexible et sûr qu’IKEv1. Meilleur support cloud aussi.

Réponses rapides, partie 3

• Question : Dynamique ou statique ? Réponse : Statique pour 5 sites. Pour dizaines et cloud, BGP, c’est la norme.
• Question : Combien de tunnels installer ? Réponse : Minimum deux par site, vers différents peers/régions. Haute dispo et maintenance sans coupure garanties.
• Question : Comment rassurer l’audit ? Réponse : Documentez politique crypto, segmentation, logs et rotation clés. Montrez contrôle accès interfaces si route-based.