8 — Azure Virtual WAN (vWAN)

Service managé qui centralise connectivité, routage et sécurité à l'échelle mondiale via des hubs gérés par Microsoft → remplace le hub-and-spoke construit à la main.

A. Vue d'ensemble

A.1 Le problème que vWAN résout

Le hub-and-spoke classique fonctionne bien à l'échelle d'une région, voire de quelques régions. Mais dès qu'on monte à l'échelle mondiale — des dizaines, voire des centaines de régions et de sites — il devient ingérable. C'est précisément ce que vWAN adresse.

Hub-and-Spoke classique : 1 VNet hub central + spokes peerés. Tout est construit manuellement : peering, VPN GW, ER GW, NVA, UDR, NSG…

Marche bien pour 1-3 régions. Mais au-delà :

• Limite 500 peerings/VNet rapidement atteinte
• Multiplication des Gateways manuelles dans chaque région
• Pas de transitivité native (hub spoke A ↔ hub spoke B ne se voient pas sans config manuelle)
• Gestion d'UDR cauchemardesque à grande échelle

Virtual WAN est un service global managé qui simplifie la connectivité multi-régions / multi-sites :

• On déclare la topologie (hubs + connexions) → MS provisionne tout
• Transitivité any-to-any entre hubs (par défaut)
• Pas besoin de monter des Gateways manuellement dans chaque région
• Branch / VPN / ER / P2S tout supporté nativement

A.2 Hub-Spoke custom vs vWAN — quand choisir quoi ?

🎯 Règle simple : 1-3 régions, simple → Hub-Spoke. ≥ 4 régions, multi-sites branch, SD-WAN, simplification → vWAN.

B. Composants

B.1 Schéma global

                    ┌────────────────────────────┐
                    │      Virtual WAN           │
                    │  (ressource globale)        │
                    └───────────┬────────────────┘
                                │
        ┌───────────────────────┼───────────────────────┐
        │                       │                       │
   ┌────▼─────┐            ┌────▼─────┐            ┌────▼─────┐
   │ Hub WEU  │◄──hub-to──►│ Hub EUS  │◄──hub-to──►│ Hub APAC │
   │ (West EU)│   hub      │ (East US)│   hub      │ (SE Asia)│
   └────┬─────┘            └────┬─────┘            └────┬─────┘
        │                       │                       │
   ┌────┴──────┐           ┌────┴──────┐           ┌────┴──────┐
   │ VNets,    │           │ VNets,    │           │ VNets,    │
   │ S2S VPN,  │           │ S2S VPN,  │           │ P2S VPN,  │
   │ ER, P2S   │           │ ER        │           │ ER        │
   └───────────┘           └───────────┘           └───────────┘

B.2 Ressources clés

B.3 Hub Gateway — managée MS

La Hub Gateway managée MS ne doit pas être confondue avec le routage hub-to-hub.

• Hub Gateway = les Gateways VPN/ER/P2S dans le hub (équivalent des VNet Gateways classiques, mais MS les déploie pour toi)
• Hub-to-hub routing = transit automatique entre les hubs du même vWAN, géré par le backbone MS via BGP interne

C. SKUs

Le SKU Basic se limite au S2S VPN et ne fournit pas d'interconnexion entre les hubs ; pour bénéficier de l'ensemble des fonctionnalités, le SKU Standard est requis.

🚨 Basic est uniquement pour migration trial ou très petite PME single-region S2S. Pour tout déploiement enterprise → Standard obligatoire.

⚠️ Upgrade Basic → Standard : possible dans le portail (irréversible). Downgrade Standard → Basic : impossible.

D. Virtual Hub Capacity / Scale Units

La capacité d'un Virtual Hub recouvre plusieurs notions distinctes — Routing Infrastructure Units, Gateway scale units (VPN et ExpressRoute) — qu'il faut savoir différencier pour dimensionner correctement et savoir quand augmenter quoi.

