APIM Standard v2 VNet Integration - tunnel recycles periodically 70s active / 5min dead - AppServiceLink Succeeded but zero traffic in integration subnet

Bendriss, Abdelmalek 0 Points de réputation
2026-06-01T21:12:32.45+00:00

APIM Standard v2 VNet Integration - tunnel recycles periodically 70s active / 5min dead - AppServiceLink Succeeded but zero traffic in integration subnet

Service : API Management Service

Catégorie : Networking and Connectivity / Adding service to VNET

Ressource : apim-geomatic-dev

Sévérité : B - Moderate

Description :

ENVIRONMENT:

  • Resource: apim-geomatic-dev (rg-geomatic-dev, Canada Central), StandardV2
  • Integration subnet: snet-apim-v2 (10.20.3.0/24), delegation Microsoft.Web/serverFarms
  • Service endpoints: KeyVault, Sql, Storage, EventHub, AzureActiveDirectory, ServiceBus (all Succeeded)
  • AppServiceLink: Succeeded -> apimazwebplanOVFkPI4f7SeVoKRDa (Microsoft subscription 0673795b)

SYMPTOM:

Periodic VNet Integration tunnel cycling:

  • ALIVE ~70s: HTTP 500/503 in <500ms (backend reached, VNet Integration working)
  • DEAD ~5min: BackendConnectionFailure, connection timed out: 10.20.0.7:80 after 20s
  • SPONTANEOUS RECOVERY after ~5min without intervention

EXACT ERROR (captured via on-error policy):

X-Backend-Error: request-forwarder | BackendConnectionFailure | connection timed out: 10.20.0.7:80

X-Backend-Elapsed: 20101ms

APIM OUTBOUND IP: 20.220.134.255 (Microsoft-managed, NOT from snet-apim-v2 10.20.3.x)

VNET FLOW LOGS EVIDENCE (2026-06-01T19:37Z-19:46Z, 306KB blob analyzed):

Sources present: 10.20.0.x (AKS nodes), 10.244.x.x (pods)

Source 10.20.3.x (snet-apim-v2): ZERO FLOWS - absent even during ALIVE window

=> AppServiceLink established but NO packets transit through integration subnet

CYCLE DATA (Test 80x3s, continuous 3s interval):

16:29:43 ALIVE start (HTTP 500/503, 63-436ms)

16:30:54 DEAD start at req#22 DESPITE continuous traffic

16:36:25 SPONTANEOUS RECOVERY req#58 (~5min17s later)

16:36:25 ALIVE again (HTTP 500/503, 58-913ms)

TEST RESULTS:

Test A (keepalive): tunnel drops at 71s DESPITE continuous 3s traffic = NOT idle timeout

Test C: spontaneous recovery after 5min = periodic Azure worker rotation

DIAGNOSIS: Periodic tunnel rotation by Azure infrastructure (lifecycle, not idle)

natGatewayState=Enabled: IMMUTABLE via ARM PATCH and Bicep deploy

NGINX 10.20.0.7: HTTP 200 in 1s from inside VNet (az aks command invoke confirmed)

QUESTIONS:

  1. Why does AppServiceLink (Succeeded) generate ZERO traffic in snet-apim-v2, even during the ALIVE window where APIM returns responses in <500ms?
  2. Why does the VNet Integration tunnel cycle ~70s/5min regardless of traffic?
  3. Is natGatewayState=Enabled preventing stable RFC1918 routing through the VNet Integration? Can it be disabled on Standard v2?
  4. Does the App Service worker (apimazwebplanOVFkPI4f7SeVoKRDa, subscription 0673795b, RG canadacentPreProStandardV-20260525195953-cKTQ7FZPo) recycle the VNet Integration tunnel periodically by design?
Gestion des API Azure
Gestion des API Azure

Service Azure qui fournit une plateforme de gestion hybride multicloud pour les API.

0 commentaires

1 réponse

