How to Configure Windows Subsystem for Linux (WSL 2), Systemd Support, and Bridged Networking in Windows 11

Windows Subsystem for Linux 2 (WSL 2) represents a fundamental architectural departure from the original translation-layer design of WSL 1. Operating atop a lightweight utility virtual machine managed by the Microsoft Hyper-V hypervisor, WSL 2 provides full Linux kernel compatibility and native virtualised filesystem performance. However, power users, DevOps engineers, and system administrators often encounter two critical architectural limitations in default installations: the absence of systemd as the standard system and service manager under PID 1, and the network isolation imposed by Network Address Translation (NAT).

Configuring native systemd support unlocks enterprise system services, micro-services, and daemon supervisors such as Docker Engine, Podman, and Kubernetes micro-clusters directly within Linux distributions. Pairing this with bridged networking or advanced mirrored network modes allows the virtualised Linux environment to obtain a dedicated IP address on your physical local area network (LAN), making services directly accessible to external hosts without brittle port-forwarding scripts.

---

Architectural Overview: WSL 2 Init vs Systemd and Network Modes

Historically, WSL launched distributions using a proprietary Microsoft init binary (/init) mapped to PID 1. This bespoke process handled interoperability between Windows and the Linux guest, such as launching background tasks, synchronising environment variables, and establishing filesystem mounts (Plan 9 / 9P filesystem protocol). Because traditional enterprise daemons rely on systemd to manage units, sockets, and cgroups, standard systemctl commands failed with errors stating that the system had not been booted with systemd.

Modern WSL builds (version 0.67.6 and newer) resolve this by nesting Microsoft’s init process within a dedicated PID namespace where systemd assumes PID 1, while preserving Windows-Linux interop hooks. Simultaneously, network virtualization has progressed from legacy NAT to advanced virtual switch bridging and mirrored networking.

Network Mode	Virtualisation Architecture	IP Address Allocation	Host & LAN Accessibility	Best Use Case
NAT (Default)	Hyper-V internal virtual switch with dynamic subnetting	Isolated private subnet (e.g. 172.x.x.x) translated at host	Accessible from host via localhost; LAN access requires manual port proxying	Standard CLI development, lightweight scripting
Mirrored	Windows Hyper-V Network Virtualisation (HNV) interface mirroring	Mirrors host network interfaces and physical adapter IPs	Bi-directional native localhost binding; IPv6 and VPN split-tunnelling support	Corporate VPNs, web development requiring seamless localhost parity
Bridged	Hyper-V External Virtual Switch bound directly to physical NIC	Dedicated IP lease from local LAN DHCP or static enterprise range	Independent node on physical LAN; fully routable without host port proxies	Self-hosted daemons, staging servers, database nodes, network testing

---

Prerequisites and Environment Verification

Before modifying configuration files, ensure that your Windows 11 installation and WSL kernel satisfy the minimum build requirements. Systemd integration requires WSL package version 0.67.6 or later, while advanced bridged and mirrored networking features require Windows 11 Build 22621 (22H2) or higher.

Open an elevated PowerShell prompt (Run as Administrator) and inspect the current WSL version and installed distributions:

# Verify WSL version details
wsl --version

# Confirm target distribution runs under WSL 2 architecture
wsl --list --verbose

If the output does not display discrete version numbers for the WSL kernel and WSLg, update the core subsystem package from the Microsoft Store or GitHub releases:

# Update WSL components to the latest servicing release
wsl --update

# Ensure kernel update status is current
wsl --update --web-download

---

Enabling Native Systemd Support in Distribution Configuration

Configuration of distribution-specific behaviour in WSL is controlled by /etc/wsl.conf located inside the guest Linux filesystem. Enabling systemd instructs the WSL loader to initialise systemd as PID 1 upon boot.

Step 1: Edit the Distribution wsl.conf File

Launch your target distribution (such as Ubuntu or Debian) and edit the configuration file with administrative privileges:

sudo nano /etc/wsl.conf

Append the [boot] section and set the systemd flag to true:

[boot]
systemd=true

[user]
default=username

[interop]
enabled=true
appendWindowsPath=true

Save the file (Ctrl + O, then Enter) and exit the editor (Ctrl + X).

Step 2: Terminate and Restart the Subsystem

To force the subsystem to reload the configuration and launch systemd under a clean namespace, terminate running instances from Windows PowerShell:

# Shut down all active WSL 2 utility virtual machines
wsl --shutdown

Relaunch your Linux distribution from Windows Terminal or the Start Menu. Verify that systemd has assumed process identifier 1 and that the service manager reports an active state:

# Inspect PID 1 process designation
ps -p 1 -o comm=

# Verify systemd operational status
systemctl is-system-running

The command should return systemd for PID 1, and the operational status should report either running or degraded (the latter is normal if non-critical units such as serial console or display managers fail to bind in a headless VM environment).

---

Configuring Bridged Networking with Hyper-V External Virtual Switch

By default, WSL 2 operates behind a virtual Hyper-V NAT switch. To grant the WSL virtual machine direct access to your local physical network as a standalone device with its own LAN IP, create an External Virtual Switch in Windows Hyper-V and instruct WSL to bind to it via .wslconfig.

Requirement Note: Creating Hyper-V Virtual Switches requires Windows 11 Pro, Enterprise, or Education editions with the Hyper-V feature enabled. For Windows 11 Home users, the Mirrored Networking mode detailed further below provides an ideal alternative.

Step 1: Identify the Physical Network Adapter

Open an elevated PowerShell window and identify the exact name of your active Ethernet or Wi-Fi network interface:

# List available physical network adapters
Get-NetAdapter | Where-Object { $_.Status -eq 'Up' } | Format-Table -Property Name, InterfaceDescription, MacAddress, LinkSpeed

Take note of the Name field corresponding to your primary physical network connection (for instance, Ethernet or Wi-Fi).

Step 2: Create the Hyper-V External Virtual Switch

Using PowerShell, create a new external switch bound directly to that physical adapter. Replace "Ethernet" with your exact adapter name:

# Create External Virtual Switch named "WSL-Bridge"
New-VMSwitch -Name "WSL-Bridge" -NetAdapterName "Ethernet" -AllowManagementOS $true

The -AllowManagementOS $true parameter guarantees that your host Windows operating system continues to share network connectivity through the newly created virtual switch without dropping internet access.

Step 3: Configure Global WSL Settings (.wslconfig)

Global hardware and networking parameters for WSL 2 are governed by a configuration file in your Windows user profile: %USERPROFILE%\.wslconfig.

Open or create this file in PowerShell or Notepad:

# Open or create .wslconfig in Notepad
notepad $env:USERPROFILE\.wslconfig

Add the [wsl2] section with the vmSwitch parameter referencing your newly created virtual switch:

[wsl2]
# Direct WSL 2 to use the external bridged Hyper-V switch
vmSwitch=WSL-Bridge

# Optional: Customise resource allocations
memory=8GB
processors=4
swap=4GB

Save and close the file.

Step 4: Restart WSL and Verify LAN IP Allocation

Shut down the subsystem to apply the global virtual switch binding:

wsl --shutdown

Launch your Linux distribution and inspect the assigned network interface:

# Inspect IP address on the primary interface (eth0)
ip -4 addr show eth0

Rather than an isolated 172.x.x.x NAT address, eth0 will now hold an IP leased directly from your local router’s DHCP pool (for example, 192.168.1.145/24), placing your Linux guest on the same subnet as other physical devices on your LAN.

---

Alternative: Mirrored Networking Mode (Windows 11 23H2+)

For systems running Windows 11 Build 22621+ where creating a Hyper-V external switch is impractical (such as on laptop Wi-Fi interfaces that reject MAC address spoofing, or on Windows 11 Home editions), Microsoft introduced Mirrored Networking. In this mode, the Linux environment mirrors the host’s actual network interfaces seamlessly.