D.1 Le truc à comprendre : 3 dimensions indépendantes

Un Virtual Hub a 3 types de capacités séparées, chacune dimensionnée indépendamment :

💡 Analogie simple : le hub est un bâtiment. Les RIU = capacité électrique du bâtiment (ascenseurs, lumières — sert tout le monde). Les VPN/ER scale units = capacité des bureaux spécifiques (VPN room, ER room) installés dans le bâtiment.

D.2 Routing Infrastructure Units (RIU)

C'est la capacité du hub lui-même, pour le routage interne. Tu en as besoin dès qu'il y a un hub, même sans VPN ni ER.

Ce que ça dimensionne :

• Nombre max de VNets connectables au hub
• Nombre max de VMs aggregate (somme des VMs dans tous les spokes) que le hub peut gérer
• Bandwidth de routage interne agrégé (entre les spokes, hub-to-hub, vers les gateways)

Échelle :

• Default : 2 RIU (= 3 Gbps + 2 000 VMs). Au-delà, progression linéaire ≈ 1 Gbps et 1 000 VMs par RIU ; max 50 RIU = 50 Gbps / 50 000 VMs
• Min 2, max 50
• Auto-scaling : Azure peut monter automatiquement quand le nombre de connexions augmente (sauf valeur fixée manuellement)

⚠️ Le nombre de VNet connections ne dépend PAS des RIU. La limite est 500 − (nombre de hubs) par vWAN sans Routing Intent (les RIU dimensionnent le débit et le nombre de VMs agrégées, pas le nombre de connexions VNet).

• Coût : facturé par RIU au-delà de 2 (prix indicatif, vérifier la calculatrice Azure — les prix évoluent)

D.3 VPN Gateway Scale Units (S2S et P2S)

Nécessaire seulement si S2S VPN ou P2S VPN est activé dans le hub. La VPN GW dans un hub vWAN est différente d'une VNet Gateway classique (managée par Azure, scalable nativement).

Ce que ça dimensionne :

• Bandwidth de la VPN Gateway dans le hub
• Nombre max de tunnels et de users simultanés

Échelle :

• 1 SU = 500 Mbps (2 instances actives pour la résilience)
• S2S : min 1, max 20 SU (= 10 Gbps agrégés)
• P2S : va au-delà de 20 SU — jusqu'à 200 SU (= 100 Gbps, 100 000 users max par hub) ; la table de débit P2S diffère (paliers de connexions concurrentes : 500 → 1000 → 5000 → 10 000 selon les SU, puis +10 000 users par paire d'instances au-delà de 20 SU)
• Connexions S2S (branches) supportées : 1000 par hub (2000 tunnels IPsec)

D.4 ExpressRoute Gateway Scale Units

Nécessaire seulement si ER est activé dans le hub.

Échelle :

• 1 SU = 2 Gbps
• Min 1, max 10
• FastPath nécessite ≥ 10 SU (la limite max)

D.5 Tableau récap — quand utiliser quoi ?

D.6 Quand dimensionner / re-dimensionner

Au déploiement initial :

• En cas de doute → min partout (2 RIU, 1 VPN SU si VPN, 1 ER SU si ER)
• Possibilité d'augmenter sans interruption de service
• Diminuer : pas toujours possible (selon la conf et les connexions actives)

Au runtime, monter si :

• Latence ou pertes paquets sur le hub → RIU à augmenter
• Saturation des tunnels VPN (latence montante, débit plafonné) → VPN SU à augmenter
• ER utilisation > 70% capacity → ER SU à augmenter

Coût :

• RIU : facturé par RIU au-delà de 2 (les 2 premiers inclus)
• VPN SU : ~$0.36/h par SU
• ER SU : ~$0.43/h par SU

Vérifier les prix actuels sur la calculatrice Azure (peuvent évoluer).

D.7 Le routing preference (à ne pas confondre avec scale units)

