VNet Data Gateway : le guide complet de débogage

Le VNet Data Gateway permet à Power Platform et Power BI de se connecter aux services de données Azure (SQL, Synapse, Azure Data Explorer, etc.) via un Azure Virtual Network sans installation de passerelle on-premises. Pas de VM à gérer, pas de service de passerelle à maintenir.

Quand cela fonctionne, c'est transparent. Quand ce n'est pas le cas, les messages d'erreur sont parmi les plus cryptiques de l'écosystème Microsoft. Ce guide parcourt chaque scénario d'échec courant avec des étapes de diagnostic concrètes.

Comment fonctionnent réellement les VNet Data Gateways

Avant de déboguer, comprenez l'architecture :

1. Power Platform envoie une requête de données au service VNet de Power Platform
2. Le service injecte un sous-réseau managé dans votre Azure VNet
3. Le trafic transite par l'espace d'adressage privé du VNet vers la source de données cible
4. La source de données répond par le même chemin réseau privé
5. La résolution DNS se fait à l'intérieur du VNet (c'est extrêmement important)

Le sous-réseau managé est délégué à Microsoft.PowerPlatform/vnetaccesslinks. Power Platform gère le réseau au sein de ce sous-réseau. Vous gérez tout le reste : NSG, DNS, peering, firewalls.

Étape 1 : Vérifier les prérequis Azure

Avant de consulter les logs, confirmez les bases. La plupart des échecs du VNet gateway sont des erreurs de configuration d'infrastructure.

1.1 Configuration du sous-réseau

Le VNet Data Gateway nécessite un sous-réseau dédié délégué à Power Platform. Ce sous-réseau ne peut pas être partagé avec d'autres services.

Vérifiez dans le portail Azure : Virtual Networks > Votre VNet > Subnets

Vérifiez :

• Le sous-réseau a une délégation configurée sur Microsoft.PowerPlatform/vnetaccesslinks
• Le sous-réseau a au minimum une plage d'adresses /24 (256 adresses). Microsoft recommande /24 minimum.
• Le sous-réseau n'est pas associé à un Network Security Group qui bloque le trafic sortant (plus de détails à l'étape 4)

# Azure CLI: verify subnet delegation
az network vnet subnet show \
  --resource-group myResourceGroup \
  --vnet-name myVNet \
  --name powerplatform-subnet \
  --query "delegations[].serviceName" \
  --output tsv

Sortie attendue : Microsoft.PowerPlatform/vnetaccesslinks

Si la délégation est manquante ou incorrecte, la création du gateway échouera avec une erreur générique "provisioning failed".

1.2 Enregistrement du Resource Provider

Le resource provider Microsoft.PowerPlatform doit être enregistré dans votre abonnement Azure.

az provider show --namespace Microsoft.PowerPlatform --query "registrationState" --output tsv

S'il retourne NotRegistered :

az provider register --namespace Microsoft.PowerPlatform
# Wait 2-5 minutes, then verify
az provider show --namespace Microsoft.PowerPlatform --query "registrationState" --output tsv

1.3 Alignement des régions

Le VNet Data Gateway, le Azure VNet et l'environnement Power Platform doivent être dans la même région Azure. Il n'y a pas de support inter-régions.

Piège courant : les environnements Power Platform affichent les régions comme "Europe" ou "United States", tandis qu'Azure utilise des régions spécifiques comme "West Europe" ou "East US 2". La correspondance est :

Si votre VNet est dans "France Central" mais que votre environnement Power Platform est dans "Europe" (mappé sur West Europe), cela ne fonctionnera pas. Vous avez besoin du VNet dans West Europe ou North Europe.

Étape 2 : Vérifier la création et le statut du gateway

2.1 Vérifier le statut du gateway dans le Power Platform Admin Center

Naviguez vers : Power Platform Admin Center > Data (preview) > Virtual network data gateways

Le gateway devrait afficher le statut "Active". Statuts courants et leur signification :

2.2 Vérification via PowerShell

# Requires Power Platform admin or gateway admin role
Get-DataGatewayCluster -GatewayType VirtualNetwork | Format-Table Name, Status, Region

Si le gateway n'apparaît pas dans la liste, il n'a pas été créé avec succès. Retournez à l'étape 1.

Étape 3 : Échecs de résolution DNS

Le DNS est la cause d'environ 50 % des échecs de connexion du VNet gateway. Le symptôme est toujours le même : "Unable to connect to the data source" sans détail utile.

3.1 Comment fonctionne le DNS dans ce contexte

Le VNet Data Gateway résout les noms d'hôtes en utilisant le DNS configuré sur le VNet. Il n'utilise pas le DNS public par défaut.

Si votre cible est une base Azure SQL à myserver.database.windows.net et que vous utilisez des Private Endpoints, la chaîne de résolution DNS est :

1. Le paramètre DNS du VNet pointe vers Azure DNS (168.63.129.16) ou un serveur DNS personnalisé
2. La zone DNS privée privatelink.database.windows.net résout vers l'IP privée
3. Le gateway se connecte à l'IP privée à travers le VNet

