To unblock a specific IP address for WSL 2 in Windows Defender Firewall, you must create an inbound rule that allows traffic from the WSL 2 virtual network adapter. This is achieved by identifying the unique IPv4 address assigned to the vEthernet (WSL) adapter and configuring a firewall rule that permits connections from that specific source address.
Understanding the WSL 2 Network Architecture
WSL 2 operates on a Hyper-V virtual switch, which creates a virtual network interface on the host machine. Unlike WSL 1, which shared the host's networking stack, WSL 2 has its own private IP address. This isolation means that standard outbound rules often work, but inbound connections from the host or other local devices require explicit configuration. The virtual adapter is typically named vEthernet (WSL). When you attempt to connect to a service running inside WSL 2 from a proxy application or another tool on Windows, the Windows Firewall blocks the incoming traffic by default because it does not recognize the WSL 2 IP as a trusted source.
Identifying the WSL 2 IP Address
The first step is to determine the current IP address assigned to your WSL 2 instance. This address can change upon restart unless configured statically. To find it, open PowerShell or Command Prompt and run the following command:
ipconfig | findstr /i "vEthernet"Look for the entry labeled vEthernet (WSL). Note the IPv4 Address listed next to it. Alternatively, you can check the IP directly from within the WSL 2 distribution by opening Ubuntu and running hostname -I. However, for firewall rules, you need the address visible on the Windows host side.
Creating the Firewall Rule via PowerShell
Using PowerShell provides the most reliable method for creating precise firewall rules. You will use the New-NetFirewallRule cmdlet. Before executing the command, ensure you are running PowerShell as an Administrator. Replace <WSL_IP> with the actual IP address identified in the previous step.
New-NetFirewallRule -DisplayName "Allow WSL 2 Inbound" -Direction Inbound -LocalPort Any -Protocol TCP -RemoteAddress "<WSL_IP>" -Action AllowThis command creates a new rule named "Allow WSL 2 Inbound". It specifies that the rule applies to inbound traffic, accepts any local port, uses the TCP protocol, targets the specific remote address of the WSL 2 instance, and sets the action to allow. If you need to allow UDP traffic as well, you should run a similar command with -Protocol UDP.
Verifying the Rule Configuration
After creating the rule, verify that it exists and is enabled. You can list all firewall rules containing "WSL" using the following command:
Get-NetFirewallRule -DisplayName "*WSL*" | Format-List DisplayName, Enabled, Direction, Action, RemoteAddressEnsure that the Enabled property is set to True. If the rule is disabled, you can enable it using Enable-NetFirewallRule. Additionally, check the firewall logs if you suspect the rule is being overridden. Enable logging in Windows Defender Firewall advanced settings under the Advanced Security tab, specifically for dropped packets, to confirm whether traffic from the WSL IP is still being blocked.
Troubleshooting Common Issues
If connections still fail after applying the rule, consider the following factors. First, ensure that the service inside WSL 2 is actually listening on the correct interface. Sometimes services bind only to 127.0.0.1, which prevents external access even if the firewall is open. Bind the service to 0.0.0.0 or the specific WSL IP address. Second, check for conflicting rules. A previously created rule with higher priority might be blocking the traffic. Use Get-NetFirewallRule to inspect rule priorities. Finally, remember that network changes in WSL 2 can sometimes reset the adapter state. If the IP address changes, you must update the firewall rule's RemoteAddress parameter accordingly.
Managing Permissions and Policy Overrides
In enterprise environments, Group Policy Objects (GPOs) may restrict the ability to modify firewall rules. If you encounter permission errors when running PowerShell commands, you may need to manage Windows Firewall with Local Admin Permissions. Refer to guides on Managing Windows Firewall with Local Admin Permissions to resolve policy conflicts. Without appropriate administrative rights, the New-NetFirewallRule command will fail silently or throw an access denied exception.
Alternative Approaches for Proxy Usage
If you are trying to use a proxy app from the command line within WSL 2, you might not need to unblock inbound traffic at all. Instead, configure the proxy to listen on localhost and forward requests. However, if you require direct access to the WSL 2 IP from the host, the firewall rule described above is the standard solution. For issues related to IP conflicts that might interfere with this setup, see Preventing Windows 10 IP Address Conflict: 0.0.0.0 to ensure your network stack remains stable.
Frequently Asked Questions
Does the WSL 2 IP address change after a reboot?
Yes, by default, the WSL 2 instance receives a new dynamic IP address each time it starts. You must update the firewall rule's remote address manually or configure a static IP within the WSL 2 distribution to maintain consistent access without modifying firewall rules repeatedly.
Can I allow all ports for the WSL 2 IP instead of specifying them?
Yes, using -LocalPort Any in the PowerShell command allows all inbound ports. However, this reduces security by exposing all services on the WSL 2 instance to the host network. It is safer to specify only the necessary ports if you know which services require external access.
Why is my WSL 2 IP showing as 172.x.x.x?
This is normal behavior. WSL 2 uses a private virtual network range, typically starting with 172.16.0.0 or 172.17.0.0. These addresses are not routable on your physical LAN but are fully accessible within the Windows host environment through the virtual adapter.
How do I remove the firewall rule if it causes issues?
You can delete the rule using PowerShell by running Remove-NetFirewallRule -DisplayName "Allow WSL 2 Inbound". Ensure the display name matches exactly what was used during creation. This reverts the firewall state to its default blocking behavior for that specific IP.
Do I need to restart Windows after adding the rule?
No, restarting Windows is not required. The firewall rule takes effect immediately upon creation. You can test connectivity right away using tools like Test-NetConnection in PowerShell or by attempting to connect from your proxy application.