Outbound App Service connectivity failure over Global VNet Peering after Hub Address Space change

Question

Outbound App Service connectivity failure over Global VNet Peering after Hub Address Space change

Samir Tapde 0

Issue Summary

Outbound TCP traffic from a Windows App Service (Premium v3) fails to reach a VM in a peered Spoke VNet across regions (Global Peering), despite VM-to-VM traffic succeeding on the same path.

Environment

Hub VNet: Central India (172.15.0.0/16)

App Service: tradeannexapi integrated into subnet snet-appsvc-v2 (172.15.2.0/24).

Spoke VNet: West India (10.3.0.0/16) via Global Peering.

Destination: Spoke VM (10.3.0.4) listening on port 1926.

Diagnostic Evidence

VM-to-VM Success: A Test VM in the Hub (172.15.0.4) successfully connects to the Spoke VM (10.3.0.4:1926). This confirms Peering, Spoke NSGs, and Spoke Routing Tables are 100% correct for the 172.15.x.x range.

App Service Local Success: The App Service successfully reaches the Hub VM (172.15.0.4:3389). This confirms VNet Integration is functional locally.

Pktmon Results: pktmon on the Spoke VM shows 0 packets received when triggered from the App Service, while showing successful Rx/Tx for the Hub VM. Traffic is dying before leaving the Hub region.

A TCP trace from the App Service worker process (w3wp.exe) confirms that the application is successfully generating SYN packets for 10.3.0.4:1926 from source IP 172.15.2.254. However, the trace shows a total absence of ingress traffic (SYN-ACK) from the peered VNet, confirming that the return path is being dropped at the regional gateway level.

Troubleshooting Completed

Address space was recently changed from 10.0.0.0/16 to 172.15.0.0/16.

App Service VNet Integration has been disconnected and recreated on a fresh subnet.

WEBSITE_VNET_ROUTE_ALL is set to 1.

Peering "Sync" has been performed; "Allow Forwarded Traffic" is enabled on both sides.

Spoke VPN Gateway reset has been performed.

App Service Plan has been scaled to force worker migration.

Request

Please investigate the Regional Gateway/SDN routing for the App Service workers in Central India. It appears the internal routing for the App Service "Swift" integration is not honoring the Global Peering path for the new 172.15.x.x prefix, even though the VNet System routes are correct.

Issue Summary

Outbound TCP traffic from a Windows App Service (Premium v3) fails to reach a VM in a peered Spoke VNet across regions (Global Peering), despite VM-to-VM traffic succeeding on the same path.

Environment

Hub VNet: Central India (172.15.0.0/16)

App Service: tradeannexapi integrated into subnet snet-appsvc-v2 (172.15.2.0/24).

Spoke VNet: West India (10.3.0.0/16) via Global Peering.

Destination: Spoke VM (10.3.0.4) listening on port 1926.

Diagnostic Evidence

VM-to-VM Success: A Test VM in the Hub (172.15.0.4) successfully connects to the Spoke VM (10.3.0.4:1926). This confirms Peering, Spoke NSGs, and Spoke Routing Tables are 100% correct for the 172.15.x.x range.

App Service Local Success: The App Service successfully reaches the Hub VM (172.15.0.4:3389). This confirms VNet Integration is functional locally.

Pktmon Results: pktmon on the Spoke VM shows 0 packets received when triggered from the App Service, while showing successful Rx/Tx for the Hub VM. Traffic is dying before leaving the Hub region.

Troubleshooting Completed

Address space was recently changed from 10.0.0.0/16 to 172.15.0.0/16.

App Service VNet Integration has been disconnected and recreated on a fresh subnet.

WEBSITE_VNET_ROUTE_ALL is set to 1.

Peering "Sync" has been performed; "Allow Forwarded Traffic" is enabled on both sides.

Spoke VPN Gateway reset has been performed.

App Service Plan has been scaled to force worker migration.

Request

Please investigate the Regional Gateway/SDN routing for the App Service workers in Central India. It appears the internal routing for the App Service "Swift" integration is not honoring the Global Peering path for the new 172.15.x.x prefix, even though the VNet System routes are correct.

Golla Venkata Pavani 4,095 Reputation points Microsoft External Staff Moderator

2026-04-27T20:12:12.9533333+00:00
Hi @Samir Tapde

Thank you for reaching us regarding the issue.

Traffic dying before leaving the Hub region with 0 packets on Spoke VM points to one specific layer:

The App Service Swift integration's internal SDN stamp still has stale/incomplete routing for the 10.3.0.0/16 prefix via Global Peering

The VM-to-VM path bypasses the Swift layer entirely, that's why it works. The App Service must go through Swift, which has its own internal routing plane.

