Dear Azure Team, I have an azure managed mysql database in virtual network vnet1 and a virtual machine in vnet2. I am unable to get this VM to access the database. I have a hub-spoke architecture with both vnet1 and vnet2 peered with my hub-vnet with firewall. I am not interested in peering vnet1 and vnet2. I tried to setup a FQDNs network rule in firewall but then this required that You must enable DNS Proxy on the Firewall before you can add Network rules with FQDN Destinations. I am not very vast in azure firewall and i do not want to upset or cause disruptions to existing systems. What is the safest way to achieve this? What also is the implication of You must enable DNS Proxy on the Firewall before you can add Network rules with FQDN Destinations. In anyway, will this really solve the problem? The database is using private DNS connection string like name.mysql.database.azure.com with no public access and I'd like to maintain this status. Seun

@Seun Ore , Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well. I understand that you have a Managed mySql in vnet1 and a VM in vnet2 and these two VNETs are peered to a HubVNET which has a Azure Firewall and you would like to establish Transit connectivity between the Spokes VNET1 and VNET2. Before Troubleshooting for VNET2, I would suggest you to make sure VMs in VNET1 are able to reach and access the database. Can you confirm if the VMs in VNET1 work with the Database? For Transit connectivity, I believe the service you are using is Azure Database for MySQL - Flexible Server Correct me if I am wrong Can you confirm if UDRs are associated to both the subnet of the VM and the subnet of the managed database with a route 0.0.0.0/0 pointing to Azure Firewall IP ? In the network rules, may I ask why you are planning to use a FQDN instead of IP Address? From the VM, please run * nsolookup name.mysql.database.azure.com *and share the results From the VM, please run * ping name.mysql.database.azure.com *and share the results Cheers, Kapil

Azure Database Access from A Different Virtual Network

Accepted answer

KapilAnanth-MSFT 47,196 Reputation points Microsoft Employee

2024-07-01T09:32:08.8233333+00:00
@Seun Ore ,

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I understand that you have a Managed mySql in vnet1 and a VM in vnet2 and these two VNETs are peered to a HubVNET which has a Azure Firewall and you would like to establish Transit connectivity between the Spokes VNET1 and VNET2.

Before Troubleshooting for VNET2, I would suggest you to make sure VMs in VNET1 are able to reach and access the database.

Can you confirm if the VMs in VNET1 work with the Database?

For Transit connectivity,

I believe the service you are using is Azure Database for MySQL - Flexible Server

Correct me if I am wrong

Can you confirm if UDRs are associated to both the subnet of the VM and the subnet of the managed database with a route 0.0.0.0/0 pointing to Azure Firewall IP ?

In the network rules, may I ask why you are planning to use a FQDN instead of IP Address?

From the VM, please run *nsolookup name.mysql.database.azure.com *and share the results

From the VM, please run *ping name.mysql.database.azure.com *and share the results

Cheers,

Kapil
Please sign in to rate this answer.

1 person found this answer helpful.
Seun Ore 80 Reputation points

2024-07-01T10:38:45.5166667+00:00

@KapilAnanth-MSFT thank you!

Can you confirm if the VMs in VNET1 work with the Database? Yes

I believe the service you are using is Azure Database for MySQL - Flexible Server. Yes

Can you confirm if UDRs are associated to both the subnet of the VM and the subnet of the managed database with a route 0.0.0.0/0 pointing to Azure Firewall IP ? The last time I did this, it caused a downtime for some of our services in vnet2. Because earlier, I created a route in both vnets, pointing to the private IP of the azure firewall instance and associated vnet2 subnet to it. I removed it in order to restore our services.

nslookup name.mysql.database.azure.com Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find name.mysql.database.azure.com: NXDOMAIN ping name.mysql.database.azure.com ping: name.mysql.database.azure.com: Name or service not known

However, from a server deployed into hub-vnet subnet, I was able to ping and nslookup the database successfully.

KapilAnanth-MSFT 47,196 Reputation points Microsoft Employee

2024-07-01T12:45:10.3433333+00:00

@Seun Ore ,Without UDR, Transit connectivity across Peered VNETS (Spokes) will not work.

You must check what are the dependencies and work on them.

If you want only traffic between VM and Database to go via Firewall, what you can do is,

In the Route Table attached to the VM, instead of 0.0.0.0/0, add the subnet range of Database and nextHop as Azure Firewall

In the Route Table attached to the Database Subnet, instead of 0.0.0.0/0, add the subnet range of the VM and nextHop as Azure Firewall

This way, the default route (0.0.0.0/0) will not be impacted

Wrt DNS,

I take it that "name" is just a place holder and you used the exact name of the Database server name.

i.e., nslookup <YOURDATABASENAME>.mysql.database.azure.com

