Any feedback yet on update v2.1.166 released Sept 17th?

https://www.glasswire.com/changes/

I often man our helpdesk, and I have not seen any major issues as of yet but I’ll keep on the lookout as always!

We plan to release a quick update in the next week or so that adds a loading animation when switching between firewall modes. This is because with some PCs and larger rule sets there can be a delay where it looks like GlassWire is frozen but it’s actually updating the rules on the backend. The update makes it clear GlassWire is doing something and is not frozen.

3 Likes

I believe there is a small error in the changelog:

Turn nslookup off in your GlassWire settings if you don’t want to see the domain names of the hosts you are connecting to.

Turning it off still shows domain names, from my experience they actually seem to be more accurate? I disabled nslookup via config edit a while back but when I had it enabled it didn’t verify if the reverse DNS it got was actually valid, I used to often see internal names like “Server01” (just an example I made up), especially on game servers.

@Thinking

I am not sure I understand.

If you used to do nslookups with GlassWire before you turned the feature off then the nslookup domains will still be visible in the software. Perhaps it’s a misunderstanding? Turning the nslookups off should stop all nslookups.

I am a bit confused as well, there seems to be a secondary way GlassWire is obtaining hostnames. On my current history file I have had it disabled since the last reset and the vast majority hosts show up fine.

GlassWire_2019-09-20_05-04-31

2019-09-20_05-05-28

Also it doesn’t seem that GlassWire is doing any reverse DNS lookups according to my DNS log.

@Thinking

I think it’s from the old cache inside GlassWire. We cache nslookups so we are not constantly doing an nslookup for every single host.

Try doing a clean install to see if it’s convenient for you, but if not I understand.

UPDATE: I confirmed with our team it’s from your cache.

Installation error on a Windows 7 computer.

Glasswire%20error

Error opening file GWCtlSrv.exe

@Mariner49

Is it possible to run Windows update on that PC?

Yes, just ran windows update. Glasswire version 2.1.158 was, and still is running.

I went a step further and created a clean Virtual Machine and took screenshots (The VM is a fully updated Windows 10 Pro install with nothing besides the stuff that comes with Windows 10)

Clean GlassWire Install (Note the disabled network connection)
vmplayer_2019-09-20_16-17-13

“nslookup” Disabled (Note the disabled network connection)

[At that point I restarted the VM and reenabled the network]

Proof that it still showed hostnames:

I checked the DNS log and there were no “.in-addr.arpa” lookups.

@Thinking

It is a misunderstanding.

You expect that the nslookup option will disable hostname resolving completely, but it does not work that way.

We use two methods to get the DNS name of the remote host. The first one is nslookup back resolving. This method is based on “.in-addr.arpa” requests.

The second method implemented by GlassWire is based on DNS packets interception. Every time when an app tries to connect to some host it resolves the hostname to its IP address, which could be described as “straight” resolving. So the DNS request packet is sent to the DNS server. The DNS server responds with the DNS response packet that contains the original hostname and a list of corresponding IP addresses.

GlassWire intercepts the response and parses it. So it can resolve the IP addresses without nslookup requests.

You confirmed that you did not see any “.in-addr.arpa” requests and this means that the nslookup option is working properly.

We added this feature for people who want more control over nslookups, for example if they want all their nslookups to be encrypted with their browser then GlassWire can’t do a secondary lookup and cause an issue for them.

If someone is using dnscrypt and the GlassWire nslookup option is off then Firefox dnscrypt connections won’t be resolved.

1 Like

I like the way you explained that. Because I was confused myself. Thanks Ken_GlassWire!

I was already aware that GlassWire does not only rely on nslookup to resolve hostnames, however the reason why I brought it up in the first place was this text in the changelog:

Turn nslookup off in your GlassWire settings if you don’t want to see the domain names of the hosts you are connecting to.

And even you and your team thought the cache was the reason that my GlassWire still showed hostnames. Did you guys forget DNS packet inspection is a feature of your software? :laughing: