Expressroute gateway no transmitting TCP packets

Question

Expressroute gateway no transmitting TCP packets

Duncan Edwards 1

We have setup an Expressroute gateway in a hub VNET with an associated route table. We are able to ping from on an on-premise device to a Nutanix NC2 VM but TCP packets do not reach the NC2 infrastructure.

How can I tell where the packets are going and how far they get though the Azure setup?

Thanmayi Godithi 11,825 Reputation points Microsoft External Staff Moderator

2026-05-29T11:30:23.8933333+00:00
Hi Duncan Edwards ,

Thank you for reaching out on Microsoft Q&A forum.

To figure out exactly how far your packets are getting, here’s a step-by-step approach you can use:

Verify your routes • Go to your VM in the Azure portal → Networking → Effective routes. • Make sure your on-prem prefixes are being learned via BGP and that no User-Defined Route is hijacking the path.

Check network security rules • If you have any NSGs on the gateway subnet or on the VM’s NIC, run Network Watcher’s “IP flow verify” (also called Connection troubleshoot) for your TCP port. This will tell you whether Azure is blocking the flow.

Trace the path with Network Watcher • Use the “Next hop” feature in Network Watcher to see where Azure is sending your traffic at each hop. • Optionally enable a packet capture on the target VM (tcpdump/Wireshark) to confirm whether the packets ever arrive at the VM’s NIC.

Run ExpressRoute diagnostics • In the Azure portal, open your ExpressRoute circuit → Diagnose and solve problems → Connectivity & Performance issues → Issues with Private peering → Test private-peering connectivity. – Use PsPing from your on-prem device to the VM’s private IP on the TCP port you’re testing. – The results will tell you if traffic reaches the Microsoft Edge (MSEE), the gateway, and where it’s dropped or not returned.

Drill into firewall and VM-level filters • On the Nutanix VM itself, ensure the OS firewall isn’t blocking your TCP port. • If you’ve got an Azure Firewall, NVA or Azure Stack Hub firewall in the path, verify that the TCP port is allowed.

Hope that helps you pinpoint exactly where your TCP packets are being dropped!

Let me know if the above helped or if you need further assistance.If the answer is helpful, kindly upvote it.

1 answer

Your answer

Thanmayi Godithi 11,825 Reputation points Microsoft External Staff Moderator

2026-05-29T11:30:23.8933333+00:00

Hi Duncan Edwards ,

Thank you for reaching out on Microsoft Q&A forum.

To figure out exactly how far your packets are getting, here’s a step-by-step approach you can use:

Verify your routes • Go to your VM in the Azure portal → Networking → Effective routes. • Make sure your on-prem prefixes are being learned via BGP and that no User-Defined Route is hijacking the path.

Check network security rules • If you have any NSGs on the gateway subnet or on the VM’s NIC, run Network Watcher’s “IP flow verify” (also called Connection troubleshoot) for your TCP port. This will tell you whether Azure is blocking the flow.

Trace the path with Network Watcher • Use the “Next hop” feature in Network Watcher to see where Azure is sending your traffic at each hop. • Optionally enable a packet capture on the target VM (tcpdump/Wireshark) to confirm whether the packets ever arrive at the VM’s NIC.

Run ExpressRoute diagnostics • In the Azure portal, open your ExpressRoute circuit → Diagnose and solve problems → Connectivity & Performance issues → Issues with Private peering → Test private-peering connectivity. – Use PsPing from your on-prem device to the VM’s private IP on the TCP port you’re testing. – The results will tell you if traffic reaches the Microsoft Edge (MSEE), the gateway, and where it’s dropped or not returned.

Drill into firewall and VM-level filters • On the Nutanix VM itself, ensure the OS firewall isn’t blocking your TCP port. • If you’ve got an Azure Firewall, NVA or Azure Stack Hub firewall in the path, verify that the TCP port is allowed.

Hope that helps you pinpoint exactly where your TCP packets are being dropped!

Let me know if the above helped or if you need further assistance.If the answer is helpful, kindly upvote it.

Answer 1

Duncan Edwards 1

Issue resolved by creating dummy vnets with same address space as the NC2 overlay and peering with the hub vnet

0 comments