I am trying to troubleshoot two Azure VNETs that have been peered together. Lets call these VNETs A and B. There are multiple services running on a VM in VNET A on different ports. I am trying to access them from a VM in VNET B.
I observe the following behaviour:
nc -vz vm-in-host-a.something.com 11294
Connection to vm-in-hosta.something.com 11294 port [tcp/*] succeeded!
nc -vz vm-in-host-a.something.com 11291
nc: connect to vm-in-host-a.something.com 11291 (tcp) timed out: Operation now in progress
nc: connect to vm-in-host-a.something.com port 11291 (tcp) timed out: Operation now in progress
nc: connect to vm-in-host-a.something.com 11291 (tcp) timed out: Operation now in progress
Next I try the following:
usr/sbin/traceroute -I -4 -p 11294 vm-in-host-a.something.com
traceroute to vm-in-host-a.something.com (10.225.16.6), 30 hops max, 60 byte packets
1 * * *
2 10.225.16.6 (10.225.16.6) 150.447 ms 150.485 ms 150.363 ms
And lastly, the following:
/usr/sbin/traceroute -I -4 -p 11291 vm-in-host-a.something.com
traceroute to vm-in-host-a.something.com (10.225.16.6), 30 hops max, 60 byte packets
1 * * *
2 10.225.16.6 (10.225.16.6) 213.935 ms 213.760 ms 213.609 ms
Why would nc fail and traceroute succeed? Is there a way to check where exactly this port is being blocked? If its being blocked on VNET A or B or at exactly which point?
You are using ICMP tracing (by specifying the
-I
switch), and, according to the traceroute man page, the-p
option in this caseSo
traceroute
does not connect to the port you think it does, it simply sends out ICMP probes. To use a TCP port for scanning, you should use the-T
switch instead of-I
.