Azure VMs Virtual Network inter-communication
Asked Answered
W

2

15

I'm new to Azure (strike 1) and totally suck at networking (strike 2).

Nevertheless, I've got two VMs up and running in the same virtual network; one will act as a web server and the other will act as a SQL database server.

While I can see that their internal IP addresses are both in the same network I'm unable to verify that the machines can communicate with each other and am sort of confused regarding the appropriate place to address this.

Microsoft's own documentation says

All virtual machines that you create in Windows Azure can automatically communicate using a private network channel with other virtual machines in the same cloud service or virtual network. However, you need to add an endpoint to a machine for other resources on the Internet or other virtual networks to communicate with it. You can associate specific ports and a protocol to endpoints. Resources can connect to an endpoint by using a protocol of TCP or UDP. The TCP protocol includes HTTP and HTTPS communication.

So why can't the machines at least ping each other via internal IPs? Is it Windows Firewall getting in the way? I'm starting to wonder if I've chose the wrong approach for a simple web server/database server setup. Please forgive my ignorance. Any help would be greatly appreciated.

Withdrew answered 21/12, 2012 at 19:3 Comment(0)
A
13

If both the machines are in the same Virtual Network, then just turn off Windows Firewall and they will be able to ping each other. Other way is to just allow all incoming ICMP traffic in Windows Firewall with Advanced Settings.

However there is a trick. Both the machines will see each other by IP Addresses, but there will be no name resolution in so defined Virtual Network. Meaning that you won't be able to ping by name, but only by direct IP address. So, if want your Website (on VM1) to connect to SQL Server (on VM2), you have to address it by full IP Address, not machine name.

The only way to make name resolution within a Virtual Network is to use a dedicated DNS server, which you maintain and configure on-premises.

This article describes in details name resolution scenarios in Windows Azure. Your particular case is this:

Name resolution between virtual machines and role instances located in the same virtual network, but different cloud services

You could potentially achieve name resolution, if you put your VMs is same cloud service. Thus you will not even require dedicated virtual network.

Auston answered 21/12, 2012 at 19:53 Comment(5)
I have a feeling that what is being asked here is about the stuck in the Network Identifying state... this seems to happen a lot for no apparent reason... When it does, the VM loses all connectivity with other PC's in the network, irrespective of firewall status.Goa
I just put my hostnames/ip addresses in a HOSTS file, and it resolves them automatically.Successive
yeah, "great", and what happens when your VM restarts due a scheduled maintenance and looses its IP Address?Auston
Please take care to not do what I did - turn the Firewall back on after testing pings and lock myself completely off the VM. Take care when you re-enable the firewall that you don't accidentally stop yourself connecting via remote desktop!Jujube
Today there is alreday the Custom Script Extension: azure.microsoft.com/blog/2014/04/24/… which can be execute regardless of firewall rules. Thus you can remotely do whatever you want with the machine (given that this what you try to achieve is achievable with PowerShell)Auston
C
0

If your VMs are inside a Virtual Network in Azure, then you have to make sure two things.

  1. Required Port is enabled.
  2. Firewall is disabled on the server.

I was trying to connect to one VM where SQL Server DB was installed, from another VM. I Had to enable 1433 port in the VM where SQL was installed. For this you need to add an MSSQL endpoint to the VM on the azure management portal. After that i disabled windows firewall. Then i was able to connect to the VM from another.

Cadell answered 4/1, 2016 at 9:23 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.