I am pretty new to Azure, I need to give developers access to our database in Azure. The problem is that each time when they connect to the database, they need to whitelist client IP in the firewall which is practically frustrating.
Can someone help me find the best solution so that they don't need to do this every single time since everyone is using broadband connections they don't have a static IP so it's like practically creating new rules every single time.
It's only possible (as far as I know) with a P2S Vpn connection to a Azure VM, where the Azure VM Vnet has a private endpoint connection to the database server.
See also : https://techcommunity.microsoft.com/t5/azure-sql/connect-to-azure-sql-database-with-point-to-site-connection-and/m-p/1362840
Related
We were trying to get rid of all our IP whitelisting and avoid using it as much as possible. The main 2 reasons for this were to make everything more secure and also simplify it. Instead of asking for the clients IP-address (that would change over time) and modifying it all the time we wanted use a P2S VPN to avoid whitelisting. And deciding with the AAD VPN who could use the VPN and who couldn’t was also a nice way to give people permission to make use of the P2S VPN.
We successfully added a Private Endpoint to the SQL Server were users can connect to the SQL Server while using SSMS trough the P2S VPN. But the options seems to be not available for the Azure Analysis Services. Is there another a way to give the AAS a private IP-address or a workaround to avoid whitelisting as much as possible?
I’ve talked about this with a AAS Support Engineer, I got told that currently in 2020 either to add the Azure Analysis Services to a VNET so the P2S VPN can connect to it or connecting the Azure Analysis Services to a Private Endpoint isn’t possible. I understood that there is no other option than whitelisting the clients in the AAS Firewall.
Hopefully this answer helps someone in a similar situation.
I'm using SSMS to connect to Azure DB from my laptop. I have provided my laptop IP address in "Set server firewall". However, each time when connecting from SSMS it's considering my public IP address, instead of laptop IP.
My questions are:
why is it not considering my Laptop IP?
How safe is it to configure a public IP address in Azure's "set server firewall"? Will not it possible someone having same public IP can able to connect to Azure DB?
How the Azure DB can be configured so that it should account the request from my laptop IP only?
Azure PaaS service has a public endpoint, so it means that you cannot connect to them from your private IP, you must configure your Azure PaaS with your public IP. There is an option to make a public endpoint as a private endpoint using a private link, vpn point to site, virtual network gateway. Please, have a look at this article for more details.
You can keep security your connection from public IP using Azure PaaS firewall once your connection from your source to azure allows only you public IP, but you have to change this IP in firewall for each time your IP is renewed in case it is dynamic. For the best practice you should consider a private link or a Azure Instance Manager SQL which has more option, but it is more expensive then Azure PaaS SQL.
To help you answer these questions, we first must consider the network topology involved. Your laptop is likely connected to a wireless access point which is connected to a network switch. All traffic on the switch (or series of switches depending on the location you are at) uses a private IP addresses to communicate. These addresses cannot be routed on the public internet. In order for you to access the Azure SQL Database which sits on a different private network then your laptop, it had to travel over the public internet. This means your traffic is going through a series of routers and in order for the connection to correctly route between you and Azure, it needs your public IP address.
It is safe to a certain point. The Azure SQL Server you are connecting too uses SSL/TLS to encrypt the traffic so communication over the public web is encrypted. Your concern for essentially spoofing the public IP is valid which is why it is crucial to make sure you have selected a strong password for the SQL login. Microsoft also deploys a series of edge security services that monitors for attacks on any of their services to ensure the safety of their platform and will flat out block suspected attacks.
If you want to restrict traffic so that only your laptop can be used, now we are introducing a complex but doable architecture. You will need to setup a VNet and VPN Gateway in Azure and connect the two services. You will have to then connect the Azure SQL Database to the VNet you just setup. Once completed, you will need to access the VPN from your laptop which will grant you access to the database. The actual setup isn't trivial as there are many things to take into consideration such as cost, hardware capabilities on your side and security requirements.
At the end of the day, what should drive the "right solution" should be your security requirements. For some, running via a public IP is sufficient, for others they need to access it over a VPN.
To address your comment below, I needed more space so I'm amending the solution.
Anytime you make something publicly accessible over the internet, there is a possibility for someone else to access it. The chances are lowered the more complex you make the password to the resource. If you do not have a static IP address for your internet or someone spoofs your public IP address, there is a chance an attacker will have the ability to connect to the Azure SQL Server. This is where the password complexity comes into play. The stronger the password, the harder/longer it will take to brute force their way in.
If you have time to do the research/learning on this, I'd suggest taking a look at the online training Microsoft has for the Azure Solutions Architect certification. I think it will help you to better understand the intricacies involved with building a solution such as this.
https://learn.microsoft.com/en-us/learn/certifications/azure-solutions-architect
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
I have this application thats using a centralized database located outside of the firewall.
I need to run an azure-china hosted instance of my application.
I have had some issues with getting the application to start and I'm not quite sure why. One thing that struck me is that I have heard a lot of rumors regarding a Chinese firewall. Could this be the problem? That the Chinese application can't request my centralized database?
thanks in advance!
I'm in Beijing and I don't think it's because the GFW. You can RDP to the virtual machine or cloud service instance and try to PING or TELNET to your database address to see if it's a connection issue. And just a kind reminder, check the firewall rule of your database if you are using SQL Azure.
Just my 2 cents hope this helps
This is very normal when you are doing cross-border projects.
Apart from the GFW, the public internet connection from/to China is neither stable, you can get a generous amount of packet loss.
To get a centralised database accessing in China, a common practise it to use a tunnel to bridge the server and the database. IPsec VPN, OpenVPN, MPLS or even a dedicated line can work pretty well.
Another though is why not try some other providers.
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!