I have an Azure App Service with HTTPs enabled only and Azure Active Directory as a way to Authenticate to the service.
I am planing to geo-locate my App Service on a second region but at the moment I am trying to test that Azure Traffic Manager works with my current site. However, there are few things that are confusing me:
When I created the ATM, the DNS name was HTTP and not HTTPs. Seems there is no option to have a DNS name with HTTP.
After I added the endpoint, I tried to navigate to the URL http://foo.trafficmanager.net and it redirects to https://foo.trafficmanager.net/ and shows the following error. This site is not secure. Seems there is a certificate error. Why is rerouting automatically to HTTPs now?
Is there any documentation step by step to configure ATM? I am not interested in purchasing a domain, I am totally fine with https://foo.trafficmanager.net/ as my URL as long as the connection is secure all the time.
Azure Traffic Manager supports probing both over HTTPS and HTTP. For HTTPS:
Server-side certificates are not validated
SNI server-side certificates are not supported
Client certificates are not supported
There are more details you can take a look: FAQs and Traffic Manager endpoint monitoring.
With HTTPS, the monitoring port should change from 80 to 443 and also your monitoring path points to a valid page for your service.
Update
There is an issue that what does Azure Traffic Manager work. For more details, see What is Traffic Manager.
Azure Traffic Manager is a DNS-based traffic load balancer that
enables you to distribute traffic optimally to services across global
Azure regions while providing high availability and responsiveness.
The DNS of Traffic Manager itself just uses the HTTP protocol. But it can probe both HTTP and HTTPS. All the HTTPS for your application just set in your Web App Service.
Hope this will help you.
Related
I have a web server on -premises and have configured the Azure Traffic Manager with external endpoint that points to the public IP address of the web server.
The web server's external DNS is www..com. As per the Microsoft Documentation i have added the traffic manager DNS Name : http://.trafficmanager.net as a CNAME record to www..com.The monitoring status on the Traffic Manager reports that the on-premises server endpoint is healthy.
The issue i am having is that now when i go to www..com, where it used to work correctly before it now reports:
"Account Suspended" and the following has been appended to the URL: /cgi-sys/suspendedpage.cgi.
Im not sure what the issue is here as it was working without the traffic manager but now it is not accessible.
Any guidance on why this is occurring would be greatly appreciated.
As the comment from #juunas, the Traffic Manager would not modify the URL, it uses DNS to direct client requests to the most appropriate service endpoint based on a traffic-routing method and the health of the endpoints. Clients then connect to the service endpoint directly, not through Traffic Manager. Traffic Manager does not see HTTP traffic between client and server. Read here for more details.
If you see any HTTP error, it must be coming from your application. Not sure what the web app what you are using, and you may google that error for more references. Such as “This Account Has Been Suspended” – How to Fix Website Problem?
Hope this could help you.
I have a Azure cloud service (abc.cloudapp.net) which has authentication enforced using OpenId-Connect. Recently I decided to put it behind a Traffic Manager (abc.trafficmanager.net) for maintenance reasons. After reading about how Traffic Manager works on Microsoft docs, my understanding (as per the flow diagram below) was that when someone hits the TM, it will simply do the DNS look-up for my cloud service and return a 302 with the location as abc.cloudapp.net (or IP may be) and then the client follows the redirect. The documentation clearly says so :
The most important point to understand is that Traffic Manager works at the DNS level. Traffic Manager uses DNS to direct clients to specific service endpoints based on the rules of the traffic-routing method. Clients connect to the selected endpoint directly. Traffic Manager is not a proxy or a gateway. Traffic Manager does not see the traffic passing between the client and the service.
But what I am seeing (through Fiddler/Chrome dev-tools) is that TM seems to be hitting the actual cloud service endpoint causing authentication issues as the redirect URL in my cloud service doesn't match the TM URL and so forth.
Is TM supposed to do this? Or am I missing something crucial here. Below is a related thread.
RequireNonce is 'true' (default) but validationContext.Nonce is null in Azure Traffic Manager , OpenIdConnectAuthentication
Traffic manager operates at DNS level, there is no 302 since it does not operate using HTTP. When a client makes a DNS query for your domain name, traffic manager will send back a DNS reply that the service is over there.
The client will then connect to the Traffic Manager URL/your custom domain using the IP address given by traffic manager.
So the URL the user sees doesn't change, traffic manager just tells them where the service is.
Say, I have two app service (HTTPS only is enabled):
https://myapp1.azurewebsites.net
https://myapp2.azurewebsites.net
I can call both app service endpoints using HTTPS successfully.
Then I created a traffic manager and add above two endpoints to traffic manager, say:
myapps.trafficmanager.net
After the traffic manager is created and endpoint added, the trafficmanger host name myapps.trafficmanager.net is also automatically added into custom domains of two app services. But without SSL binding to traffic manager host name.
Then if I call traffic manager endpoint using HTTPS: https://myapps.trafficmanager.net, I will got untrusted SSL cert error/warning. That is expected.
Since traffic manager just works on DNS level, the real request is actually send to the app service endpoint which has correct SSL cert binding. My question is:
From security point of view, is it safe to call the non-cert binding traffic manager endpopint using HTTPS in my code (say, using .NET HttpClient) but just ignore the cert error?
I recently set one of these up as well and fought with it for a bit. The short answer is that it is probably safe, but it sounds like you may be using the Traffic Manager incorrectly. You shouldn't be using the URL in the Traffic Manager as your end point if you want to use SSL. Instead configure your vanity domain name, mycoolsite.com to point to myapps.trafficmanager.net, using a DNS CNAME record.
If you want to use SSL and a single URL you should configure the custom URL and install an SSL cert at the service level. It should be same custom URL on both app services. This must be configured at in the app service, not in Traffic Manager.
I had to read this a few times to understand how it works under the hood, but it was helpful.
So in summary, to set it up properly, the steps would be:
Configure custom/vanity domain on both app services
Install the SSL cert on both app services
Setup and configure the Traffic Manager
Point the custom/vanity URL to the traffic manager using a DNS CNAME record
There is no need to bind a cert with traffic manager since the server certificate is not validated when using traffic manager health probes via HTTPS. Moreover, the traffic manager works at the DNS level. The clients connect directly to the selected endpoint, not through Traffic Manager.
In this case, you could use HTTPS for endpoints and use health probe via HTTPS. Even you could not bind a cert with traffic manager, you could make sure that the monitoring port is configured correctly in Traffic Manager (e.g. 443 instead of 80) and also your monitoring path points to a valid page for your service.
Another SO answer explains this more details. If you still want to make this warning disappearing, you can get a free SSL from letsencrypt.org and add that to your custom domain with the *.trafficmanager.net.
In our scenario, we are providing SaaS platform which will automatically create customer specific traffic manager (xxxx.trafficmanager.net) each time when customer onboard our platform.
The traffic manager will points to app service cross regions.
The problem is, that if customer calls the traffic manager with HTTPS, the CERT warning will be shown. I know we can bind the cert to each of customer's traffic manager and upload the cert to azure. But since the traffic manager is automatically created in runtime, how can we automatically get a cert and bind to xxx.trafficmanager.net?
Traffic Manager works at the DNS level. It sends DNS responses to direct clients to the appropriate service endpoint. Clients then connect to the service endpoint directly, not through Traffic Manager. You will bind your cert to the endpoint, not Traffic Manger. If the endpoint is an Azure Web App, you can use the CLI or Powershell to bind the cert.
Therefore, Traffic Manager does not provide an endpoint or IP address for clients to connect to.
Traffic Manager supports probing over HTTPS. Configure HTTPS as the protocol in the monitoring configuration.
Traffic manager cannot provide any certificate validation, including:
Server-side certificates are not validated
SNI server-side certificates are not supported
Client certificates are not supported
I have a Website running on Azure. I added a custom domain and an SSL to enable https access to it.
All is fine. Few days ago Azure had a network issue in a datacenter where my website is hosted( West Europe) and of course my site was affected during that time.
So i've decided now to put my site under traffic manager and deploy it in 2 regions.
Configuring Http acces with ATM works. But when i switch to Https( choosing https protocol in ATM config page) all endpoints get "Degraded" status.
so, my questions are: do i have to add certifcate to traffic manager in order to use https? How can i add https endpoints to ATM?
Traffic Manager supports health probes via both HTTP and HTTPS. Note that when using HTTPS health checks:
The server certificate is not validated (hence there's no need to
register the certificate with Traffic Manager)
Client certificates are not supported
SNI certificates are not supported
Please check the above. Please also check that your monitoring port is configured correctly in Traffic Manager (e.g. 443 instead of 80) and also your monitoring path points to a valid page for your service.
These pages may be helpful:
Traffic Manager endpoint monitoring
Troubleshooting 'Degraded' endpoint status
If you still can't get it to work, please raise a Support ticket. If you do solve the problem, please reply back to let us know what it was
Regards,
Jonathan Tuliani, Program Manager, Azure Traffic Manager