App service giving Error 403 - Forbidden while integrate VNET and Nsg

Tahami Rizwan 20 Reputation points

I am running my backend API's in azure app service. Trying to secure my API's that can only be access from certain resources. When Access the API it gives Error 403 - Forbidden

I have done:
.Created a VNET with NSG
.Add all IP's in a rule of NSG
.Attach VNET with app service

When I remove VNET from app service app service is browse successfully

How app service can be accessed from specified ip's using VNET and Nsg?

Azure Virtual Network
Azure Virtual Network
An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.
2,304 questions
Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
7,401 questions
0 comments No comments
{count} votes

2 answers

Sort by: Most helpful
  1. VasimTamboli 4,785 Reputation points

    Check NSG rules: Ensure that the NSG associated with your VNet allows inbound traffic from the specific IP addresses or ranges that you want to grant access to your API. Review the NSG rules and verify that they are correctly configured to allow traffic on the necessary ports for your API.

    Verify VNet integration: Double-check the VNet integration settings for your App Service. Ensure that you have correctly integrated your App Service with the desired VNet and subnet. You can review the integration settings in the Azure portal under the "Networking" section of your App Service.

    Check App Service access restrictions: Verify that the App Service's access restrictions are properly configured to allow traffic from the specified IP addresses. In the Azure portal, navigate to your App Service, go to the "Networking" section, and click on "Configure Access Restrictions." Add the appropriate IP restrictions to allow access to your API.

    Validate IP address configuration: Make sure the IP addresses you are trying to access the API from are correctly specified. Double-check the IP addresses or ranges and ensure they are accurate.

    Verify subnet-to-subnet connectivity: If you have multiple subnets within your VNet, verify that the necessary connectivity exists between the subnet hosting the App Service and the subnet from which you are accessing the API. Ensure that the necessary network routes and peering connections are correctly configured.

    Diagnose network connectivity: Use tools like Azure Network Watcher or Azure Diagnostics to diagnose the network connectivity between the accessing IP addresses and your App Service. These tools can help identify any network issues or misconfigurations.

    Check for other security mechanisms: Ensure that there are no other security mechanisms in place, such as Azure Firewall or Azure Application Gateway, that might be blocking the traffic to your API. Review the configuration of these services to ensure they are not causing the "403 - Forbidden" error.

  2. Grmacjon-MSFT 17,381 Reputation points

    @Tahami Rizwan You're right, managing IP restrictions at the individual App Service level does not scale well, especially when you have a large number of IP addresses to whitelist.

    The better approach is to use Network Security Groups (NSGs) associated with the subnet to control access at the network level. Here is how you can do it with NSGs on your VNet integrated subnet:

    1. Remove any app-level IP restrictions from your App Services so that access control happens only through the NSG.
    2. Add an inbound NSG rule to allow inbound traffic from your source IP addresses on ports 80 and 443. You can use service tags like AzureLoadBalancer as needed.
    3. Add any default deny rules to block all other inbound traffic. Place this lower priority.
    4. Integrate all your App Services into the secured VNet subnet either using regional integration or gateway.
    5. Now the NSG rules will be applied to all App Services in that subnet uniformly. No need for app-level configs.
    6. To add new IPs, simply update the allow rule on the NSG. Changes apply instantly.

    This way you get a single source of truth for access control at the network layer, while App Services inherit it automatically without config overhead.

    Hope that helps.


    0 comments No comments