GlassWire auto lockdown?

#1

Can GlassWire lock the firewall on its own?

I got an error message in a highlighted bar across the top of the GlassWire UI today indicating something may be wrong, and that I should check the website for an update. And it locked the firewall to all outbound traffic. I was unable to unlock it. I had to terminate GlassWire and reset the Windows firewall to default settings to access the net again.

#2

@zzz00m

Sorry, what exactly did the error say? I don’t recall GlassWire having an error message like that. Perhaps it was another app?

No, GlassWire does not take actions on its own.

1 Like
#3

Sorry, I don’t have the exact message. I had never seen this before, but the message was contained in a narrow colored bar across the width of the upper pane of the GlassWire UI, at the top, right below the tab buttons. I wish I had thought to take a screenshot, before I closed the program out, but this occurred before my first cup of coffee and upon first boot-up of the day, and I was just trying to get online.

Recently I have been monitoring my net connections immediately post boot. I had updated to Windows 10 1809 earlier this month, and was just checking for any new connections.

It was clearly not a Windows pop-up dialogue, or a dialog window from another app, as it was fully integrated into the GlassWire Pro UI (v2.1.152), running on Windows 10 Pro 1809.

The essence of the message was that the firewall had been locked or blocked. And I had not clicked on anything in GlassWire yet to cause this, as I saw the message just as I opened the GlassWire UI.

Could this GlassWire message have been generated by some action taken by the Windows Firewall? After I exited the GlassWire UI, and stopped the GlassWire service, I still had no net access. I had to disable the Windows firewall to get online.

Recovery consisted of:
Reset the Windows firewall to defaults.
Uninstalled GlassWire.
Rebooted.
Re-installed GlassWire with the reset and clean install options.

Everything seems to be running OK now, but it is a puzzle why this happened.

The only other thing that I did prior to this event, was that I used Windows Date and Time to re-synchronize the system time via internet. It moved the time back by (-)4 hours, as the time setting was reflecting UTC from the UEFI/BIOS, and not my local time.

#4

Just an update to my last post.

I normally run GlassWire in “Ask To Connect” mode. So today I took a look around the Windows Firewall UI itself, and it seems that this GlassWire mode switches the Windows Firewall state for outbound connections from “Allow” (default), to “Block”.

So all outbound connections are denied by default, unless there is a specific rule allowing them, which GlassWire generates when you “Click To Allow”. As you would expect.

In this scenario, it would seem possible that if there was a sudden corruption to the rules put in place to allow specific outbound connections, then everything would be blocked by default. No auto lockdown would be required. It would just happen by default if the existing rules were unavailable, invalid, or ignored.

With my issue, everything outbound was suddenly blocked. So that does imply that something, I don’t know what exactly, happened to the existing rules.

Just fyi, I checked the setting in GlassWire for “Click To Block”, and that setting switches Windows Firewall outbound connections back to “Allow” (default) from “Block”.

#5

I had the exact same issue:

GlassWire adds it’s own entries to the Windows Firewall for each app you have allowed/blocked. These appear as numbered rules; e.g. Glasswire.app.in_123

It would seem that this configuration can become corrupted which stops the firewall behaving as expected. The solution I was given was the same as you did; nuke all settings and start over. This is less than satisfactory if you have a lot of rules and other configuration settings to recreate.

There is a horribly manual method of backing up and restoring your GlassWire database, but I doubt this will help with the firewall. This could certainly benefit from some improvement:
https://www.glasswire.com/userguide/#Backup_Settings

#6

Did you guys use two firewall software applications simultaneously that can access the Windows Firewall API? I’m trying to guess what could cause something like this. That’s strange that the rules could get corrupted.

We’re controlling the Windows Firewall API, so those files are controlled by Windows itself.

Or perhaps this is a known bug with a recent Windows update and that’s why you both experienced this issue.

#7

I wasn’t using any other third-party software. Which is why the “Ask To Connect” feature was one of the selling points for me.

I have not had the issue reoccur since starting over. But I would feel more reassured if there was a button to backup/restore all GlassWire and firewall settings, along with network labels and traffic data.

If I had to reset everything again I would not be a happy bunny.

#8

We hope to add an easier backup system in the future. Thanks for your feedback.

It’s unusual for the Windows Firewall API to have trouble or get corrupted somehow since this is part of Windows itself. For example I myself have used GlassWire from its 1.0 version in 2014 to now and I have never had this issue, and nobody on our team has either.

But, perhaps some kind of Windows update recently could cause the issue. I haven’t experienced this myself yet but we’ll be on the lookout.

I’ll also ask our quality assurance to test with the latest Windows updates and see if we can recreate this. If we can recreate this we can give a detailed report to Microsoft about their Firewall API.

Thanks for your reports.

2 Likes
#9

Not running any other firewalls.

I am running Windows 10 Pro 1809, with the March updates (Build 17763.404). But I had been running that build with no problems for at least a week prior to the firewall issue occurring.

As I mentioned earlier, the most recent change made on my end before the issue, was setting Windows date and time back several hours. The computer had booted up ok with network access, but the clock was reflecting UTC time, and not my local time. So I triggered a manual Windows internet time change, and then soon after … BOOM! Could conflicting time stamps have created a firewall rules error?

Nuking the firewall and clean installing solved it for me, but that is a bit heavy handed way to deal with this. Will look forward to an easier backup system!

Before you ask about the time being off, I will add that it was caused by the system time in the UEFI/BIOS being changed by something I did when Windows was not running. Windows didn’t suddenly get weird in that regard, since it takes the time from the system clock. That part was my fault for not setting it correctly before booting Windows, but it shouldn’t have had any major impact when it was changed.

1 Like
#10

@ittroll

Did your date/time on your OS change recently also?

@zzz00m Very interesting! That will help our testing a lot, thank you for sharing that info.

1 Like
#11

FYI, some solutions to fix problems with those cumulative updates to 1809 suggest resetting network adapters. I’m not sure why but it does indicate that there have been network configuration problems on some systems and this could affect GlassWire.

What network configuration changes could cause GlassWire to not match existing firewall rules and create what appear to be duplicates?

1 Like
#12

As far as I know, there were no recent changes made to my network configuration, or adapters.

The system was running stable for at least a week with the March 1809 updates in place. Windows is shutdown every night, and and booted daily. Running very clean, no other errors to report.

Have deferred the April updates so far, as I usually wait until the weekend prior to patch Tuesday to install the previous month’s patches. I prefer to let others be the beta testers! :wink:

1 Like
#13

Not at the time I experienced the issue, I had problems in January and February. It seemed to coincide with the install of a Windows cumulative update. But I found no evidence that this was the cause.

1 Like