Share via

Hyper-V VM on VLAN 191: L2 works (DHCP/ARP), no L3 routing past gateway. Same VM works untagged. Where's the issue?

Nick Ren 30 Reputation points
2026-06-06T13:34:19.8566667+00:00

Setup:

  • Hyper-V Host: Windows Server 2022, Intel I219-LM NIC
  • vSwitch: External, Trunk-Switch, bound to I219-LM
  • Gateway: MikroTik RouterOS
  • Two VMs on same Trunk-Switch:
    • Ubuntu VM (VLAN 77, eth0.77 netplan subinterface, 172.16.1.*****/24) → works perfectly
    • Windows Server 2022 VM (VLAN 191, 172.16.191.*****/30) → broken
      Same VM, same host, same physical NIC, same vSwitch. Only difference is the VLAN. On the broken VLAN 191 NIC, verified working:
      • DHCP DISCOVER → DHCP OFFER from gateway (DHCP works over VLAN 191)
      • ARP request → gateway MAC learned (7*:9a:18:**:**:**)
      • tracert 8.8.8.8 hop 1 = 172.16.191.***** responds <1ms (gateway processes packet)
      On the broken VLAN 191 NIC, NOT working:
      • Ping to gateway times out
      • tracert hop 2+ all timeout (anything past gateway dies)
      • TCP test to any external IP times out
      • DNS queries timeout (DNS server is the gateway)
      Same VM, same host, same physical NIC, same vSwitch. Only difference is the VLAN. On the broken VLAN 191 NIC, verified working:
      • DHCP DISCOVER → DHCP OFFER from gateway (DHCP works over VLAN 191)
      • ARP request → gateway MAC learned (78:9a:18:**:**:**)
      • tracert 8.8.8.8 hop 1 = 172.16.191.***** responds <1ms (gateway processes packet)
      On the broken VLAN 191 NIC, NOT working:
    • Ping to gateway times out
    • tracert hop 2+ all timeout (anything past gateway dies)
    • TCP test to any external IP times out
    • DNS queries timeout (DNS server is the gateway)
    Hyper-V host configuration verified: 
      - `Get-VMNetworkAdapterVlan` shows Trunk 1,191 correctly

        - MAC Spoofing: On

              - AllowTeaming: On (during LBFO testing)

                    - Registry: `VlanFiltering = 0` already set on Intel I219 driver
    Configurations I've tried on the Windows VM — ALL give identical results (L2 works, L3 doesn't forward):
    1. Hyper-V Trunk + guest VlanID 191 (current)
    2. Hyper-V Trunk + LBFO Team + VLAN191 subinterface (Ubuntu-equivalent setup)
    3. Hyper-V Access mode VLAN 191 + guest VlanID 0 (via GUI checkbox)
    4. DHCP from MikroTik (gives /30 mask) and static IP with /24 mask
    5. DNS as gateway and external DNS (1.1.1.1, 8.8.8.8)
    6. All firewall profiles disabled inside guest
    7. LSO, RSC, RSS, IPSec offloads all disabled on guest's vNIC
    8. NativeVlanId 0, 1, and 191 — all same result Hyper-V host configuration verified:
      1. Get-VMNetworkAdapterVlan shows Trunk 1,191 correctly
      2. MAC Spoofing: On
      3. AllowTeaming: On (during LBFO testing)
      4. Registry: VlanFiltering = 0 already set on Intel I219 driver
    Configurations I've tried on the Windows VM — ALL give identical results (L2 works, L3 doesn't forward):
    • Hyper-V Trunk + guest VlanID 191 (current)
    • Hyper-V Trunk + LBFO Team + VLAN191 subinterface (Ubuntu-equivalent setup)
    • Hyper-V Access mode VLAN 191 + guest VlanID 0 (via GUI checkbox)
    • DHCP from MikroTik (gives /30 mask) and static IP with /24 mask
    • DNS as gateway and external DNS (1.1.1.1, 8.8.8.8)
    • All firewall profiles disabled inside guest
    • LSO, RSC, RSS, IPSec offloads all disabled on guest's vNIC
    • NativeVlanId 0, 1, and 191 — all same result
    My questions: 
        1. Is my Hyper-V VLAN setup correct for VLAN 191 on Windows Server 2022? Did I miss any Windows-specific configuration that would make VLAN-tagged traffic work?

          1. Given that DHCP/ARP/tracert hop 1 all succeed on VLAN 191 (proving L2 + gateway L3 ingress work fine), but anything past the gateway dies (no forwarding/NAT), is this conclusively a MikroTik gateway-side routing/NAT issue for the 172.16.191.0/30 subnet?

                1. Is there anything else I can verify or test from the Windows/Hyper-V side before concluding the issue is on the MikroTik?

                **Note:** The "no internet" status persists across guest reboots, host reboots, and various Hyper-V configuration changes. The behavior is 100% consistent — VLAN 191 traffic reaches the gateway successfully (L2) but never gets forwarded onward (L3). Behavior identical regardless of which Windows VLAN tagging method is used.
