Windows Firewall Control (WFC) by BiniSoft.org

@alexandrud

I found a minor issue with WFC on my system, Win10x64 v2004. It won't show invalid rules after selecting show duplicate rules in the rules panel. If I select show invalid rules first in the rules panel then they show, but if I select show duplicate rules first and then select show invalid rules then they won't. I have to select refresh list and then select show invalid rules in order for them to show.

Like I said it's minor, but I thought I would bring it up here in case you were unaware of it and would like to change the behavior so that it always shows invalid rules whenever invalid rules is selected, assuming you can reproduce it.

 

This is by design. Show invalid rules applies a filter over the existing loaded items. For duplicate items a grouping is applied over loaded items. Any entry that is not part of the subset is removed, so everything is applied to what is displayed. I will see if this can be improved.

 

Sorry if this is a known issue or has been discussed before:

Freshly installed Windows 10 2004, WFC 6.3.0.0: when medium filtering is selected the outbound allow rules of WFC aren't effective for certain services, such as Windows and Store updates (svchost). According to the log they're being blocked instead. I tried it with and without WFC's recommended rules, via notifications and learning mode. The allow rules are always correctly created - also checked them in the Windows Defender Firewall UI - but in the end the affected services/processes are being blocked. Other freshly created allow rules such as Firefox are working fine. Any idea?

BTW no other changes have been made to the default settings of WFC, secure rules are disabled. The problems are gone when low filtering profile is selected, so it's not an issue of an overseen block rule or similiar.

 

Is "usocoreworker.exe" allowed to connect ?
Did you took a look at the Firewall log to see what s being blocked or allowed ?

 

Yes, is allowed.

For example Windows Update is being blocked several times (never allowed) when an update search is initialized - even though a proper allow rule exits. I also tried it with learning mode so the needed rules were created automatically. Didn't help. As soon as the WFC filtering level is changed to low the Windows updates start. So in medium filtering mode WFC/WDF somehow doesn't seem to find the matching rule (although it definitely exits) and blocks the "unknown" outbound connection.

I can provide screenshots later if needed.

 

@someone2

The "good" thing is: you have no explicit block rule for "usocoreworker.exe" because that would also work in Low profile mode.

To find out why is that no working after switching to Medium profile, it would be indeed good to post the related allow rule(s).

 

If you have allowed a specific service name for a svchost.exe rule and that service is still blocked, you can somehow verify the rule that blocked the connection.

• Reproduce the issue
• Run command in a CMD window with administrative privileges: netsh wfp show state (this will create a XML file in the current folder)
• Open the event viewer: Run (Windows+R) > eventvwr.msc
  • go to "Windows logs" > "Security"
  • in the list, identify the dropping packet log (hint: use the Search feature on the right menu, searching for items (source IP, destination port, etc.) specific to your issue)
  • in the log details, scroll down and note the Filter Run-Time ID used to block the packet
  
  
  
• Open the generated wfpstate.xml file:
  • search for the noted filter ID, and check out the rule name (element "displayData > name" on the corresponding XML node)
  
  

If the name is Default Outbound then it may be a bug in Windows Firewall. This means the allow rule targeted to that specific service name was ignored. Why was ignored, I have no clue, the code is in Microsoft assemblies and I do not have access there. In Windows 10, Windows Update uses more services for updating purposes, so to use Windows Update, you mostly need to allow svchost.exe on remote ports 80,443 with no service name set. If you consider that such a rule is very wide, then disable it and manually enable it once a week when you manually check for updates.

 

The rule name in the XML file is indeed "Default Outbound".

After removing the service name (wuauserv) from my existing, ineffective svchost.exe rule and restricting the protocol to TCP remote ports 80, 443 it works flawlessly! I can live with that - thank you, alexandrud!

Out of curiosity I added WFCs recommended rules again which I had in the beginning: the Windows Update rule only includes port 443. 80 is missing which seemed to be the problem in my earlier tests. Did you change that recently? On my old system from 2016 your Windows Update rule included port 80 - but maybe I edited it, don't really remember.

 

I have to re-add port 80 in WFC recommended rules. I was expecting it to use only SSL, therefore only port 443. However, it appears that it still uses some non SSL connections on port 80. So, yes, just add 80 too and I will also update this in next WFC version.

 

The WFC recommended rule "WFC - Internet Control Message Protocol (ICMPv4-Out)" is applied to the program "System" (as are a handful of other rules). What is referred to by "System" here? And does it have any associated executable/application package/service?

 

Is it your PC , wide opened to the internet.

 

Without that rule some applications/online games may not work properly.Same for the Inbound one.
The ICMP rules should be made/edited from the Windows Advanced Settings though, as in this way you can access the ICMP types, so you can make proper rules with what is really needed in the ICMP field.
This forum has some recommendations regarding what ICMP types should be allowed.Use the search function.

 

In Windows Firewall with Advanced Security WFwAS (not in WFC) create rule, that allow outgoing only ICMPv4 Type 8 Code 0 (echo request) and check the invisibility of the computer from the outside https://ping.eu/ Add this rule in autorized group in WFC.

 

Feature Request: time based rule editor, example: minutely, hourly, daily, weekly, monthly, yearly, enable or disable "powershell.exe" rule for "this long".

 

Does anyone know why the following rule is ignored by WFC?
https://i.postimg.cc/zvrP1ZxN/Image-060.png
I keep getting the following notification, and accompanying entry in the Connections Log:
https://i.postimg.cc/3x4j9fZF/Image-066.png
Thank you.

 

Will not probably happen very soon The implementation would use the Description property of the rule which may be extended to include a JSON settings instead of a simple string. In this way, the properties may be extended with more properties, including a time frame when a rule is enabled or not, the order in the Rules Panel, etc. This is a little bit complex and I have a lot of work in the following months. But I will add this in the backlog. It will be done at some point.

 

In search of a solution, try actualization the source and destination addresses and ports, or vice versa, completely abandon their actualization (allow all).

 

Do I understand that your last WFC version is built based on the old type 'Secure Rules 5 0 2 0' ?
thks

 

5.3.1.0

 

@myk1

It's absolutely NOT recommended to revert back to an old version especially to a SUCH old version. You can't benefit of all the fixes etc. You should be not surprised if something runs bad ...

See the changelog here:

https://binisoft.org/changelog.txt

 

No, no I don't want to 'revert' ..

 

Ahh, ok, then sorry for the noise!

 

Running latest W10 2004, and 5.3.1.0 with absolutely NO problems, and there's nothing in those change logs that requires one to update, but enjoy the added telemetry, or Event Viewer errors if you remove it I guess.

 

I've tried every combination of options, and the only one that seems like it might be work is to allow each IP address individually...only 500 so far!

 

But I do not get it. The last version of WFC is it with Option 1 OR Option 2 ?
(see:https://www.wilderssecurity.com/threads/windows-firewall-control-wfc-by-binisoft-org.347370/page-229)