Bug: Acrylic DNS and WSL2 Port Conflict Issues
Closed this issue · 5 comments
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 microsoft/WSL#4364 (comment), 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:
-
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). -
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
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).
@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.
@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.
This change has been working well for me and after reading more of the thread at microsoft/WSL#4364 (comment), this appears to be a recommended solution.
A PR has been submitted.