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!
Related
We have a sql server firewall setup with no IP access and "Allow Azure Services" flag also set to off.
I understand this means no azure services and no external clients will be able to access the sql server and database.
however, when i try Import Database option on sql server, with bacpac stored in azure storage, we get a strange error of an IP that needs to be given access in sql server firewall. The error reads.
Client with IP address 65.52.129.125 is not allowed to access the server.
While our azure infra is in West Europe, there is no mention of what this IP belongs to and what is the purpose of it.
The same error of course also occurs from Infra as a code approach and CI-CD Pipelines. and I think adding an IP without any information is risky.
Has anyone faced this before? or if anyone knows , what is azure database import using underneath for which this IP needs access and will it always be the same?
65.52.129.0 - 65.52.129.255 is an IP address range owned by Microsoft Corporation and located in Netherlands.
Please read the following explanation about why you should enable Azure Services access on the firewall at least while doing export/import operations. When you finish import/export operations, then disable Azure Services access.
"The IP address space used for outbound connections from the Import/Export Service infrastructure to the target logical server is not documented, and is subject to change at any time. Therefore, given that connections to the target Azure SQL Database server are gated by server firewall, the only fully reliable way to ensure that the Import/Export service will be able to connect is to enable the firewall rule that allows access from all Azure services (or, equivalently, from the 0.0.0.0 IP address). Obviously, opening the firewall to a large IP address space is a network security risk. Security conscious organizations will want to mitigate this risk by disabling this firewall rule as soon as the import operation completes successfully..."
Source is here.
We are considering using Azure Analysis Services for the BI requirements. Currently, the databases are deployed behind a firewall in a VNET. Since AAS do not have either VNET support or has static IP address range, how do we connect to the databases behind the firewall? I have seen one solution where folks are talking about using the gateway (https://azure.microsoft.com/en-gb/blog/azure-analysis-services-integration-with-azure-virtual-networks-vnets/). But apart from using Gateway, what are the other options I have?
You need to
Install On-Premises Data Gateway on VM
Add VM Virtual Network to SQL firewall settings
Set AAS to use On-Premises Data Gateway
Force all AAS traffic through gatway. This is important.
As for other options I don't think there are any that are good in terms of security. AAS IP can change during restarts so you can't make it this way. Unless you write script which changes IP every time but its cumbersome.
At this time gateway is our current production solution for this scenario.
For dev/test you can always examine the connection failure error from AAS to SQL Database, extract the IP address and add a firewall exception for that IP address, or a small range containing it.
We are setting up SQL Always On in Azure VM (IAAS). We followed the steps given in Configure Always On Availability Group in Azure VM manually and the setup is working fine. Since the setup is using the internal load balancer, the listener is available only internally i.e. using a jump box. We are using NSGs to restrict access to the servers from our office IPs and allow access to the SQL Servers from developer machines. This works for direct access to the individual SQL server but not via listener. What can be done to allow access from outside of the VNET?
This subscription is standalone and not connected to the on-premise via site-to-site VPN or Express Route. The resources should be accessed using internet and source IPs are specifically white listed (it is a very small fixed list).
You can configure a Point-to-Site connection to allow your clients to connect the Azure VNet then use sql server.
Yes, the solution to which is to use a Point-to-Site with a VPN gateway deployed.
But, keep in mind that you can have a max of 128 users.
Apart from which, P2S should do the trick here.
I have an Azure Cloud Service (Worker Role) that needs to connect to my Azure SQL database and also connect to an external database.
In development the external database was on the public Internet and connectivity was not a problem.
However, the solution now needs to be deployed in a production environment and access to the external database is to be restricted by setting up a Virtual Network.
The Cloud Service, when deployed in the Virtual Network, gets an IP from the subnet, but seems to become inaccessible to the outside world, and is not connecting to the Azure SQL database (I also cannot RDP to it).
This seems to be beyond my level of understanding of networking, but I don't see why it should lose access to its neighbours in the Azure environment.
What am I missing? Do I need to get involved with Endpoints? Is the Virtual Network misconfigured?
Thanks in advance.
Your question is quite vague, in terms that it does describe the whole picture in the best possible way. Let me put my answer based on my understanding about your issue.
First of all - Azure virtual Network is Virtual Network. It is designed to enable secure cross-premisses connectivity with Windows Azure Data Center.
When you deploy a proper PaaS Cloud Service (Worker Role / Web Role) in a Virtual Network, the role instances get IP Addresses allocated from the defined DHCP pool (the VNet Definition).
When you deploy any service in an Azure Virtual Network you have to take care of Name Resolution! Meaning that, if you do not provide a proper DNS Server, your cloud instances will not be able to resolve any address. That includes Azure SQL Database servers. More on Name Resolution can be read here.
Next, but not less important - Azure SQL Database servers are not part of, and, as of March'2013, cannot be added to Azure Virtual Network!
The last statement means that in order for your Worker Role to access Azre SQL Database server, you need to provide a proper DNS server in your Azure Virtual Network.
And lastly, when you deploy a PaaS service into a Virtual Network, in order to access it via Remote Desktop need to:
* Properly enable and configure RDP extension. it will anyway create Input Endpoint. But this is the only way to enable RDP on PaaS right now;
* You could probably enable RDP via PowerShell startup script and access RDP via the VPN tunnel for the Virtual Network - say you configured a Site-to-Site or Point-to-site VPN for your Azure VNet.
Check the building cross-premises Virtual Network guide here.
My Azure web role can, using remote desktop, connect with a browser (IE) to google.com and to a DMZ server on our corporate network.
My web role cannot connect via HTTP GET (IE) to a non-DMZ box behind the firewall. My web role cannot ping this box either. My service is hosted in north/central, allegedly all published IP ranges of north/central have been granted access to the target IP by our CorpIT people. They claim they are seeing no traffic via their sniffer from my compute instance IP when I attempt to ping or HTTP GET against the target local IP.
CorpIT wants help from the Microsoft side but we have no Microsoft relationship. I'm convinced this is the outcome of months of slapdash thirdhand firewall rules applied to the target environment in question. What can I do to further elucidate this for CorpIT?
thx in advance!
You can try to run a trace route or get a network trace from the Azure instance and see what you get back from where. You could also create a support case with microsoft:
https://support.microsoft.com/oas/default.aspx?&c1=501&gprid=14928&&st=1&wfxredirect=1&sd=gn
I wouldn't bet on using the IP ranges to make your applications work correctly. Windows Azure already provides you with some services that allow you to solve these types of issues:
Windows Azure Connect: Allows you to create an IPSec secured connection between your servers and your hosted services. This means you won't need to add rules to the firewall for incoming traffic.
Windows Azure Service Bus Relay: Allows you to expose WCF services to the cloud without having to add rules to the firewall for incoming traffic. Choosing this option might add some extra work for you to do, you might need to create a WCF service if you don't already have one and change the code in your Web Role to connect to this WCF Service.