Getting ddev to work with xdebug in WSL2 without disabling firewall.

[sboden]

I miss one final part to make my ddev installation work without getting security on my a**, I need some guidance.

I have a Windows 10 laptop. I use WSL2 on which I installed native docker-ce and ddev. I have PhpStorm running on Windows. Everything works except for xdebug when I don't disable the Windows Defender firewall. Are there any instructions on how to poke holes in Windows Defender for my setup?

More information:

I put my xdebug port to 9003. ufw is "Inactive" on the WSL2 (Ubuntu) host.

Extract from "ipconfig /all" on Windows:

Ethernet adapter vEthernet (WSL):

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 172.30.32.1(Preferred)

With Windows Defender fully active, I can't connect from within the ddev container:

ddev ssh
/var/www/html$ telnet host.docker.internal 9003
Trying 172.30.32.1...

When I disable the WSL interface of Defender (either by the "Advanced options" in Windows Defender), or by running following commands in an elevated cmd on windows:

powershell -Command "Set-NetFirewallProfile -Profile Private -DisabledInterfaceAliases 'vEthernet (WSL)'"
powershell -Command "Set-NetFirewallProfile -Profile Public -DisabledInterfaceAliases 'vEthernet (WSL)'"

After this I can do following and xdebug also works with PhpStorm:

telnet host.docker.internal 9003
Trying 172.30.32.1...
Connected to host.docker.internal.
Escape character is '^]'.

The remaining problem is that by disabling the WSL part of the firewall, Windows Security puts the firewall in a "to be looked at" state, which triggers Intune (so I can't access Microsoft Azure anymore until it's resolved) and it also flashes some warning on the company's security board apparantly.

I went through the ddev troubleshooting sections, which says to disable the firewall but no details on exactly what to execute to poke the hole in Windows Defender. I also tried the script at microsoft/WSL#4139 (comment) which doesn't work for my setup for some reason.

What would I need to execute to poke the right hole in Windows Defender firewall without shutting it down completely?

What I already tried and what doesn't work is e.g. from an elevated cmd on Windows:

netsh advfirewall firewall add rule name= "Open Port 9003" dir=in action=allow protocol=TCP localport=9003

and

netsh advfirewall firewall add rule name= "Open Port 1-65500" dir=in action=allow protocol=TCP localport=1-65500

[rfay]

This is a problem for you and your IT department to sort out. A standard Windows machine running WSL2 does not have this problem with Windows Defender. But thank you so much for studying it so carefully and going through the troubleshooting steps! You've done a great job.

[rfay]

I would start by using the Windows Defender Firewall GUI to create an exception for port 9003, but I imagine you already tried that? that would be the very first thing.

[sboden]

Done that... but that doesn't work. I also tried following network firewall rules (from an elevated powershell):

New-NetFirewallRule -DisplayName "Test 9003" -InterfaceAlias "vEthernet (WSL)" -Direction Inbound -Protocol TCP -LocalPort 9003 -Action Allow
New-NetFirewallRule -DisplayName "WSL_Inbound" -Direction Inbound   -InterfaceAlias "vEthernet (WSL)"  -Action Allow

(each one separately)... also no joy. I checked the block rules in place: there's 1 for Skype, but that's it. All the other are Allow.

When I switch off Defender for the WSL part, xdebug works perfectly. I just don't find the right commands to "mess up" Defender to get the same result, but not mess it up so much that Defender will alert security. There's nothing special about the installed Defender, it's the default Windows 10 version (just that some group checks all the warnings the Defenders generate).

When I start ddev with DDEV_DEBUG=true I get this part for the IP address:

2024-02-05T20:55:30.553 host.docker.internal=172.30.32.1 derived from globalconfig.DdevGlobalConfig.XdebugIDELocation
unable to determine WSL2 host.docker.internal because /etc/resolv.conf is not available or not auto-generated

Because I do this upfront:

ddev config global --xdebug-ide-location=172.30.32.1

else host.docker.internal is set to 127.0.0.1 which doesn't work even without firewall.

I'm not the only one with the issue... there's this microsoft/WSL#4139 and microsoft/WSL#4585 and a couple of issue tickets in ddev.

[rfay]

If host.docker.internal is getting set (inside ddev-webserver) to 127.0.0.1, then it's being set by something other than DDEV.

It looks like you have auto-generation of /etc/resolv.conf turned off on your system.

If you look at /etc/resolv.conf in your WSL2 distro, you should see something like this

buildkite-agent@tb-wsldd-05:/etc$ cat resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.20.176.1

It appears that you have turned off auto generation in /etc/wsl.conf? Is that the problem?

You should not be having to do the ddev config global --xdebug-ide-location=172.30.32.1 step, and where did you get the IP address?

Please check your Windows-side hosts file to check to see if it has host.docker.internal in it; it should not. You can normally delete anything in there that is provided by docker desktop.

[sboden]

Going from WSL1 to WSL2 I lost DNS resolution, and that got solved by applying the fix from microsoft/WSL#5420 (comment), except that I run dnsmasq in WSL2. When I revert it and restart wsl I get this in /etc/resolv.conf

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.30.32.1

172.30.32.1 is the IP address from the WSL adapter in ipconfig /all in Windows:

Ethernet adapter vEthernet (WSL):
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 172.30.32.1(Preferred)

I don't run Docker desktop, I run docker-ce native in WSL2. I don't have any host.docker.internal in the windows hosts files.

[rfay]

I recommend strongly that you create a new WSL2 Ubuntu distro from scratch. The fact that you had a history starting with WSL1 causes many things about your system to be suspect.

If I were you I would completely uninstall WSL, then reinstall it from scratch, and create a new distro.

Make backups first of course.

[sboden]

To complete the story. I activate xdebug debugging.

When I disable WSL in Defender I get this:

[3074] Log opened at 2024-02-07 13:16:38.547552
[3074] [Step Debug] INFO: Checking for client discovery headers: 'HTTP_X_FORWARDED_FOR,REMOTE_ADDR'.
[3074] [Step Debug] INFO: Checking header 'HTTP_X_FORWARDED_FOR'.
[3074] [Step Debug] INFO: Checking header 'REMOTE_ADDR'.
[3074] [Step Debug] WARN: Could not discover client host through HTTP headers, connecting to configured address/port: host.docker.internal:9003.
[3074] [Step Debug] INFO: Connected to debugging client: host.docker.internal:9003 (fallback through xdebug.client_host/xdebug.client_port).
[3074] [Step Debug] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/html/vendor/bin/robo" language="PHP" xdebug:language_version="8.1.23" protocol_version="1.0" appid="3074" idekey="PHPStorm"><engine version="3.2.1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2023 by Derick Rethans]]></copyright></init>
[3074] [Step Debug] <- feature_set -i 1 -n show_hidden -v 1

docker.host.internal = 172.30.32.1 ... The IP address of the WSL interface (ipconfig /all under Windows).

When I restore the Defender settings I get this:

[3141] [Step Debug] ERR: Time-out connecting to debugging client, waited: 200 ms. Tried: 192.168.32.5:9003 (from HTTP_X_FORWARDED_FOR HTTP header), host.docker.internal:9003 (fallback through xdebug.client_host/xdebug.client_port).
[3141] [Step Debug] INFO: Checking for client discovery headers: 'HTTP_X_FORWARDED_FOR,REMOTE_ADDR'.
[3141] [Step Debug] INFO: Checking header 'HTTP_X_FORWARDED_FOR'.
[3141] [Step Debug] INFO: Client host discovered through HTTP header, connecting to 192.168.32.5:9003.
[3141] [Step Debug] WARN: Creating socket for '192.168.32.5:9003', poll success, but error: Operation now in progress (29).
[3141] [Step Debug] WARN: Could not connect to client host discovered through HTTP headers, connecting to configured address/port: host.docker.internal:9003.
[3141] [Step Debug] ERR: Time-out connecting to debugging client, waited: 200 ms. Tried: 192.168.32.5:9003 (from HTTP_X_FORWARDED_FOR HTTP header), host.docker.internal:9003 (fallback through xdebug.client_host/xdebug.client_port).
[3141] Log closed at 2024-02-07 13:17:53.416225

No idea what 192.168.32.5 is (it's not my windows address). And the thing triggering the debugging is a behat test running from the CLI inside the ddev webcontainer.

[rfay]

I think 192.168.32.5 is probably xdebug trying all the IPs it can, probably using HTTP headers. it's a relatively new feature in xdebug where it tries various things.

[bmsimo]

I'm going to have to revive this thread, but, i've had the same exact problem @sboden has had. I've had to disable the firewall since there was no other solution. Until i decided to just test it today, and xdebug is working again with the firewall enabled with no issue.

It didn't occur to me before, but i was running Ubuntu 18.04 before and have had some other issues besides the firewall, so I installed the latest version of Ubuntu (24.04) and i'm using ddev 1.23.5.

It works perfectly now.

[rfay]

It sounds like everything is working, yay!