Share via

App Service VNET integration - Resources in peered network not reachable after changing subnets

Langner, Clemens 20 Reputation points
2025-09-24T10:02:07.5466667+00:00

Hello together,

we have a problem after changing app services to use a new subnet due to change of VNET Address space.

Environment / State before change

Working state before:

  • Hub-VNET with a firewall, which is configured as DNS-Server
  • Spoke-VNET, were e.g. App services are located within subnets with VNET integration
  • Peering between Spoke-VNET and HUB-VNET
  • UDRs, which are deployed for all Spoke-VNET subnets with a 0.0.0.0/0 next hop to the virtual appliance (HUB-VNET firewall)

What has been done?

  • Added a new VNET Address Space to the Spoke-VNET
  • Created new Subnets in the Address Space in the Spoke-VNET
  • Synced the Peering between Spoke-VNET and HUB-VNET, to add the new Address Space
  • Removed the VNET integration of affected app services and added a new using the newly created subnets.
  • Restarted the App Services
  • Removed the old subnets and the old VNET Address Space
  • Synced the Peering between Spoke-VNET and HUB-VNET, to remove the old Address Space

Problem

Right after doing the sync for the peering to remove the old address space, the app services sporadically cannot reach ressources/IPs, which are located a peered HUB-VNET after syncing the VNET peering on the HUB-VNET.

It was tested with checking the application itself and a curl & dig in Kudo to reach the ressources.

Following fixes were tried:

  • Restarted app service and instance
  • Removed and added the vnet integration
  • Removing and Adding UDRs fixed it for couple of minutes
  • Checked peering, everything was in sync

Workaround

Scaling the app service plan up and down did fix the problem and we are checking, if the problem will occure again or if it is permanent.

Question

As for my understanding, the server is re-created when scaling the ASP and sometimes resolves some problems in underlying infrastructure.

Is the cause of the problem known and is there another solution to solve the problem?

Is there another way to do a change of address spaces without running into this problem, did we make a mistake here?

Azure App Service
Azure App Service

