How to connect to Azure Database for MySQL – Flexible Server in a private network configuration

Azure Database for MySQL is a fully managed, enterprise-ready service that provides high performance, scalability, and security for your MySQL applications. However, sometimes you might encounter connectivity issues when trying to access your database from different sources and networks. In this blog post, I’ll show you how to troubleshoot and resolve these types of issues based on three common network scenarios, as well as for an on-premises scenario. 

Note: If you can’t connect to the server by using the server name and receive an “Unknown Host” error, it’s most likely related to a DNS name resolution issue, which will be covered in a later post in this series. 

Scenario 1: Source and Azure Database for MySQL server are in the same virtual network (vNet) 

In this scenario, both your source and your Azure Database for MySQL server are in the same vNet, but they might be in different subnets. For example, you might have a virtual machine (VM) in one subnet and your database server in another subnet, as shown in the following figure: 

Fig.1: MySQL and Source (VM) in same vNet and different subnet 

If the name is resolving to the correct IP address and the client can’t connect to the server, then possible reasons for the connectivity failure include the following: 

• Network security group (NSG): An NSG is a filter that controls the inbound and outbound traffic to and from your resources. You need to make sure that there are proper rules defined on the NSG that allow the connection between your source and your database server. For example, you might need to allow the port 3306 for MySQL traffic. 
• Route table: A route table is a set of rules that determine where the traffic is directed in your vNet. You need to make sure that there is no route that blocks or redirects the traffic between your source and your database server. For example, you might have a virtual appliance in the route table that acts as a firewall and blocks the traffic. 
• Firewall logs: If you have a firewall in your vNet, you need to check the live logs on the firewall to see if the traffic is blocked or allowed. You can use the IP address of your source and your database server to filter the logs. 

Scenario 2: Source and Azure Database for MySQL server are in different vNets 

In this scenario, your source and your Azure Database for MySQL server are in different vNets, which might be in the same or different regions. For example, you might have a VM in one vNet and your database server in another vNet, as shown in the following figure: 

Fig2 : Source (VM) in vNet 1 and Azure MySQL in vNet2 

If the name is resolving to the correct IP address and the client can’t connect to the server, then possible reasons for the connectivity failure include the following: 

• vNet peering: vNet peering is a mechanism that connects two vNets by using a low-latency, high-bandwidth connection. You need to make sure that your source vNet and your database server vNet are peered to each other, and that the peering is bidirectional. This means that both vNets can initiate and accept traffic from each other. 
• NSG and route table: After you have peered your vNets, you need to check the NSG and the route table of both vNets to make sure that there is no rule that blocks or redirects the traffic between your source and your database server. You can follow the same steps as in scenario 1 to check these settings. 

Scenario 3: Source and Azure Database for MySQL server are in different vNets in a hub-and-spoke model 

In this scenario, your source and your Azure Database for MySQL server are in different vNets, but they are connected to a central hub vNet that acts as a gateway. This is a common network architecture that simplifies management and provides centralized control and visibility. 

For example, you might have a VM in one spoke vNet and your database server in another spoke vNet, and both are connected to a hub vNet that has a network appliance, such as Azure Firewall, Azure Virtual WAN, or a third-party network virtual appliance (NVA), as shown in the following figure: 

Fig3: Source (VM) in vNet 1 and Azure MySQL in vNet2 and the entire arrangement is in Hub and Spoke Model 

If the name is resolving to the correct IP address and the client can’t connect to the server, then possible reasons for the connectivity failure include the following: 

• vNet peering: You need to make sure that your source vNet and your database server vNet are peered to the hub vNet, and that the peering is bidirectional. This means that both vNets can initiate and accept traffic from the hub vNet. 
• Network appliance: You need to make sure that the network appliance in the hub vNet does not block or redirect the traffic between your source and your database server. You can check the configuration and the logs of the network appliance to see if the traffic is allowed or denied. You can use the IP address of your source and your database server to filter the logs. 
• NSG and route table: You also need to check the NSG and the route table of the hub vNet and the spoke vNets to make sure that there is no rule that blocks or redirects the traffic between your source and your database server. You can follow the same steps as in scenario 1 and 2 to check these settings. 

Scenario 4: Source is on-premises and Azure Database for MySQL server is in a vNet in a hub-and-spoke model 

In the previous sections, I’ve shown you how to connect to Azure Database for MySQL from different network configurations within Azure. In this section, I’ll show you how to connect to Azure Database for MySQL from on-premises sources, such as your laptop, a PC, or a VM using a site-to-site VPN connection. 

In this scenario, your source is on-premises and your Azure Database for MySQL server is in a vNet that’s connected to a central hub vNet that acts as a gateway. This is a common network architecture that simplifies management and provides centralized control and visibility. 

For example, you might have a client on-premises and your database server in a spoke vNet, with both connected to a hub vNet that has a VPN gateway, as shown in the following figure: 

Fig4: Source (client) is on-premises and Azure MySQL in vNet2 and on-premises to Azure connectivity completed via Site-to Site VPN 

If the name is resolving to the correct IP address and the client can’t connect to the server, then possible reasons for the connectivity failure include the following: 

• On-premises firewall: You need to check on the on-premises firewall to ensure that the outgoing traffic from the client is allowed. You might need to open the port 3306 for MySQL traffic and the port 443 for SSL traffic. 
• Hub firewall: You need to check the firewall on the hub vNet to ensure that the traffic from the client’s private IP or the client’s public IP is not blocked. You can check the live logs on the firewall to see if the traffic is allowed or denied. You can use the IP address of your client and your database server to filter the logs. 
• VPN configuration: You need to check the VPN configuration and ensure that the connection from the client is reaching the hub vNet. You can use tools like tracert or ping to test this. You also need to make sure that the VPN gateway on the hub vNet is configured with the correct local network gateway, virtual network gateway, and connection settings. For more information, see Connect an on-premises network to a Microsoft Azure virtual network and Extend your on-premises subnets into Azure using extended network for Azure. 
• NSG and route table: You also need to check the NSG and the route table of the hub vNet and the spoke vNets to make sure that there is no rule that blocks or redirects the traffic between your client and your database server. You can follow the same steps as in the previous scenarios to check these settings. 

Conclusion 

In this blog post, I’ve shown you how to connect to Azure Database for MySQL from different network scenarios and on-premises sources using a site-to-site VPN connection. I’ve also covered how to troubleshoot and resolve the most common connectivity issues. This information should help you to better take advantage of the power of Azure Database for MySQL – Flexible Server for your applications using the best network topology/architecture. 

I hope that this post article helpful, and we’re always interested how you plan to use Flexible Server deployment options to drive innovation to your business and applications. 

For additional information on topics discussed in this post, see the following resources: 

• Networking overview - Azure Database for MySQL - Flexible Server 
• Hub-spoke network topology with Azure Virtual WAN - Azure Architecture Center 
• Azure Private DNS documentation 
• Connect an on-premises network to a Microsoft Azure virtual network - Microsoft 365 Enterprise 
• Hub-spoke network topology in Azure - Azure Architecture Center 
• Do check out our Troubleshooting Series video on Connectivity for an explanation and demo on common private network configuration scenarios:

Also be sure to check our article, Private Link for Azure Database for MySQL - Flexible Server about another popular way to configure private networking using Azure Private Link. 

If you have any feedback or questions about the information provided above, please leave a comment below or email us at AskAzureDBforMySQL@service.microsoft.com. Thank you!