Experiencing issues with egress traffic from sidecar containers to a peered Virtual Network (VNet) in Azure App Service setup.

Question

App Service VNet Integration + multi-container (sitecontainers): egress from sidecar containers to a peered VNet (private MySQL) times out even with outboundVnetRouting.allTraffic=true, while a VM in the same integration VNet succeeds. Sidecar egress is fully supported, or any extra configuration is required?

Answer 1

Sidecar containers in Azure App Service share the same network stack as the main app container. When App Service regional VNet Integration is configured, outbound traffic from the app is routed according to the VNet integration routing settings, including peered VNets, but there are current limitations and requirements that can affect this scenario.

From the available information:

1. Sidecar support and limitations
   • Sidecars are supported for Linux apps, including custom containers, but there are platform limitations: App Service Environment (ASE) and national clouds may not be supported yet, and networking is simplified so that all containers share localhost and must use unique ports.
   • Storage and networking features are more limited than in Docker Compose; all containers share the same host network, and there is no per-container VNet configuration.
2. VNet Integration routing behavior
   • With regional VNet Integration enabled, outbound routing is controlled by the outboundVnetRouting properties:
     • outboundVnetRouting.allTraffic=true routes all outbound traffic (application + configuration) through the integrated VNet.
     • outboundVnetRouting.applicationTraffic=true routes only application traffic through the VNet; configuration traffic (image pulls, content share, backup, etc.) can be selectively routed using the individual configuration routing flags.
   • The same routing applies to all containers in the App Service (main and sidecars), because they share the app’s network context.
3. What this implies for sidecar egress to a peered VNet
   • There is no separate or additional VNet Integration configuration for sidecars; they use the same VNet integration and routing as the main app container.
   • If a VM in the same integration VNet can reach the private MySQL in a peered VNet, but the App Service containers time out, the issue is likely in one of these areas rather than a lack of sidecar support:
     • Peering configuration (missing or asymmetric “Allow forwarded traffic” / “Allow traffic from remote VNet” settings).
     • NSG or firewall rules on the integration subnet, peered VNet subnet, or MySQL instance that treat App Service delegated subnet traffic differently from the VM subnet.
     • Route tables (UDRs) applied to the integration subnet or peered VNet subnet that affect App Service traffic differently.
   • The platform doesn’t expose a separate control to enable egress only for sidecars; if the main container can reach the destination over VNet Integration, sidecars should be able to as well.
4. Additional tooling
   • For App Service, the Network troubleshooter under Diagnostic and solve problem can be used to validate VNet Integration and routing, but note that the “connection issues” scenario does not yet support Linux or container-based apps. Configuration checks (subnet validity, deletion issues) are still available and can help confirm that the integration subnet is correctly configured.

Summary:

• Sidecar egress over App Service VNet Integration is supported and uses the same routing as the main app container; there is no extra sidecar-specific configuration flag.
• Timeouts to a peered VNet when outboundVnetRouting.allTraffic=true is set usually indicate a peering, NSG, firewall, or route-table issue rather than a sidecar limitation.

---

References:

• Sidecars in Azure App Service
• Migrate Docker Compose apps to sidecars in Azure App Service
• Manage Azure App Service virtual network integration routing
• Troubleshoot virtual network integration with Azure App Service