Windows for business | Windows Server | Networking | Other
0 comments

Answer accepted by question author

Zeeshan Nasir Bajwa 1,416 Reputation points
2026-06-06T14:12:40.5833333+00:00

Hi @Nick Ren

Layer 2 is working fine, So traffic between VM and Microtik are working. The biggest red flag is /30 subnet. You mentioned 172.16.191.x/30. A /30 provides only Network ID, Host A, Host B and Broadcast ID.

Please check source NAT by following command on router OS:

/ip firewall nat print detail

Look for something similar to "chain=srcnat action=masquerade out-interface=WAN" or "chain=srcnat action=src-nat src-address=172.16.191.0/30"

A very common issue is src-address=172.16.1.0/24 exists for VLAN 77 but no NAT rule covers 172.16.191.0/30.

In this scenario, traffic reaches Microtik then routes it toward internet, upstream drops RFC1918 source addresses, which results everything beyond hop 1 dies, exactly the symptoms you are seeing.

Check Firewall forward chain by below command on router OS:

/ip firewall filter print stats

Look for "chain=forward action=drop" or "src-address=172.16.191.0/30"

Counters increasing on a drop rule would immediately identify the problem.

While pinging 8.8.8.8 from windows, put below command of torce tool on router OS:

/tool torch interface=vlan191

Do you see "172.16.191.x -> 8.8.8.8" if yes traffic is leaving tge VM and entering Microtik.

Use packet capture on WAN by putting below command on router OS:

/tool sniffer quick ip-address=8.8.8.8

or

/tool sniffer quick interface=WAN

If packets from 172.16.191.x never appear on WAN routing/firewall is blocking them or if they apear with private source addresses then NAT is missing.

Compare VLAN 77 and 191, this is the fastest route.

put commands on router OS:

  1. /interface vlan print detail
  2. /ip address print detail
  3. /ip route print detail
  4. /ip firewall nat print detail
  5. /ip firewall filter print detail

for:

VLAN 77 (working)

VLAN 191 (broken)

You'll likely find one of:

Missing NAT

Missing interface list membership

Missing firewall allow rule

Wrong subnet mask

VRF mismatch

  • Policy routing rule

From the Windows VM:

  • Test-NetConnection 8.8.8.8 -TraceRoute

route print

Verify:

0.0.0.0/0 -> 172.16.191.<gateway>

  • If the default route is correct, Windows has essentially been ruled out.

Given:

DHCP works

ARP works

Gateway MAC learned

Hop 1 responds

Multiple Hyper-V VLAN methods show identical behavior

Ubuntu on another VLAN works through the same host/NIC/vSwitch

I would estimate well over 90% probability that the problem is on the MikroTik side, specifically:

  • Missing/incorrect NAT rule for 172.16.191.0/30
  • Firewall forward-chain rule blocking VLAN 191
  • Interface list membership issue (LAN/WAN lists)
  • Policy routing/VRF configuration affecting VLAN 191
  • Hyper-V does not appear to be the root cause based on the evidence you've provided.

If this resolves your issue, please accept this ANSWER or if you have any question drop a comment. Thanks

Was this answer helpful?

2 people found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

    Comments have been turned off. Learn more

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.