Si un maillon de cette chaîne est cassé, la connexion échoue.

3.2 Diagnostic : tester le DNS depuis l'intérieur du VNet

Déployez une VM de test temporaire dans le même VNet (un sous-réseau différent convient) et testez la résolution :

# From a VM inside the VNet
Resolve-DnsName "myserver.database.windows.net" -Type A

Résultat attendu avec Private Endpoint :

Name       : myserver.privatelink.database.windows.net
Type       : A
IPAddress  : 10.0.1.5   # Private IP from your VNet range

Mauvais résultat (résolution publique malgré le Private Endpoint) :

Name       : myserver.database.windows.net
Type       : A
IPAddress  : 40.114.x.x  # Public Azure IP

Si le DNS résout vers une IP publique alors que vous attendez une IP privée, vérifiez :

1. La zone DNS privée privatelink.database.windows.net est liée au VNet
2. Les paramètres DNS du VNet pointent vers Azure DNS (168.63.129.16) ou un forwarder DNS qui redirige vers Azure DNS
3. Si vous utilisez un DNS personnalisé (DNS Active Directory par exemple), les conditional forwarders pour database.windows.net doivent pointer vers 168.63.129.16

3.3 Pièges du serveur DNS personnalisé

Les environnements d'entreprise utilisent presque toujours des serveurs DNS personnalisés (généralement intégrés à Active Directory). Cela introduit deux modes d'échec :

Échec 1 : Le serveur DNS n'est pas dans le VNet. Si le serveur DNS personnalisé est on-premises ou dans un VNet différent, le VNet Data Gateway ne peut pas l'atteindre sauf si le peering VNet et le routage sont correctement configurés.