Le routing preference est une autre dimension : pas une question de capacité, mais de préférence de chemin quand plusieurs sources de routes BGP arrivent au hub.

Détaillé en §E ci-dessous (Hub Routing Preference). Distinct des scale units.

D.8 Bonne pratique

Commencer bas (2 RIU, 1 SU si VPN, 1 SU si ER), monter au besoin selon le monitoring Azure Monitor (Network Insights). Sur-allouer = surcoût inutile. Sous-allouer → latence/perte.

E. Hub Routing Preference

Quand un hub vWAN apprend des routes depuis plusieurs sources (ER + VPN par exemple) pour le même préfixe, lequel préfère-t-il ?

3 modes :

Configuration : Virtual Hub > Settings > Routing Preference > <choix>

💡 Avec Routing Intent (voir §G), les routes "secured path" sont toujours préférées sur les routes ER sans secure path, peu importe la routing preference.

F. Virtual Hub Routing (route tables intégrées)

Chaque Virtual Hub a des route tables managées personnalisables pour contrôler quel spoke voit quoi.

F.1 Default Route Table

• Créée automatiquement à la création du hub
• Toutes les connexions VNet propagent leurs routes par défaut à cette table
• Toutes les connexions VNet s'associent par défaut à cette table → elles utilisent les routes de cette table pour leur trafic

→ Conséquence : par défaut, tous les spokes se parlent entre eux via le hub.

F.2 Custom Route Tables

Tu peux créer des route tables custom pour des cas comme :

• Isolation : spoke3 ne doit voir que spoke1, pas spoke2
• Insertion d'un firewall : route 0.0.0.0/0 → NVA sur certains spokes seulement
• Multi-tenancy : chaque tenant a sa propre route table, isolation totale

F.3 Propagation vs Association

C'est la confusion la plus classique. Bien distinguer :

Exemple concret : pour une connexion spoke3-to-hub, on sélectionne la nouvelle route table au lieu de la table par défaut, on positionne Propagate to none et on associe la route table spoke3-rt. Décomposé :

