How are two different appservices identified - azure

How are two appservices in the same appservice plan uniquely identified though I understand they have different urls but it is explained that at the backend this urls are converted into IP addresses however the appservices have the same Outbound IP addresses

URLs are not converted into IP addresses on the backend side, domain names like myapp.azurewebsites.net are resolved to IP addresses by DNS servers - and afterwards the client sends an HTTP request to the derived IP address which belongs to a server on Azure side. Indeed this means that the Azure backend wouldn't be able to assign a request to the right app service so there is another property necessary for this matching - which is the HTTP Host header. This header is used by an internal load balancer (called a "front end" on Azure side) which distributes the request to the worker(s) your application is running on.

Yes the inbound and outbound IP addresses has little to do with the selection of app services running on ASP's, the outbound IP can even be totally different than the ASP addresses if you are using a NAT GateWay or other services.
If you want a more specific answer please ask a more specific question as in what problem are you trying to resolve?

Related

azure linux web app whitelist IP gets 401 error

Our website is hosted on the Azure Linux web app, the site pulls data from third-party vendors. So we need to whitelist our website IP address to their server but after adding the IP for whitelisting still getting 401 unauthorized errors.
We checked the vendor and the IP has been configured properly but why we are getting 401 errors while pulling data via API call.
The IP address we found from Azure Portal --> web app --> select properties and the virtual IP address.
Any help or recommendation will be helpful.
If I understand you correctly, you are trying to whitelist the web app against the firewall for the third-party vendors app?
If so, then the virtual IP address that you have added is the ingress IP address for the web app. You need to add the outbound IP addresses from the Properties blade for the web app to the vendor's firewall.
You should note that there can be up to 11 of these IP addresses. Also, if you scale the web app up or down to a different service plan, or perform any change that will result in a new scale plan, the IP addresses will change. This does not apply to scaling out to multiple instances.
Using a static IP address solved the problem.

Use CloudFlare so I can access website hosted in Azure via IP Address

I am very new to Cloudflare. So please bear with me. I need to access my website (hosted in Microsoft Azure - App Services) via IP address instead of the domain name.
To do this, I need to add HOST=www.mydomain.com into the HTTP header when requesting the website via IP address.
I heard it can be solved via Cloudflare, but the person I asked will not elaborate further. Is it possible? If yes, what service should I purchase? Any manual or instruction will be appreciated.
If Cloudflare isn't possible, do you have any service recommendations?
Thanks :)
The reason the host header is needed is because Azure App Services are multi-tenant (multiple apps on a single IP) by default. So, the server needs some way to know where to route your request to (the host name). In addition, IPs are not guaranteed to be static (they can change as you scale for instance).
It should be possible to secure a single static IP address using the following method -
https://learn.microsoft.com/en-us/azure/app-service/overview-inbound-outbound-ips#get-a-static-inbound-ip
What is unclear is whether or not this IP would also be dedicated (meaning only your domain would use it). This is what would be required in order to allow you to access the app service without a hostname specified.
Cloudflare will not solve this issue, as it sits at the DNS layer (domain name access). Accessing a server via IP would bypass Cloudflare entirely.

Azure Load Balancer Get Originating Client IP

I am using the Azure Standard Load Balancer (client -> external lb => firewall => internal lb => server), when my api request gets to the server I need to be able to identify the originating clients ip address.
I have tried to use X-Forwarded-By and some other request headers but it looks like they're either not supported or have been stripped.
I have not been able to find any documentation online pertaining to the issue - does anyone know how I can access the client ip address?
Thanks
It sounds like you are using the LB for a HTTP backend. Thus, its important to understand what LB does - and what not. There are many good articles out there if you search of "azure load balancer vs application gateway". Here is one example which sums it up well:
The Load Balancer is a TCP/UDP load balancing and port forwarding
engine only. It does not terminate, respond, or otherwise interact
with the traffic. It simply routes traffic based on source IP address
and port, to a destination IP address and port.
Thus, it does not add anything to your HTTP headers etc.
So, LB is more like a router than a proxy. If you want the latter, I suggest you look at Azure Application Gateway. This, btw, can include Web Application Firewall. So you might be able to reduce three components into one.

Keeping my out bound IPs on App Service

I have a website on Azure App service and I've asked a service provider to open up for my outbound IP addresses. How can I make sure that those IPs won't change?
If there is a new IP assigned to my app service, all calls from that IP will be blocked by the service provider.
The outbound IP addresses are per stamp/scale unit that the apps are on. It is not specific to a certain webspace or resource group.
You can find the stamp/scale unit in the Properties blade under the FTP Hostname endpoint. It should list out something like "waws-prod--". All of the apps in the same stamp/scale unit number in that region will have the same outbound IP addresses, as they are per stamp/scale unit.
The list of outbound IP addresses is not completely static but normally it does not change. Check out the reasons for the IP change in the thread outlined by Ruslan.
If you need both incoming and outgoing to be static, you will need an App Service Environment. This will give you dedicated IP addresses.
For more information see: https://learn.microsoft.com/en-us/azure/app-service/environment/app-service-app-service-environment-intro and https://msdn.microsoft.com/en-us/magazine/mt793270.aspx.

Azure traffic manager -IP whitelisting

I have a Azure Traffic Manager over a geo distributed cloud service. I need to lock down my cloud services which are primarily web apis so that they are accessible to only a certain range or IP ADDRESSES. Is there a way to achieve this? Or may be there are ways to restrict IP addresses on cloud services. But with a combination of traffic manager on top of that would that work?Does traffic manager flow the source ip address to the cloud services?
Traffic Manager cannot filter traffic. It just responds to DNS queries from clients.
The source IP address will be the original one because the traffic doesn't go through Traffic Manager, it only tells the caller where to go, and the caller then calls your service directly.
Late to the party but: if you ended up using a whitelist on for example an Azure App Service than you will need to add the addresses of Traffic Manager as well. Otherwise Traffic Manager will not be able to check the health of your App and report it as degraded.
You can find it here: https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-faqs#traffic-manager-endpoint-monitoring
Direct link: https://azuretrafficmanagerdata.blob.core.windows.net/probes/azure/probe-ip-ranges.json
Also late to the party but we were restricting our App Services by IP address and all of a sudden our traffic managers started to display degraded after working fine for years. After lots of investigation we think that Azure added some new traffic managers that were on different IP addresses so they were getting blocked by our IP restrictions. The original restrictions had included a small range of IP addresses for the traffic manager but this list looks like its expanded. The best solution is to allow the traffic manager through, not based on its IP address buts its service tag as below :

Resources