Win-Kex in WSL2 Kali fails to connect after system reboot.

[snowmirage]

I've followed the guide posted here https://www.kali.org/docs/wsl/win-kex/

Right after the install I can run Kali in WSL2 and running "kex" launches as expected.

However once I reboot the host Windows 10 PC it fails with the following error.

 CConn:       unable to connect to socket: No connection could be made because
              the target machine actively refused it. (10061)

I completely removed Kali, reinstalled it from the windows store, went through the steps in that guide and again it worked, until a reboot then I see the same error.

I don't fully understand how this works, but I thought it must be the windows firewall or something.

I disabled all the windows firewalls, for private, public, and domain networks. No change.

Then I started trying to find the traffic for that VNC connection. Kali had 2 network interfaces lo, and an ethernet interface. Running a tcpdump on either of them did not show the VNC traffic.

Then I tried a wireshark capture in Windows 10 and found the VNC traffic on the loopback interface in windows.

After a fresh install Win-Kex works and I see the connection in the capture (image below)

pcap working.jpg

After a reboot I can see the TCP SYN responded to with an immediate RST as if the port isn't open / the firewall is blocking this. (image below)

pcap fail.jpg


Are there hidden settings for the windows firewall for the loop back interface or something? In my hours of google searching I couldn't find anything to indicate that could be the issue.

I'm hoping someone might have some suggestions here I would greatly appreciate it.

[spitfire400]

Hey there @snowmirage ! Sorry you had to wait so long for a response on this thread, I haven't been around much lately on the linux side of things. I did however recently setup kali GUI with kex in wsl 2. Before you reboot the machine the next time, I would suggest using the kali bash terminal/window or zsh terminal if you have swapped to this already. Run the command "kex stop". This kills the process down before you log off/reboot windows. So that the next time you launch kali again, typing "kex" will re-start the environment you already closed down previously with the stop command.

Hope this helps with your post here,

Spitfire

[spitfire400]

I would try running command ?key stop? without the quotes in future to close down the VM before logging out/rebooting the machine

[ndroid]

You need to kill the current vnc display before attempting to connect again
You can either
1- Target the vnc display you want to kill using the following command:
kill kex
stop kex

or
2- choose what display you want to kill like so:
vncserver -kill :<display number>
for example: vncserver -kill :3

both worked for me resolving that issue

[Sibyllin]

I am having the exact same issue, couldnt find a work around either. Had to go back to using VMware for now

[crouzilles]

Before you restart your windows machine, how do you exit from kali? and how do you stop kex?

I am new to this also but what I do is press F8 -> Exit viewer, then in the kali prompt I press F8 again then Enter, then I type "kex stop", then exit

Once I have done that I restart windows, and I can start kali again as well as kex

I hope this helps

Regards

[snowmirage]

Thanks for all the advise.

I should have posted back sooner, replied to another post I made on another forum but not this one.

What seems to have fixed it for me as suggested is "kex stop" in the WSL2 terminal.

What blows my mind is why that fixed it.


I 100% powered down the laptop and removed its battery (for another reason) several times and still had the issue. But "kex stop" did indeed appear to shut down the process then when running kex again starts it fresh.

But how could powering off the host not have killed that process there's no power it can't be running. This leads me to believe that windows is doing some "magic" in the background to either suspend the host OS (windows) to disk and or at least WSL2 even though I shutdown the host.

I suppose this could make some sense now that I'm thinking with a clearer head.

If I was running say a VM in VMware player and just shutdown the host the default behavior might be to suspend the VM save its state to disk then resume it next time I powered up the host. But nothing about running WSL2 gave me as a user any indication there was a suspend + resume type of action going on. I am new to WSL in general so this could very well be my own incompetence.

Anyway I hope others hitting the same brick wall find this thread and it helps

[juliom]

If you already can?t start kex, you will need to kill one more time by:
vncserver -kill :1
then run kex again and press F8 and go to advanced conf and check the allow more concurrent sessions.

I've followed the guide posted here https://www.kali.org/docs/wsl/win-kex/

Right after the install I can run Kali in WSL2 and running "kex" launches as expected.

However once I reboot the host Windows 10 PC it fails with the following error.

 CConn:       unable to connect to socket: No connection could be made because
              the target machine actively refused it. (10061)

I completely removed Kali, reinstalled it from the windows store, went through the steps in that guide and again it worked, until a reboot then I see the same error.

I don't fully understand how this works, but I thought it must be the windows firewall or something.

I disabled all the windows firewalls, for private, public, and domain networks. No change.

Then I started trying to find the traffic for that VNC connection. Kali had 2 network interfaces lo, and an ethernet interface. Running a tcpdump on either of them did not show the VNC traffic.

Then I tried a wireshark capture in Windows 10 and found the VNC traffic on the loopback interface in windows.

After a fresh install Win-Kex works and I see the connection in the capture (image below)

pcap working.jpg

After a reboot I can see the TCP SYN responded to with an immediate RST as if the port isn't open / the firewall is blocking this. (image below)

pcap fail.jpg


Are there hidden settings for the windows firewall for the loop back interface or something? In my hours of google searching I couldn't find anything to indicate that could be the issue.

I'm hoping someone might have some suggestions here I would greatly appreciate it.

[Tornado]

I have typed kex stop and kex kill several times but it still won't let me connect. It continues to reply with:


Use of uninitialized value in pattern match (m//) at /usr/bin/vncserver line 490.
vncserver: Can't parse pid file '/home/tornado/.vnc/MilkyWay.localdomain:1.pid'!


Error connecting to the KeX server.Please try "kex start" to start the service.
If the server fails to start, please try "kex kill" or restart your WSL2 session and try again.


I then get a window from TigerVNC Viewer that says:

unable connect to socket: Connection refused (10061)


I have tried restarting my PC, looking through task manager, and trying to open the .pid but I can't find a way to fix it.

[D6ddy60ddy]

There is an alternative solution.

If you want, you still can use the ESM mode (https://www.kali.org/docs/wsl/win-kex-esm/), what is using native windows clients and protocols, and still can work, if the tigervnc failed. You can use the

kex --esm

command. (Tested on win10 Pro (18363) with Win-Kex 2.7, Kali Linux (2021.1) and WSL2)