We are currently running a virtual network with a web cluster (2 servers) hosting our front end .NET web application and a service cluster (2 servers) hosting our internal .NET WCF service which then connects to the database.
So at the moment we have one external IP which points to www.ourwebsite.com which is load balanced over our web cluster. We then have an internal load balancer on an internal IP which points to wcf.outwebsite.local using an internal DNS server so all the traffic to the back end remains in our private virtual network.
We are looking to deploy this onto azure app service premium in an internal network. We would use 2 app pools, 1 for the front end application and one for the backend WCF service so they can scale independently of each other what I cant work out is how we can set internal URL's or IP addresses for the back end WCF service and ensure that they cant be accessed by the outside world.
Does any one know if this is possible in azure app service so we can secure internal services as I cant find anything in there documentation about it?
I guess you are referring to Azure App Service Environment.
You can control inbound requests via Network Security Gateways. See this article:
https://azure.microsoft.com/en-us/documentation/articles/app-service-app-service-environment-control-inbound-traffic/
Related
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.
I have an Azure WebRole, which publishes a WCF Service with PerSession setting. This means, session needs to be preserved for a long time... This is because of synch-framework and cannot be changed.
Now I have the problem when I want to use Multi-Instances on that Web Role (Classic Azure Cloud Service)
Can I configure an Application Gateway with endpoints not to the Public WebRole but to each Instances, so that the Gateway handles the Balancing?
How?
Thanks
Technically, the Application Gateway support for multi-tenant backends, you could configure an IP address or FQDN of your instances in the backends. Here is a quickstart: Direct web traffic with Azure Application Gateway - Azure portal
However, the Application Gateway is known as application layer (OSI layer 7) load balancing which enables you to manage traffic to your web applications. Perhaps the traditional layer 4 load balancer is better for balancing WCF Service. Moreover, In Cloud Services, you get a load balancer automatically configured when you create the service. You could get more explanation in this question.
Ref: Get started creating an internal load balancer (classic) for cloud services
I have configured an Application Gateway in front of multiple Azure Web App backend pools as per this article.
In addition to providing a WAF, I use the Application Gateway to offload the SSL connection to the backend pools. I have configured the backend pools to use the FQDN of the App Service instances as they're not currently deployed into a VNET.
Based on the following scenario:
Request to custom.com:443 ---> Application Gateway ---> custom.azurewebsites.net:80
My concern is that the connection from the Application Gateway to the Web App is unencrypted over port 80 and I haven't found anywhere that describes this connectivity as happening over the Azure backbone network. Is there any risk that this traffic could be sniffed and compromised?
Spoke to Microsoft support who said the traffic from my Application Gateway to my Web App will stay on the Microsoft backbone.
He also pointed me to the following knowledge article; which states:
If the destination address is for one of Azure's services, Azure routes the traffic directly to the service over Azure's backbone network, rather than routing the traffic to the Internet. Traffic between Azure services does not traverse the Internet, regardless of which Azure region the virtual network exists in, or which Azure region an instance of the Azure service is deployed in.
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
I have multiple web apps on Azure that I want to put behind an Application Gateway in order to use a single domain name with path routing.
However, my web apps needs to connect to a db outside of Azure. So I wonder what will the IP of the requests from these web apps to the db would be? I hope it will be the gateway public IP so I only have to authorize one IP at my db provider but I don't find any docs to confirm it (or not).
So I wonder what will the IP of the requests from these web apps to
the db would be?
If you want your web apps to connect a database outside Azure, you may need App service Environment. Because the Web Apps need VNet to connect other resources. Also, due to the date base is outside Azure , you need to create VPN gateway to connect it. This connection is between the Web App and the database, not Application Gateway and Database.
So, the IP of requests from those Web Apps is not the IP of Application Gateway, It depends on the VNet in App Service Environment.
This picture explains how this environment works:
I hope it will be the gateway public IP so I only have to authorize
one IP at my db provider but I don't find any docs to confirm it (or
not).
Also, if you still want to use one IP to connect other resources, you can also add Internal Loadbalancer to achieve that.
You can see more details about Integrating your ILB ASE with an Application Gateway to help your deploy resources.
Please let me know if this answer helps.
I would suggest using the Azure Web App's Hybrid connection. This provides a TCP tunnel in a secured fashion between your azure web app and your SQL db. There is a service bus in between and you have to install the relay agent in your network that does the outgoing communication to this service bus.
Hybrid connection diagram
Details are at:
https://learn.microsoft.com/en-us/azure/app-service/app-service-hybrid-connections
The app gateway's public IP address can't be leveraged nor is it necessary to manage connections between Azure Web Apps and databases outside of Azure. The web apps have their own IP addresses.
On another note, my blog post may be useful to understand how the architecture and configuration between app gateway and azure web app.