WSL 2 and the Hyper-V Firewall: Where Mirrored Networking Is Actually Filtered

A service listening inside WSL and reachable from Windows localhost, but not reachable from another machine on the same LAN, is frequently misdiagnosed as a Linux firewall problem — checking iptables or ufw rules inside the distribution — when the actual filtering decision is happening at a layer those tools have no visibility into at all: the Hyper-V firewall, sitting between WSL’s networking and the rest of the network.

Why WSL 2 networking involves a firewall layer beyond Linux’s own

WSL 2 runs inside a lightweight virtual machine, and traffic to and from that VM crosses Windows’ own virtualization networking stack before it reaches (or leaves for) the wider network. Starting in Windows 11, version 22H2, the Hyper-V firewall became a distinct network firewall solution specifically covering traffic to and from containers and virtualized environments hosted by Windows — including WSL. On machines running Windows 11 22H2 and higher with WSL 2.0.9 and higher, this firewall is turned on by default, meaning it’s actively making filtering decisions about WSL traffic whether or not you’ve configured anything inside Linux at all.

Mirrored networking mode is where this becomes most visible

Setting networkingMode=mirrored in .wslconfig (available on Windows 11 22H2 and higher) changes WSL’s networking architecture so that Linux sees the same network interfaces Windows itself sees, rather than a separate, NAT-translated virtual network. This mode’s benefits — IPv6 support, better VPN and multicast compatibility, and the ability to reach the WSL environment directly from the LAN — are exactly why it makes the Hyper-V firewall layer’s role more consequential: with Linux interfaces mirroring the host’s own, a service bound inside WSL is genuinely closer to being LAN-reachable, which means the firewall policy governing that reachability matters considerably more than it did under the older, more isolated NAT model.

Why iptables rules alone can’t tell you the full story

A Linux firewall rule inside the distribution governs what Linux itself permits at its own network stack layer. It says nothing about whether the Hyper-V firewall, sitting at the Windows virtualization layer above it, additionally permits or blocks that same traffic before it ever reaches Linux’s own filtering rules, or after Linux has already allowed it out. A connection can be blocked by the Hyper-V firewall despite a permissive Linux ruleset, and equally, a restrictive Linux ruleset can block traffic that the Hyper-V firewall itself would have allowed through — the two layers are independent, and diagnosing connectivity by checking only one of them gives an incomplete picture.

Building an accurate mental model before troubleshooting

Before changing any specific rule, write down what you actually expect: which process is listening, on which Linux-side address and port, which Windows network profile (Domain, Private, Public) is currently active, and whether the intended reachability is localhost-only, LAN-wide, or something in between. This matters because Windows firewall profiles apply different default policies depending on network profile, and a service that should be reachable on a trusted office LAN but not on a public Wi-Fi network needs a firewall configuration that actually reflects that distinction, not a single blanket rule assumed to apply everywhere.

Testing from three vantage points, not one

Confirming actual reachability requires testing from each relevant vantage point separately: from inside the Linux distribution itself (confirming the service is genuinely listening and Linux’s own rules permit local access), from the Windows host (confirming the Hyper-V firewall and Windows-side routing allow host-to-guest reachability), and from a separate machine on the LAN (confirming the full path Windows exposes externally). A service reachable from Windows localhost but not from the LAN has narrowed the problem to the host-to-network boundary specifically — exactly where Hyper-V firewall rules and the active Windows network profile are the relevant things to check, rather than anything inside Linux.

Adjusting Hyper-V firewall rules when default behavior doesn’t match your need

Windows exposes Hyper-V firewall configuration through the standard Windows Defender Firewall with Advanced Security interface and equivalent PowerShell cmdlets, since Hyper-V firewall rules are managed through the same overall firewall management surface rather than an entirely separate, WSL-specific tool. Community tooling such as WSL2-HyperV-Firewall-Manager exists specifically because the default advanced security console isn’t always the most convenient interface for WSL-specific rule management, but any change made through such a tool is ultimately expressed as ordinary Windows firewall configuration and should be understood and reviewable as such, not treated as an opaque, WSL-specific black box.

Falling back to NAT networking when mirrored mode isn’t supported

Not every environment supports mirrored networking mode — older Windows builds, certain enterprise policy configurations, or specific network adapter configurations can cause WSL to report that mirrored networking or the Hyper-V firewall integration isn’t supported, falling back to the older NAT-based model instead. If mirrored mode was expected but WSL reports falling back, that’s worth investigating as a distinct problem (a Windows version or policy mismatch) before assuming any firewall-specific troubleshooting applies, since the entire premise of Hyper-V firewall governing WSL traffic depends on mirrored mode’s networking architecture actually being active in the first place.

Documenting the expected reachability alongside the service

Because the layered nature of this filtering is genuinely easy to forget between troubleshooting sessions, noting — right next to a service’s own configuration — whether it’s meant to be localhost-only, host-reachable, or LAN-reachable, and which firewall layer enforces that boundary, saves a future troubleshooting session from re-deriving the same three-vantage-point test from scratch.

Reviewing active Hyper-V firewall rules directly

Get-NetFirewallHyperVRule

Listing the currently active rules this way, rather than assuming based on the default profile alone, confirms exactly what’s permitted or blocked for WSL and other virtualized traffic on a specific machine — a necessary step before concluding a specific reachability gap is expected default behavior rather than an actual misconfiguration worth correcting. Related: Fixing WSL2 Networking and DNS Resolution Failures · How to Configure and Switch WSL2’s Networking Mode

Sources: