I was doing some experiments with the Traffic Manager (new azure portal). I configured a new Azure Traffic Manager and added two Azure WebApp endpoints.
But when trying to browse Traffic Manager endpoint I am getting
This site can’t be reached, niktm.trafficmanager.net’s server DNS address could not be found.
The Status' of the TM endpoint are "Enabled" and both the Web apps are up and running. Also, the Azure Traffic Manager Monitoring status is Online.
I did this few times and still getting the same result. Am I missing something?
Another reason why Azure Traffic Manager could not working with Azure App Service (Web App) is because you are using Basic service-tier, which doesn't support Traffic Manager feature. As a result, a Traffic Manger Profile has the Inactive status and Stopped for Endpoint monitor status.
This site can’t be reached, niktm.trafficmanager.net’s server DNS address could not be found.
If I do not add any endpoints in my traffic manager, Monitor status is Inactive.
To verify DNS propagation using http://digwebinterface.com/, I could find similar result as yours niktm.trafficmanager.net.
And if I browse to {my traffic manager name}.trafficmanager.net, I could see same error message in browser.
If I add available endpoints for traffic manager, I will see Dig result like below, and I could browse to {my traffic manager name}.trafficmanager.net.
I suspect that your endpoints do not really add to traffic manager even though Azure portal shows they are enabled and online. You could try to create a new traffic manager and add endpoints to check if it will work fine, if Azure traffic manager still/always not work fine in your subscription, you may need to create a support ticket to fix this issue.
Related
Earlier we had Windows App Service Plan and App services within the plan have VNet-integration enabled to connect to on-premises services. It used to reach on-premises services from the app service by resolving the domain names.
Recently Microsoft announced that regional VNet-integration for Linux App Services feature is Generally Available. we tried to migrate all our windows app services to Linux. Fortunately, we did not face any issues with subnet-delegation. But after the migration, the Linux app services are not able to reach on-premises service. It says UnknownHostException from the java code and tried from Kudo console, there also it says domain name is not being resolved. and we noticed that logs are not being pushed to Application Insights.
The next day, we just tried with IP address instead of domain names, it worked. For Application Insights, we could not do anything. To just confirm for Application Insights, we disconnected the vnet-integration for app service, then the app is able to send logs to application insights.
So what would be the problem?
You cannot create a Linux Web App in an App Service plan already hosting non-Linux Web Apps. I suppose you have created new app service plan and app service for Linux to manage regional VNet Integration.
Your app cannot resolve addresses in Azure DNS Private Zones without
configuration changes
The feature is fully supported for both Windows and Linux web apps.
All of the behaviors act the same between Windows apps and Linux apps.
Also, from https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances
In the scenario of name resolution from App Service Web Apps in one virtual network to VMs in a different virtual network, it requires customer-managed DNS servers forwarding queries between virtual networks for resolution by Azure (DNS proxy). See Name resolution using your own DNS server.
By default, app service use the Azure providing DNS server in the delegated VNet, it don't know your on-premise DNS records. You need to deploy a custom DNS server in your Azure virtual network and target network to forward the DNS query.
For Application Insights, you could check if you have a rule blocking the outbound call to application insights if you have set the app setting WEBSITE_VNET_ROUTE_ALL to 1. Refer to this.
If you integrate your app with your VNet, the default behavior remains
as it was. You would only be able to reach RFC1918 addresses
(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and service endpoints.
Just like with Windows, the feature now supports outbound calls into
the VNet on non-RFC1918 addresses as well. To reach all addresses you
need to set the app setting WEBSITE_VNET_ROUTE_ALL to 1, your app will
then enable all of the outbound traffic from your app to be subject to
NSGs and UDRs.
Finally, all of a sudden it got resolved by itself. And when we asked Microsoft Support, its mentioned that they have done recent network update in their backbone network.
Since we did not know what was the issue, we did not migrate Win to Linux in our higher env, we rollback to Windows and there was no issue after that.
Hi, I am trying to configure a basic traffic manager on my azure account. But I always got 404 not found when I using the traffic manager URL.
I have two app service for the TM endpoints:
1. xxxus.azurewebsites.net
2. xxxeu.azurewebsites.net
TM Url is:
xxxtm.trafficmanage.net
I was able to use www.whatsmydns.net to check what the tm is heading to.
But when I use the TM url, I got this:
Did anyone has the same issue? Looking forward to your help
Thank you
I ran into the exact same thing and just found the solution - the app service plan needs to be at least a standard SKU. I was using a free tier, and that was causing my 404.
From Microsoft's Traffic Manager documentation:
Only Web Apps at the 'Standard' SKU or above are eligible for use with Traffic Manager. Attempts to add a Web App of a lower SKU fail. Downgrading the SKU of an existing Web App results in Traffic Manager no longer sending traffic to that Web App.
Currently, you could not add web apps from different subscriptions to the same traffic manager configuration since It is not possible to use Web Apps from multiple subscriptions with the same domain name. Refer to this. You can check this on your side. If so, you can remove one website from your endpoint, then add the website to the same subscriptions.
Moreover, the 404 error always happen due to the domain name could not be resolved by its IP address. It may be one of the following reasons:
The custom domain configured is missing an A record and/or a CNAME record.
The browser client has cached the old IP address of your domain. Clear the cache and test DNS resolution again. On a Windows machine, you clear the cache with ipconfig /flushdns.
You can follow the quickstart to create a Traffic Manager profile, then follow this to verify your traffic manager settings.
I encountered similar issue. My problem is one of my app service is a free tier, so I scaled it up to standard one. And delete my traffic manager and reinstalled and add the service endpoint again, the issue gone.
It's strange. Nslookup will take you to the right web app but the browser will show 404. Changing the app service plan to 'Standard' SKU fixed it for me.
What am I trying to do
I have to azure apps deployed as App services. To make rest post easy let's call them "blog" and "landing_page". Both of them are hosted, so they URL are blog.azurewebsites.net and landing_page.azurewebsites.net.
I want to configure "something" in Azure with following rules:
if user access http://mydomain/ - content of landing_page.azurewebsites.net
if user access http://mydomain/blog - content of blog.azurewebsites.net
What I tried
After reading documentation, I have to reject Traffic Manager because it works on DNS level. From the other two I decided to use Application Gateway, because it should work on eny Endpoint (Any Azure internal IP address, public internet IP address, Azure VM, or Azure Cloud Service).
I configured my Application Gateway setting backend to: landing_page.azurewebsites.net. But in "Backend health" the app status is unhealthy. I tried also:
blog.azurewebsites.net - unhealthy
www.wp.pl (polish news portal) - is working
gazeta.pl (polish news portal) - is working
stapp.space (my blog) - this is same as piotrstapp.azurewebsites.net and status is unhealthy
Question :)
What did I wrong? Maybe should I use something else on Azure? Or am I missing something?
Make sure that custom probes is turned on and configured in the HTTP settings of the WAF for your site. If you don't the Application Gateway will try to go to the IP of the App Service Environment without passing a Host header, which won't work and will throw the probe into an unhealthy state resulting in a "502 Gateway Proxy" error.
There is a great article here
You may want to check out Azure's application gateway path-based rules function:
Create a path-based rule for an application gateway by using the Azure portal
Today I was doing some experiments with the new Traffic Manager (new azure portal). I configured a new Azure Traffic Manager and added an Azure Website endpoint. But the Traffic Manager endpoint status says Status of the endpoint as "Stopped" where the Web app is up and running. Also the Azure Traffic Manager Monitoring status is Inactive. I am confused. I did this few times and still getting the same result.
Am I missing something?
Traffic Manager is only eligible for use with App Services (formerly known as Azure Websites and Azure Mobile Services) at the 'Standard' level or above. If you downgrade your App Service to the Free or Basic tiers, it shows as 'stopped' in Traffic Manager (this is somewhat misleading and we are working to improve the experience).
Mentioned here.
I've deployed an Azure cloud service (not a web site) and I'm trying to access it via a browser. When I attempt to browse to the 'site url', it times out. Nor can I ping the Public VIP listed in the Azure dashboard for the service. Hrm.
Now, if I log on to one of the instance VMs, fire up IIS Manager and find the IP address it has listed for the web site, I can browse to that one. Weird.
I'm sure I'm just thick and am missing something simple here. Can anyone point me in a good direction to make my service's site url browsable?
The service definition I'm using is https://github.com/NuGet/NuGetGallery/blob/master/src/NuGetGallery.Cloud/ServiceDefinition.csdef, if that helps.
You can check the "endpoints" tab under the cloud service section of the Azure portal.
There should be an endpoint listed for HTTP that redirects to your VM. You can forward different public ports on the cloud service to individual ports on specific VMs within the cloud service.