Accessing service on a Virtual Machine from azure app service - azure

We have got VMs on Azure and services are running in there.
We are trying to deploy our MVC Web application to Azure App service, which accesses some of the services from the VM using the private IPs but it can't connect to the service hosted on the VM using the private IP. We were assuming that all of our resources will be in the same network, can anyone help with this?
Thanks

Azure App service are having two kinds of hostings
Single Tenant (App Service Environment) which is dedicated to the customer
Multi tenant ( shareable across other customer subscription inside a data center scale unit)
If your application is hosted as multi tenant application meaning app service URL {WEbAppName}.Azurewebsites.net then its internet facing application and if it needs to connect to any VNET (Virtual Network) hosted service then it needs to integrate to any or same VNET.
How to do App service VNET Integration:
https://learn.microsoft.com/en-us/azure/app-service/overview-vnet-integration#regional-virtual-network-integration
Once the App service integrated with VNET then ideally it has connectivity with all the services present inside the same VNET or with peered VNET.
How to confirm connectivity from App Service to VNET hosted resource.
Go to App Services application => Advanced tools or console => perform below commands sequence wise as the HTTP communication happens through this sequence:
nslookup {Destination_FQDN} {Optional-DNSServer}/nameresolver {Destination_FQDN} {Optional-DNSServer}
tcpping {Destination FQDN}
curl -v {DestinationFQDN}
Common Scenarios:
If you're receiving connection refused it means its NSG is not allowing the communication.
If you're getting request time out it means it could be due to firewall or no proper routes to reach to destination.
If its connection abort it means its intermediate device is not passing connection through.
Troubleshoot connectivity issues using Azure Network Watcher: https://learn.microsoft.com/en-us/azure/network-watcher/network-watcher-connectivity-portal

Related

VNet Integration For Azure Web App and Azure SQL Server

