Which exceptions should I add for WSL and Hyper-V in Avast Firewall?

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)


Solution 1:

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.

Solution 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:

  • VScode: Developing in WSL
  • VScode: Remote development FAQ
  • Where is the Linux Subsystem's filesystem located in Windows 10?
  • Accessing Ubuntu data (like "/etc") from Windows