Firewall Exposure with Glasswire Remote Connection (resolved)

I ended the second of two threads about a problem establishing a remote connection to a server ( Resolved: One of three PCs will not allow Remote Connection ) with the following:

Windows 10 is constantly reminding me to “Turn on Window Firewall”. As you can see here, Windows Firewall is already on.

But going deeper into the Firewall, you can see that Wifi protection is not enabled.

If I click on that Wifi box enabling the Firewall for my network, the remote connection to that machine will stop and it cannot connect again. When I remove the selection from Wifi, I can immediately re-establish the remote connection to the machine.

One last thing – the Glasswire Firewall setting is ON for all my machines.

Thank you for reporting this. We’ll try to reproduce this on our end and see what we can suggest.

Hello Rich,

Did you try to restore the default Firewall policy as I recommended in one of the previous reports?

Yes – it had no effect on either connecting or on this requirement to have Wifi protection disabled.

As far as I can see Firewall blocks all the incoming connections, which do not have the allowing rule.
Could you check the “Inbound rules” at the Advanced settings of the Firewall and find the rule “GlassWire Service”. It should be enabled and, the profile option should be set to “All” and Action should be “Allow”. Also please check whether the file path to GWCtlSrv.exe is correct.

Thanks for the suggestion, Richie, but the Inbound rules for Glasswire are present and correct as you described including the file path. I checked all my remote systems to be sure.

I also specifically re-checked the Win7 machine to be sure it really was acting the same. As soon as I enabled Firewall on Wifi on that machine, the remote connection to my client was dropped.

Although I didn’t expect it to matter, I set my network to allow file sharing just in case there was a relationship to “network files”, but again no change.

I will go back and re-check my router setting yet again, but I expect that is not the problem. Regardless, I will be updating my router later today, so that will change anyway.

Finally, I also will try setting up an explicit Inbound Firewall rule to allow port 7007 on the Private network setting. If that works, at least it will minimize any exposure, but that shouldn’t matter to the Glasswire developers. They will still want to know why there is such and exposure at all. Me to.

Ok, I’ve done both of the above with no change in the situation. I understand well almost all of the router options and have passing knowledge of the rest, so I don’t think I’m missing anything. (I’m not sure I’ll be able to say the same about the new AC1900 router, but it practically feeds me anyway…)

I think the Firewall rule was simple to implement (and undo), but I’m open to any suggesstions. As soon as I implemented the rule, no change on the remote connection, but again when I enabled Wifi protections, the remote connection dropped.

Updating with the current Glasswire release and a little new information.

Both machines are now running Glasswire 1.1.36b. An internal problem (see below) led to turning Wifi Firewall protection on the remote machine back ON – which resulted in the remote connection immediately being dropped as soon as I clicked on OK for the window. After getting 1.1.36b installed, I re-tried unchecking the Firewall Wifi for Private Networks. As I watched, the remote connection restarted. I had also opened the Glasswire Firewall window on the remote machine to watch if anything changed on it when the Wifi protection was removed – no changes. (This latter was while directly running the remote machine – not via the remote session.)

Same thing when I again checked the Wifi protection for Private Networks on the remote machine using 1.1.36b – the remote session immediately stopped updating on the remote session Graph. Again no changes in the Glasswire Firewall window.

As for the “internal problem” I referred to above – that is my wife. She is not willing to run without the Wifi Firewall protection enabled despite the fact that we are on an internal protected subnet. Since she brought in a virus on her machine while connected outside our network two weeks ago (immediately detected and cleaned up with Avast), she is not willing risk any exposure. This means that I have lost my entire purpose for purchasing Glasswire – that is, protecting and managing our home network via remote monitoring.

Apparently no one else has reported this problem, yet I have it on all 4 PCs in my network. I have seen it while running several different network configurations with 4 different routers from 3 different manufacturers. My Glasswire client is Win10; 2 of the remote servers are Win10 with the other remote server on Win7. All show both this problem and also the graphic problem I reported elsewhere in which the mini-session tabs appear with a separation from the main Glasswire window (which again, apparently no one else has seen).

My understanding is that Glasswire will be handling remote connections differently with your upcoming new version. I hope that will address this problem. And I think you should note that although I am monitoring Glasswire’s Firewall tab while the reported remote connection loss occurs, when I stop the Windows Firewall on that machine, there is no indication of a change in the Glasswire Firewall display.

1 Like

Thanks. I reported this to the dev team again so we can investigate and fix it.

1 Like

I appreciate it. I’ll be happy to do any other testing that you folks need. fyi, I said it elsewhere, but my current router is a Netgear R7000 AC1900.

1 Like

We just released an update this morning. Please upgrade to our latest version and see if it solves this problem.

Avast reported that GlassWireSetup.exe has a virus and deleted the file immediately.
Please see the avast report below and confirm that your file does not have this virus. Then I will try and will report back to avast appropriately. This has never happened with any download previously.

Someone else reported it also. We’re changing the installer around to get rid of the false positive.

We are going to remove the update from our main download link until Avast white lists it, then repost it. Sorry for the problem. It appears Avast has decided that the installer we use is a virus, even if it’s completely empty.

Ok, I suspected it was a false positive.

Success!! This issue is apparently resolved with 1.1.39b!

With the holiday, it took me a while to get the machines update to 39b and then rebooted, but once done, I am now able to establish the remote connection when the remote machine has the Windows Firewall fully implemented.

As I said previously, my wife had refused to run without the Private firewall Wifi option selected (meaning standard full Windows Firewall implemented). After loading that remote machine with 1.1.39b and rebooting, I was able to establish the remote connection.

This completes the need I have to monitor the key machines in my network from my Glasswire client. Both these machines run Win10. I will also try this with my two test machines (Win10 Insider test machine and a Win7 machine) and report the result, but that will take a while longer and is not critical from my perspective.

Edit: It occurs to me that the problem resolution may be related to updating Win10 to the 1511 release. Please let me know.