I have created an azure function app and it does not have any access restrictions or VNet applied. But I have locked down the storage account associate with the app using private endpoint. When I am connected to azure VPN client, the log streaming is not working it is giving an error saying "Unable to open a connection to your app. This may be due to any network security groups or IP restriction rules that you have placed on your app. To use log streaming, please make sure you are able to access your app directly from your current network."
When disconnected from VPN client logs are working properly.
What could be going wrong ?
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.
We are developing a app on azure virtual machine and the VM has ngnix installed with TLS version 1.2. The app consists of two action which performs salesforce and office365 oauth flow. The app worked pretty fine on local and azure app service too.
Problem
For some reason, we are moving the app to azure VM. Here is the problem, after oauth the flow returns a code and we need to generate the access_token using that code through a https request to office365 endpoint. The endpoint response is either timeout or Error Read ECONNRESET.
Analysis
The only working URLs,
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net
https://myapp.vault.azure.net/secrets/{Secret-Name}?api-version=2016-10-01
Both the above is used to fetch the access token and key vault secrets. Luckily, this is working pretty fine and I am able to get all the secrets from azure key vault.
But the below urls are either no response timeout or Error: Read ECONNRESET
https://login.microsoftonline.com/{Tenant-Id}/oauth2/v2.0/token
https://test.salesforce.com/services/oauth2/token
I’ve also tried other public or fake rest APIs like,
https://reqres.in/
https://jsonplaceholder.typicode.com/
None of them seems to be working. Does anyone faced this kind of issue?
Just clarify the answer from the comments for more references.
The Error Read ECONNRESET means the other side of the TCP conversation abruptly closed its end of the connection. This is most probably due to one or more application protocol errors. Refer to this SO for details.
Moreover, you have only working URLs from Azure Instance Metadata service and Azure Key Vault service, other public or fake rest APIs are failures. So you properly face internet connectivity issue on that VM or VNet itself. You could check if the firewall is blocking the outbound traffic to the Internet on the local VM or NSG rules.
In the end, some change in the firewall settings fixes this issue.
I've deployed a Java Function with the App Service Plan on Azure and also associated a VPN (connecting back to my data center) to that App Service Container. My application is trying to send an HTTP request to another server in my data center over the VPN but the requests fails with a "Time out" exception. If I connect directly to my data center VPN (not through Azure) it works no problem.
Also, strangely, if I recreate the function in C# it works from Azure.
1) I've tried connecting to different ports with a raw TCP socket, no luck.
2) I've dumped the list of adapters to a log and the VPN adapter doesn't show up. Should it?
What's my next step in troubleshooting?
I'm taking my first foray into Azure Service Fabric using a cluster hosted in Azure. I've successfully deployed my cluster via ARM template, which includes the cluster manager resource, VMs for hosting Service Fabric, a Load Balancer, an IP Address and several storage accounts. I've successfully configured the certificate for the management interface and I've successfully written and deployed an application to my cluster. However, when I try to connect to my API via Postman (or even via browser, e.g. Chrome) the connection invariably times out and does not get a response. I've double checked all of my settings for the Load Balancer and traffic should be getting through since I've configured my load balancing rules using the same port for the front and back ends to use the same port for my API in Service Fabric. Can anyone provide me with some tips for how to troubleshoot this situation and find out where exactly the connection problem lies ?
To clarify, I've examined the documentation here, here and here
Have you tried logging in to one of your service fabric nodes via remote desktop and calling your API directly from the VM? I have found that if I can confirm it's working directly on a node, the issue likely lies within the LB or potentially an NSG.
I'm trying to connect my Azure Web App to an Existing VPN.
To connect to this VPN I must give to the admin some configurations, but I'm not sure of HOW can I provide them from Windows Azure.
As far as I have understand is all about creating the Virtual Network and the "connect it".
Like:
Create Virtual Network
Create Public Gateway
Create Local Gateway
Connect something somehow
https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-site-to-site-resource-manager-portal
In my specific case, for the configuration, are required a lot of parameter that I don't know how / where to find:
VPN Endpoint IP
IKE (Encryption type, Authentication Method, Diffie-Hellman Group, Sec Lifetime, Preshared secret)
IPSEC (Perfect Forward Secrecy)
Network profile
In the docs there is a link to Check Point NGX and Microtik so I check out this tutorial:
https://blogs.technet.microsoft.com/netgeeks/2017/07/11/creating-a-site-to-site-vpn-ipsec-ikev2-with-azure-and-mikrotik-routeros/
But how can I get this parameter to perform the connection? Do I need to install extra software on my WebApp? How can I include my web app in the VPN?
And, is there any simplify way for Web App that does not include creating the whole infrastructure?
Thanks in advance
As EvilSnobu said, you can use Hybrid connections to connect your Azure APP service and your on-premises.
Hybrid Connections can be used to access application resources in other networks.
My understanding is that you have Azure Web App and you need to
connect to an on-premises network via VPN?
You are right, the Hybrid connection feature requires a relay agent in the network that hosts your Hybrid Connection endpoint.
You should download and install Hybrid connection manager (HCM) on your local machine and use it to connect to that app service.