1

Summary:

I have my firewall blocking the WSL server (Ubuntu 18.04) only when running on Visual Studio Code. It is also preventing my Hyper-V VM (Ubuntu 19.04) to establish almost every connection to internet, for example sudo apt update or browsing (for some reason I can ping successfully though but I would't focus on this as of now).

Details:

After many trail and error efforts I have isolated and concluded that my firewall (Avast Premier) is the only culprit for this. Disabling the firewall for 10 mins allows me to do these two different operations, connect to WSL server from Visual Studio Code and also to navigate and update packages in my virtualized Ubuntu from Hyper-V.

What I have done so far:

I have checked that VSCode has all connections allowed in all ports (inbound and outbound):

enter image description here

Allowing rules seem to be in place:

enter image description here

And also added VSCode to the antivirus exceptions list:

enter image description here

None of the actions above worked, only disabling the firewall.

Question:

What rules should I add to the firewall for allowing:

  1. WSL server (Ubuntu 18.04.2) from VSCode
  2. Internet connection on Ubuntu 19.04 from Hyper-V.

Notes: WSL works perfectly outside VSCode. I can even start a batch terminal from it (the connection from the left of status bar is what is the issue).


UPDATE:

This is the output I get from WSL terminal in VSCode:

Failed to connect to the remote extension host server (Error: connect ETIMEDOUT 127.0.0.1:62388)

Failed to connect to the remote extension host server (Error: connect ETIMEDOUT 127.0.0.1:62388)

  • What is the Windows 10 version? Are you using WSL2 in insider build? – Biswapriyo Sep 2 '19 at 4:26
  • @Biswapriyo It's Windows 10 Pro build 18362, using WSL 1 (not insiders editions) – kerzek Sep 2 '19 at 19:14
  • Have you tried allowing WSL itself? You might also contact Avast since it’s their software that isn’t working as you have configured it. – Ramhound Sep 2 '19 at 19:21
  • @Ramhound I will try adding wsl.exe to the exceptions list and post it here – kerzek Sep 2 '19 at 19:37
  • No luck, same result after adding C:\Windows\System32\wsl.exe to the exceptions list – kerzek Sep 2 '19 at 19:43
1
+50

The Avast Forums post Support WSL pico processes has this useful text:

Avast. much like Windows Defender currently requires the entire Linux distribution to be exempted in order to run pico processes. This is an unacceptable risk to security in any corporate environment. What Avast needs to do is treat Pico processes the same way as Windows processes. Microsoft will soon be releasing an update to Windows Defender in "Skip-Ahead Insiders" builds that manage rules at per process/port level. Avast should implement a similar setup. There is a blog from 2016 Microsoft has provided to assist third-party vendors such as Avast to integrate with WSL. Here's the blog: https://blogs.msdn.microsoft.com/wsl/2016/11/01/wsl-antivirus-and-firewall-compatibility/

The Microsoft article Pico Process Overview further explains the concept:

This post discusses pico processes, the foundation of WSL. It explains how pico processes work in Windows and goes into the history of how they came to be, the abstractions we decided to implement and the various use cases beyond WSL that emerged.

As far as I could find, the Ubuntu release in Windows resides in the following folders:

  • C:\Program Files\WindowsApps\CanonicalGroupLimited.UbuntuonWindows_1804.2019.521.0_x64__79rhkp1fndgsc
  • C:\Users\USERNAME\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc
  • C:\Windows\System32\lxss

If the Avast Forums post is correct, these are the folders that are need to be exempt in Avast in order to allow the execution of Ubuntu.

As far as Avast settings are concerned, it has been advised to enable the following:

  • Internet Connection Sharing mode
  • Allow all connections with Friends when in Private mode
  • Enable automatic profile switching
  • Enable automatic port scan detection

A reboot is required after enabling these settings.

These are all only workarounds, until Avast releases an update to support WSL. If the above workarounds don't work for you, you need to disable the Avast firewall while using WSL, or suspend Avast until they fix the problem. Until then, Windows Defender is good enough for most purposes.

  • I've added the entire WSL folder to the exceptions along with the advanced settings (note, type geek:area in the settings search bar to access). Also the lxss folder. Restarted and the same, sorry for the bad news. It's frustrating, I might have to change for other firewall solution. I would't want to disable the entire firewall altogether while working on WSL. – kerzek Sep 4 '19 at 2:13
  • In most posts I have seen people have opted for just this: Disabling the Avast firewall while using WSL. You may open a support ticket with Avast, since the problem is on their side. As a remark: Windows Defender has much advanced the last years and is good enough and is free. It is also guaranteed to work correctly for all new evolutions of Windows, so is just a matter of set-it and forget-it. – harrymc Sep 4 '19 at 6:24
  • I´m going to opt for Windows Defender, for my everyday work it does its job. In the meantime let's see what Avast says. – kerzek Sep 4 '19 at 21:41
  • I have moved that part from a comment to the answer. You might consider accepting my answer as you have accepted my advice. – harrymc Sep 6 '19 at 7:35
  • It's not a problem related to the antivirus, exclusion folders list does not affect firewall. In my case all was solved when I added the rule to allow inbound/outbound TCP/UDP traffic for the WSL node executable, in my case in "C:\Users\giuse\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\rootfs\home\developer\.vscode-server\bin\b37e54c98e1a74ba89e03073e5a3761284e3ffb0\node". Check the answer of @Biswapriyo for more details. – Neurone Sep 28 '19 at 21:16
2

Requirements:

  • A GNU/Linux distribution installed in WSL with proper toolchain for development language. For example build-essential in Debian based distributions for C/C++ language.
  • Latest Visual Studio Code with Remote - WSL extension installed.
  • Internet connection because the Remote WSL extension downloads a backend NodeJS server in previously mentioned WSL distribution.

Procedure:

  • Get the Visual Studio Code executable full path and allow it in firewall. Typically this will be:
%LOCALAPPDATA%\Programs\Microsoft VS Code\Code.exe
  • Allow the /usr/lib/apt/methods/http executable in firewall to use apt to download packages. For Ubuntu 18.04 the path is:

  • Run VScode, install Remote - WSL extension. Start VSCode from WSL in Command Prompt. It will ask to connect with running distribution and install the backend silently.

%LOCALAPPDATA%\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\rootfs\usr\lib\apt\methods\http
  • Allow the node executable in firewall to connect between frontend and backend of Remote - WSL extension. In WSL, go to user home folder ~/.vscode-server-insiders/bin and get the next folder name (very big cryptic number like, actually it's commit hash). The full Windows style path will be as previous:
%LOCALAPPDATA%\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\rootfs\home\test\.vscode-server-insiders\bin\0f73473c08055054f317c1c94502f7f39fdbb164\node

Now restart VSCode and it may work. The full folder path will be different for different GNU/Linux distribution name. Do not mix the slashes in full path. See this Q&A to know how to get that path.

Further reading:

  • I have found and added the paths mentioned to the exceptions list, but the issue persists. I also added the extention's path C:\Users\myUser\.vscode\extensions\ms-vscode-remote.remote-wsl-0.39.2\*. Thanks for your comments. – kerzek Sep 3 '19 at 1:12
  • @kerzek Add the rule for both inbound and outbound in Windows Firewall and Avast both. – Biswapriyo Sep 3 '19 at 17:32
  • I solved all the problem allowing TCP/UDP inboud/outbound for the node executable, in my case "C:\Users\giuse\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\rootfs\home\developer\.vscode-server\bin\b37e54c98e1a74ba89e03073e5a3761284e3ffb0\node" – Neurone Sep 28 '19 at 21:13
  • See here for an example working configuration: imgur.com/a/FchzRTu – Neurone Oct 1 '19 at 22:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.