I have an Azure Web App and an Azure SQL Server, both in the same subscription. Both of them are connected to the same VNet Subnet as shown in the below snapshots. The SQL Server is configured not to Allow Azure Resources and Services to access the server, as it should only permit access from either the connected subnet or a set of IP rules.
Unfortunately, the SQL Server is actively refusing any connection from the web app stating that the web app IP is not allowed to access the server.
The interesting thing is that I have the exact same configuration working on another subscription.
What could I be missing?
Snapshots:
1- Here you can see the web application connected to the "webapps" subnet
2- And here you can see the SQL Server connected to the same subnet
3- And that's the error I get
TLDR
The configuration is correct, but an app service restart may be required.
VNET Integration
The configuration of using a virtual network to connect a web app to a SQL database is correct: if the web app is connected to the same subnet/vnet which is allowed in the database's ACLs, and the Microsoft.Sql service endpoint is enabled on the subnet, the web app is able to communicate to the database. This is the whole reason for service endpoints: you do not need to configure with IP allowances on the database.
As to why the configuration still resulted in an error, it could be the order in which the resources were configured. We were experiencing the exact same setup and issue (which is what let me to this question)!
We connected our web app to the subnet/vnet but had not enabled the service endpoint on the subnet. We then added/allowed the subnet/vnet as an ACL in the database, during which we were prompted to enable the Microsoft.Sql service endpoint (we did). However, even after waiting ~20 minutes, we were still seeing the same connection issue.
However, once we restarted the app service, the issue went away and the web app could connect to the SQL database.
I suspect the issue is due to enabling the subnet's service endpoint after the app service was connected to the subnet. The app service must need a restart to refresh the app service's vnet config/routing.
Configuration NOT needed
Contrary to other answers, you do not need to configure firewall IP allowances nor enable access to Azure services and resources. In fact, there are downsides to both approaches:
Enabling access to Azure services and resources allows any Azure-based resource to connect to your database, which includes resources not owned by you. From doc:
This option configures the firewall to allow all connections from Azure, including connections from the subscriptions of other customers.
Unless you're using an App Service Environment (which is significantly more expensive than normal App Service plans), your web app's outbound IP addresses are neither static nor specific to your application. From doc:
Azure App Service is a multi-tenant service, except for App Service Environments. Apps that are not in an App Service environment (not in the Isolated tier) share network infrastructure with other apps. As a result, the inbound and outbound IP addresses of an app can be different, and can even change in certain situations.
The second point is further elaborated upon in this Github issue:
IPs are indeed shared with other App Service plans (including other customer's plans) that are deployed into the same shared webspace. The network resources are shared among the plans in a workspace even if the computing instances are dedicated (e.g. in Standard tier). This is inherent to the App Service multi-tenant model. The only way to have a dedicated webspace (i.e. outbound IPs) is to deploy an App Service plan into an App Service Environment (ASE) (i.e. Isolated tier). ASE is the only thing that offers true single-tenency in App Service.
So neither of the above options will truly harden your SQL database if you want to isolate communication from only your web app. If you have resources in the same subnet, using vnet integration is the correct way to solve the problem.
If resources cannot be in the same subnet, the solution is to use Private Endpoints.
Virtual networking in Azure is quite different from how it would work on premises.
I had similar problems in production environment and digging deep, the working solution (meeting security standards and create a secure connection to the database) was to create a private endpoint for SQL access in the virtual network. Then all the calls to the SQL were performed internally (it did not go on the internet), and the databases were denying all public calls.
In your case now, you deactivated the Allow Azure apps to access so when your app is trying to access the SQL the server checks the ip to find out if it is white listed or not. So fast solutions would be one of the following:
Enable Azure Web apps to access SQL
Find all outbound IPs of your web app and register them in you SQL firewall/ security settings.
If you talk about a proper production environment with security regulations I would suggest you go down the more tedious path of private endpoints.
You have to configure the outbound IPs from the app service in the sql fw.
You can find them under properties of your app service. Documentation.
The reason why is that the VNET integration doesn't give your app service an outbound IP in the VNET you configured it in, so the FW you configured doesn't work.
I have working web apps which access storage accounts and KVs. These storage accounts and KVs accept traffic from a particular subnet and the web apps have been configured to integrate with those subnets. I did face an issue where even after integration apps were not able to access these resources. What worked for me was, I changed the App service SKU from Standard to Premium and restarted the app. As you can see, it warns that "Outgoing IPs of your app might change". This is not guaranteed solution but it worked for me.. several times! Not sure about SQL server though. Private endpoint does seem like the way to go but you can give this a try.

Azure logic app with AS2 connector through VPN

I am currently setting up an Azure logic app with an AS2 connector.
Now I am being asked to connect to the partner via VPN. From googling I think that is possible to somehow add the logic app to a VNET and then setup a site-to-site VPN gateway.
It is my first time to work with either Logic apps or AS2.
Question:
Is it possible to setup an Azure logic app with AS2 connector that connects through a VPN?
How might I do it?
Yes, it's possible.
First of all, you need to connect to Azure virtual networks from Azure Logic Apps by using an integration service environment (ISE), With ISE, you deploy the Logic Apps service into your virtual network.
When you create a logic app or integration account, select your ISE as their location. Your logic app or integration account can then directly access resources, such as virtual machines (VMs), servers, systems, and services, in your virtual network. This virtual network can be an existing VNet that has a VPN connection to the partner or you can select an Azure VNet as a peer for your environment.
You may note those prerequisites before your deploy ISE, and your ISE needs four empty subnets that aren't delegated to any service. You also can optionally set up NSGs by filtering network traffic across subnets.
Here is a detailed explanation in this blog--Introducing Azure Logic Apps Integration Service Environment (ISE).
For more references: https://learn.microsoft.com/en-us/azure/logic-apps/connect-virtual-network-vnet-isolated-environment-overview

Can Azure Functions be deployed to a Vnet?

Can Azure Functions be deployed inside a VNet?
If I created an App Service environment in a VNet and then picked that App Service Plan when creating the Function, Would that mean that the Azure Function is deployed inside the VNet and have the same restrictions etc. as defined by the VNet?
Yes, you can host an Azure function on Azure App Service Environment which provides a fully isolated and dedicated environment for securely running App Service apps or your functions. You will have fine-grained control over inbound and outbound application network traffic. So it could be restricted by network security groups.
ASEs are isolated to running only a single customer's applications and
are always deployed into a virtual network. Customers have
fine-grained control over inbound and outbound application network
traffic. Applications can establish high-speed secure connections over
VPNs to on-premises corporate resources.
VNet Integration with Azure function is a feature to use Azure Functions to connect to resources in an Azure virtual network. VNet Integration is only for making outbound calls from your app into your VNet.
In this case, you just need to deploy your Azure function in a VNet with ASE instead of VNet integration. Read Services that can be deployed into a virtual network
Yes it can be deployed inside a VNet. I would recommend you to go through the documentation
integrate Functions with an Azure virtual network
An Azure Function can be deployed on an App Service Environment. The App Service Environment is deployed on your own VNET which can have access to on-prem resources via ExpressRoute.

Do i need point to site vpn with azure waf and web app

I have been messing around with Azure trying to get a web app up and running. My plan was to create a WAF and site the web app behind that, each in a seperate subnet and then to use the service endpoint tech to point the web app to a database.
I have been stopped in my tracks almost straight away with the revelation that if i want to use a WAF in front of the web app i have to configure the networking in the web app but when i choose a vnet it says that no gateway is configured for the selected VNET.
My question being is do i have to use point to site VPN to get this setup working? i thought that it would work like
INTERNET ---> VNET ----> subnet ----> WAF -----> subnet -----> web app ----> service endpoint ------> DB
but that doesnt seem to be the case. I am not keen on the idea of having to install a client certificate on every machine in our network that might want to access this website (it is currently internal). I suppose i am looking for the best of both worlds. Accessible from the internet but having the added comfort of having something like a WAF sat in front of it to make up for any security inadequacies which might exist somewhere in said app.
Thanks
As far as I know, you could not deploy a web app in a VNet unless you are using the App Service Environment(Isolated). App VNet integration could not do it. It allows you to securely access resources in a VNet. For example, you have a database on an Azure VM in a private VNet. You could not access it from Azure web app to this database if this database is not available publicly, but you could reach it via app VNet integration.
VNet service endpoints is another different service. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. If you enable such service endpoint like Azure SQL database( which differs from the database on Azure VMs) in a VNet, this means only the resource in these authorized VNets could access your SQL database unless you add an exclusion like the public IP address in the firewall of the database.
In this case, you could put a Public facing Azure app gateway at the high level of the web app service, then add the Azure app gateway public IP in the IP restriction of the web app.This will restrict to access to web app via Azure web app gateway over the Internet. Also, you could control the network inbound and outbound in Azure app gateway subnet NSG. See Network security groups on the Application Gateway subnet if you want to add an NSG to the app gateway subnet level. I think these are enough if you just want to create a WAF and site the web app behind that.
Furthermore, if you want to let web app privately access the Azure SQL database. You could deploy a web app in an ASE, then enable the VNet service endpoint for Azure SQL database. App VNet integration does not need to use it with the service endpoint.
If you want to use Azure WAF with Azure App Service (multi-tenant) you can, you just need to ensure you are supplying the host header with your request.
If you want you Azure Web App on a VNet, you will need to run your Azure Web App on an App Service Environment (Isolated). This version of Azure Web App is more expensive but allows you to apply NSG's to the VNet to fully control access to your web app. Personally I think WAF w/ Azure App Service (multi-tenant) should meet your needs.
We have it all documented here:
https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-web-app-overview
https://learn.microsoft.com/en-us/azure/application-gateway/configure-web-app-portal

Hosting web api as webapp in azure along with VM in same data center

I have a VM running SQL Server in Azure East US2. I also hosted a webapi as azure web app. Connection string used in webapi is being routed through internet gateway right now. I want to ensure that both of these services are hosted on same data center so that they communicate over LAN instead of internet gateway.
I was trying to setup a VNET and when I tried adding this VNET to webapi, it asks to setup VPN gateway. Why do I need to setup VPN gateway, are they not aware of being on same data center. Can't they be put on LAN without setting up VPN.
When you deploy both your VM and your Web App in Azure East US2 they land on the same geo-region. Please note that a lot of Azure Regions do have more than one facility (the thing you call Data Center), and you have no control over where exactly within a region (i.e. East US2) your resource will be deployed.
Now, if you want to talk to your SQL Server on an Azure VM from the Web App, you have to use VNet integraton. Because you are not deploying into a App Service Environment, you have to connect your web app to the VNet where your SQL Server is. The way to do this is by implicitly utilising a Point-to-Site VPN Connection between your web app and your VNet.
Do not worry, the whole process is automated and you do not have to deal with certificates and certificate roll-over, but there is a need for VPN Gateway. That's way you are being asked for the VPN Gateway.
But you should really consider using Azure SQL DB instead an SQL Server on VM.

Resources