Add UDR on App Service Subnet:

This is almost certainly your fix. The App Service subnet needs an explicit route forcing traffic to the Spoke via the correct next hop.

Recreate VNet peering on both sides

Delete and recreate peering (rather than only using “Sync”) to ensure full propagation of updated address space and routing

Reference:
https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-intermittent-outbound-connection-errors
https://learn.microsoft.com/troubleshoot/azure/virtual-network/virtual-network-troubleshoot-peering-issues
https://supportability.visualstudio.com/AzureAppService/_wiki/wikis/AzureAppService/188306/Web%20App%20-%20Windows/Web%20App%20(Windows)%20-%20Networking/Configuring%20VNET%20integration%20with%20App%20Service/Regional%20Vnet%20Integration
Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well
Samir Tapde 0 Reputation points

2026-04-28T08:50:50.8266667+00:00

Hi Pavani,

Thank you for your insights regarding the Swift Integration layer. I have followed your recommendation for a full infrastructure refresh.

I completely deleted and recreated the VNet Peerings on both sides (Hub-to-Spoke and Spoke-to-Hub) to ensure a clean rebuild of the SDN bridge. I also added a manual User Defined Route (UDR) on the App Service subnet specifically pointing traffic for the 10.3.0.0/16 range to the Virtual Network.

Unfortunately, the results remain unchanged. The App Service continues to experience a 'black hole' effect where SYN packets are generated but never reach the Spoke VM, while standard VMs in the Hub continue to have 100% connectivity success.

This leads me to believe the 'SDN Stamp' in the Central India region is fundamentally out of sync with the VNet's current routing table. I am escalating this to Microsoft support as a platform routing failure.

Thanks again for your help in isolating this to the Swift layer.

Best regards, Samir
Golla Venkata Pavani 4,095 Reputation points Microsoft External Staff Moderator

2026-04-28T19:51:33.1933333+00:00

Hi @Samir Tapde

Thank you for validating all the recommended steps. Since VNet peering, UDR, and VM‑to‑VM connectivity are working as expected, this confirms the issue is not on the customer configuration side.

Based on this, the behavior indicates a platform-side routing inconsistency specific to App Service VNet Integration, where outbound traffic is generated but not reaching the peered VNet.

Could you please Support Case ID via private chat that we will provide an update for your issue.
Golla Venkata Pavani 4,095 Reputation points Microsoft External Staff Moderator

2026-04-30T17:13:36.79+00:00

Hi @Samir Tapde

I'm just reaching out to see if your issue has been resolved or not and could you please Support Case ID via private chat that we will provide an update for your issue.
Samir Tapde 0 Reputation points

2026-05-01T03:39:22.53+00:00

It is so strange that I am unable to raise a support case! My subscription has support plan (developer). Can you help me find a reason? I can share subscription and resource information on PM if you want.
Golla Venkata Pavani 4,095 Reputation points Microsoft External Staff Moderator

2026-05-04T18:29:32.04+00:00
Hi @Samir Tapde

Regarding your concern about being unable to raise an Azure support case even though you have a Developer support plan, this behavior is expected based on how Azure support plans are designed.The Developer support plan is intended primarily for non‑production and dev/test scenarios and provides limited support capabilities.

Before concluding, you may want to verify the following:

Ensure your account has the required RBAC permissions (Owner / Contributor / Support Request Contributor) on the subscription, as these are required to create support requests.

Confirm that the Developer support plan is correctly linked to your subscription under Help + Support → Support plans

Verify that the subscription is active and not restricted or managed under a CSP model (which may require contacting the provider instead)

Recommended approach:

Upgrade to a higher support plan (Standard or above)

This will allow you to create a direct technical support ticket

Recommended for complex networking or platform-level issues requiring engineering validation

Raise a Billing/Subscription support request (free for all customers) and request assistance in enabling or routing a technical support case.

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well

1 answer

Your answer

Golla Venkata Pavani 4,095 Reputation points Microsoft External Staff Moderator

2026-04-27T20:12:12.9533333+00:00

Hi @Samir Tapde

Thank you for reaching us regarding the issue.

Traffic dying before leaving the Hub region with 0 packets on Spoke VM points to one specific layer:

The App Service Swift integration's internal SDN stamp still has stale/incomplete routing for the 10.3.0.0/16 prefix via Global Peering

The VM-to-VM path bypasses the Swift layer entirely, that's why it works. The App Service must go through Swift, which has its own internal routing plane.

Add UDR on App Service Subnet:

This is almost certainly your fix. The App Service subnet needs an explicit route forcing traffic to the Spoke via the correct next hop.

Recreate VNet peering on both sides

