Earlier we had Windows App Service Plan and App services within the plan have VNet-integration enabled to connect to on-premises services. It used to reach on-premises services from the app service by resolving the domain names.
Recently Microsoft announced that regional VNet-integration for Linux App Services feature is Generally Available. we tried to migrate all our windows app services to Linux. Fortunately, we did not face any issues with subnet-delegation. But after the migration, the Linux app services are not able to reach on-premises service. It says UnknownHostException from the java code and tried from Kudo console, there also it says domain name is not being resolved. and we noticed that logs are not being pushed to Application Insights.
The next day, we just tried with IP address instead of domain names, it worked. For Application Insights, we could not do anything. To just confirm for Application Insights, we disconnected the vnet-integration for app service, then the app is able to send logs to application insights.
So what would be the problem?
You cannot create a Linux Web App in an App Service plan already hosting non-Linux Web Apps. I suppose you have created new app service plan and app service for Linux to manage regional VNet Integration.
Your app cannot resolve addresses in Azure DNS Private Zones without
configuration changes
The feature is fully supported for both Windows and Linux web apps.
All of the behaviors act the same between Windows apps and Linux apps.
Also, from https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances
In the scenario of name resolution from App Service Web Apps in one virtual network to VMs in a different virtual network, it requires customer-managed DNS servers forwarding queries between virtual networks for resolution by Azure (DNS proxy). See Name resolution using your own DNS server.
By default, app service use the Azure providing DNS server in the delegated VNet, it don't know your on-premise DNS records. You need to deploy a custom DNS server in your Azure virtual network and target network to forward the DNS query.
For Application Insights, you could check if you have a rule blocking the outbound call to application insights if you have set the app setting WEBSITE_VNET_ROUTE_ALL to 1. Refer to this.
If you integrate your app with your VNet, the default behavior remains
as it was. You would only be able to reach RFC1918 addresses
(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and service endpoints.
Just like with Windows, the feature now supports outbound calls into
the VNet on non-RFC1918 addresses as well. To reach all addresses you
need to set the app setting WEBSITE_VNET_ROUTE_ALL to 1, your app will
then enable all of the outbound traffic from your app to be subject to
NSGs and UDRs.
Finally, all of a sudden it got resolved by itself. And when we asked Microsoft Support, its mentioned that they have done recent network update in their backbone network.
Since we did not know what was the issue, we did not migrate Win to Linux in our higher env, we rollback to Windows and there was no issue after that.
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 am trying to setup the availability test (URL-Ping test) in Azure Application Insights, but the endpoint that requires the basic authentication. And the endpoint(Azure App Services) resides in internal App Service Environment (ASE).
So, can anyone suggest me how to check the availability for the internal azure app services hosted inside internal App Service Environment.
A bit late the response, but here it goes.
Please have a look at this article that explains how to do it. Basically you need to configure rules on your NSG to allow inbound traffic from your Application Insights instance.
If your URL is not visible from the public internet, you can choose to selectively open up your firewall to allow only the test transactions through. To learn more about the firewall exceptions for our availability test agents, consult the IP address guide.
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.
I am planning on using an outsourcing team for data processing and want to avoid them downloading or storing client data on their local machines. To facilitate this, I want to create an Azure VM in which they can do all their work (msoft office, etc.) and access an ASP MVC app hosted as an app service in Azure. The MVC app is integrated with the corporate AD and for the outsourcing logins I want to see if the request is coming from my VM or the internet (the latter gets denied). So far I have:
Created a ASP MVC5 app and an Azure VM
Connected the two via VPN (point to site)
When I attempt to go to the public URL for the website on the VM, I get the "this page can't be displayed" thing, which leads me to believe I'm on the right track (now I have to update the hostfile of the machine to the private IP of the mvc app service app?). How do I do the following:
Connect to the app service via web browser (this needs to be over the vnet so that I can pick and choose in the app code who can login outside the network)
Get the network ip of the app service so I can update the VM hostfile
Am I on the right track here? Thanks in advance!
Your understanding of Azure App service is not accurate. Azure App service cannot be accessed via a private IP. They already sit inside a private vnet. They can be only accessed via public hostname with a common DNS name (azurewebsites.net)
Your scenario requires the Azure Web app and the VM to reside in the same VNET, which is not possible. There is another offering called ILB ASE, which allows you to do this. But it's a more elaborate setup. See this for more information: Using ILB with AN ASE
In your scenario you can restrict access to the web app via IP Restrictions module. See this article: IP & Domain Restrictions in Azure App Service
I understand this not the solution u wanted. What you want can be achieved via ILB ASE, but that is an expensive and elaborate set-up.
HTH
you may want to try using cloud service, though MS recommends App Service, you requirement doesn't fit into App service..
Official documentation from MS: https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-startup-tasks-common
Block a specific IP address
You can restrict an Azure web role access to a set of specified IP addresses by modifying your IIS web.config file. You also need to use a command file which unlocks the ipSecurity section of the ApplicationHost.config file.
Can anybody tell me how to connect a web app running on azure to existing web services (.ASMX) on premises?
We do not have the source for the services they are exposed by third party applications and we do not want to open them up to public access.
Sounds like Azure's Service Bus Relay Service might be what you're looking for...
There might be three options based on your scenario. But I personally prefer the third one.
If you used azure cloud service (web role, worker role), you can use Windows Azure Connect. It builds an IP-sec communication between the azure machine and your local machine. Then you can connect to your local service through the its IPv6 address.
If you used azure virtual machine to host your azure project you can use Virtual Network. It's more powerful than the Windows Azure Connect.
You can use Windows Azure Service Bus Relay. It can open your local service to the cloud regardless how your azure project is hosted. But since it's only support WCF of Service Relay, and since you cannot change codes and config of your service, you might need some more works. Maybe you can create a small WCF on your local machine as a proxy, register it to Service Bus Relay, and pass all request/response to your local service.