Issues with "Hyper-V" networking only very selectively passing traffic.

Tris Mabbs 20 Reputation points
2026-07-13T10:27:29.08+00:00

Good day.

I'm working on a PoC Citrix installation. There's a "Windows Server 2025" VM (running on "VMware", with all CPU virtualisation features exposed to the VM), on which I've installed the "Hyper-V" role and "Network Virtualization" feature (required so it can be managed by "System Centre 2025"'s "Virtual Machine Manager"). I've created an "external" switch within "Hyper-V", which is bound to the second network card in the "Windows Server 2025" VM:

User's image

As you can see, SR-IOV is disabled at the switch level. I've created some VMs, all of which have SR-IOV disabled at the VM level; E.g.:

User's image

All other settings are left at their default values (E.g., "Enable virtual machine queue"), though I have changed the dynamic MAC address range so as not to cause any potential conflicts with any other "Hyper-V" hypervisors on the network.

So, all perfectly straightforward a setup. If I enable "Allow management operating system..." then the "Windows Server 2025" DHCPs an IP address on that interface, which I can "ping" both from the server itself, elsewhere on the network, and from a VM... well, if I manually assign an IP address to the VM anyway, because that's the issue here - traffic from any VM simply does not make it off the server. Mostly... Let me clarify:

Install a VM and it gets a NIC with an appropriate MAC address, but can't DHCP for an IP address - the traffic never leaves the server. I know it never leaves the server because I've installed "WireShark" and when I capture that NIC (assuming "Allow management operating system..." is ticked, obviously...) there's no DHCP traffic.
OK, assign a static IP address (temporarily "borrowed" from our DHCP server) to the NIC in the VM and try "ping"ing the default gateway. No corresponding traffic on the server NIC...
However, what makes this really weird is that, with a manually assigned IP address, I do see SSDP traffic from that VM going out over the server NIC:

User's image

(10.100.10.109 is the address I manually assigned to the VM).

So it's really, really weird - only SSDP traffic is making it off the VM and onto the LAN - literally everything else (including DHCP packets...) is getting lost somewhere.

I've removed and recreated the "Hyper-V" external switch; I've enabled and disabled IO-SRV; I've prodded and poked at this pretty much every way I can and I can't see any reason for this behaviour. I regularly use "Hyper-V", so I'm used to many of its little... quirks... but this isn't one I've seen before. However where I've used "Hyper-V" before it's always been on physical hardware rather than, as here, on virtual, so I can only guess that might have something to do with it, though honestly I can't imagine what...

The VM I originally created was a "Windows 11 22H2" system (installed with no networking, obviously...). With no networking, I can't "Windows Update" it, so I downloaded "Windows 11 25H2" and spun up another VM using that, just to see whether it was a "Windows 11 22H2" issue. Nope - "25H2" behaves the same way. I've also spun up a "Red Hat 10" VM on there for comparison, and that also behaves the same way - no networking.

This is the second system where I've had this issue - the Citrix PoC started as a single "Windows 2025 Server system, but I had exactly the same problem with "Hyper-V" networking on there, so I built a second "Windows 2025 Server" just to run "Hyper-V" in case it was some conflict between "Hyper-V" and the Citrix virtualisation software. Apparently not...

Any ideas, anyone? Thanks in advance!

Windows for business | Windows Server | Networking | Network connectivity and file sharing
0 comments No comments

Answer accepted by question author
Xuan Nhu 1,050 Reputation points Independent Advisor
2026-07-13T11:07:18.42+00:00

Hi,

The fact that SSDP traffic leaves the VM while DHCP, ARP and ICMP do not is a very useful clue. It suggests that the Hyper-V virtual switch itself is functioning, but that traffic forwarding is being filtered somewhere in the nested virtualization path rather than inside the guest OS.

Since you’re running Hyper-V inside VMware, I’d first verify the VMware vSwitch/port group configuration. Hyper-V creates additional MAC addresses for its guest VMs, so the VMware port group hosting the Windows Server 2025 VM must allow Promiscuous Mode, MAC Address Changes, and Forged Transmits. If any of these are set to Reject, the outer hypervisor may silently drop frames from the nested Hyper-V guests. This is one of the most common causes of nested Hyper-V networking problems.

I’d also confirm that the VMware virtual NIC connected to your external Hyper-V switch is using VMXNET3 (or test with E1000E as a comparison), and temporarily disable VMQ and any offload features on that adapter to rule out a driver interaction:

Set-NetAdapterVmq -Name "<adapter>" -Enabled $false

Because the issue occurs with both Windows and Red Hat guests, it is very unlikely to be guest OS specific. It also makes an issue with DHCP itself unlikely, since even statically addressed VMs cannot send ordinary unicast traffic.

As another test, create an Internal Hyper-V switch and attach two nested VMs to it. If those VMs can communicate with each other normally, but connectivity fails only when using the External switch, that would further isolate the problem to the VMware-to-Hyper-V networking boundary rather than Hyper-V itself.

Was this answer helpful?

1 person found this answer helpful.

0 additional answers

Sort by: Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.