Glasswire not cleaning up Windows Firewall rules?

Hi all,

I just had to completely reset my Windows firewall rules and do a clean reinstall of Glasswire because I ran into some issues.

After cleaning up some rules in Glasswires “inactive apps” list, some programs were not able to connect to the network anymore. For example Steam, which had some entries in “active apps”, which I left alone and some in the “inactive apps” which I removed.

I was under the impression, that when I delete an entry from any list (blocked/active/inactive) and the program in question tries to establish a connection again, GW will ask again if I would like to allow or block the app (im running Elite and GW set to “Ask to connect”). But this was not the case. I couldn’t get the popup to show up.
The only way for steam to work was to set firewall to “off” in GW.

I know that GW utilizes the windows firewall for blocking/allowing stuff so i checked the Windows firewall incoming/outgoing rules. There I saw a massive amount of Glasswire rules (I’m running GW for a few years now), much more than were visible on the GW firewall tab.

After resetting everything and clean-reinstalling GW, things seem back to normal again. But i can see the same behaviour - if i block an app and remove it from GWs firewall list, it still remains in the windows firewall as

Now my question:
Is this expected behaviour or is this a bug? Shouldn’t GW clean up the unused firewall rules?

I also noticed that glasswire took longer and longer until it shows firewall “ON” after rebooting. I think this was because of the large amount of firewall rules which it had to parse. After resetting all rules, GW turns firewall to “ON” quickly again after a reboot.

Sorry for the long read, hope you guys can clear these things up for me!


First of all, are you using any other firewall besides GlassWire, or have you used another firewall previously? Two firewalls at once using the Windows Firewall API can cause all kinds of unexpected issues.

We group our rules neatly under the “GlassWire” group under the Windows Firewall if anyone wants to check them.

It is true if you delete an app from the list and if you’re in “Ask to connect” mode, it should ask to connect again next time as you suggested. If you use our search feature on the firewall is it possible there is another Steam there that’s a different version? Sometimes two versions of the same app can be on the firewall tab.

I’m just using Glasswire and windows defender + malwarebytes free, nothing else. Running Windows 10 1909.

When the issues were happening, i was using the search function in the firewall tab but didn’t find anything from steam that was being blocked.
Only when looking into the windows firewall rules could i see some steam processes were being blocked with rule name

Is it normal behaviour for glasswire to leave the rules in windows firewall even though they have been removed from gw?


1 Like


It depends on the type of rule. Were you deleting the rules through Windows Firewall yourself, or just mousing over the rule in the GlassWire Firewall and pressing the “X” button? Was GlassWire’s firewall on or off while you were doing this?

Please give numbered steps on what we should do to reproduce the issue and we will see what we find. Also please go to the top left GlassWire menu and choose “About” and let us know what version you have, plus what version of Windows.

I was deleting the rule through Glasswire by pressing the X. GW Firewall was turned on. I’m running the latest available version - 2.1.167

Here are the steps:

  • In Glasswire, block any app by pressing the greyed out flame icon. It will show up under blocked apps in GW.

  • Now check in the Windows Firewall ruleset. For both incoming and outgoing rules, there should be a “block” rule called “” that corresponds to the app you just blocked. You can verify by checking the program path for the rule

  • Back in Glasswire, delete the rule by pressing the “X” button. The app is now gone from the Glasswire list.

  • Refresh the Windows Firewall ruleset. The rule for app is still there even though it is gone from Glasswire.

In my opinion, the rule should be removed from the Windows Firewall ruleset when it is removed via the X in Glasswire.

Before the clean install I did yesterday, even when i relaunched the app in question, Glasswire didn’t ask me if I wanted to allow it again. The app just wasn’t able to connect to the network anymore. Only when i deleted the corresponding rule in the windows firewall was the app working.

Now after the clean install, everything seems to be back to normal again - even though i delete ann app from Glasswire via the X, i get asked if i want to allow it once i launch the app again.
But the issue i had was with apps I deleted from the “inactive” section in GW. I don’t have that section yet and don’t know if it makes a difference. I suggest you also delete an app from the inactive section without blocking it first when trying to replicate the issue.

Thanks for your support!


I am experiencing the exact same issue. I have not made any changes to Windows Firewall default settings and do run any other apps.

While the firewall button in GW is off; all connections work as expected.

When the firewall button in GW is turned on and a few apps are blocked, they cease to connect; as expected.

After unblocking the selected apps(while GW firewall button is left on), connection continues to fail.

Connections resume, only after turning off the firewall button.

Running version 2.1.167 Windows 10 64.
I have uninstalled and downloaded/reinstalled twice.


Can you tell us some of the app names that continue to fail while in “Ask to connect”?

If you uninstall GlassWire, then go to the Windows Firewall control panel and choose “restore defaults”, then reboot, then reinstall GlassWire using its “clean install” and “reset firewall” options does it solve it for you?

I never used or tried “ask to connect”.

I used “click to block” and I blocked and unblocked firefox…


We will have a major update out in a few weeks. Please give it a try. Meanwhile we’ll try to reproduce this with our QA team.