The most common reason traceroute succeeds while ping fails in WSL2 is that the Windows Defender Firewall or host network security policies block ICMP Echo Request packets, which are required for ping, while allowing the UDP or ICMP probes used by traceroute. This discrepancy occurs because WSL2 runs in a lightweight utility VM with its own NAT interface, and the host firewall often treats inbound traffic from this virtual network differently than standard loopback or physical adapter traffic.
Understanding the Network Architecture
To troubleshoot this effectively, you must understand how WSL2 handles networking. Unlike previous versions of WSL, WSL2 runs a real Linux kernel inside a Hyper-V virtual machine. This VM is isolated behind a NAT (Network Address Translation) layer on the host machine. When you run
ping from within the WSL2 Ubuntu environment to an external IP address, the packet travels through the virtual switch, out to the internet, and back. However, when you attempt to ping the WSL2 instance from the Windows host, or when the WSL2 instance attempts to receive ICMP responses, the Windows Firewall acts as a gatekeeper.
Traceroute works because it typically uses high-numbered UDP ports or specific ICMP types that might not be blocked by default restrictive rules, or because the dynamic port allocation allows the return path to establish. Ping relies strictly on ICMP Type 8 (Echo Request) and Type 0 (Echo Reply). If the firewall drops these specific packets, the connection appears dead to ping but alive to other diagnostic tools.
Checking Windows Firewall Rules
The primary suspect is almost always the Windows Defender Firewall. By default, Windows may block incoming ICMP requests for privacy reasons, especially if the network profile is set to "Public." You need to verify if the firewall is actively dropping these packets.
Open PowerShell as Administrator and run the following command to list all firewall rules related to ICMP:
Get-NetFirewallRule -Name *ICMP* | Select-Object DisplayName, Enabled, Direction, Action
Look for rules that allow inbound ICMPv4 or ICMPv6. Specifically, ensure that there is an enabled rule allowing inbound traffic for protocol type ICMPv4. If no such rule exists, or if it is disabled, you will need to create one. Do not rely on generic "WinRM" rules, as those manage remote management connections and do not affect basic network diagnostics like ping.
If you need to enable ICMP manually, use this command to create an inbound rule for IPv4:
New-NetFirewallRule -DisplayName "Allow ICMPv4 Echo Request" -Protocol ICMPv4 -IcmpType 8 -Enabled True -Profile Any -Action Allow
Note that ICMP Type 8 corresponds to Echo Request. A common error is using Type 129, which is for IPv6 Echo Request. Ensure you are targeting the correct protocol version. If your WSL2 instance is communicating over IPv6, you should also create a corresponding rule for ICMPv6 with Type 128.
Verifying WSL2 Network Interface
Sometimes the issue is not the firewall but the network configuration within WSL2 itself. Check the IP address assigned to your WSL2 instance by running
ip addr show in the Linux terminal. Identify the interface named
eth0 and note its IP address.
Next, try pinging this IP address directly from the Windows Command Prompt or PowerShell. If this fails, the problem is definitely between the Windows host and the WSL2 VM. If it succeeds, the problem lies in outbound connectivity or DNS resolution within WSL2.
You can also check if the WSL2 firewall (iptables) is blocking traffic. Run the following command inside WSL2:
sudo iptables -L -n -v
Look for any DROP or REJECT rules in the INPUT chain that might be filtering ICMP. In a standard installation, this table should be empty or only contain ACCEPT rules for established connections. If you see aggressive filtering, reset it using:
sudo iptables -F
Be cautious, as this clears all rules. It is usually safer to just ensure no explicit DROP rules exist for ICMP.
DNS and Resolution Issues
While DNS issues typically cause timeouts rather than immediate failures, they can sometimes manifest as ping failures if the system cannot resolve the hostname to an IP address that is reachable. Use
nslookup or
dig inside WSL2 to verify that domain names resolve correctly.
If DNS works but ping still fails, compare the behavior with
traceroute. Traceroute provides hop-by-hop information, showing where the packet stops. If traceroute shows the first hop (your local router) but then times out, the issue is likely upstream or with intermediate firewalls. If it reaches the destination IP but reports no response, the target host is blocking ICMP.
For more details on interacting with WSL2 networking, see
How to Ping WSL2 Ubuntu from Windows Host. This resource covers additional scenarios where host-to-guest communication is restricted by network isolation policies.
Advanced Troubleshooting Steps
If the above steps do not resolve the issue, consider checking the Hyper-V Virtual Switch settings. The WSL2 instance uses a private virtual switch managed by the
vEthernet (WSL) adapter. Ensure that this adapter is not disabled or misconfigured in the Network Connections panel of Windows.
Additionally, some third-party antivirus software installs its own firewall drivers that sit below the Windows Networking stack. These can intercept and drop ICMP packets regardless of Windows Firewall settings. Temporarily disabling such software can help isolate the cause.
Finally, ensure that your WSL2 version is up to date. Older versions had bugs regarding network stack initialization. Update WSL by running:
wsl --update
Then restart the WSL instance completely using:
wsl --shutdown
This ensures that the network interfaces are re-initialized cleanly. For insights into how WSL2 differs from other Linux distributions in Windows environments, refer to
Difference between Windows WSL, which highlights architectural nuances that can affect network behavior.
Frequently Asked Questions
Why does traceroute work but ping fails?
Traceroute often uses UDP packets on high ports or ICMP Time Exceeded messages, which may be allowed by firewalls that strictly block ICMP Echo Requests. Ping relies solely on ICMP Echo Request/Reply, which are frequently blocked by default security policies for privacy reasons.
How do I allow ping from Windows to WSL2?
You must create an inbound firewall rule on the Windows host that allows ICMPv4 Echo Requests. Run the PowerShell command
New-NetFirewallRule -DisplayName "Allow Ping" -Protocol ICMPv4 -IcmpType 8 -Action Allow to enable this traffic explicitly.
Can I disable ICMP blocking in WSL2?
WSL2 does not have a built-in toggle to disable ICMP blocking; it inherits the network policy from the host. You must configure the Windows Firewall or any third-party security software to permit ICMP traffic between the host and the WSL2 virtual network adapter.
Is this issue specific to Ubuntu in WSL2?
No, this is a general WSL2 networking characteristic affecting all Linux distributions running in the subsystem. The underlying issue is the interaction between the Hyper-V virtual switch and the Windows host firewall, not the specific Linux distro installed.
What if my firewall rules are correct but ping still fails?
Check for interference from third-party antivirus firewalls, verify that the
vEthernet (WSL) adapter is active, and ensure that the WSL2 network stack is healthy by restarting the service with
wsl --shutdown. Also, verify that you are pinging the correct IP address assigned to eth0.