6 — Point-to-Site VPN (P2S VPN)

Tunnel chiffré entre un utilisateur individuel (laptop, via client VPN) et un VNet Azure → l'accès distant pour les télétravailleurs et sous-traitants, un endpoint à la fois.

A. Vue d'ensemble

P2S VPN = tunnel chiffré entre un user individuel (laptop, mobile) et un VNet Azure. Pas de tunnel de site à site, on parle endusers / télétravailleurs / sous-traitants.

A.1 Différence avec S2S

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

A.2 Quand choisir P2S plutôt que S2S ?

• Users distribués sans LAN central → P2S
• Télétravail : laptop d'un employé chez lui → P2S
• Audit ou sous-traitant ponctuel → P2S (auth Entra ID, révocation rapide)
• Pas de hardware on-prem disponible → P2S (S2S nécessite un device)

B. VPN Gateway pour P2S

B.1 Caractéristiques

• Type : VPN
• VPN type : Route-based obligatoire (policy-based ne supporte PAS P2S)
• SKU : VpnGw1AZ minimum (Basic ne supporte pas OpenVPN ni P2S Entra/RADIUS)
• GatewaySubnet /27 minimum (P2S Address Pool s'ajoute aux besoins)
• Public IP Standard (Static)

B.2 Pas de Local Network Gateway

Avec P2S, pas de LNG ni de Connection. Tout est configuré directement sur la section P2S de la VPN Gateway :

• Address Pool
• Tunnel type
• Authentication method
• VPN Client config à télécharger

C. Tunnel Types

C.1 OpenVPN (recommandé)

• SSL/TLS sur TCP 443 → passe les firewalls / proxies / NAT sans souci
• Cross-platform : tous les OS, tous les mobiles
• Recommandé par défaut pour les nouveaux déploiements
• Supporte les 3 méthodes d'auth (Cert, Entra ID, RADIUS)

C.2 IKEv2

• IPsec UDP 500 + 4500 → bloqué par certains firewalls/proxies
• Standard du marché (intégré natif iOS, Mac, Windows)
• Performant en LAN/réseau ouvert, problématique derrière NAT strict
• Supporte Cert et RADIUS, pas Entra ID

C.3 SSTP

• TLS sur TCP 443 → passe les firewalls
• Windows only (legacy, intégré au système)
• Limite : 128 connexions max simultanées quel que soit le SKU (limite historique)
• 🚨 SSTP en cours de retraite (2 jalons) : 31 mars 2026 → activer SSTP sur une GW n'est plus supporté ; 31 mars 2027 → les connexions SSTP existantes sont suspendues et cessent de fonctionner → migrer vers OpenVPN ou IKEv2
• Use case rare aujourd'hui (OpenVPN sur Windows fait pareil sans la limite)

C.4 Combo possible

Plusieurs tunnel types peuvent être activés simultanément sur la même VPN GW → chaque client utilise celui qui marche le mieux selon sa plateforme. Le plus courant : OpenVPN + IKEv2 combinés.

D. Authentication Methods

D.1 Vue d'ensemble

D.2 Tableau de compatibilité Tunnel × Auth

🚨 Entra ID auth = OpenVPN uniquement. Pour du SSO/MFA Entra → forcément OpenVPN.

D.3 Azure Certificate Auth — théorie

Concept Certificate Authority (CA)

Une CA est une entité qui émet des certificats et qui est trustée par les systèmes qui vérifient ces certificats.

Hiérarchie typique :

• Root CA : certificat racine, auto-signé, en haut de la chaîne
• Intermediate CA : certs signés par la Root, plus opérationnels
• End-entity (client) cert : signé par la Root ou Intermediate, utilisé pour s'authentifier

Chaîne de confiance :

• Quand un client présente un certificat client à Azure, Azure regarde qui l'a signé (parent dans la chaîne)
• Si la signature remonte jusqu'à une Root CA dont Azure a la clé publique → trust → OK
• Sinon → rejet

Auto-signé pour le lab

Pour un POC P2S :

• On crée un self-signed root cert (pas de CA externe, on fait nous-mêmes)
• On crée un client cert signé par ce root
• On upload la clé publique du root à Azure
• On installe le client cert (avec clé privée) sur le PC user

Quand l'user se connecte :

1. Le client présente son cert client à Azure
2. Azure vérifie la signature → remonte au root
3. Azure compare au root upload → match → ✅

En prod : utiliser une vraie CA

• CA interne entreprise (AD CS, EJBCA…) avec hiérarchie root + intermediate
• CA publique (DigiCert, Let's Encrypt, GlobalSign) — moins courant pour auth client
• Le root cert (CA d'entreprise) est uploadé une fois, ensuite tous les certs émis par cette CA sont trustés automatiquement par Azure

D.4 Revoked certificates

Problème : un user quitte la société, son cert client est encore valide → il peut encore se connecter au VPN. Mauvais.

Solution : liste de révocation côté Azure.

VPN Gateway > Point-to-site configuration > Revoked certificates

• Ajouter le thumbprint du cert à révoquer
• Au prochain login, Azure refuse la connexion (même si cert encore valide cryptographiquement)

💡 En entreprise avec CA interne → utiliser CRL (Certificate Revocation List) ou OCSP publiés par la CA, pas la liste manuelle Azure.

E. Address Pool

L'Address Pool se configure dans Point-to-site configuration de la VPN Gateway. C'est une plage CIDR d'IPs que Azure distribue aux clients VPN quand ils se connectent.

Exemple : pool 172.16.0.0/24 → 256 IPs allouables à 256 users simultanés.

E.1 Règles importantes

• Pas d'overlap avec :
  • L'address space du VNet Azure
  • L'address space on-prem (sinon retour de paquet impossible)
• Suffisamment large pour le nombre de users simultanés attendus
• Une IP attribuée tient la durée de la connexion (libérée après déconnexion)

E.2 Routes additionnelles (advertised routes)

Par défaut, le client VPN reçoit les routes vers les CIDR du VNet Azure + ses peerings.

Pour qu'un client puisse aussi atteindre :

• Un site on-prem via S2S transit (le VPN GW relaie)
• Un VNet en cross-region peering
• Un IP range externe spécifique

→ on les ajoute dans Additional routes to advertise. Le client VPN reçoit ces routes en plus → son trafic vers ces IPs passe par le tunnel VPN au lieu d'Internet direct.

Cas typique : forced tunneling P2S → ajouter 0.0.0.0/0 aux routes annoncées → tout le trafic du client passe par Azure (filtré, loggé).

F. Always-On VPN

Fonctionnalité Windows non spécifique à Azure, mais à connaître pour l'examen.

F.1 Concept

Avec un P2S classique, l'user doit cliquer manuellement sur "Connect" dans le VPN Client. Always-On automatise ça → le VPN est établi avant ou dès que l'user se connecte à Windows.

F.2 2 types de tunnels

Les 2 peuvent coexister (Device + User Tunnel actifs en même temps).

F.3 Setup

Always-On nécessite :

• P2S VPN configuré sur VPN GW Azure (côté Azure : pas de différence)
• Cert-based authentication (Always-On ne supporte pas Entra ID auth pour le device tunnel)
• Windows VPN Profile déployé sur les PCs : XML config qui inclut <AlwaysOn>true</AlwaysOn>

<VPNProfile>
  <AlwaysOn>true</AlwaysOn>
  <NativeProfile>
    <Servers>azure-vpn-gateway.fqdn.com</Servers>
    <NativeProtocolType>Automatic</NativeProtocolType>
    ...
  </NativeProfile>
</VPNProfile>

F.4 Trigger conditions

Le profil peut spécifier des trigger automatiques (au-delà du "always always") :

• Network connection : VPN s'établit quand le PC quitte le LAN corp et se connecte à un Wi-Fi externe
• DNS suffix : si le PC perd le DNS interne corp.local, déclenche le VPN
• Application launch : VPN s'établit quand une app spécifique se lance (ex : Outlook, Teams, RDP client)

Déploiement : profil pushé via Intune (MDM) ou PowerShell Add-VpnConnection + Group Policy.

G. Azure Network Adapter (ANA)

G.1 Concept

ANA = mécanisme pour transformer un Windows Server en client P2S VPN automatiquement, géré par Windows Admin Center (WAC).

Au lieu d'installer manuellement le VPN client + cert + config sur chaque serveur Windows on-prem qui veut accéder à Azure, WAC déploie ANA qui s'occupe de tout.

G.2 Use case

• Hybrid Windows Servers : 50 serveurs Windows on-prem qui doivent atteindre Azure pour services managés (Azure Files, Backup, etc.)
• Pas de S2S VPN ou ER disponible : trop cher ou setup réseau impossible
• Setup individuel par serveur souhaité (chaque serveur a son propre tunnel)

G.3 Architecture

ON-PREM                                  AZURE
┌──────────────────┐                    ┌───────────────────┐
│ Windows Server   │                    │ VNet Azure         │
│ + Azure Network ─┼─── P2S OpenVPN ───►│ + VPN Gateway     │
│   Adapter        │                    │   (P2S configured) │
└──────────────────┘                    │                   │
                                        │ + Azure Files,    │
                                        │   Storage, etc.   │
                                        └───────────────────┘

WAC pilote l'install/config d'ANA sur chaque serveur Windows.

G.4 Implémentation

1. VPN Gateway Azure déployée, route-based, P2S avec Certificate Auth (ANA exige cert)
2. Windows Admin Center installé (on-prem ou hub Azure)
3. Ajouter le Windows Server cible dans WAC
4. Add Azure Network Adapter dans WAC :
   • Sélectionne la sub Azure + VPN GW
   • WAC génère un cert client + l'installe sur le serveur
   • WAC télécharge le VPN profile + configure ANA
5. Le serveur Windows a maintenant un adapter "Azure VPN" qui s'auto-connecte au démarrage

G.5 Avantages

• Pas de S2S VPN ou ER à déployer (économie)
• Granularité par serveur : chaque serveur a son propre tunnel et son cert (révocable individuellement)
• Setup automatisé via WAC, scale propre

G.6 Limitations

• Cert-based auth uniquement (pas Entra/RADIUS)
• Windows Server uniquement (pas Linux)
• WAC requis (overhead managérial)

H. Re-download du client après changement de topologie piège exam

🚨 Piège AZ-700 classique : toute modification de la topologie du VNet (ajout d'un peering, gateway transit, nouveau subnet routé, ajout d'une route advertised) laisse le profil VPN client existant sans connaissance des nouvelles routes.

Action : VPN Gateway > Point-to-site configuration > Download VPN client + ré-installer le profil sur les postes user.

Pas besoin de :

• Redémarrer la GW
• Toucher au gateway transit
• Modifier les credentials user

I. Diagnose & resolve client-side and authentication issues (P2S)

Checklist regroupée des erreurs P2S typiques côté client/auth (objectif officiel « Diagnose and resolve client-side and authentication issues »).

I.1 Certificat (cert auth)

• Chaîne incomplète / root non trusté → erreur « A certificate chain processed but terminated in a root certificate which is not trusted ». Le AzureClient.pfx doit être dans Current User\Personal\Certificates et le root dans Local Computer\Trusted Root Certification Authorities. ⚠️ Ne pas cocher Enable strong private key protection à l'import.
• Root cert non uploadé sur la GW (ou clé corrompue/expirée) → erreur « The message received was unexpected or badly formatted (0x80090326) ». Vérifier que le root est bien présent dans Point-to-site configuration, sinon le supprimer et le ré-uploader (data en une seule ligne, sans espace/retour ligne, sinon « Data for certificate is invalid »).
• Cert client absent → erreur « A certificate could not be found… (Error 798) » : le P2SChildCert (avec clé privée) doit être installé dans le Personal store du user.
• Cert client révoqué : thumbprint dans Point-to-site configuration > Revoked certificates → 🚨 révocation individuelle par cert (révoquer un root/intermediate ne révoque PAS automatiquement ses enfants).

I.2 Tunnel type mismatch

• Le tunnel type du client doit correspondre à celui activé sur la GW (OpenVPN / IKEv2 / SSTP). 🚨 Entra ID = OpenVPN uniquement ; un client IKEv2/SSTP ne s'authentifiera jamais via Entra. Re-générer le bon package client si besoin.

I.3 Profil client obsolète

• 🚨 Après tout changement de topologie/routes (peering, transit, route advertised) OU après un upgrade de GW (le cert serveur roule à >50 % de sa vie) → re-télécharger et ré-installer le VPN client config sur tous les postes, sinon déconnexions / routes manquantes.

I.4 Auth Microsoft Entra ID

• Audience / Issuer / Tenant erronés : Audience = App ID Azure VPN c632b3df-fb67-4d84-bdcf-b95ad541b5c8 (ou custom audience) ; Issuer = https://sts.windows.net/<tenantID>/ (💡 trailing slash obligatoire, sinon échec) ; Tenant = https://login.microsoftonline.com/<tenantID> (sans slash final).
• OpenVPN obligatoire + app Azure VPN présente dans le tenant (Enterprise applications). Custom audience → ajouter aussi applicationid dans le profil XML pour éviter les popups de re-login.
• Token expiré : « Your authentication with Microsoft Entra is expired » = refresh token expiré (90 j par défaut, ou sign-in frequency Conditional Access) ou invalidé (user retiré, sessions révoquées, device non conforme). Solution : se reconnecter (interactive sign-in). 💡 Debug via Entra sign-in logs.

I.5 RADIUS

• NPS injoignable : IP privée du NPS doit être routable depuis la GW (propagée à la GatewaySubnet). Ports RADIUS 1812/1813 ouverts.
• Secret partagé erroné → NPS Event ID 18 (message authenticator invalide) ; RADIUS client manquant → Event ID 13 (IP cliente invalide, déclarer la VPN GW comme RADIUS client). Network policy / credentials → Event ID 6273 (access denied : mauvais mot de passe, compte verrouillé, policy refusante).

I.6 Où lire les logs

• P2SDiagnosticLog : activité P2S (IKEv2 + OpenVPN uniquement), succès/échec d'auth, IP allouée.
• IKEDiagnosticLog : debug verbeux IKE/IPsec (utile pour échecs de connexion / déconnexions IKEv2).
• 💡 Network Watcher > VPN troubleshoot : diagnostic GW/connexion, dépose un zip de logs (IkeLogs.txt) dans un storage account (ex. « Authentication failed. Check shared key »).

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

Scenario 1 : ESN — 200 développeurs en télétravail

Contexte business : ESN française, ~200 devs en télétravail à 50%. Ils accèdent à des VMs de dev (Visual Studio, bases internes) hébergées dans Azure. Pas de boîtier VPN, ils sont sur laptops perso ou pro. Choix architectural : P2S OpenVPN + authentification Entra ID + MFA via Conditional Access, avec un pool d'adresses large et un SSO transparent. Architecture / pattern :

• VNet hub avec VPN GW VpnGw3AZ (route-based, jusqu'à 1000 connexions P2S OpenVPN en même temps).
• Config P2S : tunnel OpenVPN + auth Entra ID.
• Address Pool 172.30.0.0/22 (1024 IP, de la marge pour grandir).
• Conditional Access : MFA exigé pour l'app Azure VPN, mais sauté pour les laptops conformes (moins de friction).
• Arrivée d'un dev : on l'ajoute au groupe Entra vpn-devs, il obtient l'accès à l'app Azure VPN automatiquement (assignment required ON).
• Départ : on le retire du groupe, accès coupé immédiatement. Trade-offs assumés :
• Gain : accès identity-aware avec MFA et provisioning/déprovisioning par groupe Entra.
• Perte : dépendance à OpenVPN (exclut IKEv2) et à la maturité Entra ID/Conditional Access. Pièges à éviter :
• Choisir IKEv2 au lieu d'OpenVPN : pas d'auth Entra ID, on retombe sur cert/RADIUS, plus lourd.
• Pool /26 (64 IP) : saturé dès 50 connexions en pic. Toujours voir large.
• Conditional Access qui bloque sans exception : avalanche de tickets quand un dev voyage dans un pays bloqué. Toujours prévoir une règle break-glass.
• Activer OpenVPN + IKEv2 ensemble : les utilisateurs en IKEv2 ne pourront pas s'authentifier via Entra (IKEv2 ne gère pas Entra).

📐 Réf. CAF/WAF — Zero Trust remote access (identity-aware VPN) : moderniser le P2S en intégrant l'auth Entra ID et en imposant Conditional Access (MFA, device compliance, Named Locations) avant l'établissement du tunnel = accès least-privilege, identity-aware. Lien

Scenario 2 : Cabinet médical — médecins en astreinte avec cert auth + MFA

Contexte business : 4 hôpitaux d'un GHT. Les médecins d'astreinte consultent les dossiers patient (DPI) depuis chez eux. Confidentialité des données de santé critique, audit obligatoire. Pas d'Entra ID mature (juste du Workspace 365). Choix architectural : P2S OpenVPN + authentification par certificat émis par la CA maison (Microsoft AD CS), avec révocation centralisée via CRL. Architecture / pattern :

• VPN Gateway VpnGw2AZ, config P2S :
  • Tunnel OpenVPN (multi-plateforme : médecins sur Mac, iPad…).
  • Auth par certificat Azure.
  • Certificat racine de l'entreprise (AD CS) uploadé dans Azure.
• Chaque médecin reçoit un certificat client émis par AD CS, installé sur son device pro.
• La CRL (liste des certificats révoqués) est publiée sur un serveur web HTTP qu'Azure peut consulter.
• Un médecin part : son certificat est révoqué dans AD CS, la CRL se met à jour, Azure refuse sa connexion au contrôle suivant.
• Logs P2S envoyés vers Log Analytics + alerte sur les connexions à des heures inhabituelles. Trade-offs assumés :
• Gain : auth forte sans Entra ID mature, révocation centralisée par CRL, audit conforme santé.
• Perte : PKI (AD CS + CRL) à exploiter, gestion du cycle de vie des certificats clients. Pièges à éviter :
• Gérer la révocation à la main dans Azure (ajouter les empreintes une par une) : ingérable à 200 médecins. Seule la CRL automatique tient la route.
• Certificat client valable 5 ans : un médecin part et son certificat reste valide. Viser 1-2 ans max.
• Ne pas activer les logs P2SDiagnosticLog : impossible de prouver « le Dr X a consulté le DPI le 2026-03-15 à 22h ». Activer les logs dès le départ.
• VPN Gateway Basic : pas d'OpenVPN ni d'auth Entra/RADIUS. Il faut au moins VpnGw1AZ.

📐 Réf. CAF/WAF — Zero Trust : éviter l'accès réseau over-permissif (least privilege) : un tunnel VPN large reproduit le modèle d'accès trop permissif ; segmenter finement et journaliser limite reconnaissance et mouvement latéral en cas de cert/credential compromis. Lien

Scenario 3 : Manufacturier — Always-On VPN pour 500 laptops corporate

Contexte business : industriel, 500 laptops corporate sur 20 sites (commerciaux, RH, IT). Ils veulent un VPN transparent (l'utilisateur ne clique sur rien), connecté en permanence aux ressources internes (intranet, SharePoint, serveurs de fichiers, mises à jour GPO). Choix architectural : Always-On VPN (Device Tunnel + User Tunnel) avec auth par certificat, déployé via Intune. Architecture / pattern :

• VPN Gateway VpnGw3AZ, P2S en auth par certificat (Always-On l'exige pour le device tunnel).
• Profil VPN XML avec <AlwaysOn>true</AlwaysOn> + déclencheurs (s'active dès qu'on quitte le LAN corp.local).
• Device tunnel : monté au démarrage, avant le login Windows (pour GPO, scripts de connexion, Intune).
• User tunnel : monté à la connexion de l'utilisateur.
• Profil poussé via Intune Configuration Profile > VPN.
• Certificat client distribué automatiquement via Intune SCEP/PKCS (la CA AD CS émet les certificats à la demande).
• Additional routes : on déclare les plages on-prem joignables via le transit S2S (la VPN GW relaie vers le datacenter). Trade-offs assumés :
• Gain : VPN transparent always-on, accès dès le démarrage (GPO/Intune), déploiement industrialisé.
• Perte : auth par certificat obligatoire (exclut Entra ID), profils Intune/SCEP et déclencheurs à maintenir. Pièges à éviter :
• Mettre l'auth Entra ID sur un profil Always-On : elle ne gère pas le device tunnel. Le certificat est obligatoire.
• Certificat client sans renouvellement auto : il expire en silence, et un matin « VPN coupé ». Utiliser SCEP avec renouvellement automatique.
• Déclencheurs mal réglés (oubli du trigger « suffixe DNS ») : le VPN se monte même au bureau, inutilement. Affiner les déclencheurs.
• Pas d'Additional routes vers les plages on-prem : les télétravailleurs ne peuvent pas atteindre le datacenter via le transit Azure.

📐 Réf. CAF/WAF — Conditional Access pour Always-On VPN : coupler l'infra Always-On (profils poussés via Intune) à Conditional Access permet d'appliquer un contrôle d'accès policy-based (MFA, compliance) aux connexions VPN. Lien

DEMO — chemins portail

1. DEMO — Configure P2S VPN avec Entra ID Auth

Prérequis : VPN Gateway existante (VpnGw1AZ minimum, route-based).

Étape 1 — Configurer Entra ID enterprise app pour le VPN :

Une seule fois par tenant : Azure préinstalle une "Azure VPN" enterprise app. Vérifier dans Microsoft Entra ID > Enterprise applications > Azure VPN qu'elle est présente.

Étape 2 — Configurer P2S sur la VPN GW :

VPN Gateway > Point-to-site configuration > Configure now

• Address pool : 172.16.0.0/24
• Tunnel type : OpenVPN (SSL) (obligatoire pour Entra)
• Authentication type : Microsoft Entra ID
• Tenant : https://login.microsoftonline.com/<tenant-id>/
• Audience : c632b3df-fb67-4d84-bdcf-b95ad541b5c8 (ID public de l'app Azure VPN)
• Issuer : https://sts.windows.net/<tenant-id>/
• Save

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

VPN Gateway > Point-to-site configuration > Download VPN client

• Package zip contient le profil (pas de cert, l'auth est faite via Entra à la connexion)

Étape 4 — Installer côté user :

• Installer Azure VPN Client depuis le Microsoft Store (Windows) ou App Store (iOS/Mac)
• Importer le profil zip téléchargé : Azure VPN Client > Import > sélectionner le profil
• Cliquer Connect → popup Entra ID → login + MFA → connexion établie

Étape 5 — Vérifier :

• Client reçoit une IP du pool (ex 172.16.0.5)
• Trafic vers le VNet Azure passe par le tunnel
• Pour révoquer un user : retirer l'utilisateur de l'enterprise app Azure VPN (révocation centralisée)

💡 MFA + Conditional Access : activable via la policy Entra associée à l'app Azure VPN (ex : exiger Compliant device, MFA, location check, etc.).

2. DEMO — Configure P2S VPN avec Certificate Auth

Phase 1 — Théorie cert (voir §D.3 plus haut)

Phase 2 — Création des certificats (PowerShell sur ton PC Windows)

Note : cette partie nécessite PowerShell car le portail ne génère pas de certs. C'est de la génération de cert local, pas une commande Azure CLI.

Self-signed root cert :

$params = @{
  Type = 'Custom'
  Subject = 'CN=P2SRootCert'
  KeySpec = 'Signature'
  KeyExportPolicy = 'Exportable'
  KeyUsage = 'CertSign'
  KeyUsageProperty = 'Sign'
  KeyLength = 2048
  HashAlgorithm = 'sha256'
  NotAfter = (Get-Date).AddMonths(24)
  CertStoreLocation = 'Cert:\CurrentUser\My'
}
$cert = New-SelfSignedCertificate @params

Client cert (signé par le root, à lancer juste après) :

$params = @{
  Type = 'Custom'
  Subject = 'CN=P2SChildCert'
  DnsName = 'P2SChildCert'
  KeySpec = 'Signature'
  KeyExportPolicy = 'Exportable'
  KeyLength = 2048
  HashAlgorithm = 'sha256'
  NotAfter = (Get-Date).AddMonths(18)
  CertStoreLocation = 'Cert:\CurrentUser\My'
  Signer = $cert
  TextExtension = @('2.5.29.37={text}1.3.6.1.5.5.7.3.2')
}
New-SelfSignedCertificate @params

Phase 3 — Exporter le root cert (clé publique seulement)

1. Lancer certmgr.msc
2. Naviguer vers Personal > Certificates
3. Sélectionner P2SRootCert → Right-click → All Tasks > Export
4. NO, do not export the private key (on n'exporte QUE la clé publique pour Azure)
5. Format : Base-64 encoded X.509 (.CER)
6. Sauvegarder → ouvrir le .cer dans Notepad → copier le contenu (entre -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----)

Phase 4 — Configurer P2S Azure avec ce root cert

VPN Gateway > Point-to-site configuration

• Address pool : 172.16.0.0/24
• Tunnel type : OpenVPN (SSL) ou IKEv2
• Authentication type : Azure certificate
• Root certificates :
  • Name : P2SRootCert
  • Public certificate data : coller le contenu Base64 du .cer (sans les headers BEGIN/END CERTIFICATE)
• Revoked certificates : laisser vide pour démo (ajouter un thumbprint pour révoquer un cert client précis)
• Save

Phase 5 — Télécharger et installer côté user

• VPN Gateway > Point-to-site configuration > Download VPN client → zip
• Sur le PC user : importer le profil dans Azure VPN Client ou OpenVPN Client (selon tunnel type)
• S'assurer que le P2SChildCert (avec clé privée) est installé dans le Personal store du user (certmgr.msc)
• Connect → Azure vérifie la chaîne (P2SChildCert signé par P2SRootCert) → trust → connexion établie

💡 Tout changement de config P2S après la connexion (ex : changement tunnel type, ajout d'une route) impose de re-télécharger le client config + ré-installer le profil. Sinon le client utilise l'ancienne config.

3. DEMO — Configure P2S VPN avec RADIUS Auth

Setup lab : VM Windows Server jointe à un domaine AD (DC on-prem ou Azure), rôle NPS installé.

Phase 1 — Configurer le serveur NPS (RADIUS)

Sur le DC Windows Server (ou serveur dédié) :

1. Installer le rôle Network Policy Server (NPS) :
   • Server Manager > Add Roles > Network Policy and Access Services
2. Register server in AD :
   • nps.msc > Action > Register server in Active Directory
   • Cela autorise le NPS à lire les credentials AD
3. Déclarer la VPN GW Azure comme RADIUS Client :
   • nps.msc > RADIUS Clients and Servers > RADIUS Clients > New
   • Friendly name : vpngw-azure
   • Address (IP) : adresse IP privée de la VPN GW Azure (visible dans Connection Health Status ou en faisant un test)
   • Shared secret : générer un secret robuste (à noter pour la config Azure)
4. Créer une Network Policy :
   • nps.msc > Policies > Network Policies > New
   • Conditions :
     • User Groups : par exemple Domain Users ou groupe spécifique VPN-Users
   • Constraints : Authentication methods → PAP + MS-CHAP v2 (selon ce que la VPN GW envoie)
   • Settings → Allowed

Phase 2 — Configurer P2S Azure avec RADIUS

VPN Gateway > Point-to-site configuration

• Address pool : 172.16.0.0/24
• Tunnel type : OpenVPN ou IKEv2
• Authentication type : RADIUS authentication
  • Primary server IP address : IP privée du serveur NPS (ex 192.168.1.10)
  • Server secret : le shared secret défini sur NPS
  • (Optional) Secondary server IP : IP du NPS secondaire (HA)
• Save

Phase 3 — Tester

• Télécharger le client config + installer sur le PC user
• Connect → popup user/password (credentials AD)
• NPS reçoit la query Azure → check AD → autorisé → connexion établie

💡 Use case typique : entreprise avec AD on-prem mature, veut conserver les credentials AD pour VPN. NPS = "pont" entre VPN Azure et AD on-prem.