24

In Azure, I turned on IP restrictions for:

  • Web App (Networking > Access Restrictions)
  • SQL server (Firewalls and virtual networks > Add client IP)
  • SQL database (Set server settings)

The solution still builds locally and in DevOps (aka Team Foundation Server).

However, Azure App Service Deploy now fails:

##[error]Failed to deploy App Service.
##[error]Error Code: ERROR_COULD_NOT_CONNECT_TO_REMOTESVC
More Information: Could not connect to the remote computer 
("MYSITENAME.scm.azurewebsites.net") using the specified process ("Web Management Service") because the server did not respond. Make sure that the process ("Web Management Service") is started on the remote computer.
Error: The remote server returned an error: (403) Forbidden.
Error count: 1.

How can I deploy through the firewall?

Do I need a Virtual Network to hide Azure resources behind my whitelisted IP?

Alfred Wallace
  • 1,741
  • 1
  • 14
  • 32
  • Are you trying to deploy directly (from local) or from DevOps? I assume you local IP address is included in your IP whitelist? – Bryan Lewis Apr 02 '19 at 15:09
  • First, check into DevOps. Then, deploy automatically from DevOps. My local IP has been added to all whitelists - IP restrictions have been confirmed to be in effect by trying different IPs via VPN. – Alfred Wallace Apr 02 '19 at 15:18
  • Sorry, further clarification. Is DevOps in this case your own TFS server (on prem) or Azure DevOps? – Bryan Lewis Apr 02 '19 at 15:22
  • We use Azure DevOps. – Alfred Wallace Apr 02 '19 at 15:23
  • I just realized that the SQL server is set up with SQL Server Authentication - does it mean the SQL server doesn't actually need a firewall, only the Web App? – Alfred Wallace Apr 02 '19 at 15:55

6 Answers6

41

The REST site scm.azurewebsites.net must have Allow All, i.e. no restriction. Also, Same restrictions as ***.azurewebsites.net should be unchecked.

It does not need additional restriction because url access already requires Microsoft credentials. If restrictions are added, deploy will fail the firewall, hence the many complications I encountered.

Alfred Wallace
  • 1,741
  • 1
  • 14
  • 32
  • 2
    +1 - Thanks for this - I didn't understand from the Azure Portal's user interface as to what this setting was being used for, so thought I was doing right in checking it. Turns out, this is what was stopping me from making my processes work. – Brett Rigby Nov 11 '19 at 12:07
  • This seems like a security issue waiting to happen. – GaTechThomas Jun 05 '23 at 18:22
9

I think the answer is incorrect as you might face data ex-filtration and that's the reason Microsoft provide the feature to lock down SCM portal (Kudu console) There is also a security issue on Kudu portal as it can display the secret of your keyvault (if you use keyvault) and you don't want someone in your organisation to access the Kudu portal for example.

You have to follow this link https://learn.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops

It will provide you Azure DevOPS IP range that you need to allow on the SCM Access restriction.

Update: To make it works as expected and to use App Service Access Restriction (same for an Azure Function), you need to use the Service Tags "AzureCloud" and not the Azure DevOPS IP range as it's not enough. on the Azure Pipeline logs, you can see the IP blocked so you can see that it's within the ServiceTags "AzureCloud" in the Service Tags JSON file It's not really clear on the MS Doc but the reason is that they struggled to define a proper IP range for Azure DevOPS Pipeline so they use IPs from AzureCloud Service Tag. https://www.microsoft.com/en-us/download/details.aspx?id=56519 enter image description here

HoLengZai
  • 301
  • 3
  • 13
  • The upside of creating a single access restriction with the AzureCloud tag is that you don't need to keep updating it when Azure IP addresses change, the downside is that you're allowing all datacenter public IP addresses, from all regions. As per the link included https://learn.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops ideally you should be creating access restrictions for just the AzureCloud IPs in the geography your Azure DevOps organization is in. So that limits your exposure but requires it to be refreshed from time to time. – Robert Shattock Aug 03 '21 at 08:02
  • 1
    @RobertShattock, I thought the same as you but your comment is unfortunately incorrect. The link that you mentioned is related to their Azure DevOPS Services Server (=hosted at Microsoft) but not the VM used by Azure DevOPS Pipeline itself. And as mentioned on Microsoft docs or forum (i forgot where), they mentioned that the VM can be "used" from any Azure region (only the VM, not the DevOPS Services server itself. It is really 2 different things). – HoLengZai Aug 04 '21 at 15:41
  • 1
    additional thought: If you want to be closer to a zero-trust behaviour, you should add 2 tasks on your pipeline with Azure CLI to temporary allow AzureCloud then remove it (need to check if Azure CLI support these ServiceTags parameters for App Service yet but I guess it is possible now) – HoLengZai Aug 04 '21 at 15:42
4

Try adding the application setting WEBSITE_WEBDEPLOY_USE_SCM with a value of false to your Azure App Service. This was able to solve my issues deploying to a private endpoint.

David Christiansen
  • 5,869
  • 2
  • 36
  • 42
ToddWolf
  • 41
  • 1
  • Hmm, this solution didn't work for me. I'm having DevOps deploy to an App Service Slot that has a Private Endpoint. Any other ideas? – Cole Sep 04 '21 at 14:36
3

In my case I was deploying using Azure DevOps and got the error. It turned out the app service where my API was being deployed to, had the box checked "Same restrictions as xxxx.azurewebsites.net", under access restrictions or IP restrictions. you need to allow scm.azurewebsites.net.

Johnny A
  • 31
  • 1
2

In my case it was because the daily quota was overpassed.

So the solution in this case is either wait or pay more (scale up) the app service

screenshot

chelder
  • 3,819
  • 6
  • 56
  • 90
1

In my case this was because the wrong agent (Windows Hosting) was being used when I should have been using a self hosted internal agent... so I needed to change it at the following location

enter image description here

72GM
  • 2,926
  • 3
  • 27
  • 33