DDEV on WSL/name.ddev.site not working

[sboden]

Maybe someone has a solution for my problem: I can access my ddev project using the 127.0.0.1 address and port, but I can't access it using the ddev.site URL (without port).

I'm running ddev on WSL2 Ubuntu 20.04 using a drupal 8 project, using the ddev version (v1.18.2). In the past it worked properly using both types of URL, after moving to another pc and another corporate network the https://project_name.ddev.site stopped working. I did follow the ddev troubleshooting guide without results. I can reproduce the problem with the small testddev project (phpinfo) from the troubleshooting guide.

I start ddev in WSL2, all is ok. When I ping project_name.ddev.site from a windows cmd it shows me 127.0.0.1 . I didn't put project_name.ddev.site in my windows hosts file; but when I add it, it's the same result. (I can also ping google.com so I have internet connectivity). If I go in my (chrome) browser to https://127.0.0.1:49165 I get my drupal logon screen. When I go to https://project_name.ddev.site I get a "The site can't be reached". When I go to https://project_name.ddev.site:49165 I get the logon screen again.

What I'm actually wondering now is "when the name URL (without specifying port) worked, how did the system find the port number to use?". That's the thing I'm missing now I guess.

Edit ... I checked "docker ps", the ddev-router is running intercepting ports 80 and 443. All the firewalls on my laptop are switched off

Regards,
Sven

[rfay]

So the fundamental things are

• Name lookup. What does junk.ddev.site resolve to on the Windows side and on the WSL2 side? As suggested in the docs and elsewhere, if you don't have name resolution working on both sides, you may have to add your project's hostname to the hosts file on either side.
• Connectivity: It's possible for a firewall or vpn to prevent the web connection from the Windows-side browser from getting to WSL2.
• Something on the windows side may be listening on ports 80/443, and prevent you from getting the correct connection.
• Try using a different port, (router_https_port, etc.)

You'll be happy and sad to know that people use this every day without trouble, so it's almost certainly a networking issue on your computer. Happy because it's solvable, sad because it's something you have to chase.

I recommend starting by debugging on the WSL2 side. Use curl <http://<project>.ddev.site in WSL2. Does it work, show the page?

Then try the same thing on the host. You should be able to connect to the project and see html. Use curl or whatever you have.

Please go through the troubleshooting suggestions carefully and see what you can figure out.

[sboden]

I did some further digging. I'm pretty fond of ddev and I had it running on my old laptop, so I know it works. It stopped working on my new laptop with a different build of Windows 10 and which also connects to another corporate network.

My drupal site worked, only the ddev-router failed to route from 127.0.0.1:443 to the correct port my drupal site was running on. Where I got sidetracked is that ddev-router started without complaining and was in "healthy state". What I now found is that the Windows " IP helper" service was listening on TCP 0.0.0.0:443 which I thought would do the proxying from Windows to WSL. But after stopping that service and a ddev powerdown/start combination, ddev-router works again normally.

When afterwards I do a:

netsh interface portproxy show all

in a cmd on the windows side, I also see the ports 80/443 on the windows side connecting to the wsl side (while I thought that was actually the job of the IP Helper service).

Thanks,
Sven

[rfay]

I'm not sure whether you're saying that you got some progress or not, but it sounds like you're understanding the nature of the problem.

One easy technique you can use that will solve loads of problems is to run your browser inside WSL2. On Win11, this is built in, on Win10 you may need an X11 helper like X411.

[sboden]

I got it solved, thanks. The problem was that the Windows IP Helper service was listening on TCP 0.0.0.0:443, which somehow caused the (Chrome) browser on Windows side not being able to "talk" to ddev-router, although the ddev-router itself came up normally and was in a "healthy state". Stopping the IP Helper service made everything work normal again (after a ddev powerdown/start).