Trier par : Le plus utile
Le plus utile Plus récent Plus ancien
  1. Pravallika KV 18,855 Points de réputation Personnel externe de Microsoft Corporation Modérateur
    2026-06-01T21:38:51.4633333+00:00

    Bonjour @Bendriss, Abdelmalek ,

    Il semble que vous observiez le comportement classique du tunnel P2S (Point-to-Site) d’intégration sortante Standard V2, plutôt qu’un problème de configuration des NSG ou des UDR.

    Voici ce qui se passe et pourquoi vous constatez ces cycles d’environ 70 secondes de fonctionnement suivies de 5 minutes d’interruption, ainsi qu’une absence totale de flux dans votre sous-réseau:

    AppServiceLink est uniquement utilisé pour le plan de contrôle, pas pour votre chemin de données

    • Le lien d’association de service « apimazwebplan... » que vous voyez est le mécanisme par lequel le plan de contrôle APIM déploie une sorte de mini « passerelle VPN » dans votre réseau virtuel (VNet).
    • Les appels vers votre backend (10.x.x.x:80) sortent en réalité depuis l’hôte de travail APIM via le pipeline sortant mutualisé d’Azure (avec SNAT vers 20.x.x.255) et non directement depuis une interface réseau située dans snet.
    • C’est la raison pour laquelle les VNet Flow Logs n’affichent aucun trafic provenant de 10.20.3.x, même lorsque les réponses sont retournées en moins de 500 ms.

    Le cycle d’environ 70 secondes actives / 5 minutes inactives correspond à une rotation intégrée du tunnel P2S

    • Sous le capot, Standard V2 utilise un tunnel Point-to-Site de type App Service (SSTP). Ces connexions P2S sont renouvelées automatiquement par la plateforme toutes les quelques minutes (renouvellement de certificats, maintenance des hôtes, correctifs système, etc.), et non en raison d’une période d’inactivité.
    • Vous observez la fenêtre d’environ 70 secondes lorsque le tunnel SSTP est actif. Ensuite, le worker le ferme, puis le reconstruit environ 5 minutes plus tard, ce qui explique votre phénomène de « récupération spontanée ».

    L’état natGatewayState=Enabled ne bloque pas le trafic RFC1918

    • Une passerelle NAT attachée à votre sous-réseau d’intégration n’affecte que le trafic Internet (0.0.0.0/0) et non le trafic privé utilisant les plages d’adresses RFC1918 (10.x.x.x, 172.16.x.x–172.31.x.x, 192.168.x.x).
    • Vous ne pouvez pas désactiver ce comportement sur Standard V2, car il est géré par la plateforme Azure.

    Oui, cette reconstruction périodique du tunnel est un comportement normal sur Standard V2

    • Elle fait partie de l’infrastructure sous-jacente d’intégration P2S d’App Service. Il n’existe aucun paramètre côté client permettant d’augmenter la durée de vie du tunnel sur Standard V2.
    • Si vous avez besoin d’un chemin réseau entièrement appairé (peered), statique et constamment disponible vers votre VNet, il est nécessaire de migrer vers une instance Premium V2 et d’utiliser VNet Injection plutôt que l’intégration sortante.

    Si vous avez besoin d’une connectivité réellement ininterrompue vers votre sous-réseau, la solution recommandée et documentée est Premium V2 avec VNet Injection. Dans le cas contraire, ce cycle d’environ 5 minutes reste un comportement attendu sur Standard V2.

    Références :

    J’espère que ces informations vous seront utiles.

    Si cette réponse vous a aidé à résoudre votre problème, merci de prendre un moment pour cliquerUser's imagepuis sur Yes à la question "Was this answer helpful?". Si vous avez d’autres questions, n’hésitez pas à nous en faire part.

    Cette réponse vous a-t-elle été utile?

    2 personnes ont trouvé cette réponse utile.

Votre réponse

Les réponses peuvent être marquées comme « Acceptées » par l’auteur(e) de la question et « Recommandées » par les modérateurs, ce qui aide les utilisateurs à savoir que la réponse a résolu le problème de l’auteur(e).