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.
Related
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
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.
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
Can I migrate my domain into Azure and still allow local workstations to join that domain? I currently have a setup of 7 workstations and 1 server. I'd like to move the server into Azure. It's the domain controller, DNS, AD, and file server. Is my scenario possible? I would just like to make it seem as if the workstation doesn't know the difference other than its now connecting to a different server. The end user would still work as they used to as well. I've found a lot of info on joining other Azure VMs to a Azure-hosted domain controller, but nothing like I'm looking for. It's for a small business setup and I'm new to Azure, but instead of replacing aging server hardware, I'd rather move it to the cloud. If only certain services are possible, that's fine, the minimum requirement would be just being able to setup a domain. I can setup file services through other methods if need be. Thanks!
According to the Description of support boundaries for Active Directory over NAT
The Microsoft statement regarding Active Directory over NAT is:
Active Directory over NAT has not been tested by Microsoft.
We do not recommend Active Directory over NAT.
Support for issues related to
Active Directory over NAT will be very limited and will reach the
bounds of commercially reasonable efforts very quickly.
The problem is that as part of the connection sequence the AD server will send its local IP Address for the client to connect to, so the client will attempt to connect to the address behind NAT.
The only way you can connect a client to an AD VM is to go through a virtual network. So as long as you had a site to site VPN your clients wouldn't notice any difference.
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!