For testing, you can add an entry in the Host file pointing <YOURDATABASENAME>.mysql.database.azure.com to the private IP address of the Database

Once done, share the results of ping <YOURDATABASENAME>.mysql.database.azure.com

Let me know how it goes with UDR and Host file.

Seun Ore 80 Reputation points

2024-07-09T21:19:57.5+00:00

@KapilAnanth-MSFT many thanks for the response and sorry for late response.

I will attempt this tomorrow and revert.

Seun Ore 80 Reputation points

2024-07-11T13:07:17.6966667+00:00

@KapilAnanth-MSFT Thank you again for your help!

I have tried out the above mentioned routes and this didn't work. I modified the /etc/hosts file to include 10.15.x.x name.mysql.database.azure.com and still didn't work.

Lastly I setup firewall network rule to allow traffic from VM private IP (source) to DB private IP (destination) on port 3306.

These three combinations failed to work for me.

By the way, name in name.mysql.database.azure.com is not the full DB name. I only used that as security on public platform.

I thought that the solutions lie somewhere between proper routes and firewall. Now this has failed.

KapilAnanth-MSFT 47,196 Reputation points Microsoft Employee

2024-07-11T14:02:38.38+00:00

@Seun Ore ,

Thanks for the info.

Did you see the Azure Firewall logs?

i.e., did you see a packet from AzureVM to Database on the Azure Firewall Logs?

This will clarify if the packet reached the Azure Firewall or not

And also, if the Firewall allowed or denied the packet.

When you say "didn't work."

What exactly is the issue?

Time out or some other error message

Please share the results of traceroute 10.15.x.x from the VM

Also, please share the results of ping 10.15.x.x

Seun Ore 80 Reputation points

2024-07-12T11:40:36.6166667+00:00

Thank you very much @KapilAnanth-MSFT

Not sure what I can make of this firewall logs. Maybe I am not writing the query properly.

I relaxed the firewall network rule by pointing the protocol to any and destination port to all (*) knowing well that ping and traceroute are ICMP protocols.

KapilAnanth-MSFT 47,196 Reputation points Microsoft Employee

2024-07-12T12:13:02.5933333+00:00

@Seun Ore ,

This indicates the packet reached the Firewall, and Firewall allowed it.

I am suspecting the Database VM is not accepting the connection.

As next steps,

#1

Deploy a TestVM in the Hub VNET

And test connectivity from this TestVM to the DatabaseVM

#2

From the Database VM, perform Check NIC Effective Routes and let me know what is the nextHop for the 172.16.75.9 range?

From the Database VM , Check IP flow verify

Virtual Machine : VMDatabase

NIC : <DEFAULT>

Protocol : TCP

Direction : InBound

Local IP : 10.15.3.4 Local Port : 3306

Remote IP : 172.16.75.9

Remote Port : 1234

And share the results.

You can get the same results using NSG diagnostics as well

Seun Ore 80 Reputation points

2024-07-12T12:55:04.8633333+00:00

Database is fully managed (PAAS). Azure Database for MySQL flexible server. Not a single deployed VM.

And yes there is a VM in hub-vnet that is able to access our databases including this particular one I am troubleshooting for. The hub-vnet is peered with the vnet where the database is deployed and that make connectivity possible.

For the VM in hub-vnet,

I did next hop checking and found that next hop is firewall IP just as specified in route table.

KapilAnanth-MSFT 47,196 Reputation points Microsoft Employee

2024-07-15T07:05:42.73+00:00

@Seun Ore ,

The configuration looks correct and you confirmed VMs in Hub is able to access the Database.

From the Spoke, what exactly is the error message you are seeing now?

Can you please share the exact error message

Seun Ore 80 Reputation points

2024-07-15T11:30:38.1433333+00:00

@KapilAnanth-MSFT thank you very much for help!

This issue has now been resolved. Every step taken previously as suggested above is correct and necessary. One last and missing step was enabling private DNS zone for both vnets. Apparently, the only way to establish comm. between database and VM in different vnets is via private DNS zone. Docs in this link https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-networking-vnet

KapilAnanth-MSFT 47,196 Reputation points Microsoft Employee

2024-07-15T11:35:57.92+00:00

That's wonderful @Seun Ore , it's usually some minor configuration lacking somewhere.

I'm glad that we were able to arrive at the solution and thank you for posting your solution so that others experiencing the same thing can easily reference this!

I would greatly appreciate if you could Accept and Upvote the answer and close this thread

Original posters help the community find answers faster by identifying the correct answer.

Thanks for your continued contribution on Q&A and appreciate much for taking the time to share your feedback.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Azure Database Access from A Different Virtual Network

0 additional answers

Your answer