• Association = spoke3-rt → spoke3 utilise les routes de spoke3-rt pour son trafic (donc il voit seulement spoke1 selon la règle qu'on a créée)
• Propagation = None → spoke3 n'annonce PAS son CIDR aux autres tables → spoke1 et spoke2 ne savent pas atteindre spoke3

💡 C'est pour ça qu'à la fin, ping spoke1 → spoke3 ne marche pas. Il faut soit :

• Propager spoke3 vers la default table, OU
• Ajouter manuellement une route statique dans la default table pointant vers spoke3 (comme dans la démo)

F.4 Labels

Label = groupe logique de route tables. Permet de propager vers plusieurs tables d'un coup.

Exemple : label prod couvre les tables prod-eu, prod-us, prod-apac. Au lieu de propager spoke vers 3 tables → propager au label prod.

💡 Le label Default regroupe automatiquement toutes les default route tables des hubs du vWAN. Pratique pour propager partout.

G. Routing Intent & Routing Policies (feature clé moderne)

G.1 Concept

Routing Intent = manière déclarative de pousser tout le trafic d'un hub vers une next hop résource de sécurité (Azure Firewall, NVA, SaaS security).

Au lieu de bricoler des route tables custom + UDR + propagations partout, on déclare :

"Tout le trafic privé doit passer par cette ressource X. Tout le trafic internet doit passer par cette ressource Y."

Et Azure provisionne automatiquement toutes les routes nécessaires.

G.2 2 types de Routing Policies

Private Traffic Policy

• Tout le trafic privé entrant/sortant du hub (VNets, S2S, P2S, ER, inter-hub) passe par la next hop ressource
• Next hop = Azure Firewall ou NVA
• Use case : inspection complète du trafic interne corporate

Internet Traffic Policy

• Tout le trafic à destination d'Internet (0.0.0.0/0) passe par la next hop ressource
• Next hop = Azure Firewall, NVA, 3rd-party SaaS security (ex Zscaler, Check Point CloudGuard)
• Use case : SSE (Secure Service Edge), filtrage internet centralisé pour 1000 users distribués

G.3 Limites

• Max 1 Internet policy + max 1 Private policy par hub
• Une seule next hop resource par policy
• Routing Intent remplace les custom route tables (pas compatible — il faut supprimer les custom routes avant d'activer)

🚨 Routing Intent est exclusif aux custom route tables : toutes les custom routes doivent être supprimées avant de l'activer.

G.4 Hub Routing Preference avec Routing Intent

⚠️ Quand Routing Intent est activé, les routes "secure path" (qui passent par la NVA/Firewall) sont toujours préférées sur les routes ER classiques sans Routing Intent. La préférence ER ne s'applique qu'aux hubs sans Routing Intent.

G.5 Forced Tunnel via Routing Intent

Quand Routing Intent Private est activé, on peut activer le mode Forced Tunnel Internet :

• Tout le trafic Internet est forcé vers l'on-prem via ER/VPN (le firewall on-prem filtre)
• Disponible uniquement avec Routing Intent + Private policy. Sans Routing Intent → impossible de forcer le tunnel internet en vWAN.

H. Network Virtual Appliance (NVA) dans un Hub vWAN

On déploie une NVA tierce dans le hub plutôt qu'Azure Firewall lorsqu'on a besoin de la même technologie qu'on-prem — c'est-à-dire conserver l'éditeur et les règles déjà en place via un produit 3rd party.

H.1 Quand utiliser NVA plutôt qu'Azure Firewall ?

• Cohérence avec on-prem : même éditeur (Cisco, Palo Alto, Fortinet, Check Point) → mêmes règles, mêmes équipes, même certif
• Features spécifiques : URL filtering avancé, SD-WAN intégration, App-ID, threat prevention propriétaire
• Licensing existant : entreprise a déjà des licences Palo, autant les utiliser dans Azure
• Multi-cloud : la même NVA tourne sur AWS / GCP, cohérence dans la sécurité

H.2 NVA Partners supportés (via Azure Marketplace)

• Cisco Cloud onRamp (Catalyst SD-WAN)
• Fortinet Secure SD-WAN
• Palo Alto Networks Prisma SD-WAN
• Check Point CloudGuard
• Versa Networks
• Aruba/Silver Peak
• Etc.

H.3 Déploiement dans un Hub vWAN

Le déploiement se fait depuis Hub > Network Virtual Appliance > Create Network Virtual Appliance, en choisissant l'appliance (Fortinet ou autre). Il faut au préalable une User Assigned Managed Identity ; un rôle Network Contributor sur la sub suffit en général.

Process :

1. Subscribe à l'offre vendor dans Azure Marketplace (BYOL ou pay-as-you-go)
2. Créer une User Assigned Managed Identity avec rôle Network Contributor sur la sub
3. Dans le hub vWAN : Network Virtual Appliances > Create NVA
4. Choisir le vendor (ex Fortinet)
5. Sélectionner la Managed Identity
6. Configurer scale units (bandwidth de la NVA dans le hub)
7. Provisionning automatique (NVA tournée par Azure dans le hub managé, les VMs ne sont pas visibles)
8. Activer Routing Intent avec la NVA en next hop

H.4 NVA vs Secured Virtual Hub (Azure Firewall)

I. Secured Virtual Hub

Concept : Hub vWAN Standard + Azure Firewall intégré dans le hub → sécurité centralisée sans monter de hub VNet custom.

I.1 Caractéristiques

• Azure Firewall (Standard ou Premium) déployé directement dans le Virtual Hub managé MS
• Tu n'as pas à gérer le subnet AzureFirewallSubnet ni le déploiement
• Géré via Azure Firewall Manager
• Compatible avec Routing Intent : Firewall = next hop pour Private et Internet policies
• Avantage vs Hub-Spoke custom + Azure Firewall : pas de peering, pas d'UDR, pas de subnet à gérer

I.2 Setup

1. Hub vWAN Standard existe
2. Virtual Hub > Security > Azure Firewall and Firewall Manager > Convert to Secured Virtual Hub
3. Sélectionner SKU Firewall (Standard ou Premium)
4. Attacher une Firewall Policy
5. Azure provisionne (déploiement long ~30 min)

🏢 Scénarios d'entreprise (CAF/WAF)

Scenario 1 : Multinationale tech — 30 bureaux dans 5 continents

Contexte business : multinationale tech (10 000 employés), 30 bureaux dans 25 pays. Connectivité hybride : sièges via ExpressRoute (Paris, NY, Tokyo), bureaux secondaires via S2S VPN, télétravailleurs via P2S. Avant : 5 régions en hub-spoke fait main, ~150 peerings, gouvernance impossible à tenir. Choix architectural : Virtual WAN Standard global + 5 Virtual Hubs régionaux + Routing Intent avec Azure Firewall Premium dans le hub principal + un profil User VPN global (P2S transparent partout). Architecture / pattern :

• 1 vWAN vwan-global (Standard).
• 5 Virtual Hubs : hub-eu-west, hub-eu-north, hub-us-east, hub-us-west, hub-apac.
• Connexion hub-à-hub automatique (tout le monde se parle via le backbone Microsoft).
• Sièges : connexions ExpressRoute (FastPath sur hub-eu-west et hub-us-east, ER GW 10 SU).
• Bureaux secondaires : S2S VPN (~25 sites, BGP activé), 2 SU par hub (1 Gbps suffit).
• P2S sur les 5 hubs avec une seule User VPN Configuration (auth Entra ID + Conditional Access).
• Secured Virtual Hub sur hub-eu-west (Azure Firewall Premium) + Routing Intent (policies Private + Internet) : tout le trafic passe par le firewall.
• Logs vers Log Analytics central + Sentinel. Trade-offs assumés :
• Gain : connectivité globale managée par Microsoft, ~150 peerings manuels supprimés, gouvernance centralisée.
• Perte : SKU Standard obligatoire (migration depuis Basic irréversible), dépendance forte au managé Microsoft. Pièges à éviter :
• Faire du hub-spoke manuel à 30 sites : 30 VPN GW + 30 LNG + 30 connexions + peerings à monter à la main = cauchemar.
• Choisir le SKU Basic « pour commencer petit » : pas de hub-à-hub, pas d'ER, pas de Routing Intent. Il faut migrer vers Standard ensuite (irréversible).
• Une config User VPN différente par hub : les utilisateurs jonglent avec plusieurs profils. Une seule User VPN Configuration au niveau vWAN.
• Oublier le Routing Intent : l'Azure Firewall du hub ne voit pas tout le trafic, des contournements deviennent possibles.

📐 Réf. CAF/WAF — Virtual WAN network topology (Azure Landing Zone) : placer tous les composants vWAN, Azure Firewall et le plan DDoS dans la connectivity subscription, un hub par région, et étendre via plusieurs hubs/région pour dépasser les limites d'un hub unique. Lien

Scenario 2 : SD-WAN unifié avec Cisco Catalyst dans le hub

Contexte business : industriel avec 80 sites usine. Déjà équipé en Cisco Catalyst SD-WAN on-prem (cEdge, vBond, vManage). Ils veulent que les usines remontent vers Azure via le même SD-WAN, piloté depuis vManage. Pas envie de gérer deux systèmes en parallèle (Cisco + VPN GW Azure). Choix architectural : vWAN Standard + une NVA Cisco Catalyst SD-WAN dans le hub + intégration vManage + Routing Intent. Architecture / pattern :

• vWAN Standard avec 2 Virtual Hubs (Europe, Americas).
• NVA « Cisco Catalyst SD-WAN » (depuis la Marketplace) déployée dans chaque hub.
• vManage (on-prem ou hébergé) gère la config SD-WAN et la pousse à la fois vers les cEdges des sites et vers la NVA Cisco dans Azure : une vue unique.
• Sites usine : les cEdges Cisco montent des tunnels SD-WAN vers la NVA Azure (via internet ou ER).
• Routing Intent activé : tout le trafic privé inter-hub passe par la NVA Cisco, avec les mêmes règles qu'on-prem.
• Avantage : l'équipe réseau garde ses outils Cisco, sa formation et ses certifications. Trade-offs assumés :
• Gain : pilotage unifié depuis vManage, réutilisation des compétences/outils Cisco existants.
• Perte : NVA Cisco exclut un Azure Firewall dans le même hub (1 seul next hop), NVA à déployer dans chaque hub. Pièges à éviter :
• Vouloir une NVA Cisco ET un Azure Firewall dans le même hub : impossible, une routing policy n'a qu'un seul next hop. Il faut choisir.
• Oublier la Managed Identity + le rôle Network Contributor : le déploiement échoue en silence.
• Sous-dimensionner les Infrastructure Units de la NVA : débit plafonné pour les 80 sites.
• NVA Cisco dans le hub WEU mais sites APAC routés vers un hub APAC sans NVA : règles fragmentées. Déployer une NVA dans tous les hubs.

📐 Réf. CAF/WAF — Combine security solutions in a single hub (hub-spoke vWAN) : un hub n'a que 2 routing policies (1 private + 1 internet), une seule next hop chacune ; deux NVA tierces dans le même hub ne sont pas supportées — l'inspection inter-hub exige le routing intent sur chaque hub. Lien

Scenario 3 : Workforce hybride global — P2S massif avec SSE

Contexte business : entreprise tech 100% télétravail, 3000 employés dans 40 pays. Règle : tout le trafic internet pro doit être filtré (compliance + sécurité). Pas de proxy on-prem possible (aucun datacenter corporate). Choix architectural : vWAN Standard + P2S OpenVPN sur 4 hubs régionaux + Routing Intent Internet pointant vers le connecteur SaaS Zscaler ZIA. Architecture / pattern :

• 4 hubs (Europe, Americas, APAC, Africa).
• User VPN Configuration globale avec auth Entra ID + Conditional Access (MFA, conformité du device).
• P2S Gateway sur chaque hub, 10+ scale units (jusqu'à 10 000 utilisateurs en pic).
• Un address pool différent par hub pour tracer facilement.
• Routing Intent Internet : next hop = connecteur SaaS Zscaler ZIA (NVA SaaS).
• Chaque utilisateur P2S se connecte au hub le plus proche ; son trafic internet est inspecté par Zscaler dans ce hub.
• Trafic privé (vers les apps SaaS Azure de l'entreprise) : Routing Intent Private + Azure Firewall pour l'inspection. Trade-offs assumés :
• Gain : filtrage internet SSE global sans proxy on-prem, accès le plus proche par hub régional.
• Perte : facturation Zscaler ZIA au Go transité, multi-hub et scale units à dimensionner pour les pics. Pièges à éviter :
• Un seul hub global : latence énorme pour l'APAC. Le multi-hub est obligatoire à cette échelle.
• Pas de Routing Intent : le trafic internet sort direct du hub et contourne Zscaler.
• P2S à 1 scale unit : ~500 utilisateurs max par hub, saturation.
• Oublier la facturation du connecteur Zscaler ZIA (au Go transité) : mauvaise surprise sur le budget.

📐 Réf. CAF/WAF — Security pillar (WAF service guide Virtual WAN) : pour le P2S, privilégier l'auth Entra ID (Conditional Access, MFA, device compliance) ; déployer un secured hub avec routing intent internet pour l'inspection sortante, et router les logs (Tunnel/Gateway/Route) vers Log Analytics. Lien

DEMO — chemins portail

1. DEMO — Configurer Virtual WAN & Hub

Étape 1 — Créer le Virtual WAN :

Home > Virtual WANs > + Create

• Basics :
  • Subscription, Resource Group, Region (région du vWAN object, peu importe car global)
  • Name : vwan-corp
  • Type : Standard (Basic = limité S2S only)
• Review + create

Étape 2 — Créer le Virtual Hub :

Virtual WAN > Hubs > + New hub

• Basics :
  • Region : West Europe (région du hub)
  • Name : hub-weu
  • Hub private address space : 10.100.0.0/23 (utilisé par MS pour les ressources internes du hub — pas d'overlap avec les VNets spoke)
  • Virtual hub capacity : 2 Routing Infrastructure Units (default) → suffit pour ~25 VNets
• Site to site (VPN gateway) : (optionnel à cette étape, à activer si besoin S2S)
  • Scale units VPN : ex 1
• Point to site (User VPN) : (optionnel)
• ExpressRoute : (optionnel)
• Routing Preference : ExpressRoute (par défaut) / VPN / AS Path
• Review + create

⏱️ Création du hub = 20-30 min.

2. DEMO — Connecter 2 VNets au Hub

Prérequis : 2 VNets créés (spoke1-vnet 10.1.0.0/16, spoke2-vnet 10.2.0.0/16), chacun avec une VM dedans.

Virtual WAN > Virtual network connections > + Add connection

Pour chaque VNet :

• Connection name : spoke1-to-hub
• Hubs : hub-weu
• Virtual network : spoke1-vnet
• Propagate to none : Non (laisser tout par défaut)
• Route Table : Default (par défaut)
• Add

Idem pour spoke2-to-hub.

Test : VM dans spoke1 ping VM dans spoke2 → ✅ marche (transit automatique via le hub, propagation par défaut → la default route table contient les CIDRs des 2 spokes). Le hub se charge du routage par défaut, donc les deux VMs communiquent sans configuration supplémentaire.

3. DEMO — Customize Routing for Hub Connections

Objectif : spoke3 doit voir seulement spoke1, et spoke1 doit savoir parler à spoke3.

Prérequis : VNet spoke3-vnet 10.3.0.0/16 créé avec une VM.

Étape 1 — Créer la custom Route Table :

Virtual Hub > Route Tables > + Create route table

• Name : spoke3-rt
• Labels : (vide pour cette démo)
• Routes :
  • + Add route :
    • Route name : to-spoke1
    • Destination type : CIDR
    • Destination prefix : 10.1.0.0/16 (CIDR de spoke1)
    • Next hop type : Virtual network connection
    • Next hop : spoke1-to-hub

Étape 2 — Connecter spoke3 au hub avec la route table custom :

Virtual WAN > Virtual network connections > + Add

• Connection name : spoke3-to-hub
• Virtual network : spoke3-vnet
• Routing Configuration :
  • Associate Route Table : spoke3-rt (spoke3 utilise CETTE table)
  • Propagate to Route Tables : None (spoke3 N'ANNONCE PAS son CIDR ailleurs)
  • Propagate to Labels : (vide)
• Add

Test 1 : ping spoke3 → spoke1 → ✅ marche (spoke3 connaît spoke1 via spoke3-rt) Test 2 : ping spoke3 → spoke2 → ❌ ne marche pas (spoke3 ne connaît pas spoke2) Test 3 : ping spoke1 → spoke3 → ❌ ne marche pas (spoke3 n'a pas propagé son CIDR à la default table → spoke1 ne sait pas que 10.3.0.0/16 existe)

Étape 3 — Faire connaître spoke3 à spoke1 (et spoke2) :

Virtual Hub > Route Tables > Default > + Add route :

• Route name : to-spoke3
• Destination type : CIDR
• Destination prefix : 10.3.0.0/16
• Next hop type : Virtual network connection
• Next hop : spoke3-to-hub

Test final : spoke1 ↔ spoke3 → ✅. spoke3 → spoke2 → ❌ (toujours). C'est l'isolation voulue.

💡 Alternative : au lieu d'ajouter une route statique manuelle, on aurait pu activer Propagate to Default sur spoke3 → spoke3 annoncerait son CIDR à la default table → spoke1 et spoke2 connaîtraient spoke3 automatiquement. Le choix dépend du niveau d'isolation voulu.

4. DEMO — Configure P2S VPN avec vWAN

Étape 1 — Créer une User VPN Configuration au niveau du vWAN (pas du hub) :

Virtual WAN > User VPN configurations > + Create user VPN config

• Name : userVpn-corp
• Tunnel type : OpenVPN (recommandé)
• Authentication type : Azure Active Directory (Entra ID) + entrer Tenant ID, Audience, Issuer (comme dans la fiche 6)

Étape 2 — Activer P2S sur le hub existant :

Virtual Hub > User VPN (Point-to-site) :

• Gateway scale units : 1 (500 Mbps, ~500 users)
• Address pool : 172.30.0.0/24
• User VPN configurations : userVpn-corp
• Save

Étape 3 — Télécharger le profil VPN client :

Virtual WAN > User VPN configurations > <userVpn-corp> > Download Virtual WAN user VPN profile

OU Virtual Hub > User VPN > Download VPN profile

Les 2 fonctionnent (le vWAN-level prend la config globale, le hub-level inclut les routes spécifiques au hub).

Étape 4 — Installer côté user :

Importer dans Azure VPN Client → Connect → login Entra → IP du pool → accès aux VNets connectés au hub.

💡 Avantage vWAN P2S : P2S se déploie sur plusieurs hubs (1 par région) avec la même User VPN Configuration → les users se connectent au hub le plus proche.

5. DEMO — Configurer NVA dans un Hub vWAN

Prérequis :

• Hub vWAN Standard
• User Assigned Managed Identity (mi-nva-fortinet) avec rôle Network Contributor sur la sub
• Subscription Fortinet dans Azure Marketplace (BYOL ou PAYG)

Étape 1 — Déployer la NVA dans le hub :

Virtual Hub > Network Virtual Appliance > Create Network Virtual Appliance

1. NVA Vendor : Fortinet (ou Cisco, Palo, etc.)
2. Plan : sélectionner offer (PAYG ou BYOL)
3. NVA Infrastructure Units : 2 (équivalent throughput)
4. Managed Identity : mi-nva-fortinet
5. Configurer vendor-specific settings (VLANs, IP ranges, etc.)
6. Create → provisioning ~30 min

Étape 2 — Activer Routing Intent avec la NVA en next hop :

⚠️ Préalable obligatoire : supprimer toutes les custom routes / route tables sur le hub avant d'activer Routing Intent.

Virtual Hub > Routing > Routing Intent and Routing Policies > + Configure

• Internet Traffic : Activé → Next hop = NVA
• Private Traffic : Activé → Next hop = NVA
• Save

Résultat :

• Tout le trafic privé inter-spoke passe par la NVA
• Tout le trafic Internet sortant passe par la NVA
• La NVA gère le filtrage selon ses propres règles

Résultat net : c'est désormais la NVA qui contrôle tout le trafic entre les spokes.

6. DEMO — Supprimer un Virtual WAN

Ordre de suppression (important — Azure refuse si dépendances) :

1. Supprimer toutes les connexions :
   • Virtual network connections
   • VPN connections (et VPN sites)
   • ExpressRoute circuit connections
   • User VPN configurations
2. Supprimer les NVAs dans le hub
3. Supprimer les Routing Intent (s'il y en a)
4. Désactiver les gateways du hub (S2S, P2S, ER)
5. Supprimer les Virtual Hubs (un par un, ~20 min chacun)
6. Enfin, supprimer le Virtual WAN

⏱️ Suppression d'un hub = 15-25 min. Patience.

⚠️ Ne pas supprimer le vWAN directement sans avoir vidé les hubs : erreur garantie.