yCodeTech / valet-windows

Laravel Valet for Windows.
https://packagist.org/packages/ycodetech/valet-windows
MIT License
27 stars 4 forks source link

Bug: Acrylic DNS and WSL2 Port Conflict Issues #14

Open jerrens opened 3 days ago

jerrens commented 3 days ago

Description

After installing valet-windows, everything appeared to be working great until I rebooted. After the reboot, WSL2 would not launch, which also impacted Docker (uses WSL under the hood in Win 10) and a few other things.

When starting a new instance of WSL (Ubuntu), the following message would appear in the terminal:

Failed to configure network (networkingMode Nat). To disable networking, set wsl2.networkingMode=None in C:\Users\jerre.wslconfig Error code: Wsl/Service/CreateInstance/CreateVm/ConfigureNetworking/HNS/0xffffffff

After some investigation, it turns out that Acrylic DNS Proxy service was using port 53 (default) which is needed by WSL2 in Windows and since the service was automatically starting, it was able to bind to port 53 first and then block whatever service (svchost.exe >> netsvcs -p) was needed by WSL2.

Following instructions from https://github.com/microsoft/WSL/issues/4364#issuecomment-766760961, I was able to modify %AppData%\Composer\vendor\ycodetech\valet-windows\bin\acrylic\AcrylicConfiguration.ini and changed LocalIPv4BindingPort=54 (was =53). After running valet restart acrylic, the commands

Get-NetUDPEndpoint | Where {$_.LocalPort -eq "53"} | select LocalAddress,LocalPort,@{Name="Process";Expression={(Get-Process -Id $_.OwningProcess).ProcessName}}

Get-NetUDPEndpoint | Where {$_.LocalPort -eq "54"} | select LocalAddress,LocalPort,@{Name="Process";Expression={(Get-Process -Id $_.OwningProcess).ProcessName}}

showed the expected output:

PS C:\> Get-NetUDPEndpoint | Where {$_.LocalPort -eq "53"} | select LocalAddress,LocalPort,@{Name="Process";Expression={(Get-Process -Id $_.OwningProcess).ProcessName}}

LocalAddress LocalPort Process
------------ --------- -------
::                  53 AcrylicService
0.0.0.0             53 svchost

PS C:\> Get-NetUDPEndpoint | Where {$_.LocalPort -eq "54"} | select LocalAddress,LocalPort,@{Name="Process";Expression={(Get-Process -Id $_.OwningProcess).ProcessName}}

LocalAddress LocalPort Process
------------ --------- -------
0.0.0.0             54 AcrylicService

Some alternative suggestions that I didn't try were:

  1. Set the Acrylic DNS service to be Automatic (delayed) start. In theory, this would give time for the other service that used port 53 to start first, then Acrylic to attempt later (and be denied). This felt like an ugly work-around and having the potential of not always working as expected (ie. race condition).

  2. Set LocalIPv4BindingAddress=127.0.0.1 (instead of =0.0.0.0)

Since the Acrylic configuration change was made in the *.ini managed by valet-windows, what impact would there be for other users to make the above changes part of this package?

Steps To Reproduce

See Description

Diagnosis

N/A

jerrens commented 3 days ago

I have now tried the alternative and updated AcrylicConfiguration.ini with:

LocalIPv4BindingPort=53
LocalIPv4BindingAddress=127.0.0.1

And this also works.

For me, this is the preferred approach since I only want local request to be impacted and not request from other devices on my network (if I were to lower my firewall).

yCodeTech commented 3 days ago

@jerrens I have no idea about WSL2 or docker, as this is specific to Windows and not Linux on Windows. That's great if you've managed to figure it out.

If you would like to create a pull request with the relevant changes, and I can review the code. However, I can not test such solutions with my system not setup for WSL2. So if your tests are successful and it doesn't impact the functionality on standard Windows, then I will be more than happy to merge the PR and publish a patched version.

jerrens commented 2 days ago

@yCodeTech Let me experiment with it for a few days to make sure my recommended change doesn't have any side effects.

Also, if any others have run into this problem, and can confirm this fix works for them, that affirmation would be nice.