To enable mirrored networking, open $env:USERPROFILE\.wslconfig and configure the following parameters:

[wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

Key advantages of this mode include:

• Localhost Parity: Services listening on 0.0.0.0 inside WSL 2 are automatically accessible via localhost from Windows, and host services are reachable from WSL at localhost.
• Full VPN Compatibility: DNS tunnelling ensures corporate VPN routes and enterprise DNS resolvers are forwarded directly into Linux without broken routing tables.
• IPv6 Support: Native IPv6 addresses assigned to the Windows physical adapter are mirrored into the Linux network stack.

---

Practical Implementation: Running Managed Daemons under Systemd

With systemd active and network reachability configured, you can install and supervise production daemons using native Linux package repositories and service managers.

Step 1: Install and Enable Nginx Web Server

Update apt repositories, install Nginx, and activate the systemd unit:

# Update repositories and install Nginx
sudo apt update && sudo apt install -y nginx

# Verify systemd service status
sudo systemctl status nginx

# Enable Nginx to launch automatically whenever WSL starts
sudo systemctl enable nginx

Step 2: Test Network Reachability

In bridged mode, you can open a web browser on another computer, smartphone, or tablet connected to your local Wi-Fi or LAN, and navigate directly to your WSL IP address:

http://192.168.1.145

The standard “Welcome to nginx!” default landing page will render immediately, confirming complete LAN routing into the virtualised environment.

---

Troubleshooting Common WSL 2 Systemd and Networking Faults

Symptom / Error	Root Cause	Diagnostic & Resolution Procedure
systemctl is-system-running returns degraded	Headless VM lacks physical hardware consoles; non-essential units fail	Run systemctl --failed to identify faulty units. Typically systemd-remount-fs.service or serial-getty. Mask unnecessary units with sudo systemctl mask [email protected].
Wi-Fi drops or bridging fails when binding External VMSwitch	Physical wireless NICs enforce single MAC address per association	Wi-Fi adapters frequently drop promiscuous packet bridging. Switch to networkingMode=mirrored in .wslconfig, or bind the Hyper-V switch to a physical Ethernet NIC.
DNS resolution fails inside WSL (Temporary failure in name resolution)	Dynamic /etc/resolv.conf generation conflicts with custom networking	Disable automatic resolv generation by adding [network]\ngenerateResolvConf=false to /etc/wsl.conf. Remove symlink with sudo rm -f /etc/resolv.conf and create static file containing nameserver 1.1.1.1.
Windows Firewall blocks inbound traffic to Bridged WSL IP	Windows Defender Firewall filters virtual Hyper-V switch traffic	Create an inbound firewall rule in PowerShell: New-NetFirewallRule -DisplayName "WSL Bridge Inbound" -Direction Inbound -Action Allow -EdgeTraversalPolicy Allow.
Subsystem fails to launch with error 0x80070003 or 0x80370102	Hardware virtualisation disabled in UEFI/BIOS or Hyper-V platform offline	Reboot host and enable Intel VT-x or AMD SVM in motherboard BIOS. In Windows, verify Hyper-V feature is active via Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All.

---

Configuration Maintenance and Best Practices

To preserve stability across operating system updates and subsystem upgrades, adhere to these management practices:

• Keep Host and Guest Synchronised: Periodically execute wsl --update in Windows PowerShell to retrieve patched kernel builds, while maintaining standard package upgrades inside the guest with sudo apt update && sudo apt upgrade -y.
• Clean Daemon Shutdowns: When shutting down your workstation, execute wsl --shutdown or allow Windows to send graceful ACPI signals to give systemd units adequate time to flush cached data and unmount filesystems cleanly.
• Manage Resource Throttling: Unchecked daemons inside WSL 2 can consume substantial host RAM. Retain sensible limits in %USERPROFILE%\.wslconfig under memory and processors to guarantee that your Windows host environment retains sufficient compute headroom.