We have a VM with the following DNS on Azure:
erpone-jsl.cloudapp.net
Frequently the Default Website on this VM becomes inaccessible with the error message 'this web page can not be displayed.' However this happens only for those users who are using a particular internet service provider in the Western part of India.
If this particular ISP resets its server, the site becomes accessible.
OR if we restart this particular VM, the site becomes accessible.
But the problem recurs after a few hours or few days.
We noticed that the issue recurs when Windows 2012 (Datacenter) updates itself on the VM - but we are not sure of this, yet.
The IP pool from where this problem occurs is 116.199.168.0 to 116.199.168.21
This ISP is telling us that their IP is being blocked by Azure VM Firewall but we have not blocked or restricted any IP from our VM or IIS.
Can some one throw light on this strange phenomenon-
Page requests coming from only this range of IP is unable to access the website
but it resolves temporarily when either the VM is restarted or the ISP's Server is restarted.
Not sure what's happening in this particular case, but... Windows Azure doesn't offer a per-cloud-service firewall that provides IP-blocking. This is done at the VM level (your VMs).
That said: Have you tried accessing any other Windows Azure cloud services from those IP addresses which are having trouble accessing erpone-jsl.cloudapp.net? This would be a good test to perform, with test web applications in the same data center as erpone-jsl as well as one in another data center. You can also try putting a test website up in Azure Web Sites, free tier, which will let you deploy something in just a few minutes, with no cost, for testing purposes. You can use ftp to download diagnostic logs from Web Sites.
One thing you can do is inspect the IIS logs (Virtual Machines, or web/worker roles of Cloud Services), to see if the offending IP addresses show up in the log (and I'd suggest checking the logs of the test web site cloudapp.net's as well).
If all else fails, you can then open a support ticket, to see if Azure support has any light to shed on this.
Related
I have an Azure website (website.mycompany.com) that uses a WCF service for some data. The WCF Service sits behind an Azure Traffic Manager (service.mycompany.com) running in "priority mode", with 2 instances of the service for failover handling. With priority mode, the primary always serves up the data first, unless it's unavailable. If unavailable, the 2nd instance will reply.. and so on down the line.
We've had a few instances recently where the primary endpoint for service.mycompany.com was offline. For "partnerships" who point to service.mycompany.com, they detected the switch and all was fine. Lately however, our own site (website.mycompany.com) does NOT detect the traffic manager switch, and the website has errors since the service fails to reply.
Our failover endpoint in these instances is up, and in the past the Azure website detected the switch, it's only recently we've encountered this issue. Has anyone experienced similar issues? Are there perhaps any DNS changes that we need to tweak in our Azure Website to help it detect TTL's?
Has anyone experienced similar issues?
Do you mean the traffic manager can't switch to another endpoint immediately?
Traffic manager works at the DNS level, here are the reasons why traffic manager can't switch immediately:
The duration of the cache is determined by the 'time-to-live' (TTL) property of each DNS record. Shorter values result in faster cache expiry and thus more round-trips to the Traffic Manager name servers. Longer values mean that it can take longer to direct traffic away from a failed endpoint.
The traffic manager endpoint monitor effects the response time. More information about how azure traffic manager works, please refer to the link.
The following timeline is a detailed description of the monitoring process.
Also we can check traffic manager profile using nslookup and ipconfig in windows. About how to vertify traffic Manager settings, please refer to the link.
By the way, because traffic manager works at the DNS level, it cannot influence existing connections to any endpoint. When it directs traffic between endpoints (either by changed profile settings, or during failover or failback), Traffic Manager directs new connections to available endpoints. However, other endpoints might continue to receive traffic via existing connections until those sessions are terminated. To enable traffic to drain from existing connections, applications should limit the session duration used with each endpoint.
I'm going to refer you to my answer here because while the situation isn't exactly the same, it seems like it could have the same solution. To summarize, I find it likely that you have a connection left open to the down service that isn't being properly closed. This connection is independent of TTL, which only deals with DNS caching, and as such bypasses Traffic Manager completely.
For a pet project I'm attempting to spin up a VM on Azure that can run as my webserver, providing an Umbraco powered site, as well as some other web applications (such as a forum + planner) that require PHP. Now I've followed the steps of every guide out there, but I cannot get an external connection through to the VM's IIS and I can't find out why.
I'm hoping someone else has been through the pain that I'm currently experiencing and might point me in the direction of whatever setting I'm missing.
Spun up the VM with Server 2012 R2.
Configured it to run IIS.
Installed Umbraco, disabling the default web site and setting the Umbraco site as my default on port 80.
Checked that http://localhost maps to Umbraco - this works.
So after I had it running internally, I started tackling the external connection setup.
Navigated to the Network Security group, and added the inbound Http rule on Port 80.
Disabled Windows Firewall entirely for the sake of testing.
Added a custom dns name to the front of the xxx.[azurecloudappurl].com
Now my requests resolve but then timeout and I can't see why or where? Has anyone else experienced this? Every guide states that it should be as easy as this.
As you can visit localhost on your VM env, so it seems there is no problem with your env on VM.
Have you added the endpoint with 80 port of your VM server on Azure manage portal? As by default, the endpoint with 80 port is not opened.
You can refer to How to set up endpoints on a classic Azure virtual machine for how to add an endpoint on Azure VM.
In addition to #Gary Liu's answer if you are doing it on Azure Portal(and not on classic one).
For any new VM added through Azure exists a Network Security Group (NSG). Ports need to be opened in order to make them accessible from outside the VM. Specifically to allow your VM to serve requests coming to port 80 you need to enable HTTP port in Network Security Group. Here are the steps:
Search for VM Name on Azure portal.
Select the VM by Clicking on VM Name.
Click on Network Interfaces from left menu and select(double click) the listed one. This will show overview of Network Interface.
Now click on Network Security Group.
Click on Inbound Rules.
Add new rule selecting service as HTTP(TCP/80).
Voila done!
And here is the answer to manage an inbound rule
I set up a simple asp.net web forms test site for learning Azure, with a simple DB. Works fine locally. I deployed it to Azure. Then went through learning curve on the need to separately deploy the DB, link the resource, check connection strings and so on.
There's an issue, where the program on the site gets an error. I'm going through many paths to try to diagnose it. This question is about one specific path.
Several articles say that for the website to use the DB, I have to add the IP address of the website to the allowed IP addresses of the DB server.
https://azure.microsoft.com/en-us/documentation/articles/sql-database-create-configure/
However, I can't find the IP address for my FREE Azure website. When I researched this, it looks like there is no available fixed IP address for free websites.
So either:
1) I need to know where to get the IP address for the free website, or
2) there is some way to use Azure SQL in free websites without having to
designate an allowed IP address, or
3) something completely different.
Any help with this would be appreciated.
Thanks!
UPDATE: Below is all I see on the database configuration page, i.e. no firewall rules. However, I became convinced that the "Allowed IP Address" requirement must be finessed automagically in Azure, and so that was likely NOT the problem, which made me look more closely at the connection string, which WAS the problem. Basically one day of newbie learning curve, which I'll have to sleep on and try to understand more tomorrow.
There's an option to allow Azure services when you configure the database firewall. Check if that's checked. Also, posting the actual error message will help.
You don't need to do that for things that are hosted within the Azure platform.
Under the Azure SQL Server Firewall (Preview Portal) settings, ensure that the Allow access to Azure services is turned on:
Alternatively, via the Old Portal, the setting is found via:
Databases -> Servers -> Configure
I've just set up a windows azure VM and installed IIS on it.
When I remote desktop onto the box I can see the default IIS website fine but I can't get this to serve on the web from the IP address of the box.
I've opened up port 80 on windows firewall and also added an endpoint for port 80.
I've tried to access it with the firewall completely turned off also but to no avail...
I cant work out if there is anything else I need to do to get this working?
Add endpoints for port 80 (http) and port 443 (https) to the VM in the Azure portal (tip: this can be automated with powershell or the Azure cli).
Remote desktop to the machine. Open the Windows firewall control panel and allow traffic to port 80 (http) and port 443 (https) or just turn it off ... the firewall is ON by default (tip: can also be scripted through the VM agent / powershell).
Go to the Azure portal and find the cloudapp.net subdomain for your VM (actually the cloud service) your VM is running under. Try accessing the site with that domain. If that doesn't work, try browsing to http://localhost on the server (remote desktop) to make sure IIS works and troubleshoot from there.
Modify the DNS records of your custom domain to use a CNAME to the .cloudapp.net domain. If you need A records make sure to use the public IP of the cloud service (just ping the .cloudapp.net domain to find it or look in the Azure portal).
You might want to look into Azure Websites or Azure Cloud Services (web roles). Those are a lot easier to manage and a lot cheaper. They still offer most of the functionality.
What fixed the issue for me was to go into the Azure Portal, browse to 'Network Security Groups', select the VM and then create an inbound rule to allow traffic to port 80.
Note: Also ensure that the inbound rule to port 80 is added and enabled on the actual VM.
Well, I deleted the existing VM and Cloud service and started again - all worked fine out of the box this time.
How annoying! The only thing I did notice was that before my cloud service had the same name as my VM - this time they had different names so that might have been what was causing the issue.
Cheers
For the newer VMs and pre-configured setups (2015+), it's possible your setup is using an azure asset called "Public IP". If so, you can set a custom DNS name label in it, inside "Configuration". Note that this name will consider any type of region used when creating the VM (e.g. my-site.brazilsouth.cloudapp.azure.com).
It's good to remember that for testing purposes, it still suffices to use the value of the public IP that is randomly designated to you.
The VMs are actually accessed via a Cloud Service (well they are for me). Azure created a Cloud Service automatically to be the scaling engine/load balancer on the front of the VM. I have to connect to the web site via that cloud service, not the VM directly.
Its possible you were using the internal IP rather than the external IP.
The sites have to use the internal IP address in the bindings section of IIS. However, in your dns you will need to use the external IP. This is presumably since the 'internal IP' is just a virtual one that Azure uses to map traffic from the external network to the VM's inside azure.
You should find both the internal and external IP's are visible on the VM's desktop.
Switch off TLS 1.3 in the Registry Editor.
This is what worked for me as of writing this in Mar 2021.
I've a single Web Role Cloud Service instance running the South East Asia, with a SQL Azure Database running in the same region. I am hitting a firewall issue and the connection is blocked unless I add the Cloud Services public virtual IP to the SQL server firewall.
From everything I've read, if the two systems are in the same region, and 'Allowed Windows Azure Services' is enabled (which adds 0.0.0.0 to the firewall), then the two should be able to communicate internally?
I have some concerns about things being routed inappropriately (is data going outside the network / am I being charged for it), and having to reconfigure the firewall should the VIP change.
Is there some other address I am supposed to access the SQL azure instance by (currently hitting blah.database.windows.net)?
Your understanding is correct. If I were you I would open a support ticket with Microsoft; I have heard of this issue before, although I never experienced it myself. This sounds like an issue, so report it and watch your next invoice carefully.
Firstly,
Allowed Windows Azure Services - Will allow only azure services to access the database.
Secondly,
To be able to access the database server from any other endpoint, you need to add firewall rules to allow those specific IP ranges. If you want to connect from a machine with ip, 132.99.xx.xx you need to add a rule with start IP and end IP as 132.99.xx.xx
Hope this helps!