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.
Related
I am really new to the Azure cloud platform and need some help setting up Power BI on Azure with a static IP address to add the address to my firewall. The production MySQL is in Hostgator to distribute among the organization to access analytics.
To control the IP used to connect to your database you must install a Data Gateway either in Azure or on some server you control, and configure the Dataset to use the Gateway to refresh.
Otherwise the IP addresses that may be used by Power BI are documented in the Azure Service Tag list. But they do change over time, so it's a hassle to use with any firewall that doesn't natively support Azure Service Tags.
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 have a client who wants to connect their premises to Azure. Their main hindrance at this point is determining the best way to connect to Azure given their current connectivity configuration. They have two redundant ISP connections going to the head office for internet access. They want to be able to configure a VPN connection to Azure that would operate in a similar way i.e. if ISP A went down it would seamlessly use ISP B and vice versa. The normal multi-site VPN configuration does not fit this since there is one local network behind which means the network behind separate VPNs over each ISP would have overlapping IP address ranges which is not supported. Is such a configuration possible? (See diagram below)
Either that or is there a way to abstract the two ISP connections onto one VPN connection to Azure.
They’re currently considering using a Cisco ASA device to help with this. I’m not familiar with the features of this device so I cannot verify if it will solve their issue. I know there is also a Cisco ASAv appliance in the Azure marketplace don't know if that could also be a part of a possible solution if they went with such a device.
required vpn configuration
The Site-to-Site VPN capability in Azure does not allow for automatic failover between ISPs.
What you could do are the following
- Have automation task created that would re-create the local network and gateway connection upon failover. Manual and would take some RTO to get it up and running
- Use the Cisco CSRs to create a DMVPN mesh. You should be able to achieve the configuration you want using that option. You would use UDRs in Azure to ensure proper routing
I havent done it in Azure, but here is what you do in AWS (And I am sure there would be parallel in Azure)
Configure a "detached VGW" (virtual Private gateway) in aws. Use DMVPN cloud to connect CSRs to multi-site on-prem.
Also, for failover between ISPs you could have a look at DNS load balancing via a parallel to AWS's Route 53 in Azure.
Reference thread :
https://serverfault.com/questions/872700/vpc-transit-difference-between-detached-vgw-and-direct-ipsec-connection-csr100
Is setting firewall rule for SQL Azure server on specific IP address (or range) is favored on setting the 0.0.0.0 firewall “Allow Microsoft Services access to this server” rule in term of security ?
As far as I know 0.0.0.0 allow all access from Azure local IPs (but of course to actually connect to the database the specific server name and login username/password will need to be offered).
Using 0.0.0.0 makes the configuration more easy since there is no need to track the role instances IPs in order to enable SQL Azure server connections but it does open some risks.
I would like to hear you opinion.
Thanks!
The 0.0.0.0 setting is used internally by Microsoft to allow their services to connect to your SQL instance. Of course, in theory your SQL database is open to any Windows Azure machine out there but it's not like the potential connection surface is the entire world.
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
It is always a good practice to add the ranges which are necessary, to avoid any chances of attack
Hope this helps!
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!