5 — Site-to-Site VPN (S2S VPN)

Tunnel IPsec/IKE chiffré sur internet public → relie un site on-prem entier à un VNet Azure. L'option hybride la moins chère et la plus rapide à déployer.

A. Vue d'ensemble

S2S VPN = tunnel IPsec/IKE sur internet public qui connecte un site on-prem entier à un VNet Azure. C'est l'option hybride la moins chère, la plus rapide à déployer (vs ExpressRoute).

A.1 S2S vs P2S — quand choisir quoi ?

💡 Les 2 peuvent coexister sur la même VPN Gateway (S2S + P2S en parallèle).

A.2 S2S vs ExpressRoute

Combo prod critique : ER en primary + S2S VPN en backup BGP → 99.99% combiné (recommandé fintech, banque).

B. VPN Gateway (VNet Gateway type VPN)

Ressource Azure qui héberge le tunnel VPN du côté Azure. C'est un VNet Gateway de type VPN (≠ ExpressRoute).

B.1 Caractéristiques

• Déployée dans un subnet dédié GatewaySubnet :
  • Nom exact, sensible à la casse
  • /29 minimum mais MS recommande /27 (pour absorber les évolutions vers active-active, P2S, etc.)
• Public IP Standard obligatoire (frontend du tunnel) — 2 IPs si active-active
• 2 instances internes (active-standby ou active-active) — Azure gère, on ne voit pas les VMs sous-jacentes
• Création longue : 30-45 minutes

B.2 Local Network Gateway (LNG)

Objet Azure qui représente l'on-prem côté Azure.

Il contient :

