It appears it will be ready soon.
I hope this is ready soon, my current solution is to disable my GW firewall completely when performing requests in the Linux subsystem.
Howtogeek reports this update is coming October 2nd!
“Firewall for Linux Processes : The [Windows Defender Firewall] can now define firewall rules for any Windows Subsystem for Linux (WSL) process, just as you can for Windows processes. For example, if you launch an SSH server or web server, you’ll see a firewall prompt asking if you want to open a port for outside connections—just as if you launched the same server on Windows.”
Nice post. Thanks for sharing good information.
1 Like
Came here after being unable to do anything in Ubuntu WSL because of Glasswire…
I’m eagerly waiting for this update…
Looking good Ken, WSL interacts properly with GlassWire now.
You might need to change the pop-up so we can read it a little easier, but that’s a much smaller concern
1 Like
I can confirm that it is working. Finally I was able to remove my proxy (and the million settings inside of Linux to make everything work with it). 
1 Like
Sad to say this is not working for me. Fresh installation, with a clean config of 2.1.140. Glasswire is in “Ask to Connect” mode
When I fire up a WSL and issue a wget command, I see the expected message that dns failed to resolve the host address.
PICO pops up a second or so later asking for permission to access my router.
I grant it and issue the wget command again.
Wget still fails - unable to resolve the host address.
The only way I can get this to actually do anything is to switch glasswire off, at which point the wget command can resolve the host name and starts doing what I require.
What step am I missing here?
Thanks for your report. We will try to reproduce this on our end, and meanwhile if anyone else uses the Linux subsystem and can give feedback we’d appreciate knowing if they experience this also.
I don’t have those issues, and I’m not sure I did anything specific to allow proper name resolution in WSL.
Do you use a VPN? What does /etc/resolv.conf in WSL contain?
No problem here either, Glasswire works as expected with WSL components.
Windows 10 Pro: Version 10.0.17763 Build 17763
Glasswire: 2.1.137 (will upgrade later - whatever happend to self-upgrade?)
1 Like
No VPN at all - straight install of Windows followed by WSL - nothing out of the ordinary - literally a next, next, next, finish type of install.
resolver configuration is
# This file was automatically generated by WSL. To stop automatic generation of this file, remove this line.
nameserver 192.168.1.254
nameserver fec0:0:0:ffff::1
nameserver fec0:0:0:ffff::2
search home
192.168.1.254 is my router and it is this IP address which PICO askes for permission to connect to, and I permit it.
After posting this, I thought I’d do a little more playing about.
Glasswire on, fresh boot,
Open up WinBash and this is what I get:
➜ ~ nslookup www.google.com
../../../../lib/isc/unix/socket.c:2104: internal_send: 192.168.1.254#53: Invalid argument
../../../../lib/isc/unix/socket.c:2104: internal_send: 192.168.1.254#53: Invalid argument
^C
I then turn the firewall off and re-enter the same command:
➜ ~ nslookup www.google.com
Server: 192.168.1.254
Address: 192.168.1.254#53
Non-authoritative answer:
Name: www.google.com
Address: 216.58.210.36
Now when I turn the firewall back on again, we’re back to
➜ ~ nslookup www.google.com
../../../../lib/isc/unix/socket.c:2104: internal_send: 192.168.1.254#53: Invalid argument
../../../../lib/isc/unix/socket.c:2104: internal_send: 192.168.1.254#53: Invalid argument
../../../../lib/isc/unix/socket.c:2104: internal_send: 192.168.1.254#53: Invalid argument
;; connection timed out; no servers could be reached
However, if I try to ping an IP address:
➜ ~ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=19.0 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=16.4 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=16.1 ms
[snip]
64 bytes from 1.1.1.1: icmp_seq=31 ttl=57 time=19.2 ms
64 bytes from 1.1.1.1: icmp_seq=32 ttl=57 time=17.1 ms
^C
--- 1.1.1.1 ping statistics ---
32 packets transmitted, 32 received, 0% packet loss, time 31022ms
rtt min/avg/max/mdev = 15.587/16.745/19.270/0.971 ms
It appears that traffic is indeed getting out with the PICO rule created by Glasswire, but not on port 53.
When I go into the firewall rules themselves and look at the rule created by Glasswire ({Glasswire.app.out_56} in my case) it states that local-address ANY can talk to remote-address ANY on local-port ANY and remote port ANY. That looks find to me, but something obviously isn’t correct.
1 Like
The support for the Linux subsystem with the Windows Firewall API is quite new actually. Perhaps you need to run a Windows update and reboot if it’s a fresh yet outdated Windows install? I’m guessing that could be the issue since nobody else has reported this.
Or, maybe after running the updates try a clean install of GlassWire after you reset the Windows Firewall, and then choose “reset firewall” with our installer also.
Meanwhile we will continue to try to recreate this issue on our own machines. Thanks for your report and sorry for the problem.
Fully up to date Ken - initially installed a couple of years ago.
This IS a clean install of GlassWire, installed on the 10th January with reset option selected. I was loath to do this, as I really didn’t fancy permitting hundreds of applications again. However, when people were flagging this up as solved, I figured I’d bite the bullet.
I also downloaded the current release again, even though according to Glasswire I was already running it but found that the rules creates by the version were just the same.
@codex22 - could you possibly check the rules you have within your firewall installation to see what is permitting traffic on port 53 and/or for Pico. I found exporting the ruleset to a TSV file made it easier to search, as neither Glasswire nor Windows Firewall offer any search functionality…
Thanks for the detailed info. I will discuss this issue with our team and see if they have some other ideas of how this could happen.
Meanwhile if anyone else has this issue (with an up to date version of Windows 10 and an up to date GlassWire version) we’d appreciate a post here about it.
I can send fire over the ruleset built by Glasswire if that helps. Just shout.
1 Like
I will let them know, thank you.
Our team did a test today, here is what we did:
- We tested with the latest Windows 10 version with the latest updates.
- We used the latest Ubuntu from the Windows store.
- When we tried to download a test file for the first time, GlassWire blocked the connection and asked about wget access. We allowed it and tried again. The file was successfully downloaded.
I don’t get asked about wget access - I get asked if pico can access the internet, which I allow and then no more requests…
sigh.