Mirrored networking: reply from TUN-based VPN adapter dropped before reaching WSL vNIC

[mateus2k2]

Windows Version

Microsoft Windows [Version 10.0.26200.9168]

WSL Version

2.7.12.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.18.33.2-2

Distro Version

Ubuntu 24.04.3 LTS (Noble Numbat)

Other Software

Viscosity 1.13.1 (build 1.13.1.1884) — OpenVPN-based VPN client for Windows (https://www.sparklabs.com/viscosity/), configured as a standard dev tun (layer-3, point-to-point) client profile, pull-filter ignore redirect-private (split tunnel — only the remote's specific subnet is routed, not a full-tunnel default route).

Repro Steps

1. .wslconfig:
   [wsl2]
   networkingMode=mirrored
   firewall=true
   [experimental]
   hostAddressLoopback=true

2. Connect a Viscosity VPN profile on the Windows host that uses a dev tun (layer-3) adapter — not dev tap. Example: remote gateway 10.9.0.1, client address 10.9.0.2 on a /24, with a pushed route to a remote subnet (192.168.211.0/24) reachable only through the tunnel.

3. Confirm the VPN works from the Windows host itself: ping 192.168.211.68 succeeds (TTL 63, ~20ms).

4. Start WSL (wsl -d Ubuntu). Confirm the VPN adapter is mirrored in:
   ip addr show

eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet 10.9.0.2/24 brd 10.9.0.255 scope global noprefixroute eth4

5. From WSL: ping 10.9.0.1 (the VPN's own directly-connected gateway) → fails with Destination Host Unreachable (source 10.9.0.2, i.e. generated locally, packet never left the machine).
6. ip neigh show dev eth4 → 10.9.0.1 dev eth4 INCOMPLETE (ARP never resolves).
7. Ruled out as a config/timing issue:

• firewall=false in .wslconfig → no change.
• Fully reconnecting the VPN before starting WSL (so mirroring should pick up an already-healthy adapter) → no change, same INCOMPLETE result.
• net.ipv4.conf.{all,default,eth4}.arp_ignore=1 inside WSL → no change.
• Manually forcing WSL's ARP resolution with a static neighbor entry pointing at WSL's own internal placeholder MAC (00:11:22:33:44:55, the MAC WSL's DNS-tunneling/relay channel uses on every mirrored interface):

  sudo ip neigh replace 10.9.0.1 lladdr 00:11:22:33:44:55 dev eth4 nud permanent
  

  This does change the symptom (WSL no longer blocks the packet locally — no more "Destination Host Unreachable"), but still 100% packet loss. See the packet capture below for why.

8. Windows host's own ARP table for the same gateway is a null MAC (expected for a tun adapter — Windows never does real L2/ARP for it either, it routes to it directly at L3 as a point-to-point interface):
   arp -a
   Interface: 10.9.0.2 --- 0x1d
   10.9.0.1 00-00-00-00-00-00 dinâmico

9. Captured with pktmon (admin PowerShell) filtered on 10.9.0.1 / 192.168.211.68, with the static neighbor entry from step 7 in place, while pinging 10.9.0.1 from WSL:
   pktmon filter add -i 10.9.0.1
   pktmon filter add -i 192.168.211.68
   pktmon start --etw -c -m real-time

Result: the ICMP echo request is seen leaving WSL, traversing the relay chain (components 178→59→25→26→2→61→3→204), and the VPN gateway does reply — the reply is seen arriving back through components 204→3→61 (real host-side relay/tunnel chain). It is then dropped twice in a row before reaching WSL's vNIC:
Solte: ... Direction Tx , tipo IP , componente 150, DropReason IPSNPI: No Ethernet header
Solte: ... Direction Rx , tipo IP , componente 143, DropReason ICMP: inspection drop
Solte: ... Direction Rx , tipo IP , componente 143, DropReason INET: transport endpoint was not found
Solte: ... Direction Rx , tipo IP , componente 143, DropReason Inspection drop

Expected Behavior

WSL should be able to reach the VPN's directly-connected gateway (10.9.0.1) and anything routed through it (e.g. 192.168.211.68), matching what the Windows host itself can already do over the same tunnel — consistent with the documented purpose of mirrored networking mode (WSL shares the host's network reachability) and with Microsoft's own prior acknowledgment of this class of bug (KB5067036 regression / KB5074109 fix, "mirrored networking in WSL could fail" with VPN virtual interfaces). This machine is on a build newer than KB5074109 (10.0.26200.9168), so the originally-documented regression is not the (or not the only) cause here.

At minimum, the reply packet actually returned by the VPN gateway (confirmed via pktmon, see step 9) should not be silently dropped by the host's own relay/callout chain (IPSNPI: No Ethernet header) before it reaches the mirrored WSL vNIC.

Actual Behavior

WSL cannot reach the VPN gateway or anything behind it, even though:

• The VPN is fully healthy on the Windows host (ping succeeds, TTL 63).
• The interface is correctly mirrored into WSL with the right IP/route (ip route get 192.168.211.68 correctly resolves via 10.9.0.1 dev eth4).
• The VPN gateway does reply to WSL's request — confirmed via pktmon, the ICMP echo reply is seen arriving back through the host's relay chain (components 204/3/61).

The reply is then dropped before delivery to WSL's mirrored vNIC, root-caused via pktmon to:
componente 150, DropReason IPSNPI: No Ethernet header

i.e. the relay driver needs to wrap the reply (which arrives as a bare L3/IP packet, since it came off a tun adapter with no real Ethernet layer) into an Ethernet frame to hand to WSL's mirrored interface, and has no destination MAC to use — because no genuine ARP/L2 resolution ever happens for this adapter on either side (the Windows host's own ARP table entry for the same gateway is also a null MAC, 00-00-00-00-00-00 — Windows itself never does real L2 for this adapter, it just routes to it directly).

This means the failure is not fixable from the WSL/guest side — no sysctl, static ARP/neighbor entry, or routing change in WSL changes the outcome, since the packet is dropped by the Windows-side relay driver before it ever reaches WSL's virtual NIC. Tested and ruled out:

• net.ipv4.conf.*.arp_ignore=1 inside WSL
• Static ip neigh entry in WSL for the gateway
• firewall=true/false in .wslconfig
• Connecting the VPN before starting WSL (rules out mirroring a stale/pre-VPN adapter state)
• Full Windows reboot (also unrelated: uncovered a separate NAT-mode regression on this machine — networkingMode=mirrored removed left WSL with zero internet, no Get-NetNat object was ever created for WSL's NAT subnet; reverting to mirrored mode restored general connectivity, unrelated to this VPN-specific issue and not otherwise reported here)

The only workaround is running the VPN client inside WSL directly (bypassing the Windows-side relay entirely), which is not always viable (e.g. splitting VPN access between Windows-native apps and WSL).

Diagnostic Logs

WslLogs-2026-08-25_19-48-49.tar.gz

[github-actions]

Diagnostic information

.wslconfig found
Detected appx version: 2.7.12.0

[chemwolf6922]

Hi FetoiuCatalin . Could you please help take a look? Thanks.

Mateus (@mateus2k2) . Thanks for reporting this. While we look at it, you could try switch to virtioproxy mode if that suits your needs.

[wsl2]
networkingMode=virtioproxy

[mateus2k2]

Hi FetoiuCatalin . Could you please help take a look? Thanks.

Mateus (@mateus2k2) . Thanks for reporting this. While we look at it, you could try switch to virtioproxy mode if that suits your needs.

[wsl2]
networkingMode=virtioproxy

virtioproxy does make the VPN work on WSL, but then my LAN can't access the services running on WSL, and WSL can't reach other devices on my LAN via there LAN IP. Mirrored mode was really the best of both words. Sad it does not work anymore :(

[icicimov]

Independent reproduction with a different VPN client, and one observation that I
think narrows the mechanism: it also fails when the Windows-side adapter does
have a real Ethernet layer and a properly resolved ARP entry.

Environment (slightly older than the original report, same kernel):

Windows      10.0.26200.9106
WSL          2.7.10.0
Kernel       6.18.33.2-2
Distro       Ubuntu 24.04
Client       OpenVPN Connect 3.3.7, TAP-Windows Adapter V9
             (tap_ovpnconnect.sys 9.24.2.601), profile is dev tun / split tunnel
.wslconfig   networkingMode=mirrored, dnsTunneling=true, autoProxy=true,
             firewall=false, [experimental] hostAddressLoopback=true

Why this is not just "tun adapters have no Ethernet header"

The original analysis rests on the host's own ARP entry for the gateway being a
null MAC, because a dev tun adapter never does real L2. That is not the case
here. Although the OpenVPN profile is dev tun, the Windows-side driver is
TAP-Windows V9 — an Ethernet miniport that emulates L2 and answers ARP for a
synthetic gateway MAC. Windows resolves the tunnel gateway to a genuine MAC in
state Reachable:

# Windows, Get-NetNeighbor on the TAP adapter
<tunnel-gw>   00-FF-74-AA-BB-CC   Reachable      <- real MAC, not 00-00-00-00-00-00

# Get-NetAdapter, same interface
MacAddress    00-FF-73-AA-BB-CC                  <- adapter's own MAC

(MACs partially redacted; the relationship is exact — TAP-Windows derives the
synthetic gateway MAC from the adapter MAC, differing only in the third octet.)

So on the host side there is a real Ethernet layer, a real destination MAC, and a
resolved neighbour entry. Windows itself reaches everything through the tunnel
normally (Test-NetConnection <host behind tunnel> -Port 443 → True).

Inside WSL the mirrored interface fabricates its own unrelated L2 instead of
reflecting any of that:

# WSL
eth0          link/ether 00:15:5d:XX:XX:YY       <- Hyper-V vmbus vNIC MAC
ip neigh      <tunnel-gw> lladdr 00:15:5d:PP:PP:QQ REACHABLE
                                                 ^ a *different* Hyper-V MAC,
                                                   not the TAP gateway MAC above

Routes mirror in correctly and ip route get picks the right interface, but
every TCP connection to anything behind the tunnel is blackholed, while
non-tunnel destinations over the physical NIC are fine.

Static neighbour entry with the correct MAC also fails

The original report tried a static entry pointing at WSL's internal placeholder
MAC (00:11:22:33:44:55). Worth noting that supplying the genuinely correct
destination MAC does not help either — in this setup that MAC actually exists,
so it is a stronger negative result:

sudo ip neigh replace <tunnel-gw> lladdr 00:ff:74:aa:bb:cc dev eth0 nud permanent
sudo ip link set eth0 promisc on
# TCP connect to a host behind the tunnel: still fails

Promiscuous mode was added on the assumption that the reply would come back
addressed to the TAP adapter's MAC rather than the vNIC's. No change. Consistent
with the pktmon finding that the drop happens on the Windows side before the
vNIC is reached — but it means "the relay has no MAC to use" cannot be the whole
story, since here a correct MAC is available on both ends and supplying it
explicitly changes nothing.

Minor: firewall=false may not actually be applied

Relevant because firewall=true/false was tested and ruled out. On this
machine .wslconfig has firewall=false and WSL was restarted, yet:

Get-NetFirewallHyperVVMSetting -PolicyStore ActiveStore
# Enabled : True     <- PersistentStore shows NotConfigured, no GPO involved

So the Hyper-V VM firewall was still enabled despite the setting. Possibly
because this account is not a local administrator and WSL cannot apply it. Either
way, anyone concluding "firewall is not the cause" from that setting alone may not
have actually disabled it. (Outbound default is Allow here, so it is not the
cause in this instance.)

On the workarounds

virtioproxy has the same trade-off reported above — it restores VPN but breaks
LAN reachability in both directions, which defeats the point of mirrored mode for
anyone who needs both.

Running the VPN client inside WSL does work and is what I settled on, but it is
worth flagging that it runs into a separate WSL issue: bind() costs ~10 ms per
call under WSL2 for every socket family, and openvpn3-linux opens a fresh
netlink socket per pushed route. With a large split-tunnel route set that exceeds
its internal 5 s timeout and no tunnel is ever established. Workaround is
route-nopull plus installing the routes separately via ip -batch. Filed as
#41470; noting it here because "run the VPN inside WSL" is not necessarily a
turnkey fallback.