Complete Guide to X11 Forwarding Configuration in WSL2

WSL2 Network Architecture and X11 Forwarding Challenges

When migrating from WSL1 to WSL2, the network architecture undergoes fundamental changes. WSL2 employs full virtualization technology, running in a lightweight virtual machine, which means WSL2 instances have independent IP address spaces and reside in different network environments from the host Windows system. This architectural difference directly impacts X11 forwarding configuration methods.

Core Environment Variable Configuration

Correctly setting the DISPLAY environment variable in WSL2 is crucial for X11 forwarding. Unlike WSL1 which uses localhost:0, WSL2 requires obtaining the correct display address through the following method:

export DISPLAY=$(ip route list default | awk '{print $3}'):0
export LIBGL_ALWAYS_INDIRECT=1

This configuration queries the default routing table to obtain the host machine's IP address, ensuring X11 clients can properly connect to the X server on the Windows side. The LIBGL_ALWAYS_INDIRECT environment variable setting ensures OpenGL applications work correctly through indirect rendering.

Windows Firewall Configuration

The network isolation characteristics of WSL2 require specific configuration of the Windows firewall. An inbound rule needs to be created for TCP port 6000:

# Firewall rule configuration steps:
# 1. Open Windows Defender Firewall with Advanced Security
# 2. Create new inbound rule
# 3. Select TCP port 6000
# 4. Restrict IP range to 172.16.0.0/12 in scope settings

This configuration ensures only connections from within the WSL2 subnet can access the X server, maintaining both functionality and appropriate security levels.

X Server Access Control Settings

The X server running on the Windows side needs to be configured to allow connections from WSL2. For VcXSrv users, access control can be disabled through the following methods:

# Method 1: Configuration through graphical interface
# Uncheck "Access Control" option in Extra Settings

# Method 2: Command line startup
vcxsrv.exe -ac

Alternatively, users can choose to keep access control enabled and establish secure connections by sharing .Xauthority files. Although this method requires slightly more complex configuration, it provides better security assurance.

Complete Configuration Verification Process

To ensure correct configuration, it's recommended to follow this verification process:

# 1. Install X11 testing tools in WSL2
sudo apt update
sudo apt install x11-apps

# 2. Apply environment variable configuration
source ~/.bashrc

# 3. Run test application
xcalc

If configured correctly, the calculator application should display normally in the Windows desktop environment. This verification process confirms the complete communication pathway from WSL2 to the Windows X server.

Persistent Configuration and Automation

For daily convenience, it's recommended to persist the configuration in the ~/.bashrc file:

# Edit bash configuration file
nano ~/.bashrc

# Add the following content to the end of the file
export DISPLAY=$(ip route list default | awk '{print $3}'):0
export LIBGL_ALWAYS_INDIRECT=1

For users who frequently use X11 forwarding, the X server can be configured to start automatically with Windows by copying saved startup configurations to the startup folder.

Troubleshooting and Common Issues

Potential issues during configuration include improperly applied firewall rules, incorrect X server access control settings, or misconfigured environment variables. It's recommended to troubleshoot in the order of network connectivity, X server configuration, and environment settings, ensuring each component is properly configured.