WSL is blocked by FW without any log record

I have installed WSL (Windows subsystem for Linux) and I am trying to ping from linux but I am blocked by the FW. When I disable the FW - it’s ok.
I don’t see any event for it in the log, and I don’t know how to unblock it.

Please help.


Need more info as it should work, what Windows version and CIS version are you using? And which version of WSL did you use 1 or the newer version 2?

I have windows 10, version 2004 , with WSL 2.
Comodo firewall

Meantime I have found that ping doesn’t work, but all the applications that connect to the internet- work.



So I recently installed win10 2004 update (more specifically buil 19041.421) which allowed me to install wsl2 and over that a Kali image.

“Out of the box” the linux subsystem had no network connectivity at all, which I after I while traced back to comodo itself.

My Comodo product version is 12.0.6818.

So basically if I just run ping from the linux side, it doesn’t work at all, I’m just getting a connection refused, and comodo stays quite even though I have all on verbose.

If I then set the firewall to training mode, everything works just fine.

If I leave the ping running when it works in training mode, and then set it back to safe mode or the custom ruleset, the ping keeps working, so “Established” under the same PID seems to work.

But as soon as I kill the ping and start it again, it won’t work. So training mode doesn’t add any rules it seems.

Under firewall events I don’t see anything useful and indeed no notifications.

I tried to set the executables for the main kali process and child processes but that doesn’t change anything.

So my question is now how can I make a custom rule to allow the connections and why on earth is Comodo not giving me any notifications?

For me curl or apt won’t work either. No notifications at all.

I merged your topic with this existing one of the same issue. Try adding Windows Operating System to the firewall application rules and set it to outgoing ruleset. To add WOS you need use the running process option and add it from the running process window. Also make sure windows firewall is off for all 3 profiles but leave the windows firewall service running.



Windows firewall is off but the service is running.

I already had “Windows Operating System” entry under the application rules with allow all outgoing. Applied outgoing only to that rule now.

In the fw events log I see also quite some entries with empty application, action Asked, which never happened, direction out or 0, source and destination IPs at

No clue if those are related but definitely not properly detected by Comodo.

So yeah, still no dice.

Any other ideas regarding this? I like the comodo due to its verbosity but this is definitely an issue at the moment if no notifications are coming through but the traffic is still blocked.

Is there no debug mode for the firewall or some other way to get really low level logs?

All I know is that WSLv1 works without issues, using WSLv2 only works up to version as newer CIS builds prevents the creation of the hyper-v virtual network adapter. That issue is supposedly going to be fixed in the next release, as for this issue I think a configuration conflict is causing the blockage. Maybe try using one of the default configs that hasn’t been modified yet.

I did try with safe mode too, that then uses a built-in ruleset or am I mistaken?

No switch to one of the default configurations that you have not made changes to, i.e. switch to either the proactive, firewall, or internet security config. Just switch to a different config that is not currently set as the active configuration. Otherwise just wait for the next release to see if it fixes the issue.

Wouldn’t have a clue how would I change it :smiley: I could only select from custom ruleset or safe mode for the firewall, don’t know where to change what you described. But since then comodo started behanving badly with not showing popups at all so I just disabled the comodo firewall and went with tinywall, now everything works nicely, including wsl2.

Btw even with the firewall set on disabled, I see this in the logs (see attachement).

And needless to say, nothing was “asked” like the log claims.

Just managed to overcome connectivity issues on my Windows 10 Ubuntu (WSL 2).

Altering the following setting:
Comodo → Advanced Settings → Firewall → Global Rules → Block IP in Any To MAC Any Where Protocol is Any
by excluding the vEthernet (WSL) from this rule (please see attached screenshot),
allowed sudo apt update to execute successfully.

Thought to share it in case it helps :slight_smile:

Thank you for this idea, but you have to exclude the mac address of the vEthernet (WSL) from the destination not from the source for your workaround to work.