Traceroute works but nc fails - Where is my port being blocked?

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 case

specifies the initial icmp sequence value (incremented by each probe too).

So 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.