Cannot communicate to VM:port from internet but I can connect from within virtual network

Question

Cannot communicate to VM:port from internet but I can connect from within virtual network

Mike Totman 0

I have 2 VMs in a shared virtual network which I'm setting up to have the same software. I want to make a port available from the internet, so I make an iptables rule in the Linux host OS and then also add a rule to allow the connection in the Azure Firewall (from the Networking tab of the VMs blade in the portal)

I have them both configured the same with regard to this port, and I can connect to that port from any other server within the virtual network using the internal IP address (10.x.x.x), so I know the iptables configuration is correct. Plus they both match.

If I try to connect from outside the virtual network using the Public IP address (20.x.x.x) it succeeds for one server but fails for the second. e.g. using curl to connect to that port from my personal laptop.

I've attached screenshots of the portal blades below, showing the virtual network, and the firewall configurations for the two VMs. "spdmwdeusd0" works, "sdpmwdeust0" fails.

sdpmvnet

wd-d0-networking

wd-t0-networking

Bas Pruijn 956 Reputation points

2023-05-23T08:19:18.7+00:00
At first it seems strange that one machine does work, and the other doesn't. However:

both machines do not seem to have a public IP address assigned to the NIC. If they had, it would show at the top of your screenshot at NIC Public IP

You have only shown the NSG assigned to the NIC's of the VM's. There might also be a NSG assigned to the subnet the VM's are linked to that is interfering

Since neither of your shown NIC's does have a public IP assigned I assume that you are connecting to the VM over a secundary NIC assigned to the machine. The security settings on this secundary NIC could cause the issue.

OR

you are using a loadbalancer of some sort to access the VM and the loadbalancer configuration is not supporting connections to your test server.
GitaraniSharma-MSFT 50,096 Reputation points Microsoft Employee Moderator

2023-05-23T10:37:34.2466667+00:00

Hello @Mike Totman ,

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

You've mentioned - "If I try to connect from outside the virtual network using the Public IP address (20.x.x.x) it succeeds for one server but fails for the second".

Could you please clarify where is this Public IP (20.x.x.x) deployed? Because as @Bas Pruijn mentioned, both machines do not seem to have a public IP address assigned to the NIC. If they had, it would show at the top of your screenshot at NIC Public IP.

Regards, Gita
Mike Totman 0 Reputation points

2023-05-23T22:03:14.3833333+00:00

Thank you for your responses, I'll look into that IP address and virtual network NSG, though I think I checked that and didn't find another set of rules, but I'll confirm it.

In the meantime, I realized I forgot a few important points and background regarding this set up in my haste:
These VMs were initially created as Classic VMs nearly 8 years ago, and then finally converted to ARM style resources a year or two back. At that time, everything worked and these servers exposed the ports 22, 80, 443, and 8984.

Then when we added the new service, we added the rules to expose port 4984 and the others (the "Allow_Dev_ports" rule and port 4985) on sdpmwdeusd0 about 6-9 months ago, and that is the server that works.

About 3 months back, we changed the rules for access to port 22 to restrict it to requiring the use of the Azure VPN, hence the source IP range. Everything else still worked on both sdpmwdeusd0 and sdpmwdeust0 as expected.

In the last month we added the same service to the sdpmwdeust0 server and this is the one giving the issue.

When I say I am unable to connect to the one server from the public internet, I forgot to mention that this is only the case for the new port that I added. I can still connect to SSH, Web (80/443), and 8984. Port 4984 is inaccessible from the public internet, but is accessible from other servers in the same virtual network. And port 4985 is also accesible from that virtual network, but it's not intended to be publicly visible anyway.

1 answer

Your answer

Bas Pruijn 956 Reputation points

2023-05-23T08:19:18.7+00:00

At first it seems strange that one machine does work, and the other doesn't. However:

both machines do not seem to have a public IP address assigned to the NIC. If they had, it would show at the top of your screenshot at NIC Public IP

You have only shown the NSG assigned to the NIC's of the VM's. There might also be a NSG assigned to the subnet the VM's are linked to that is interfering

Since neither of your shown NIC's does have a public IP assigned I assume that you are connecting to the VM over a secundary NIC assigned to the machine. The security settings on this secundary NIC could cause the issue.

OR

you are using a loadbalancer of some sort to access the VM and the loadbalancer configuration is not supporting connections to your test server.
GitaraniSharma-MSFT 50,096 Reputation points Microsoft Employee Moderator

2023-05-23T10:37:34.2466667+00:00

Hello @Mike Totman ,

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

You've mentioned - "If I try to connect from outside the virtual network using the Public IP address (20.x.x.x) it succeeds for one server but fails for the second".

Could you please clarify where is this Public IP (20.x.x.x) deployed? Because as @Bas Pruijn mentioned, both machines do not seem to have a public IP address assigned to the NIC. If they had, it would show at the top of your screenshot at NIC Public IP.

Regards, Gita
Mike Totman 0 Reputation points

2023-05-23T22:03:14.3833333+00:00

Thank you for your responses, I'll look into that IP address and virtual network NSG, though I think I checked that and didn't find another set of rules, but I'll confirm it.

In the meantime, I realized I forgot a few important points and background regarding this set up in my haste:
These VMs were initially created as Classic VMs nearly 8 years ago, and then finally converted to ARM style resources a year or two back. At that time, everything worked and these servers exposed the ports 22, 80, 443, and 8984.

Then when we added the new service, we added the rules to expose port 4984 and the others (the "Allow_Dev_ports" rule and port 4985) on sdpmwdeusd0 about 6-9 months ago, and that is the server that works.

About 3 months back, we changed the rules for access to port 22 to restrict it to requiring the use of the Azure VPN, hence the source IP range. Everything else still worked on both sdpmwdeusd0 and sdpmwdeust0 as expected.

In the last month we added the same service to the sdpmwdeust0 server and this is the one giving the issue.

When I say I am unable to connect to the one server from the public internet, I forgot to mention that this is only the case for the new port that I added. I can still connect to SSH, Web (80/443), and 8984. Port 4984 is inaccessible from the public internet, but is accessible from other servers in the same virtual network. And port 4985 is also accesible from that virtual network, but it's not intended to be publicly visible anyway.

Answer 1

Mike Totman 0

Regarding the public IP addresses, each VM is associated with a "load balancer" which is connected to that public IP address. I don't know why, I assume as part of our migration, as we have not set up any extra machines for load balancing, each VM is a single machine.

When I checked on that I discovered my problem. Inbound NAT Rules on the load balancer for the non-working server sdpmwdeust0. Once I added a corresoponding rule there for the port I needed, 4984, it worked from the public internet.

I realize now that the main status pages for the VMs would've made that clearer.

Thank you for you questions which lead me to my answer.

GitaraniSharma-MSFT 50,096 Reputation points Microsoft Employee Moderator

2023-05-24T11:28:35.63+00:00

@Mike Totman , thank you for the update. Glad to hear that your issue is now resolved.

Share via

Cannot communicate to VM:port from internet but I can connect from within virtual network

1 answer

Your answer