Échec 2 : Conditional forwarders manquants. Le serveur DNS personnalisé doit rediriger les zones Azure Private Link vers 168.63.129.16. Sans cela, les Private Endpoints résolvent vers des IP publiques et la connexion échoue (si le firewall bloque l'accès public) ou contourne entièrement votre réseau privé.

# On the custom DNS server: add conditional forwarder
Add-DnsServerConditionalForwarderZone `
  -Name "database.windows.net" `
  -MasterServers 168.63.129.16 `
  -ReplicationScope "Forest"

Étape 4 : Blocages par les Network Security Groups (NSG)

Les NSG sur le sous-réseau du gateway peuvent bloquer le trafic managé de Power Platform.

4.1 Règles sortantes requises

Le sous-réseau du VNet Data Gateway a besoin d'un accès sortant vers :

4.2 Diagnostiquer les blocages NSG

Activez les flow logs NSG sur le NSG du sous-réseau et recherchez le trafic refusé :

# Check NSG rules on the subnet
az network nsg rule list \
  --resource-group myResourceGroup \
  --nsg-name myNSG \
  --output table

Recherchez toute règle Deny correspondant au trafic sur les ports 443 ou 1433 vers les service tags ci-dessus.

Erreur courante : Une règle "Deny All Outbound" à la priorité 4000 qui bloque le trafic de gestion du gateway. Le gateway apparaît actif mais ne peut atteindre aucune source de données.

4.3 Test de correction rapide

Retirez ou assouplissez temporairement le NSG du sous-réseau du gateway. Si la connexion fonctionne, le NSG est le problème. Puis rajoutez les règles de manière incrémentale :

1. Autoriser le trafic sortant vers l'IP privée de votre source de données sur le port requis
2. Autoriser le trafic sortant vers AzureCloud sur le port 443
3. Autoriser le trafic sortant vers AzureActiveDirectory sur le port 443
4. Refuser tout le reste

Étape 5 : Erreurs d'authentification et de permissions

Le gateway est connecté, le DNS résout, le trafic passe, mais la connexion échoue quand même. C'est généralement un problème d'authentification.

5.1 "Login failed for user" sur SQL Server

Le VNet Data Gateway ne change pas le fonctionnement de l'authentification. Il ne change que le chemin réseau. Le compte de service ou les identifiants de connexion doivent :

• Exister dans la base de données cible
• Avoir les permissions requises (db_datareader, db_datawriter, etc.)
• Être autorisés à se connecter depuis la plage d'IP privées du sous-réseau du gateway

-- On Azure SQL: verify the user exists and has access
SELECT dp.name, dp.type_desc, p.permission_name
FROM sys.database_principals dp
LEFT JOIN sys.database_permissions p ON dp.principal_id = p.grantee_principal_id
WHERE dp.name = 'your_service_account';

5.2 Configuration du firewall Azure SQL

Si le serveur Azure SQL a "Deny public network access" activé (comme il devrait avec les Private Endpoints), les règles de firewall ne sont pas pertinentes. Le trafic arrive via l'IP privée et contourne le firewall.

Cependant, si "Allow Azure services and resources to access this server" est désactivé et que vous n'avez pas de Private Endpoint, la connexion échouera. Le trafic du VNet Data Gateway ne se qualifie pas comme "Azure services" dans ce contexte de firewall.

La configuration correcte pour VNet Data Gateway + Azure SQL :

1. Private Endpoint activé sur le serveur SQL, lié au VNet
2. "Deny public network access" = Yes
3. Aucune règle de firewall nécessaire (le trafic est privé)

5.3 Échecs d'authentification OAuth / Entra ID

Lors de l'utilisation de l'authentification Entra ID (anciennement Azure AD) avec le VNet gateway, la requête de token passe par l'internet public vers login.microsoftonline.com, pas par le VNet. Assurez-vous que :

• Le sous-réseau du gateway autorise le HTTPS sortant vers le service tag AzureActiveDirectory
• Le service principal ou l'identité managée a les bons rôles Azure SQL
• L'audience du token est https://database.windows.net/ (pas https://management.azure.com/)

Étape 6 : Problèmes de timeout et de performance

Le gateway fonctionne mais les requêtes sont lentes ou expirent.

6.1 Vérifier le peering VNet

Si la source de données est dans un VNet différent connecté via peering :

az network vnet peering list \
  --resource-group myResourceGroup \
  --vnet-name myVNet \
  --output table

Vérifiez :

• Le statut du peering est "Connected" (pas "Initiated" ou "Disconnected")
• "Allow forwarded traffic" est activé des deux côtés si vous utilisez une topologie hub-spoke
• "Allow gateway transit" / "Use remote gateways" sont configurés correctement si un ExpressRoute ou VPN gateway est impliqué

6.2 Vérifier les problèmes de table de routage

Les routes définies par l'utilisateur (UDR) sur le sous-réseau du gateway peuvent rediriger le trafic via une appliance firewall (Azure Firewall, NVA), ajoutant de la latence ou causant des pertes.

az network route-table route list \
  --resource-group myResourceGroup \
  --route-table-name myRouteTable \
  --output table

Si une route par défaut (0.0.0.0/0) pointe vers une appliance virtuelle, cette appliance doit autoriser et ne pas inspecter/casser le TLS sur le trafic du gateway.

6.3 Vérifier les limites de requêtes Power Platform

Le VNet Data Gateway est toujours soumis aux limites de requêtes API Power Platform et au throttling Dataverse. Si les flux ou applications utilisant le gateway font des milliers de requêtes par minute, les erreurs de throttling apparaîtront comme des timeouts.

Vérifiez dans le Power Platform Admin Center > Analytics > Capacity si les limites de requêtes API sont atteintes.

Étape 7 : Collecte des logs de diagnostic

Quand tout le reste échoue, rassemblez les logs pour un ticket de support.

7.1 Log d'activité Azure

az monitor activity-log list \
  --resource-group myResourceGroup \
  --start-time 2026-01-28T00:00:00Z \
  --query "[?contains(resourceType, 'PowerPlatform')].{Time:eventTimestamp, Operation:operationName.localizedValue, Status:status.localizedValue, Detail:properties.statusMessage}" \
  --output table

7.2 Diagnostics en libre-service Power Platform

Dans le Power Platform Admin Center :

1. Allez dans Help + Support > New support request
2. Sélectionnez "Run diagnostics" avant de créer le ticket
3. L'outil de diagnostic vérifie automatiquement la configuration VNet, le DNS et la connectivité

7.3 NSG Flow Logs dans Log Analytics

Si les NSG flow logs sont activés et envoyés à un workspace Log Analytics :

AzureNetworkAnalytics_CL
| where SubType_s == "FlowLog"
| where SrcIP_s startswith "10.0.2"  // Your gateway subnet range
| where FlowStatus_s == "D"         // Denied flows
| project TimeGenerated, SrcIP_s, DestIP_s, DestPort_d, FlowStatus_s
| order by TimeGenerated desc
| take 50

Cela révèle exactement quel trafic le NSG bloque.

La checklist complète de dépannage

Parcourez cette liste dans l'ordre. Arrêtez-vous à la première défaillance :

1. Le resource provider Microsoft.PowerPlatform est enregistré
2. Le sous-réseau est délégué à Microsoft.PowerPlatform/vnetaccesslinks
3. Le sous-réseau est de taille /24 ou plus
4. La région du gateway correspond à la région du VNet et à la région de l'environnement Power Platform
5. Le statut du gateway est "Active" dans l'Admin Center
6. Le DNS résout le nom d'hôte cible vers l'IP (privée) attendue depuis l'intérieur du VNet
7. Les zones DNS privées sont liées au VNet (si vous utilisez des Private Endpoints)
8. Le NSG autorise le trafic sortant vers la source de données, AzureCloud et AzureActiveDirectory sur les ports 443/1433
9. Aucune UDR ne bloque ou ne redirige incorrectement le trafic
10. Le statut du peering VNet est "Connected" (si la source de données est dans un autre VNet)
11. Les identifiants de base de données sont valides et ont les permissions requises
12. Le firewall Azure SQL ou le Private Endpoint est configuré correctement
13. Les limites de requêtes API ne sont pas épuisées

Parcourez cette liste méthodiquement et vous trouverez le problème. Les échecs du VNet Data Gateway ne sont jamais mystérieux : c'est toujours une erreur de configuration réseau, DNS ou de permissions cachée derrière un message d'erreur peu utile.