Azure VM: cannot telnet to port 80 on 168.63.129.16, but 53 is OK. No firewall configured

Question

Azure VM: cannot telnet to port 80 on 168.63.129.16, but 53 is OK. No firewall configured

Dawid Wróbel 21

For the context, 168.63.129.16 is Azure's management IP (https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16), which the VM needs to be able to communicate with for number of reasons. I have no issues with my other VMs, except the particular one, which I need to communicate with said IP on the secondary (i.e. non-primary) interface. This is perfectly fine and should be supported without issues with manually added routes: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/multiple-nics#configure-guest-os-for-multiple-nics

The interface and routes are configured as following, with eth1 (10.1.0.8) being the secondary interface in speech:

   auto eth1  
   iface eth1 inet manual  
           address 10.1.0.8/23  
           gateway 10.1.0.1  
   eth1  
   #Azure Management  



   $ ip route  
   default via 10.1.0.1 dev eth1 proto kernel onlink   
   10.1.0.0/23 dev eth1 proto kernel scope link src 10.1.0.8

Now, I can telnet to port 53 over TCP, which provides DNS service (see the documentation on 168.63.129.16 linked above). I can also dig @168.63.129.16 just fine. However, port 80 is inaccessible, which is required for communication with Azure Agent (see: https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16#linux-os).

I am super puzzled, since there are no iptables rules active of any sorts on this VM, nor any NSGs applied on Azure end.

Any idea what's going on here?

Manu Philip 20,206 Reputation points MVP Volunteer Moderator

2022-09-04T17:59:04.56+00:00

Have you checked, if any internal firewall in the VM is blocking the port 80
Dawid Wróbel 21 Reputation points

2022-09-06T14:51:08.96+00:00

Yes, there is no firewall at all, all tables of iptables are flushed.

Accepted answer

2 additional answers

Your answer

Manu Philip 20,206 Reputation points MVP Volunteer Moderator

2022-09-04T17:59:04.56+00:00

Have you checked, if any internal firewall in the VM is blocking the port 80
Dawid Wróbel 21 Reputation points

2022-09-06T14:51:08.96+00:00

Yes, there is no firewall at all, all tables of iptables are flushed.

Answer 1

Prrudram-MSFT 28,281 Microsoft Employee Moderator

Hello @Dawid Wróbel ,

AFAIK, Azure IP 168.63.129.16 won't respond to requests coming in from IPs other than Primary for Port 80. 168.63.129.16 is a virtual IP of the host node and as such it is not subject to user defined routes.

This is partially covered in the following section. instance-metadata-service. This talks about 169.254.169.254, however, 169.254.169.254 is very much same as 168.63.129.16.

Why is my request timed out for my call to the service?
Metadata calls must be made from the primary IP address assigned to the primary network card of the VM.

Dawid Wróbel 21 Reputation points

2022-09-07T13:01:06.653+00:00

Thank you so much for finding this. Indeed, I had the very same issue with 169.254.169.254, so this explains it well.
I do wish, however, that the docs on 168.63.129.16 were updated to explicitly clarify this as well.
Prrudram-MSFT 28,281 Reputation points Microsoft Employee Moderator

2022-09-07T13:40:49.637+00:00

@Dawid Wróbel Thanks for surfacing the doc issue. I will take that forward with the content author for the document improvement for this section.

Answer 2

Additional diagnostics:

   root@vm:/home/test# traceroute -T -p 80 168.63.129.16        
   traceroute to 168.63.129.16 (168.63.129.16), 30 hops max, 60 byte packets        
    1  * * *        
    2  * * *        
    3  * * *        
    4  * * *        
    5  * * *        
    6  * * *        
    7  * * *        
    8  * * *        
    9  * * *        
   10  * * *        
   11  * *^C        
   root@vm:/home/test# traceroute -T -p 32526 168.63.129.16       
   traceroute to 168.63.129.16 (168.63.129.16), 30 hops max, 60 byte packets       
    1  * * *       
    2  * * *       
    3  * * *       
    4  * * *       
    5  * * *       
    6  * * *       
    7  * * *       
    8  * * *       
    9  * * *       
   10  * * *       
   11  * *^C       
   root@vm:/home/test# traceroute -T -p 53 168.63.129.16        
   traceroute to 168.63.129.16 (168.63.129.16), 30 hops max, 60 byte packets        
    1  168.63.129.16 (168.63.129.16)  0.433 ms  0.386 ms  0.560 ms

On another system in the same subnet:

   root@devubuntu:/home/test# traceroute -T -p 80 168.63.129.16        
   traceroute to 168.63.129.16 (168.63.129.16), 30 hops max, 60 byte packets        
   root@devubuntu:/home/test# traceroute -T -p 32526 168.63.129.16       
   traceroute to 168.63.129.16 (168.63.129.16), 30 hops max, 60 byte packets       
    1  168.63.129.16 (168.63.129.16)  0.480 ms  0.591 ms  0.712 ms       
    1  168.63.129.16 (168.63.129.16)  0.716 ms  0.575 ms  0.693 ms        
   root@devubuntu:/home/test# traceroute -T -p 53 168.63.129.16        
   traceroute to 168.63.129.16 (168.63.129.16), 30 hops max, 60 byte packets        
    1  168.63.129.16 (168.63.129.16)  0.489 ms  0.467 ms  0.820 ms

and its routing table:

   default via 10.1.0.1 dev eth0 proto dhcp src 10.1.0.6 metric 100     
   10.1.0.0/23 dev eth0 proto kernel scope link src 10.1.0.6     
   168.63.129.16 via 10.1.0.1 dev eth0 proto dhcp src 10.1.0.6 metric 100     
   169.254.169.254 via 10.1.0.1 dev eth0 proto dhcp src 10.1.0.6 metric 100

Answer 3

Cristian SPIRIDON 4,486 Volunteer Moderator

Hi @DawidWrbel-8051,

There is network connectivity to 168.63.129.16 on the first NIC.

The second NIC will not have GW assigned by Azure and need to be manually configured. But on that interface you don't have connectivity to 168.63.129.16 because it would not make sense - you already have it on the first NIC. You can configure routing to you own resources.

Hope this helps!

Dawid Wróbel 21 Reputation points

2022-09-06T14:53:13.757+00:00

Somehow my response to your post got posted under my own comment above.
Cristian SPIRIDON 4,486 Reputation points Volunteer Moderator

2022-09-06T18:51:01.973+00:00

I am not microsoft employee but my understanding is that the address 168.63.129.16 is somehow internal to Azure and can be seen only from the first NIC.

I tried a traceroute from my phone and couldn't reach it.

You can setup a GW and have Internet on the second NIC but 168.63.129.16 is not reachable from it.
Dawid Wróbel 21 Reputation points

2022-09-06T19:02:57.453+00:00

You can setup a GW and have Internet on the second NIC but 168.63.129.16 is not reachable from it.

It is reachable because as I already established, I can telnet (TCP) to its port 53 just fine. As I also mentioned, DNS queries on port 54 also work. It’s port 80 that is inaccessible. This is not a routing issue, at least not from my perspective, but rather some odd limitation on Microsoft end. That having said, nowhere in the docs do they mention it, which is why I posted here hoping for some clarification.

Share via

Azure VM: cannot telnet to port 80 on 168.63.129.16, but 53 is OK. No firewall configured

2 additional answers

Your answer