Delete and recreate peering (rather than only using “Sync”) to ensure full propagation of updated address space and routing

Reference:
https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-intermittent-outbound-connection-errors
https://learn.microsoft.com/troubleshoot/azure/virtual-network/virtual-network-troubleshoot-peering-issues
https://supportability.visualstudio.com/AzureAppService/_wiki/wikis/AzureAppService/188306/Web%20App%20-%20Windows/Web%20App%20(Windows)%20-%20Networking/Configuring%20VNET%20integration%20with%20App%20Service/Regional%20Vnet%20Integration
Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well
Samir Tapde 0 Reputation points

2026-04-28T08:50:50.8266667+00:00

Hi Pavani,

Thank you for your insights regarding the Swift Integration layer. I have followed your recommendation for a full infrastructure refresh.

I completely deleted and recreated the VNet Peerings on both sides (Hub-to-Spoke and Spoke-to-Hub) to ensure a clean rebuild of the SDN bridge. I also added a manual User Defined Route (UDR) on the App Service subnet specifically pointing traffic for the 10.3.0.0/16 range to the Virtual Network.

Unfortunately, the results remain unchanged. The App Service continues to experience a 'black hole' effect where SYN packets are generated but never reach the Spoke VM, while standard VMs in the Hub continue to have 100% connectivity success.

This leads me to believe the 'SDN Stamp' in the Central India region is fundamentally out of sync with the VNet's current routing table. I am escalating this to Microsoft support as a platform routing failure.

Thanks again for your help in isolating this to the Swift layer.

Best regards, Samir
Golla Venkata Pavani 4,095 Reputation points Microsoft External Staff Moderator

2026-04-28T19:51:33.1933333+00:00

Hi @Samir Tapde

Thank you for validating all the recommended steps. Since VNet peering, UDR, and VM‑to‑VM connectivity are working as expected, this confirms the issue is not on the customer configuration side.

Based on this, the behavior indicates a platform-side routing inconsistency specific to App Service VNet Integration, where outbound traffic is generated but not reaching the peered VNet.

Could you please Support Case ID via private chat that we will provide an update for your issue.
Golla Venkata Pavani 4,095 Reputation points Microsoft External Staff Moderator

2026-04-30T17:13:36.79+00:00

Hi @Samir Tapde

I'm just reaching out to see if your issue has been resolved or not and could you please Support Case ID via private chat that we will provide an update for your issue.
Samir Tapde 0 Reputation points

2026-05-01T03:39:22.53+00:00

It is so strange that I am unable to raise a support case! My subscription has support plan (developer). Can you help me find a reason? I can share subscription and resource information on PM if you want.
Golla Venkata Pavani 4,095 Reputation points Microsoft External Staff Moderator

2026-05-04T18:29:32.04+00:00

Hi @Samir Tapde

Regarding your concern about being unable to raise an Azure support case even though you have a Developer support plan, this behavior is expected based on how Azure support plans are designed.The Developer support plan is intended primarily for non‑production and dev/test scenarios and provides limited support capabilities.

Before concluding, you may want to verify the following:

Ensure your account has the required RBAC permissions (Owner / Contributor / Support Request Contributor) on the subscription, as these are required to create support requests.

Confirm that the Developer support plan is correctly linked to your subscription under Help + Support → Support plans

Verify that the subscription is active and not restricted or managed under a CSP model (which may require contacting the provider instead)

Recommended approach:

Upgrade to a higher support plan (Standard or above)

This will allow you to create a direct technical support ticket

Recommended for complex networking or platform-level issues requiring engineering validation

Raise a Billing/Subscription support request (free for all customers) and request assistance in enabling or routing a technical support case.

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well

Answer 1

Hello Samir Tapde,

Greetings!

Thanks for raising this question in Q&A forum.

You have done an excellent job diagnosing this! Based on your evidence — SYN packets leaving the App Service worker but no SYN-ACK returning, zero packets on pktmon at the Spoke VM, and VM-to-VM working fine — the root cause is almost certainly a stale internal SDN (Software Defined Networking) route cache within the App Service "Swift" VNet Integration infrastructure, left over from the old 10.0.0.0/16 address space. When you changed the Hub VNet address space to 172.15.0.0/16, the App Service platform's internal routing fabric did not fully propagate the new prefix for Global Peering paths, even though the VNet system routes are correct from Azure's perspective.

Here is a structured set of steps to resolve this:

Step 1: Re-sync both sides of the Global Peering explicitly

Even though you have already done a Sync, do it again in this specific order:

Go to the Azure Portal → Hub VNet (172.15.0.0/16) → Peerings.
Click on the peering link to the Spoke VNet and click Sync — then wait 2–3 minutes.
Then go to the Spoke VNet (10.3.0.0/16) → Peerings → click the peering back to the Hub and click Sync again.
This bidirectional re-sync is important after an address space change, as each side needs to re-advertise the updated prefixes independently.

Step 2: Delete and recreate the VNet Integration completely (not just disconnect)

Since the address space changed from 10.0.0.0/16 to 172.15.0.0/16, the App Service Swift integration may still have an internal reference to the old prefix. A full delete and recreate is needed:

Go to Azure Portal → App Service tradeannexapi → Networking → VNet Integration.
Click Disconnect and confirm.
Delete the subnet snet-appsvc-v2 from the Hub VNet entirely.
Recreate the subnet with a fresh name (e.g., snet-appsvc-v3) under the new 172.15.0.0/16 address space.
Re-integrate the App Service to this brand-new subnet.

This forces the Swift integration to register the 172.15.x.x prefix fresh with no stale references.

Step 3: Verify the App Service Outbound Route Table

Go to the subnet snet-appsvc-v3 in the Hub VNet.
Check the associated Route Table (if any).
Make sure there is a route for 10.3.0.0/16 (Spoke VNet) pointing to VNet Peering or Virtual Network as the next hop — not to an NVA or Azure Firewall that might be dropping cross-region traffic.
If you are using a hub-spoke with an NVA/Firewall in the middle, make sure the firewall rules explicitly allow traffic from 172.15.2.0/24 to 10.3.0.4:1926.

Step 4: Confirm WEBSITE_VNET_ROUTE_ALL and add the Spoke prefix explicitly

In App Service → Configuration → Application Settings, confirm WEBSITE_VNET_ROUTE_ALL = 1 is still set after the VNet Integration recreation.
Additionally, go to App Service → Networking → VNet Integration → and check the Outbound address prefixes listed. The Spoke VNet range 10.3.0.0/16 must appear here or be reachable via a route.
If it is missing, add an explicit route in the Route Table attached to the App Service subnet: Destination 10.3.0.0/16 → Next Hop: Virtual Network.

Step 5: Scale the App Service Plan again after the above steps

After completing Steps 1–4, force a worker migration once more:

Go to App Service Plan → Scale Up → change to a different SKU (e.g., P2v3) → Save.
Wait 5 minutes, then scale back to P3v3.
This forces the App Service workers to re-register with the updated networking configuration.

Step 6: If the issue still persists — raise a support ticket

Since your diagnostics clearly point to an internal SDN/platform routing issue in the Central India region, and you have already exhausted all client-side options, you need Microsoft's networking backend team to investigate:

Open a support request via the Azure Portal → your App Service resource → Support + Troubleshooting → New Support Request.
Choose Networking as the problem type and clearly state this is a Global VNet Peering + App Service Swift VNet Integration routing issue after address space change.
Include your pktmon evidence, the TCP trace showing SYN with no SYN-ACK, and the Correlation IDs from the Activity Log.
Request that the support engineer investigate the App Service regional gateway SDN routing table for the 172.15.x.x prefix propagation to the West India Global Peering path.

Quick Summary: The traffic is leaving the App Service correctly but is being dropped at the regional boundary because the App Service Swift integration's internal SDN fabric still has stale routing for the old address space. The fix involves a full peering re-sync in the correct order, a complete VNet Integration recreation on a fresh subnet, and route table validation followed by a worker scale cycle to pick up all changes.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

Samir Tapde 0 Reputation points

2026-04-28T08:49:59.3033333+00:00

Hi Jerald,

Thank you for the detailed breakdown. I have completed the 'Scorched Earth' approach as you suggested.

Specifically, I disconnected the VNet Integration, deleted the old subnet, and created a completely new subnet with a fresh name (snet-appsvc-v3) and a new address range (172.15.3.x). I also performed the bidirectional peering sync and scaled the App Service Plan up and down to force a worker migration.

Despite these steps, the issue persists:

Hub VM (172.15.0.4): Still succeeds with Test-NetConnection to the Spoke (10.3.0.4).

App Service (172.15.3.x): Still times out on tcpping to the same destination.

This confirms your theory about a stale internal SDN route cache. Since even a new subnet name and IP range didn't trigger a refresh, I am now pursuing a backend flush via a support ticket. I will update the thread once the Microsoft networking team provides a resolution.

Best regards, Samir

Share via

Outbound App Service connectivity failure over Global VNet Peering after Hub Address Space change

Issue Summary

Environment

Diagnostic Evidence

Troubleshooting Completed

Request

Issue Summary

Environment

Diagnostic Evidence

Troubleshooting Completed

Request

1 answer

Your answer