Azure App Service is a service used to create and deploy scalable, mission-critical web apps.

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Praneeth Maddali 9,870 Reputation points Microsoft External Staff Moderator
    2025-09-24T11:24:09.76+00:00

    Hi @Langner, Clemens

    Thank you for reaching regarding the issue with your App Services following the update to the Spoke-VNET address space and subnets. The intermittent problems accessing HUB-VNET resources after peering synchronization are likely caused by delays in route propagation or caching within the App Service VNET integration, which is typical in hub-spoke architectures using UDRs with firewall routing. Your scaling workaround helps by refreshing worker instances, but we have provided a permanent solution below.

    Steps to Resolve:

    1. Re-Sync VNET Integration:
      • In the Azure Portal, go to App Service > Networking > VNet integration > Edit. Re-add the HUB-VNET address space, then select Sync network, choose Add routes, and click Save.
      • After completing these steps, restart the App Service.
    2. Verify UDRs and Routes:
      • Review the Spoke-VNET > Subnet > Route table to confirm that 0.0.0.0/0 is directed to the HUB firewall.
      • Check Effective routes in the Portal or use Get-AzEffectiveRouteTable (PowerShell) to validate HUB-VNET routing.
    3. Enable Route All:
      • With VNET integration, activate Route All to make sure that peered traffic is routed through the VNET.
    4. Test Connectivity:
      • For Kudu (<app>.scm.azurewebsites.net), use tcpping <hub-ip> 443 on Windows or curl -v <hub-url> on Linux.
      • You can also use Diagnose and solve problems > "Network" in the Portal for automated network checks.
    5. Future Migrations:
      • Maintain both old and new address spaces for 24 hours during testing before deactivating the old space to prevent synchronization issues.

    reference:
    https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/troubleshoot-vnet-integration-apps
    https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-troubleshoot-peering-issues

    https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-intermittent-outbound-connection-errors

    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.

    Was this answer helpful?

    1 person found this answer helpful.
  2. Langner, Clemens 20 Reputation points
    2025-10-13T10:28:06.9566667+00:00

    Hello @Praneeth Maddali ,

    we were not able to resolve the problem yet, following your comment.

    • We tried to re-introduce the routing problems, but always have other results.
    • In one case, we waited more than 24 hours before removal of the old vnet range and sync the peering, which triggered the problem as it seems.
    • Checking effective routes is not possible; app service vnet integration has no NIC to check
    • Enable Route All is active
    • Re-do vnet integration is not solving the problem entirely; after some time, it comes back

    The problem is not persistent and in advance, even after removing the vnet and sync the peering and successfull testing, the problem can still occur for some of the app service instances.

    We are now contacting our Microsoft contact person to solve this, currently we can't work with this behaviour.

    Do you have any other idea, what we could check?

    Lab "A" for testing the situation we already had to reproduce the error. 

    Following steps will be done to do this:

    1. Test to reach the firewall IP in the hub network via kudu with a ping ✅
    2. A new VNET range is introduced with new subnets, NSGs, UDRs✅
    3. Sync the peering (with terraform azapi ressource) ✅
    4. Test to reach the firewall IP in the hub network via kudu with a ping and do a dig ✅
    5. All app services are moved to the new subnet with the vnet integration ✅
    6. Test to reach the firewall IP in the hub network via kudu with a ping ✅
    7. Remove the old subnet, udr association, NSGs association and old NSGs ✅
    8. Test to reach the firewall IP in the hub network via kudu with a ping ✅
    9. Remove the old VNET ✅
    10. Test to reach the firewall IP in the hub network via kudu with a ping ✅
    11. Sync the peering (with terraform azapi ressource) ✅
    12. Test to reach the firewall IP in the hub network via kudu with a ping ✅ Test OK, was working
      1. If the same problem occur with non-reachable destinations, re-creation of the peering and restart of apps services
      2. Restart app services via portal ✅
      3. Test to reach the firewall IP in the hub network via kudu with a ping ✅
    13. Scale up app services via portal ()Just one app service ✅
    14. Test to reach the firewall IP in the hub network via kudu with a ping ✅
    15. Switch to the new UDRs ✅
    16. Remove old UDRs ✅
    17. Restart app services ✅
    18. Test to reach the firewall IP in the hub network via kudu with a ping ✅
    19. LabA removed 🔴

    Lab "A2" for testing the situation we already had to reproduce the error, but with sync via portal

    Following steps will be done to do this:

    1. Test to reach the firewall IP in the hub network via kudu with a ping✅
    2. A new VNET range is introduced with new subnets, NSGs, UDRs✅
    3. Sync the peering via portal ✅
    4. Test to reach the firewall IP in the hub network via kudu with a ping and do a dig ✅
    5. All app services are moved to the new subnet with the vnet integration ✅
    6. Test to reach the firewall IP in the hub network via kudu with a ping ✅
    7. Remove the old subnet, udr association, NSGs association and old NSGs  ✅
    8. Test to reach the firewall IP in the hub network via kudu with a ping ✅
    9. Remove the old VNET ✅
    10. Test to reach the firewall IP in the hub network via kudu with a ping ✅
    11. Sync the peering via portal ✅
    12. Test to reach the firewall IP in the hub network via kudu with a ping ✅ Test was fine
      1. If the same problem occur with non-reachable destinations, re-creation of the peering and restart of apps services
    13. LabA2 removed 🔴

    Lab "B" for testing the situation to wait 24 hours between removing old vnet ranges.

    Following steps will be done to do this:

    1. Test to reach the firewall IP in the hub network via kudu with a ping✅
    2. A new VNET range is introduced with new subnets, NSGs, UDRs✅
    3. Sync the peering (with terraform azapi ressource)✅
    4. Test to reach the firewall IP in the hub network via kudu with a ping and do a dig ✅
    5. All app services are moved to the new subnet with the vnet integration ✅
    6. Test to reach the firewall IP in the hub network via kudu with a ping ✅
    7. Wait 24 hours ✅
    8. Remove the old subnets and NSGs ✅
    9. Test to reach the firewall IP in the hub network via kudu with a ping ✅
    10. Remove the old vnet range ✅
    11. Test to reach the firewall IP in the hub network via kudu with a ping ✅
    12. Sync the peering ✅
    13. Test to reach the firewall IP in the hub network via kudu with a ping ❌ Problem happened, ping to firewall not possible
    14. Issue resolve workaround: Re-introduce old address space and re-sync ✅
    15. Removed old vnet range and do sync peering again ❌ - some app service worker are having a problem
    16. Waited over a weekend: Other workers are now affected ❌

    Lab "C" for testing the situation to re-create the peering from start.

    Following steps will be done to do this:

    1. Test to reach the firewall IP in the hub network via kudu with a ping✅
    2. A new VNET range is introduced with new subnets, NSGs, UDRs✅
    3. Remove the peering ✅
    4. Test to reach the firewall IP in the hub network via kudu with a ping and do a dig, should not work ✅
    5. All app services are moved to the new subnet with the vnet integration ✅
    6. Test to reach the firewall IP in the hub network via kudu with a ping and do a dig, should not work ✅
    7. Remove the old VNET, old subnet, udr association, NSGs association and old NSGs  ✅
    8. Create the peering ✅
    9. Test to reach the firewall IP in the hub network via kudu with a ping ✅
      1. If the same problem occur with non-reachable destinations, wait 24 hours
    10. LabC removed 🔴

    Lab "Q" for testing the situation to test the rollback to old vnet range and to check firewall logs

    Following steps will be done to do this:

    1. Add firewall logs ✅
    2. A new VNET range is introduced with new subnets, NSGs, UDRs ✅
    3. All app services are moved to the new subnet with the vnet integration ✅
    4. Test to reach the firewall IP in the hub network via kudu with a ping and do a dig ❌
    5. Peering sync✅
    6. Test to reach the firewall IP in the hub network via kudu with a ping and do a dig✅
    7. Remove the old VNET, old subnet, udr association, NSGs association and old NSGs ✅
    8. Sync peering✅
    9. Test to reach the firewall IP in the hub network via kudu with a ping 
      1. Should be problematically for some instances✴️ No error

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.