Solution 1: Native GUI Support with WSLg (Recommended for Modern Windows)

For users operating on Windows 11 or Windows 10 (Version 22H2, build 2311 or later), Microsoft offers WSLg (Windows Subsystem for Linux GUI).

WSLg provides out-of-the-box support for running Linux GUI applications, eliminating the need for manual installation of an X server on Windows or intricate DISPLAY variable configuration.

Prerequisites:

• Windows 11, or Windows 10 Version 22H2 (build 2311) or higher. Your build number can be verified via the “System Information” application.
• WSL2 instance (WSL1 is not compatible with WSLg).
• (Recommended) Updated graphics drivers for your vGPU (Intel, AMD, NVIDIA).

Steps:

1. Ensure your Windows system is fully updated.
2. Update WSL to the latest version. Open PowerShell as an administrator and execute:

   wsl --update

3. Restart the WSL subsystem to apply changes:

   wsl --shutdown

   Subsequently, launching a WSL2 distribution will start the updated version.

4. Crucially, remove any manual DISPLAY environment variable settings from your WSL2 shell configuration files (e.g., ~/.bashrc, ~/.zshrc) if previously added for other X11 forwarding methods.

Why it works: WSLg integrates a Wayland server, an X server (XWayland), and a PulseAudio server directly into the WSL2 environment. It automatically manages display and audio forwarding, streamlining the process. Consequently, GUI applications launched from WSL2 generally function without additional configuration.

Read: How to Access Serial Ports (COM & ttyS) in Windows Subsystem for Linux (WSL1 & WSL2)

Solution 2: Manual Configuration for X11 Forwarding

If WSLg is unavailable or not preferred, manual configuration becomes necessary. This process involves setting environment variables within WSL2, configuring an X server application on the Windows host, and adjusting the Windows Firewall.

2.1. Essential Environment Variables in WSL2

Two primary environment variables must be established in your WSL2 Linux environment. These are typically set within your shell’s startup file (e.g., ~/.bashrc for Bash):

• DISPLAY: This variable informs Linux GUI applications about the network location of the X server.
• LIBGL_ALWAYS_INDIRECT: This variable often aids OpenGL rendering compatibility.

A common and reliable method to set these variables dynamically is:

# Add to ~/.bashrc or equivalent
export DISPLAY=$(ip route list default | awk '{print $3}'):0
export LIBGL_ALWAYS_INDIRECT=1
                

The command ip route list default | awk '{print $3}' programmatically identifies the IP address of the default gateway for the WSL2 instance. From WSL2’s perspective, this gateway IP is the address of the Windows host. Appending :0 specifies the primary display (screen 0) on that host.

Setting LIBGL_ALWAYS_INDIRECT=1 compels OpenGL applications to utilize indirect rendering, which is generally more compatible with X servers running on a separate Windows host system.

2.2. Configuring the X Server on Windows

An X server application must be installed and operational on your Windows host. Popular choices include VcXSrv and Xming. During the X server’s launch or configuration phase (e.g., using VcXSrv’s XLaunch utility), consider the following:

• Disable Access Control: This is a critical step. Search for an option like “Disable access control” and ensure it is enabled (checked). For VcXSrv, this can also be achieved by launching it with the -ac command-line argument:

  vcxsrv.exe -ac

• Native OpenGL (VcXSrv): Some users find that unchecking “Native opengl” in VcXSrv’s settings improves compatibility, particularly when LIBGL_ALWAYS_INDIRECT=1 is active in WSL2.

Disabling access control allows any client on the network, including your WSL2 instance, to connect to the X server. While convenient, it’s important to consider the security implications of this setting in environments with untrusted network participants.

2.3. Adjusting Windows Firewall

The Windows Firewall will typically block unsolicited incoming connections from WSL2 to your X server. An inbound rule must be created to permit this traffic.

1. Launch “Windows Defender Firewall with Advanced Security”.
2. Navigate to “Inbound Rules” in the left pane, then click “New Rule…” in the right pane.
3. Rule Type: Select “Port” and proceed.
4. Protocol and Ports: Choose “TCP”. For “Specific local ports”, enter 6000. (Port 6000 is the standard X11 port. If your X server is configured to use a different port or range, specify that instead). Proceed.
5. Action: Select “Allow the connection” and proceed.
6. Profile: Determine which network profiles (Domain, Private, Public) this rule applies to. “Private” is generally appropriate for home networks. Proceed.
7. Name: Assign a descriptive name, such as “WSL2 X11 Access”, and an optional description. Click “Finish”.

Enhancing Firewall Security by Scoping the Rule:
To restrict access more tightly, configure the rule to accept connections only from WSL2’s specific IP address range. Follow these steps:

1. In “Inbound Rules”, locate and right-click your newly created rule, then choose “Properties”.
2. Switch to the “Scope” tab.
3. Under the “Remote IP address” section, select “These IP addresses” and click “Add…”.
4. Input the CIDR notation for your WSL2 virtual network. Common general ranges include 172.16.0.0/12. More specific ranges (e.g., 172.23.0.0/16, 192.168.x.x/y) can be determined by examining the output of ip addr within WSL2 for the eth0 interface or the WSL network adapter settings in Windows.
5. Confirm and apply these changes.

Solution 3: X11 Forwarding via SSH

This technique leverages SSH’s secure X11 forwarding mechanism. It establishes a secure channel and generally bypasses the need for direct X server firewall port opening or global disabling of X server access control.

Prerequisites:

• An X server (e.g., VcXSrv, Xming) installed and running on Windows. It can be launched with default settings (access control enabled). Set its display number (e.g., to 0).
• An SSH server (openssh-server) installed and operational within your WSL2 distribution.

  
  sudo apt update
  sudo apt install openssh-server
  # Ensure X11Forwarding is set to yes in /etc/ssh/sshd_config (usually default)
  # sudo systemctl enable ssh --now  # For systemd-enabled distros
  sudo service ssh start           # For non-systemd init
                          

• An SSH client on Windows supporting X11 forwarding (e.g., PuTTY, the built-in OpenSSH client in Windows Command Prompt/PowerShell, or Git Bash’s SSH).

Connection Steps:

1. From your Windows SSH client, initiate a connection to your WSL2 instance with X11 forwarding enabled (-X or -Y flag). WSL2 typically forwards port 22 from the Windows host (localhost) to the SSH server in the WSL2 VM.

   
   # Using OpenSSH from Windows Command Prompt or PowerShell:
   ssh -X #YourWSLUsername#@localhost
   # Or, for trusted X11 forwarding (less secure, but may help with some apps):
   # ssh -Y #YourWSLUsername#@localhost
                           

   (Replace #YourWSLUsername# with your actual username in the WSL2 environment.)

2. Upon successful connection, the SSH session automatically configures the necessary DISPLAY variable within WSL2. GUI applications launched in this SSH session will have their display forwarded.

Creating Windows shortcuts (example using Git Bash SSH):

"C:\Program Files\Git\git-bash.exe" -c "DISPLAY=127.0.0.1:0 ssh -Y -f #YourWSLUsername#@localhost 'bash -l -c #YourGUIApplication# >/dev/null 2>&1'"
                

(Replace #YourWSLUsername# and #YourGUIApplication#. The initial DISPLAY=127.0.0.1:0 is for the Git Bash environment itself, while the SSH connection manages X11 forwarding into WSL2.)

Why it works: The SSH client on Windows establishes a local listener for X11. When a GUI application runs in WSL2 via this SSH session, its X11 traffic is securely tunneled over SSH to the client.

The client then directs this traffic to the Windows X server. This method relies on SSH for both security and display management.

Read: How to fix Bluetooth connection problems on Ubuntu 22.04

Solution 4: Advanced – Tunneling X11 via `socat` and a WSL1 Instance

This more intricate solution is suitable for scenarios where direct IP-based connections are challenging. It utilizes a WSL1 instance as an intermediary for network traffic.

Prerequisites:

• An X server active on Windows (e.g., VcXSrv), listening on its standard TCP port (e.g., 6000).
• A functional WSL1 distribution with socat installed.
• socat also installed in your primary WSL2 distribution.

Configuration:

1. Within your WSL2 distribution, establish a Unix domain socket. Use socat to forward connections from this socket, through the WSL1 instance, to the X server on Windows. Execute this command in the background in WSL2:

   
   mkdir -p /tmp/.X11-unix/
   # Replace #WSL1_DISTRO_NAME# with the actual name of your WSL1 distribution (e.g., Ubuntu-18.04-LTS)
   socat UNIX-LISTEN:/tmp/.X11-unix/X0,fork EXEC:"/mnt/c/Windows/System32/wsl.exe -d #WSL1_DISTRO_NAME# socat - TCP\:localhost\:6000" &
                           

2. Configure the DISPLAY variable in your WSL2 environment to utilize this Unix socket:

   export DISPLAY=:0

   (This defaults to using /tmp/.X11-unix/X0. If your socket path differs, adjust accordingly.)

This configuration creates a local X11 socket (/tmp/.X11-unix/X0) inside WSL2. GUI applications connect to this local socket. The primary socat instance in WSL2 captures this traffic and invokes wsl.exe to run another socat command within the specified WSL1 distribution.

The WSL1 socat, benefiting from WSL1’s simpler networking model where localhost can refer to the Windows host, then forwards the X11 traffic to the X server listening on localhost:6000 (Windows host).