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.
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.
So I'm working on building scripts to deploy Azure resources using the Az modules in PowerShell. I am new to Azure Traffic Manager, so I'm wondering if what we are looking to do is even possible, and if so, how.
We have an API Management Service (APIMS) with a handful of APIs in it that point to a few different web apps within Azure. So the way it works currently is we have a client application that will post to a specific API operation via its APIMS URL.
We are looking at the idea of using Traffic Manager purely for moving traffic from one APIMS to a another in the event that we need to create a new APIMS. I can add the existing APIMS as an endpoint to the Traffic Manager as an external endpoint using its public IP address. But beyond that, here's what I'm unsure of:
How exactly would traffic actually get routed through the traffic manager, through the APIMS, to the specific API post? (as in, what would the client application need to specify as where it's sending its post?). Or would this even work??
If we create a new APIMS, can we then simply add that as a new endpoint to the traffic manager (again, as an external endpoint via its IP address), and then delete the old APIMS endpoint?
I did find this question that's similar, but that answer is using Add-AzureTrafficManagerEndpoint as opposed to New-AzTrafficManagerEndpoint, which is what I'm using and apparently does not support -DomainName as a parameter.
Traffic manager does not route traffic, it only does domain name resolution. You could use TM for that. For your custom domain in traffic manager (say contoso.com) you can add CNAME record pointing to contoso.azure-api.net (it's preferable to use CNAME instead of A and APIM service IP may change in certain scenarios). And add SSL certificate in APIM for contoso.com. What will happen in that setup:
Client wants to make request to https://contoso.com/myapi
Client will perform DNS lookup for contoso.com and see CNAME record pointing to contoso.azure-api.net
Client will perform DNS lookup for contoso.azure-api.net and see APIM IP address
Client will try to open SSL connection to APIM
APIM having SSL certificate available will accept the connection
Client will send request.
All this does not require any special configuration from your client apart from setting it up to use "contoso.com" as a hostname for your API. Later if you want to switch to a different APIM service you could go and update TM. Client will not require any changes.
The one thing to know is that this particular setup does not require TM per se. As all you really need is a custom domain from any DNS provider because all you need to do to switch traffic from one APIM to another is update CNAME record.
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.
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.
I want to provide failover proof url for my service endpoint to users using traffic management. I have a service instance running at http://vm1.cloudapp.net/myservice:8888/index.html. If this instance goes down then the service auto starts on vm2 at http://vm2.cloudapp.net/myservice:8888/index.html n vice versa.
I want azure to hide the underlying service urls to user and expose the service at http://myservice.trafficmanager.net
Is this possible? If so, how ? From reading the documentation of traffic manager service, it looks like you can failover only at DNS level and not at url endpoint level
There are several parts to this.
Firstly, you are right that Traffic Manager works at the DNS level. It doesn't see your HTTP traffic and hence doesn't see the full URL. Since your two services instances have different DNS names, there's no issue here--you configure Traffic Manager with both names as separate 'endpoints', and Traffic Manager will direct traffic to those endpoints by providing one or other in each DNS response.
Secondly, you want to hide the URL paths. Since Traffic Manager works at the DNS level, it doesn't see your HTTP traffic and hence doesn't see the URL, only the domain name. Therefore this is something you have to handle at the application level (just as you would for a single-instance service that doesn't use Traffic Manager).
The only thing to be careful of is to make sure you configure the correct URL port and path in the Traffic Manager endpoint monitoring configuration. Just make sure that Traffic Manager shows your endpoints as 'Online', and you're good.
Jonathan