• IP publique du VPN device on-prem (pour qu'Azure sache où établir le tunnel)
• Address space(s) du réseau on-prem (les plages IP à router via le tunnel)
• Optionnellement : ASN BGP + BGP peer IP si BGP activé

💡 N sites = N Local Network Gateways. Une seule VPN Gateway peut gérer plusieurs LNG (10-100 tunnels selon SKU).

B.3 Connection

Ressource Azure qui lie la VPN Gateway et le LNG :

• Type : Site-to-site (IPsec)
• Shared key (PSK) : passphrase identique des 2 côtés (Azure ↔ VPN device on-prem)
• BGP : on/off
• Custom IPsec/IKE policy : optionnel

C. Policy-based vs Route-based

C.1 Comment ça marche ?

• Policy-based : tu déclares traffic selectors (paire source-destination de CIDR) et chaque sélecteur ouvre un sous-tunnel. Statique, peu flexible.
• Route-based : Azure utilise sa route table système + UDR + BGP. Le tunnel forwarde tout ce qui matche les routes, dynamique.

C.2 Piège exam

🚨 Le type (policy vs route) est figé à la création de la VPN Gateway. Pas de conversion in-place possible. Si tu te trompes → delete + recreate.

Règle simple : Toujours créer en route-based sauf si tu as un vieux device on-prem qui ne supporte qu'IKEv1.

C.3 Policy-based traffic selectors

Si tu choisis route-based mais que ton on-prem ne supporte que des sélecteurs précis (policy-based selectors sur la connection), tu peux activer "Policy-based traffic selectors" sur la connection Route-based. Compromis pour interop avec des vieux devices.

D. SKUs

Référence officielle : VPN Gateway SKUs

D.1 SKUs à connaître pour AZ-700 (2026)

D.2 Ce que le SKU contrôle

• Throughput total (Mbps → Gbps)
• Nombre max de tunnels S2S (10 → 100)
• Nombre max de P2S users (~250 IKEv2, ~10 000 OpenVPN)
• Support BGP
• Support Active-Active
• Zone redundancy

⚠️ Generation1 vs Generation2 : VpnGw2AZ/3AZ ont un débit supérieur en Gen2 (1.25 / 2.5 Gbps). VpnGw4AZ et VpnGw5AZ n'existent qu'en Gen2. VpnGw1AZ est Gen1 only. ⚠️ SSTP plafonné à 128 connexions P2S simultanées quel que soit le SKU (les chiffres ci-dessus = OpenVPN/IKEv2).

💡 Choix typique : VpnGw2AZ couvre 80% des PME (1 Gbps + zone-redundant). VpnGw5AZ pour les très gros sites ou les concentrateurs P2S massifs.

E. BGP (Border Gateway Protocol)

E.1 Concept

BGP = protocole de routage dynamique qui permet aux 2 extrémités du tunnel d'échanger automatiquement leurs préfixes IP.

Sans BGP (static routing) :

• Côté Azure (LNG) : tu déclares manuellement les CIDR on-prem (ex 192.168.0.0/16)
• Côté on-prem : tu déclares manuellement les CIDR Azure (ex 10.0.0.0/16)
• Si l'on-prem ajoute un subnet → tu dois maj manuellement le LNG

Avec BGP (dynamic routing) :

• Les 2 côtés s'annoncent automatiquement leurs CIDR via le protocole BGP
• Si on-prem ajoute un subnet → propagé auto au LNG après quelques secondes
• Permet aussi le failover automatique entre plusieurs tunnels (active-active, ER+VPN combo)

E.2 Précision importante

⚠️ BGP n'auto-détecte PAS l'IP publique du device on-prem. L'IP publique reste toujours à déclarer dans le LNG. BGP gère uniquement la propagation des routes, pas la découverte des endpoints.

E.3 Comment activer BGP ?

1. Sur la VPN Gateway :

   • Virtual network gateway > Configuration > Configure BGP > Enabled
   • ASN Azure : 65515 par défaut (modifiable). ASN réservés interdits : publics 8074, 8075, 12076 + privés 65515, 65517, 65518, 65519, 65520 (réservés Azure), plus les plages IANA
   • BGP peer IP côté Azure : par défaut Azure assigne automatiquement une IP depuis le GatewaySubnet (1 IP en active-standby, 2 en active-active). Une APIPA 169.254.X.X n'est utilisée que si le device on-prem l'exige (plage stricte autorisée : 169.254.21.0–169.254.22.255)

2. Sur le Local Network Gateway :

   • Local network gateway > Configuration > BGP settings
   • ASN on-prem : votre ASN, différent de l'ASN Azure (privé utilisable 64512-65514 ou 65521-65534 — les autres sont réservés Azure/IANA — ou public si vous en possédez un)
   • BGP peer IP : IP de votre routeur on-prem qui parle BGP (interne au LAN, pas internet)

3. Sur la Connection :

   • Connection > Configuration > Enable BGP > ON

4. Côté on-prem : configurer le routeur/firewall pour peerer avec le BGP peer IP côté Azure (pris dans le GatewaySubnet, ou APIPA 169.254.21.0–169.254.22.255 si applicable) et l'ASN Azure (65515 par défaut). ⚠️ Peerer avec l'IP publique de la gateway = erreur classique.

E.4 Cas où BGP est obligatoire / fortement recommandé

• Active-Active : BGP simplifie le load balancing entre les 2 tunnels
• ExpressRoute + VPN coexistence : pour le failover dynamique
• Plusieurs sites on-prem avec routes complexes (hub-spoke on-prem)
• Multi-tunnel S2S avec route convergence

F. Active-Active vs Active-Standby

F.1 Architecture sous-jacente

Une VPN Gateway = 2 instances VM déployées par Azure dans le GatewaySubnet. Elles ne sont pas visibles, c'est managé. En mode active-standby (par défaut), une seule instance est active et l'autre reste en standby ; en active-active, les deux instances sont actives simultanément.

F.2 Active-Active — comment ça marche

• 2 Public IPs distinctes (une par instance)
• 2 tunnels S2S établis simultanément depuis le device on-prem
• Côté on-prem : le device doit pouvoir gérer 2 tunnels avec ECMP (Equal-Cost Multi-Path) ou BGP load balancing
• BGP fortement recommandé : permet aux 2 tunnels de répartir la charge automatiquement

F.3 Quand l'activer ?

• Production critique : pas de window de failover, les 2 chemins servent
• Bandwidth max : doubler la capacité du SKU sans monter en SKU
• HA renforcée : si une zone Azure tombe, l'autre tunnel reste UP (avec SKU AZ)

F.4 Limitations

• ❌ Basic SKU ne supporte pas Active-Active
• ❌ Policy-based ne supporte pas Active-Active (route-based obligatoire)
• Le device on-prem doit supporter multi-tunnel + idéalement BGP/ECMP

G. AZ Redundancy

Les SKUs AZ (VpnGw1AZ-5AZ) déploient les 2 instances de la VPN Gateway dans 2 zones différentes de la région (si la région a des AZ). Si une zone tombe, l'autre instance prend le relais.

G.1 Public IPs et zones

• Public IP Standard zone-redundant : recommandée — l'IP est active dans les 3 zones simultanément, résiste à une zone qui tombe
• Public IP Standard zonal (zone 1, 2 ou 3) : OK si tu veux pinner ta gateway sur une zone précise
• ❌ Public IP Basic : retirée (sept 2025). À noter : le VPN Gateway Basic SKU lui-même n'est PAS retiré, mais il ne supporte que des Public IP Basic et n'est créable que via PowerShell/CLI

G.2 Config

• Au moment de créer la VPN Gateway → choisir SKU AZ (ex VpnGw2AZ)
• Pour les Public IPs : créer en Zone-redundant (recommandé) ou Zonal selon besoin
• Pour Active-Active : 2 IPs, idéalement les 2 zone-redundant

H. Custom IPsec / IKE Policies

H.1 Pourquoi customiser ?

• Hardware on-prem ancien qui ne supporte pas les algorithmes modernes (DH Group 14+, SHA256, AES256)
• Compliance / security team : algorithmes imposés (ex banques imposent SHA384, FIPS 140-2)
• Interopérabilité : matcher exactement la config du device partenaire
• Performance tuning : préférer AES-GCM pour offload hardware

H.2 Paramètres modifiables

H.3 Modifier la policy piège

🚨 Le custom IPsec policy doit être identique des 2 côtés (Azure ET on-prem). Si tu modifies un seul côté → tunnel down.

Procédure correcte :

1. Préparer la nouvelle config IPsec
2. Sur Azure : Connection > Configuration > IPsec/IKE policy > Custom > apply
3. Immédiatement sur le device on-prem : matcher la même config
4. Tunnel re-établi avec la nouvelle policy

I. Azure Extended Network

Objectif AZ-700 : "Implement Azure Extended Network". Feature niche mais listée — à connaître au moins conceptuellement.

Concept

Azure Extended Network (nom officiel : extended network for Azure) permet d'étendre un sous-réseau on-prem dans Azure : une VM peut garder la même IP privée que sur le réseau on-prem (le subnet est "stretched" — le même CIDR existe des 2 côtés, Azure et on-prem). Utile pour migrer des apps legacy avec IP figée (hard-codée, licences liées à l'IP, dépendances/DNS qui ne supportent pas un changement d'adresse) sans re-adresser ni reconfigurer l'app.

📌 Le scénario exam typique : une VM Hyper-V on-prem est migrée vers Azure et doit conserver exactement la même adresse IP. La marche à suivre cite « installer Windows Server + un agent » sur des appliances → c'est Azure Extended Network. Le mot-clé qui tranche = garder la même IP lors de la migration.

Comment ça marche

• Repose sur une paire de VMs appliances Windows Server (rôle Hyper-V activé / nested virtualization), une de chaque côté, pilotées par Windows Admin Center (WAC) :
  • 1 appliance on-prem : Windows Server 2019 ou 2022 (sur tout hyperviseur supportant la nested virtualization ; recommandé en cluster HA)
  • 1 appliance dans Azure : Windows Server 2022 Azure Edition obligatoire (la liste WAC ne propose QUE des VMs Azure Edition)
• Chaque appliance a 2 cartes réseau : une sur le subnet routable (lien VPN/ER), une sur le subnet étendu. On crée 2 vSwitch externes (External + Extended).
• Les 2 appliances établissent un tunnel VXLAN bidirectionnel (par défaut UDP 4789) par-dessus une connectivité existante (S2S VPN ou ExpressRoute — prérequis).
• Résultat : une VM migrée vers Azure garde son IP ; capacité jusqu'à 250 adresses IP étendues, ~700 Mbps de débit agrégé (variable selon le CPU des appliances).

Rôle de l'agent et de WAC

• Le déploiement se fait entièrement via Windows Admin Center : on installe l'extension « Extended network » (id msft.sme.subnet-stretch), on connecte WAC à Azure, puis le wizard Set up.
• Pendant le setup, on télécharge le « extended network for Azure agent package » et on l'uploade sur chaque appliance → c'est l'agent évoqué dans la question d'examen. Côté OS il tourne comme service Windows extnwagent (get-service extnwagent).
• La sélection des IP à étendre (jusqu'à 250) se fait dans WAC (Add IPv4 Addresses : ajout manuel ou découverte auto par scan). Pas de fichier de config à éditer à la main — tout passe par WAC.

Distinction à NE PAS rater : Extended Network ≠ migration de la VM

💡 Les deux sont complémentaires : Azure Migrate déplace la VM, Extended Network fait en sorte qu'elle retrouve son IP une fois dans Azure. La question « installer Windows Server + agent pour garder l'IP » vise Extended Network, pas Azure Migrate.

Quand l'utiliser

• Migration lift-and-shift d'apps legacy à IP statique non modifiable
• Période de coexistence / migration progressive (phased migration) : certaines VMs restent on-prem, d'autres passent dans Azure mais partagent le même subnet/IP range
• ❌ Pas une solution permanente : MS insiste — c'est un pont de migration. Si l'IP peut changer, mieux vaut re-adresser et brancher sur un subnet purement Azure.

Prérequis / limites

• Connectivité S2S VPN ou ExpressRoute déjà établie (virtual network gateway en place)
• VNet Azure avec ≥ 2 subnets dont un au même CIDR que le subnet on-prem à étendre (subnet unique dans le routing domain, pas de chevauchement)
• 2 appliances Windows Server (2019/2022 on-prem, 2022 Azure Edition dans Azure) avec Hyper-V + l'agent Extended Network
• Si firewall entre on-prem et Azure : autoriser le routage asymétrique (désactiver la randomisation des numéros de séquence, activer TCP state bypass) et laisser passer l'UDP 4789 (VXLAN) dans les 2 sens

💡 À l'examen : retenir Extended Network = garder la même IP on-prem dans Azure (subnet stretch via VXLAN sur VPN/ER, piloté par WAC, 2 appliances Windows Server + agent), pour migrer des apps à IP figée. Ne pas confondre avec : le peering (connecte des VNets distincts), le VPN (connecte des réseaux distincts à IPs différentes), ni Azure Migrate (migre la VM, ne stretch pas le réseau).

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

Scenario 1 : ETI multi-sites — 8 filiales connectées en S2S BGP

Contexte business : ETI industrielle, siège à Paris + 7 filiales. L'ERP passe dans Azure, chaque site doit y accéder en privé. ExpressRoute serait trop cher pour 7 petits sites. Choix architectural : une VPN Gateway VpnGw2AZ (route-based) avec BGP, 1 Local Network Gateway par site, et mode Active-Active au siège. Réglages IPsec calés sur les boîtiers Fortigate déjà en place. Architecture / pattern :

• VNet hub 10.0.0.0/16 + GatewaySubnet /27, VPN Gateway VpnGw2AZ en Active-Active (2 IP publiques zone-redundant).
• 8 Local Network Gateways (1 par site) + 8 connexions IPsec.
• BGP activé sur chaque connexion : les routes des sites arrivent toutes seules. Un site ajoute un subnet ? Azure le voit automatiquement.
• IPsec custom AES256 + SHA256 + DH Group 14, identique au profil Fortigate.
• Les spokes (apps, data, monitoring) sont peerés au hub avec Use remote gateways = ON. Trade-offs assumés :
• Gain : connectivité hybride multi-site à bas coût, routes propagées automatiquement par BGP.
• Perte : débit/latence VPN inférieurs à ExpressRoute, dépendance aux liens internet des sites. Pièges à éviter :
• Routes statiques au lieu de BGP : dès qu'un site ajoute un subnet, on oublie de l'ajouter côté Azure. BGP est obligatoire en multi-site.
• Active-Active mais device on-prem mono-tunnel : la 2e IP ne sert à rien, le débit n'est pas doublé.
• Vouloir une IP publique zone-redundant avec un SKU Basic : impossible, il faut un SKU AZ.
• LNG pointant vers une IP on-prem qui change (box grand public) : le tunnel tombe à chaque changement. Sans IP fixe, utiliser un FQDN DNS dynamique (DDNS), supporté par le LNG.

📐 Réf. CAF/WAF — Network topology and connectivity (traditional hub-and-spoke, multi-site VPN) : le hub-and-spoke traditionnel est recommandé quand la connectivité hybride principale est le VPN avec moins de 100 connexions par VPN Gateway, les spokes joignant un hub régional via peering. Lien

Scenario 2 : Banque retail — ER primary + S2S VPN backup

Contexte business : banque française avec ExpressRoute en prod vers Azure (datacenter Paris). La compliance bancaire (rapport ACPR) impose un chemin de secours si l'ER tombe. Budget OK pour doubler. Choix architectural : ExpressRoute Gateway en principal + VPN Gateway VpnGw3AZ en secours, dans le même VNet hub. BGP partout pour basculer tout seul. Architecture / pattern :

• VNet hub avec GatewaySubnet /25 (plus grand car il doit loger ER GW + VPN GW + active-active).
• ExpressRoute Gateway principale (ErGw2AZ) branchée sur le circuit ER.
• VPN Gateway de secours (VpnGw3AZ, route-based, BGP activé).
• Côté Azure, le BGP préfère l'ER au VPN.
• Côté on-prem, on annonce les mêmes préfixes mais avec AS Path prepending sur le VPN, pour qu'il soit naturellement moins prioritaire.
• Si l'ER tombe : BGP le détecte (10 s avec BFD) et bascule tout seul sur le VPN. Trade-offs assumés :
• Gain : chemin de secours conforme ACPR, bascule automatique sans intervention.
• Perte : coût doublé (deux gateways) et GatewaySubnet plus large à provisionner. Pièges à éviter :
• GatewaySubnet /27 : trop petit pour ER GW + VPN GW + active-active. /25 recommandé en coexistence.
• VPN en SKU Basic : ne coexiste pas avec l'ER. Minimum VpnGw1AZ.
• BGP désactivé sur le VPN : plus de bascule automatique, il faut intervenir à la main (UDR ou reroute).
• Tester le failover une seule fois par an : un plan de secours non testé est invalide. Faire des tests trimestriels en pré-prod.

📐 Réf. CAF/WAF — Connectivity to Azure (ExpressRoute primary + VPN backup) : utiliser ExpressRoute comme canal de connectivité principal et le VPN S2S comme source de connectivité de secours, en optimisant le routage via BGP local preference et AS-PATH prepending. Lien

Scenario 3 : Startup SaaS — VPN GW minimal pour dev/test

Contexte business : startup SaaS B2B (15 personnes), accès dev/test au cloud depuis le bureau. Pas encore de prod sur Azure. Budget serré, 1 seul ops. Choix architectural : VPN Gateway Basic (la moins chère), en policy-based si le device on-prem ne fait que de l'IKEv1 (vieux pfSense). Architecture / pattern :

• VNet dev 10.1.0.0/16 + GatewaySubnet /29 (le minimum imposé par le Basic).
• VPN Gateway Basic (~25 $/mois contre ~140 $/mois pour VpnGw1AZ).
• Policy-based + IKEv1 si le device est ancien, sinon Route-based + IKEv2.
• Pas de BGP, pas de zone-redundancy, pas d'active-active : le Basic ne les gère pas. Trade-offs assumés :
• Gain : coût minimal adapté au dev/test (~25 $/mois).
• Perte : pas de BGP ni de redondance, migration impossible sans suppression/recréation (coupure). Pièges à éviter :
• Vouloir passer en prod avec un Basic : impossible de migrer Basic vers un SKU AZ sans supprimer + recréer (coupure). Si la prod arrive dans moins de 6 mois, partir direct en VpnGw1AZ.
• Compter sur BGP plus tard : le Basic ne le fait pas, il faudra migrer.
• Partager le PSK en clair sur Slack : risque de fuite. Le stocker dans Key Vault, même en dev.
• Oublier d'éteindre la GW la nuit/le week-end : ~25 $ x 365 j = 9k $/an pour 8h/jour d'usage. Une VPN GW ne s'arrête pas, il faut la supprimer puis la recréer (compromis dev/test).

📐 Réf. CAF/WAF — Reliability in Azure virtual network gateways (choix du mode/SKU) : le mode active-standby (par défaut, sans redondance de zone) convient au dev/test, mais pour toute exigence de disponibilité réelle utiliser une IP publique Standard et viser un SKU AZ — d'où l'intérêt de démarrer directement en VpnGw1AZ si la prod approche. Lien

DEMO — chemins portail

1. DEMO — Connecter 2 VNets via S2S VPN (simulation lab on-prem)

Setup lab : 2 VNets dans Azure. VNET-A simule Azure, VNET-B simule l'on-prem (car pas de vrai datacenter sous la main).

Prérequis :

• VNET-A : 10.0.0.0/16 avec GatewaySubnet 10.0.255.0/27
• VNET-B : 192.168.0.0/16 avec GatewaySubnet 192.168.255.0/27

Étape 1 — Créer VPN Gateway A :

Home > Virtual network gateways > + Create

1. Basics :
   • Name : vpngw-A
   • Gateway type : VPN
   • VPN type : Route-based
   • SKU : VpnGw2AZ
   • Generation : Generation2
2. Virtual network : sélectionner VNET-A → Azure utilise le GatewaySubnet créé
3. Public IP : créer pip-vpngw-A (Standard, Zone-redundant)
4. Active-Active : laissé OFF pour cette démo simple
5. BGP : OFF pour démo (ON dans demo BGP)
6. Review + create

⏱️ Déploiement = 30-45 min. Lance les 2 VPN GW en parallèle.

Étape 2 — Créer VPN Gateway B (sur VNET-B) — même process.

Étape 3 — Créer Local Network Gateway de chaque côté :

Home > Local network gateways > + Create

LNG-pour-A (représente le "remote" vu depuis VNET-A — donc décrit VNET-B) :

• Name : lng-representing-B
• Endpoint type : IP address
• IP address : IP publique de vpngw-B (la VPN GW d'en face)
• Address space : 192.168.0.0/16 (les CIDR du VNET-B)

LNG-pour-B (représente le "remote" vu depuis VNET-B — donc décrit VNET-A) — miroir :

• IP : Public IP de vpngw-A
• Address space : 10.0.0.0/16

Étape 4 — Créer la Connection sur VPN GW A :

Virtual network gateway A > Connections > + Add

• Name : cn-A-to-B
• Connection type : Site-to-site (IPSec)
• Virtual network gateway : vpngw-A (auto)
• Local network gateway : lng-representing-B
• Shared key (PSK) : MySharedSecret123! (noter, à réutiliser de l'autre côté)
• IKE Protocol : IKEv2
• BGP : OFF
• IPsec/IKE policy : Default (Microsoft optimisé)

Étape 5 — Créer la Connection sur VPN GW B (miroir) :

• Name : cn-B-to-A
• Local network gateway : lng-representing-A
• Même Shared key que côté A (MySharedSecret123!)
• Même IKE protocol et policy

Étape 6 — Vérifier :

Connections > <cn-A-to-B> > Overview → Status: Connected ✅

Tester : VM dans VNET-A pingue une VM dans VNET-B → OK si le ping est autorisé par NSG.

2. Cas réel avec on-prem (équivalent à la démo lab)

Setup réel :

• VNet Azure : 10.0.0.0/16 + GatewaySubnet 10.0.255.0/27
• Onprem : VPN device (Cisco ASA, Fortigate, pfSense, Palo Alto, MikroTik, etc.) avec IP publique fixe 203.0.113.10 et LAN 192.168.1.0/24

Coté Azure :

1. VPN Gateway vpngw-prod (VpnGw2AZ, Route-based)
2. Public IP Standard pip-vpngw-prod → Azure assigne 52.X.X.X
3. Local Network Gateway lng-onprem-hq :
   • IP : 203.0.113.10 (IP pub du device on-prem)
   • Address space : 192.168.1.0/24
4. Connection cn-azure-to-onprem avec PSK OnpremCorpKey2026!

Coté on-prem (exemple Fortigate) :

config vpn ipsec phase1-interface
  edit "azure-tunnel"
    set interface "wan1"
    set ike-version 2
    set remote-gw 52.X.X.X        # IP publique de vpngw-prod côté Azure
    set psksecret OnpremCorpKey2026!
    set proposal aes256-sha256
    set dhgrp 14
  end

config vpn ipsec phase2-interface
  edit "azure-tunnel-p2"
    set phase1name "azure-tunnel"
    set proposal aes256-sha256
    set src-subnet 192.168.1.0/24
    set dst-subnet 10.0.0.0/16
  end

Coté on-prem (équivalent autre vendor) :

• Cisco ASA : crypto map, tunnel-group, crypto isakmp
• pfSense : Section IPsec, ajouter Phase 1 + Phase 2
• MikroTik : /ip ipsec peer, /ip ipsec policy

Test côté Azure : Connection > Status: Connected quand le device on-prem établit le tunnel.

3. DEMO — S2S VPN Troubleshooting

Healthprobe URLs

Azure expose des probes HTTPS sur certains ports de l'IP publique de la VPN Gateway pour vérifier la santé interne :

Réponse attendue : 200 OK avec un payload XML simple → la gateway est UP côté Azure.

Si erreur 5XX ou timeout : problème côté Azure GW → ticket support MS, pas la peine de debugger le device on-prem.

Diagnostic Logging

À activer dès le début du déploiement : créer un Storage Account (ou Log Analytics Workspace), puis configurer les Diagnostic settings de la VPN Gateway depuis Monitor.

Étape 1 — Créer un Storage Account (ou Log Analytics Workspace selon préférence) :

• Storage accounts > + Create > Standard LRS

Étape 2 — Activer Diagnostic Settings sur la VPN GW :

VPN Gateway > Monitoring > Diagnostic settings > + Add diagnostic setting

• Name : vpngw-diag
• Logs to collect : cocher toutes les catégories importantes ↓
• Destination :
  • Archive to a storage account → sélectionner le Storage Account
  • OU Send to Log Analytics workspace (recommandé pour query)

Catégories de logs

Cas pratique : tunnel down → regarder TunnelDiagnosticLog d'abord, puis IKEDiagnosticLog pour identifier l'étape où ça fail.

Reset de la VPN Gateway

VPN Gateway > Help > Reset :

• Reset la gateway → redémarre l'instance active interne
• Downtime : 30s à 1 min
• Quand l'utiliser : tunnel "stuck" en Connecting/Disconnected sans raison apparente, après des changements de PSK ou IPsec policy

⚠️ Ne pas confondre avec Connection > Reset : qui ne reset que le tunnel, pas la gateway → plus light, à essayer en premier.

VPN Troubleshoot (Network Watcher)

Network Watcher > VPN Troubleshoot

• Diagnostic automatique sur une VPN Gateway ou Connection
• Lance des tests : santé GW, état tunnel, BGP, statistiques
• Génère un rapport téléchargeable (logs + recommandations) → utile pour les tickets support MS

4. DEMO — Configure S2S VPN avec Custom IPSec Policy

Reprend la démo I.1 où le tunnel est déjà UP.

Coté Azure (portail) :

Connection > <cn-A-to-B> > Configuration > IPsec / IKE policy > Custom

Paramétrer (exemple algorithmes modernes) :

• IKE Phase 1 : AES256 + SHA256 + DH Group 14
• IKE Phase 2 : AES256 + SHA256 + PFS Group 14
• SA lifetime : 3600 sec
• SA size : 102400000 KB

Save → la connection passe en Disconnected temporairement (tunnel renégocié).

Coté on-prem (ou autre VPN GW dans le lab) : appliquer strictement les mêmes valeurs. Sinon tunnel reste down.

⚠️ Policy-based traffic selectors : option à activer si l'on-prem ne supporte que des sélecteurs IP fixes (ancienne génération de devices). Permet de garder le tunnel route-based côté Azure mais en mode sélecteurs précis côté on-prem.

5. DEMO — Explore Active-Active S2S VPN

Coté Azure :

VPN Gateway > Configuration

• Active-active mode : Enabled
• Second public IP : créer ou sélectionner pip-vpngw-A-2 (Standard, Zone-redundant)
• Save

⚠️ Pas supporté en SKU Basic.

Après le save (10-15 min de reconfig), la GW est active-active : 2 instances actives, 2 IPs publiques distinctes.

Coté on-prem : il faut configurer le device pour établir 2 tunnels IPsec (un par IP publique Azure), idéalement avec BGP pour le load balancing automatique.

Coté Connection : tu peux créer 2 Connections séparées (une par IP) ou laisser Azure gérer automatiquement.

Tester : depuis on-prem, traceroute vers Azure → tu vois alternativement les 2 IPs publiques. Charge équilibrée.