I got lost with Traffic Manager setup and custom domain name.
First I had two mobile apps in 2 regions (westeuropeapp.azurewebsites.net and brazilapp.azurewebsites.net) as endpoints of Traffic Manager (trafficmanager.trafficmanager.net). It was Working.
Then I wanted to use a custom domain name with subdomains: westeurope.mydomain.com, brazil.mydomain.com and trafficmanager.mydomain.com. So I followed Azure doc instructions and created CNAME for my subdomains pointing to the two mobile apps and to traffic manager. Then I added westeurope.mydomain.com (resp. brazil.mydomain.com) as hostname for my west europe mobile app (resp. brazil mobile app).
But when I navigate to trafficmanager.mydomain.com I got a 404.
I checked the DNS resolution with Dig, I can see that trafficmanager.mydomain.com has a cname to trafficmanager.trafficmanager.net which has a cname to westeuropeapp.azurewebsites.net which resolve to ip xxxx.This looks good.
If I type that ip into my browser I got 404. But if I type westeuropeapp.azurewebsites.net I got my app running. I also checked westeuropeapp.azurewebsites.net in Dig and it resolves to the same ip as above.
What am I missing? (I don't even talk about SSL, it will be next post.)
You also need to add trafficmanager.mydomain.com to the Mobile Apps as a custom domain.
App Service shares IP addresses across apps, so the only way for it to identify which app your request is bound for is the Host header. By adding the custom domain App Service knows to route requests for that domain to that app.
Once you add the mobile apps to the traffic manager, trafficmanager.mydomain.com will automatically gets added to the mobile app, in the host name assigned to site(App->Custom domain). Wait for sometime for the changes to propagate. After the trafficmanager is propogated, You need to add custom domain to both of your mobile apps.
This video has the details for adding custom domain for the traffic manager. https://www.youtube.com/watch?v=1ggz9qZpVHo
Related
Some of my apps are not working from some customers site, I later discovered that this was because I am using the default websites for my app hosting that is the url is myapp.azurewebsites.net which was not whitelisted on the customers firewall. The customer whitelisted my website domain name and its sub domain names .i.e mywebsite.com and *.mywebsite.com are all whitelisted.
If i were to create CNAME record which has a CNAME pointer to the azure default web app for example myapp.mywebsite.com points to myapp.azurewebsites.net, will this get around the issue ? Or do I need to whitelist myapp.azurewebsites.net Or its IP address that is the IP address of myapp.azurewebsites.net ?
Firstly, by default, apps hosted in App Service are accessible directly through the internet and can reach only internet-hosted endpoints. So, typically, anyone with the URL without any specific local network/firewall/proxy restrictions can access the WebApp URL.
As I understand, your WebApp is open to the public and only a few users (on a specific network), have trouble accessing the site. Plus, there are no access restrictions that you have implemented from the WebApp side.
Just to highlight,
Network administrators often deploy proxy servers, firewalls, or other
devices, which can help secure and give control over how users access
the internet. Rules designed to protect users can sometimes block or
slow down legitimate business-related internet traffic. This traffic
includes communications between you and Azure over the URLs listed
here.
Reference : Allow the Azure portal URLs on your firewall or proxy server
So, on case-case basis, for the affected network, you may have them add appservice.azure.com (Azure App Services) in the allowed list.
Or
As your customer performed – “The customer whitelisted my website domain name and its sub domain names .i.e mywebsite.com and *.mywebsite.com are all whitelisted.” have them add the URLs to allowedlist.
Or
Since IP address of your WebApp (see the reasons for the change), the best route would be for you to set up a custom domain for your WebApp.
Kindly check this doc - Tutorial: Map an existing custom DNS name to Azure App Service
The CNAME maps to the app's default hostname instead, which is less susceptible to change. | | Wildcard | *.contoso.com | CNAME record. |
-- As a side note (as indicated above), by setting up access restrictions, you can define a priority-ordered allow/deny list that controls network access to your app. Which is the opposite of your scenario, just sharing as FYI, in case you wish to know about access restrictions from WebApp side. Set up Azure App Service access restrictions
Let me get this out of the way, I am not that familiar with DNS setup. But I am wondering if I can have this setup. I cannot test this right now because I control the our Azure portal but not the domain name provider.
We will have 2 subdomains. For example, api.contoso.com and app.contoso.com
We currently have a single Azure App Service Plan with two apps inside. One is the frontend SPA, and the other is the backend.
Checking the IP address and Custom Domain Verification ID of the two services, they are the same! So I am wondering if the setup of the two subdomains is possible. If not I'll consider moving out one of the App Service to its own App Service Plan or maybe Just map a single custom domain to the frontend. Any tips or suggestion?
Yes this is completely possible and a very standard setup. You will use CNAME records in your DNS setup which means you won’t use the IP address of the VM that your app service plan is on. Instead a CNAME DNS record maps your custom domain to another domain - in this case the domain name of an app service.
You will configure a different custom domain on each app service (and ideally a certificate to protect it).
E.g. your DNS might look like this:
app.contoso.com CNAME myapp.azurewebsites.net
api.contoso.com CNAME myapi.azurewebsites.net
I.e. when a request is made for a domain on the left it will be forwarded to the domain on the right.
When a request is made for either of your custom domains the custom domain will be in the host header. This request will be routed to the app service gateway which will look at the host header in order to know which VM to route the request to and once on the correct VM which app service to serve the actual request.
Once you have the above setup you can query the DNS system to see the complete route that a request would take, e.g.:
nslookup app.contoso.com
may return:
Name: waws-prod-xyz-123-1234.uksouth.cloudapp.azure.com
Address: 99.99.99.99
Aliases: app.contoso.com
myapp.azurewebsites.net
waws-prod-xyz-123-1234.uksouth.cloudapp.azure.com
With this command you'll see the actual VM that your app service plan is on (I've made up the IP and VM name here!).
Is there a way to assign an IP to a Azure App Service? I just deployed my application and it's working correctly. But the problem is we need our domain to point to that App Service. Since our domain is website.com and the app service domain is website.azurewebsites.net is there a way to point the website.com to the azure url? We have a reverse proxy where we can just assign the IP and that will load the site. So if the site is website.azurewebsites.net and ip is 123 then in our reverse proxy we just assign 123 to our domain website.com. So whenever someone access website.com they are presented with website.azurewebsites.net. Is there a way to assign an IP to this app service?
Like silent mentioned, use CNAME mapping to map the domain, alternatively Web Apps actually have a list of possible outbound IP addresses, but I dont think thats reasonable, just use CNAME (you also need to verify your domain in Azure).
App Services is a shared servers which means many App Services is behind same IP hence you need to configure Custom Domain on your App Service to get it to work:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain
The shared IP can be found under your App Service on the blade Settings->Properties.
The name is "Virtual IP address"
I am trying to experiment a little bit the different configuration possibilities in Azure and I am stuck trying to correctly configure SSL custom domains when using more than one Web Site (App Service) behind a Traffic Manager.
Without problem, I was able to:
Attach a custom domain ( subdomain.mydomain.com ) to an Azure App Service ( subdomain1.azurewebsites.net )
Attach a custom domain ( subdomain.mydomain.com ) to an Azure App Service ( subdomain1.azurewebsites.net ) behind a Traffic Manager ( subdomain.trafficmanager.net) (addressed here)
But when I try to add a second App Service behind the Traffic Manager, I get the following issues:
1. Cannot attach my custom domain ( subdomain.mydomain.com ) to the second App Service ( subdomain2.azurewebsites.net ). Error message is:
Failed to update hostname bindings:
The host name subdomain.mydomain.com is already assigned to another Azure website: subdomain1.
I don't understand how SSL will work with the second website if I can't add subdomain.mydomain.com in the list of domains it listens to (and in fact, it doesn't if you don't add it).
2. Cannot add the second App Service to the Traffic Manager's list of endpoints. Error message is:
Failed to save configuration changes to Traffic Manager profile 'mytrafficmanager'.
Error: Some of the provided Azure Website endpoints are not valid: One or more conflicts detected in traffic manager configuration. Multiple domains point to region "West Europe": subdomain1.azurewebsites.net, subdomain2.azurewebsites.net
But when I read the documentation it does seem possible to add more than one endpoint in the same region:
If your profile contains multiple endpoints in the same Azure region, then traffic directed to that region is distributed evenly across the available endpoints (based on the configured endpoint enabled/disabled status and the ongoing endpoint monitoring). If you prefer a different traffic distribution within a region, this can be achieved using nested Traffic Manager profiles.
The example using Traffic Manager and App Service on MSDN's documentation only shows how to do it with one App Service.
Am I doing anything wrong? If yes, what is the right way to add several websites/App Services behind a traffic manager in Azure?
Traffic Manager does support multiple endpoints in the same region. The challenge is that the App Service has restrictions on multiple Apps in the same region sharing the same custom domain. This impacts on Traffic Manager, since the Traffic Manager profile DNS name is automatically added as a custom domain in your apps when adding them to Traffic Manager.
We are in the process of publishing new documentation that covers this exact scenario. Pasting the new text below:
Can I use Traffic Manager with more than one web apps in the same region?
Typically, Traffic Manager is used to direct traffic to applications deployed in different regions. However, it can also be used where an application has more than one deployment in the same region.
In the case of Web Apps, the Traffic Manager ‘Azure Endpoints’ type does not permit more than one Web App endpoint from the same Azure region to be added to Traffic Manager. The following steps provide a workaround to this constraint:
Check that your Web Apps within the same region are in different web app 'scale units', i.e. different instances of the Web App service. To do this, check the DNS path for the <...>.azurewebsites.net DNS entry, the scale unit will look something like ‘waws-prod-xyz-123.vip.azurewebsites.net’. A given domain name must map to a single site in a given scale unit, and for this reason two Web Apps in the same scale unit cannot share a Traffic Manager profile.
Assuming each Web App is in a different scale unit, add your vanity domain name as a custom hostname to each Web App. This requires all Web Apps to belong to the same subscription.
Add one (and only one) Web App endpoint as you normally would to your Traffic Manager profile, as an Azure Endpoint.
Add each additional Web App endpoint to your Traffic Manager profile as an External Endpoint. This requires you to use the ARM experience for Traffic Manager, not ASM.
Create a DNS CNAME record from your vanity domain (as used in step 2 above) to your Traffic Manager profile DNS name (<…>.trafficmanager.net).
Access your site via the vanity domain name, not the Traffic Manager profile DNS name.
Regards,
Jonathan Tuliani, Program Manager, Azure Traffic Manager
Jonathan,
This issue is still confusing when integrating SSL.. I'm not trying to add instances to the same region, but diff regions.
https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-how-traffic-manager-works/#traffic-manager-example
This article does a good job of explaining the routing, but minus the SSL..
From the image. Say this is my configuration.. I have a *.contoso.com wildcard SSL. Of the 3 endpoints, contoso-us, contoso-eu, contoso-asia - which one do I install the SSL? Preferably all 3, but I can't set the all to use the custom domain and the SSL..
What am I missing here?
I have a website on Azure Cloud Services, and I have enabled a wildcard for my website like: *.mywebsite.com
Then if a customer registers and select as his subdomain: client1.mywebsite.com, I only save the subdomain associated with my customer in the database. I don't need to do anything on the portal. This works as well on Azure Web Apps (Azure Websites).
Now, if my client goes to his domain provider and sets a DNS entry like:
www.client1.com CNAME client1.mywebsite.com
I can handle that correctly in Cloud Services without having to register "www.client1.com" in the Azure Portal. Is that possible in Azure Websites without having to add www.client1.com to the Azure Portal?
Short answer, no, it is not possible.
Explanation.
What you type in the address bar is the name that is presented to a web server in the HTTP request. Regardless of the underlying DNS responses. If a DNS look up of www.example.com provides an IP Address, whether a CNAME or an A record, that is where it will go and get data from. The only way to change that is with a HTTP Redirect.
In Azure the incoming server name is used to direct traffic to the correct web app (On the same set of IP Addresses there might be thousands of other websites registered) The only way it knows how to distinguish where to send the request is from the incoming server name.
Why this worked on Cloud Services.
Behind a cloud service was an IP Address that was unique to your servers behind it. When a cloud service got a HTTP request, it would process it, because there was nowhere else to send it.