Reputation: 93
I have an existing VS2010 ASP.NET webforms site that I am trying to get running on Azure as a POC for a client.
I migrated the site to a VS2012 project, added an Azure Cloud Service Project, and have deployed the site as well as the back end DB to a 3 month trial account.
I've added the IP address of my dev machine to the firewall rules for the Azure db, and I can run the project locally and connect to the Azure db without incident.
On the firewall rules for the website, I have Windows Azure Services set to yes under Allowed services. I have no other rules in place other than the one for my dev machine.
When trying to access the site from the site deployed to Azure, I get the following exception:
Cannot open server requested by the login. Client with IP address '137.135.65.13' is not allowed to access the server. To enable access, use the SQL Azure Portal or run sp_set_firewall_rule on the master database to create a firewall rule for this IP address or address range. It may take up to five minutes for this change to take effect. Login failed for user . This session has been assigned a tracing ID of . Provide this tracing ID to customer support when you need assistance.
The site works normally if I add a firewall rule for the azure server IP address, but doesn't this defeat the whole purpose of Azure? Shouldn't allowing Azure services handle this? Is there an additional config item necessary or am I missing something basic in the design? I'm not sure if this is related but the site was deployed by VS2012 as a cloud service instead of a website, is this the issue? I also added the db as a linked resource in the cloud service but that didn't seem to have any effect.
Upvotes: 2
Views: 3627
Reputation: 686
Adding the DB as a linked resource for the WebSite will fix the problem w/out having to muck about with firewall settings.
Upvotes: 8
Reputation: 13511
This is a bug in Azure. Newer IP ranges aren't included in their boiler plate "Azure Services" configuration, or something like that.
Been happening for a long time (at least ~3 years), unfortunately.
Happens with Web Roles, Worker Roles, and VMs as well - NOT specific to Web Sites. We regularly hit this with our Web and Worker Roles in US East but never saw it once in US North.
Our work-around is to add the range: 10.0.0.0-10.255.255.255. Probably not the most secure work-around but fortunately, this has so far only hit our Dev environments and not any of our Production environments.
Upvotes: 2