WSL Networking Beyond NAT and Mirrored: none and Consomme Boundaries

Most WSL networking guidance focuses on NAT and mirrored mode, but Microsoft’s current .wslconfig reference lists other values: none and consomme, in addition to a deprecated bridged mode. These options should not be treated as interchangeable labels for “offline” or “more compatible.” none disconnects the WSL network. consomme selects a WSL networking mode whose public description is limited compared with NAT and mirrored; Microsoft notes it was previously called virtioproxy and that, starting with WSL 2.3.25, failed NAT setup can fall back to Consomme. The correct operational approach is to test the actual requirement on the installed WSL version and avoid inferring undocumented implementation details.

Read the current contract, not old mode names

The current advanced settings page lists networkingMode under [wsl2]. Its documented values include none, nat, bridged (deprecated), mirrored, and consomme. It says none disconnects the WSL network, nat or an unknown value uses NAT, and WSL 2.3.25 or newer falls back to Consomme if NAT networking fails. It also says the name virtioproxy was used for Consomme in the past. A config file that still uses virtioproxy may therefore be stale relative to the current documented spelling.

The current page marks the networking mode setting as Windows 11-only and requiring Windows 11 version 22H2 or higher. Check wsl --version and the Windows build before assuming the current list is available. Store-delivered WSL can evolve independently from the Windows feature update cadence, so a host build alone is not enough to identify every feature.

The public page describes Consomme’s availability and fallback role, but it does not provide a complete topology, performance contract, VPN guarantee, or firewall bypass guarantee. Do not fill those gaps with assumptions based on the previous name. If a workload depends on a specific transport property, capture the relevant WSL version and validate it rather than claiming that Consomme behaves like a particular upstream virtual network implementation.

Use `none` only when a disconnected WSL network is the requirement

An example is:

[wsl2]
networkingMode=none

Microsoft describes this mode as disconnecting the WSL network. That makes it appropriate for a narrow test that explicitly requires no WSL network connection, or a local-only lab where applications do not need network access. It is not a substitute for a firewall policy, host isolation, a secure sandbox, or a guarantee that software cannot communicate through another enabled integration. WSL has other host/guest features, and a distribution’s processes and files still exist on the Windows machine.

Before switching, identify dependencies that can fail when network access disappears: package managers, databases with remote clients, language toolchains, cloud-init, apt timers, container pulls, DNS, proxy discovery, NTP, license checks, and development editors. Record which operations are expected to continue locally. A network disconnection can make startup jobs wait or report errors even when the underlying distribution is healthy.

After changing the mode, shut down and restart WSL. From Linux, record interface state and routes with ip address and ip route. Attempt only an approved controlled network check, and verify local filesystem, shell, and GUI workflows that are meant to remain available. An empty route table is evidence about the guest routing state; it does not prove the full Windows device is isolated from networks.

Understand Consomme as a documented alternative and fallback

Setting networkingMode=consomme explicitly requests Consomme according to Microsoft’s current table. The same page documents a NAT fallback to Consomme starting at WSL 2.3.25 if NAT networking fails. That fallback means a request for NAT may not result in the expected NAT state on those versions; operational monitoring should record effective behavior, not merely configuration intent.

The documentation gives no detailed Consomme topology in that table. Avoid describing it as “NAT with a different name,” “mirrored without firewall,” or “a direct VPN mode” unless a current primary source for the target version supports the exact claim. The old virtioproxy name is useful for recognizing legacy configuration and discussions, but it does not authorize using that spelling indefinitely. Prefer current documented names and compare behavior through a reproducible test.

If a NAT failure triggers fallback, record the version, exact startup time, config value, WSL diagnostics, interface addresses, routes, DNS status, and target reachability. The fact that a service becomes reachable after fallback indicates the networking path changed; it does not establish the root cause or guarantee identical behavior on a later release.

Keep mode selection separate from DNS and firewall configuration

Networking mode, DNS tunneling, automatic proxy import, mirrored-mode firewall handling, localhost forwarding, port binding, and host-address loopback are distinct controls. A hostname that fails may point to DNS even while IP connectivity is healthy. A port that cannot accept traffic may be a listener or firewall problem rather than a mode-selection issue. A change to none predictably removes external network connectivity but should not be used as a diagnosis for a Windows-to-WSL port-forwarding defect.

Keep one mode change per test. Use a test matrix that includes: mode configured; runtime version; guest interfaces/routes; DNS lookup result; outbound TCP test to an approved endpoint; inbound request from Windows if required; and app-level readiness. Record whether VPN and proxy are active. Do not test only ping, because ICMP may be blocked while TCP works, or may succeed while a service port is closed.

For mirrored mode, consult Microsoft’s separate networking and Hyper-V firewall guidance. For DNS tunneling, inspect the generated resolver path. For a test that explicitly selects none, avoid claiming a firewall effect beyond the documented WSL network disconnection. Each control solves a different scope of problem.

Apply a controlled mode change

Back up the current .wslconfig and merge the single test value into the existing [wsl2] section. If the machine is managed, use the approved configuration owner. Shut down all WSL 2 workloads cleanly; wsl --shutdown stops every running distribution and can interrupt databases, containers, and editor backends. Start one representative distro and collect the test matrix before bringing up dependent services.

If the new mode prevents required work, change the value back to the prior documented setting, perform another full restart, and verify the original path. If no explicit non-default mode is required, remove the override and use the current documented default. Do not toggle bridged: Microsoft has marked it deprecated since WSL 2.4.5, so existing bridged setups need a migration plan based on current official guidance rather than new deployments.

Operational acceptance

A mode choice is ready when the target WSL package and Windows release satisfy the documented prerequisites; the exact mode is verified after restart; the required DNS, routes, and application connections pass; expected negative tests fail for the intended reason; and unrelated distros still function. For none, explicitly identify which local features remain in scope and do not call the whole machine isolated. For Consomme, describe only behavior actually measured or documented.

Keep a change record with the prior mode, new mode, reason, affected service, configuration scope, restart window, diagnostics, and rollback. Revalidate after WSL updates because a fallback or mode implementation may change. The goal is not to collect networking mode labels; it is to ensure the observed client-server path matches an explicit requirement without relying on undocumented internals.

Read effective state conservatively

The WSL 2.0.4 release added the /usr/bin/wslinfo utility and its --networking-mode argument. Check that the command exists on the target installation, then capture its output alongside the Windows-side config and version inventory. Treat it as a direct mode observation, not a full health check. An effective mode label cannot prove that DNS works, that a specific route is installed, or that an inbound firewall rule allows a connection. When the command is not available, use the documented Linux interface and route observations and report that the mode is inferred from behavior rather than exposed by an introspection command.

For none, verify the intended lack of network connectivity using more than one approved path, but do not turn the exercise into an unbounded scan. For Consomme, capture one outbound destination and one required local host/guest path, then compare with a controlled NAT or mirrored test only if switching is safe. Keep the test network isolated from sensitive production systems. The objective is to establish compatibility for a known use case, not to reverse-engineer an undocumented virtual networking implementation.

Windows updates, VPN software, and policy can also alter the result independently of the WSL mode. If the same WSL setting behaves differently on two machines, compare host build, WSL package version, VPN state, Hyper-V firewall rules, route metrics, and network adapter inventory before attributing the difference to the mode. Preserve both the configured value and observed network state in any escalation.

Related:

Sources: