Windows Firewall Control (WFC) by BiniSoft.org

Bug Report: Manage Rules Window Closes When I Middle Click
Is this intentional?

 

No, that's not correct, Local addresses are Local addresses assigned (static or dynamic) to your PC only. It's not the LAN.

They can even be assigned from external Hosts. So it's possible that you receive a public routable IP via VPN. Then this IP is your Local address!

LocalSubnet is the ACTUAL Subnet. If you are logged-in in a public area for ex., your LocalSubnet is this actual Subnet there.

LocalSubnet in IPv4 are non-routable IPs. More complicated is the "new" IPv6: there exist "Site Local Unicast" addresses, which are deprecated in RFC 3879 - such addresses are in future standards defined as routable.

Another thing is the Location. ONE example: If you are define your Network at Home as PRIVATE and a VPN as unidentified (= PUBLIC) Network and your rule is set to Private only, then such rule has no effect to the LocalAddress from VPN-Host. If you set the rule to Location = ALL (for ex.), this rule should work for such a assigned VPN-IP too, regardless if this IP is in "Your" LAN or not.

But if I assume that your outgoing allow rule is set to Location = ALL, then your rule (Local address = Any, Remote address = LocalSubnet) works as follow ...

All local adresses assigned to your PC (for example your assigned LAN Network Interface Card (NIC) IP) are allowed - AND the traffic is restricted to your actual LocalSubnet, which means: restricted to all IPs in your actual Local Subnet. Could be for ex. an IP from your TV, Router, Switch, Xbox or whatever if you are in your Homenetwork; but if you are logged-in in a Public Wireless LAN (PWLAN) Hotspot for ex., this could mean: a public-router or net-printer there or even other connected devices from other peoples there (if you can relly reach an device of other user there is another thing (dependent (for ex.) from router and firewall settings of the Hotspot-Operator and/or other users).

An exception is the Loopback address (127.0.0.1 for IPv4). This address is your Localhost IP (resolved address = localhost; your Host on your PC).

For Loopback you can't make a "working" rule with Windows Firewall. The Loopback address it's always allowed.

Because this "Loopback-Effect" exist incompatibilities with other Security Solutions such as Avast. Because such solutions act as local proxy on the loopback address (for ex. to analyse web-traffic). This means for ex. you can't block outgoing traffic from your browser to Internet.

Regards,
Alpengreis

PS: It may have other exceptions or possibilities. There is therefore no claim to completeness. It is only a little illustrate how it works in principle.

PPS: Sorry for english, it's often very complex for me to explain in this language. I hope you understand, what I mean ;-)

 

Thanks for your input, after reading your post and doing some further research, I think I understand better what the Local IP address and remote IP address do. To rephrase; local IP addresses are the IP addresses which are assigned to the network adapters of the your PC, and remoter IP addresses are the IP addresses of other network devices (PCs, printers, website servers, etc.) to which your PC makes incoming/outgoing connections. So, that implies:

- Your PC could simultaneously have as many local IP addresses as the number of network adapters it has connected to a network (WiFi, Ethernet, or Bluetooth).

- Your LocalSubnet pretty much refers to your LAN (be it domain, public or private). Devices which Windows Explorer can see on the network (be it a domain network, home/private network, or guest/public network) are part of your LocalSubnet. Although, some routers are smart enough to have two separate subnets (usually one for private, the other for guest), that way, you can have multiple devices connect to the same network infrastructure, but they won't see one another.​

Based on the above, I've slightly changed the previous allow rule for the explorer.exe process as follows:

Program: C:\windows\explorer.exe
Name: Windows Explorer (explorer.exe)
Group: Windows Firewall Control
Description: Outbound rule to allow Windows Explorer (explorer.exe)
Location: Domain, Private <- No public locations
Protocol: Any
Local addresses: Any
Remote addresses: LocalSubnet
Service: Any
Direction: Outbound​

 

^ So for my understanding, you want Explorer to only (be able to) access PC's on your LocalSubnet but Explorer is not allowed to access PC's on the Internet ?

Correct ?

 

That's right.

Not necessarily connected to a network, may well also be a PC that is connected to a SINGLE UNIT, eg with a router with integrated DHCP server. The composite is then indeed a network, the PC itself is associated with a single device.

The question is not, can explorer see or not - LocalSubnet is LocalSubnet. It can be that a device is a part of your actual LocalSubnet, but explorer cannot see this device through firewall restrictions on other device or whatever.

That seems to be possible, at least with DD-WRT or openWRT. It may exist also special hardware routers (expensive?), which can handle this. If this possible with "normal" "Home-Routers", I don't know. Eventually you need also additional firewall rules (on router-side) to really seperate the subnets. But I know too little about the hole thing.​

Alpengreis

 

According to this principle the rule is now being made. And he exclude traffic within defined Public Locations.

 

As seen from the screenshots can be seen clearly only the TCP protocol. And only with the ports 80 or 443. So you could change your rule to a more restrictive setting with ...

Protocol = TCP
Remote Ports = 80, 443

You ensure so, that no other possibly undesired traffic from Win Explorer leaves your machine.

You could even be more restrictive as you could set the Interface type. So it's possible to change the rule to "Interface types = LAN" only (for ex.) - related to your setting of course. So such Win Explorer traffic would be only allowed in LAN connected situations, not with Wireless or Remote Access conditions. It's a personal decision, if you need such restrictive rules or not and it's related from each individual user (setting) and/or Security requirement.

Alpengreis

PS: And don't forget, such an allow rule works only as intended, with the WFC Profile Medium. If you switch (for installation eg) to the Profile Low, then NO traffic from Win Explorer is restricted or in other words all traffic is allowed. In such cases - to avoid such traffic, a BLOCK rule is necessary! If you switch to Profile High, then the rule is superseded with the policy "block all".

Also, such a rule is for nothing, if another allow rule with higher "priority" exist (for example "Allow all out traffic for any program to any ports".

 

That's right, and only on Domain/Private networks. On public networks, I have rules set to block all inbound and outbound connections.

It's actually possible with home routers like the ASUS RT-AC66U, which is expensive; got mine for $185, but it was a great upgrade from my 4 year old DIR-655...

As I'm only allowing LocalSubnet traffic on Domain and Pirvate networks, I don't really mind whichever protocol or port it goes through.

That brings to mind; is there a syntax in Windows Firewall that can block all traffic except LocalSubnet? Perhaps ExternalSubnet? I have WFC configured to Medium Filtering Profile, but I just want Windows Firewall to block explorer.exe so long as it's enabled (even when in Low Filtering Profile).

 

Okay, I meant more consumer router. However, sometimes you really better invest some more - and has then the right thing.
Great stuff, anyway!

Except you had "suddenly" an infected or vulnerable explorer.exe with possible impact on other processes or traffic in your private location. But well, that's maybe a bit exaggerated.

Unfortunately not, not a preconfigured "set". I have created special IP-ranges for such purposes. Here they are - without guarantee for correctness ;-)

1) Non-LocalSubnet IPv4 only:

Code:

1.0.0.0-9.255.255.255,11.0.0.0-100.63.255.255,100.128.0.0-126.255.255.255,128.0.0.0-169.253.255.255,169.255.255.255-172.15.255.255,172.32.0.0-191.255.255.255,192.0.1.0-192.0.1.255,192.0.3.0-192.88.98.255,192.88.100.0-192.167.255.255,192.169.0.0-198.17.255.255,198.20.0.0-198.51.99.255,198.51.101.0-203.0.112.255,203.0.114.0-223.255.255.255

2) Non-LocalSubnet IPv4 and IPv6:

Code:

1.0.0.0-9.255.255.255,11.0.0.0-100.63.255.255,100.128.0.0-126.255.255.255,128.0.0.0-169.253.255.255,169.255.255.255-172.15.255.255,172.32.0.0-191.255.255.255,192.0.1.0-192.0.1.255,192.0.3.0-192.88.98.255,192.88.100.0-192.167.255.255,192.169.0.0-198.17.255.255,198.20.0.0-198.51.99.255,198.51.101.0-203.0.112.255,203.0.114.0-223.255.255.255,2000::-3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff,2001:678::-2001:67f:ffff:ffff:ffff:ffff:ffff:ffff,2001:7f8::-2001:7ff:ffff:ffff:ffff:ffff:ffff:ffff

Alpengreis

 

Hello,

Before I begin, I just wanted to comment on how great a piece of software WFC is and that, overall, I've been happy with its features and performance. However, I have two issues that I'm hoping maybe someone can help me with:

1. I'm currently using WFC on a Windows 8.1 machine. I've been having issues running Windows Update manually (Control Panel > Windows Update). Check for updates seems to work correctly, but when I go to actually select and install updates, I get an error specifying "Some updates were not installed" with an error code of 80072EFD. When I switch WFC from medium filtering to no filtering, WU works without any issues. WU also works when I deleted any rules in WFC and restore default windows firewall rules. However, if I restore WFC recommended rules, or go back to medium filter, I start having problems with WU again. Also, when checking the blocked connection log right after receiving the error, I see the following being blocked: Host Process for Windows Services | C:\windows\system32\svchost.exe | Out | 49831 | 23.62.236.19 | 80 | TCP. However, the provided WFC rule for WU specifically allows the above connection, so I'm not sure why it's getting blocked. The only difference I see between the rule and the blocked connection are the capitalization in the program path (the rule has an uppercase Windows vs lower case windows in the log)... though I doubt this should be the issue. Any ideas?
2. Is there any way to handle applications that run out of a temporary location (for example: C:\...\appdata\local\temp\ocr59c3.tmp\bin\rubyw.exe)? I'm using a VPN service whose client software launches from a different temp folder each time.

Thank you for any help!

 

@Teddy879

Hi,

for such things as you describe in point 2 (at least), you can use the WFC "Install Mode" with Profile "Low". Low means in principle:

Inbound: block all except the allow rules
Outbound: allow all except the block rules

This is also the default profile setting in Windows Firewall itself (also if you reset the rules there).

So, you can set in [WFC, Options] your standard profile to "Medium" (for daily-work eg) - then activate and set [Automatically set" to "Medium" after "10" minutes] (or so). The next time, if you have to install something, you can change MANUALLY your Profile (with WFC) to "Low", then you can install things while 10 minutes - after this period (or after reboot), the Profile change automatically back to Profile "Medium".

Greetings,
Alpengreis

 

I had that issue as well when it came to Windows Updates. I must admit, I don't use the WFC pre-configured rule for Windows Updates. I made my own. SVCHOST sometimes kicks up a fuss when restrictions are placed on it (mind you, it must hate me right now since I block SVCHOST in every way, shape or form before I connect to my VPN (just let "DNS Client" Windows Service through to communicate with VPN DNS servers)).

One thing to mention, WU's don't always occur from the same IP or IP range. I spent a good week listing the IP's that WU uses and I just gave up because it was borderline suicide. The list just grows and grows and grows. You could have a list of 20 IPs or even 20 IP ranges and if WU decides to use one, just one that is not on the list, things will break.

You can't really TELL WU to use the IP lists in the rule. It will make that decision for you because M$ uses Content Delivery Networks. "23.62.236.19" is not Microsoft, it is Akamai. It doesn't appear in the WFC pre-defined list of Akamai IPs, but I made my own and added a range in it to compliment the existing one. I really don't like CDN's. I consider them right up there with NSA.

 

Is it still possible to bind svchost.exe outbound on ports 80/443 to windows update service on Windows 8.1?

 

Try to disable and re enable that option and see if this is happening again. These rules should be removed, especially in this case when they are not created at boot time.

Unfortunately, the group names are not provided by the Windows Firewall API so I can't retrieve them from nowhere. They are hard coded in WFC and only English version of the names are available.

I will update the recommended rules. I will add those entries to the context menu. Regarding the user settings, they are saved in Windows Registry under "HKCU\Software\BiniSoft.org\Windows Firewall Control" key. For now, this key can manually exported from regedit.exe and reimported any time.

Yes. As a shortcut, any window/dialog from WFC can be closed with Esc key or with the middle mouse click.

Regarding Windows Update I have to check this on a Windows 8.1 machine. Regarding the rules for those paths, Windows Firewall rules are applied per path basis. One thing that you can try is to configure your application to use only a specific local port. Then you can define a global rule that allows all programs but only for that specific port. Then, this rule will apply for your program even if the path is different.

Because of the lack of time I hadn't time to respond to all posts. I am working on all the problems you have reported.

 

Oh, no, that's bad. One apply on a predefined WFWAs rule and I have the an english labeled group name in WFWAs-GUI and also in then "Allowed Programs" Overview.

Edit: And I cannot manually set the german groupnames on all predefined rules, because it destroys the Network Sharing (see Bug Report above: if this can be fixed, then this would be an alternative)!

 

Block rules have higher precedence. So, even if you have an Allow All rule, if you block a specific program, it will be blocked on Medium Filtering profile and also on Low Filtering profile. But if you have a Block All rule (like High Filtering profile has), then all allow rules are not taken into consideration if you use any these profiles: High, Medium, Low.

I found a solution and the group names will be preserved in case the user modifies a rule and applies the changes and also when a rule is duplicated. The ICMP and Edge Traversal properties are also fixed when duplicating a rule and displayed in Manage Rules as new columns. The next version will have these fixes.

 

For me, that was clear - I related only on the allow rules. Thanks for the important addition!

About groupnames: yeahhh - every time something seems almost unsolvable, Alexandru comes but then with a solution
Of course also the rest is important.

WELL DONE

Alpengreis

 

Feature suggestion

["User created rules" as filter]

IMHO it would make sense to place the "User created rules" under Filter (instead Display).

So it would be possible to show User created rules seperated for Outbound and Inbound.

Alpengreis

 

Had a couple of hangs in WFC after right-clicking on tray icon, while a SpyShelter alert dialog is displayed almost at the same time. The context menu remains visible but it moves behind the taskbar. WFC tray icon does nothing afterwards. Had to terminate wfc.exe in task manager and restart it. Below is the information from the Event Log:

Code:

CurrentDispatcherUnhandledException was caught:!
System.Runtime.Remoting.RemotingException: Failed to connect to an IPC Port: Access is denied.

Server stack trace:
  at System.Runtime.Remoting.Channels.Ipc.IpcPort.Connect(String portName, Boolean secure, TokenImpersonationLevel impersonationLevel, Int32 timeout)
  at System.Runtime.Remoting.Channels.Ipc.ConnectionCache.GetConnection(String portName, Boolean secure, TokenImpersonationLevel level, Int32 timeout)
  at System.Runtime.Remoting.Channels.Ipc.IpcClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
  at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]:
  at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
  at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
  at WindowsFirewallControl.Utils.SingleInstanceProxy.SetCommandLineArgs(Boolean isFirstInstance, String[] commandLineArgs)
  at WindowsFirewallControl.Utils.SingleInstanceManager.UpdateRemoteObject(String uri)
  at WindowsFirewallControl.Utils.SingleInstanceManager.CreateSingleInstance(String name, EventHandler`1 callback, Int32 sessionId)
  at WindowsFirewallControl.App.OnStartup(StartupEventArgs e)
  at System.Windows.Application.<.ctor>b__1(Object unused)
  at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
  at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)

 

Windows Firewall Control v.4.1.0.2

What's new:
- New: Added new columns in Manage Rules for Edge Traversal and ICMP settings. These columns are hidden by default. They can be displayed in the data grid but they can not be modified from the Properties dialog.
- Fixed: Edge Traversal and ICMP setting are not preserved when duplicating a rule from Manage Rules data grid. The same applies to the scenario when a partial policy is imported from a file which contains such firewall rules.
- Fixed: Rules with no Group defined or with a custom Group are deleted when a rule is duplicated and the "Disable the ability of other programs to add firewall rules" is enabled.
- Fixed: The group name is saved with the English name if the user modifies a rule which is located in a default Windows Firewall group.
- Fixed: IP ranges without CIDR notation are not recognized as valid when modifying a rule. For example this was considered invalid: 224.0.0.0/255.255.255.0
- Fixed: The icons for context menu items in Connections Log and New Rules Wizard are highlighted even if the menu items are disabled.
- Fixed: A new notification for svchost.exe is not displayed if a block rule for svchost.exe for 'Any' protocol does exist. This prevents the notification for Windows Update if the recommended rule for Windows Update does not exist.
- Fixed: Search does not return valid results if the Program is set to All programs.
- Improved: The searh function was extended to find results in the following columns: Name, Program, Group, Local Ports, Local Addresses, Remote Ports, Remote Addresses. Example: The user can search for '80' to see the rules defined for this port.
- Improved: Added "Jump to rules" shortcut in the Connections Log toolbox and the other entries were added in the context menu.
- Improved: Moved 'User created rules' from Display combo box to Filter combo box. This allows filtering by inbound/outbound for user created rules. User created rules are considered the rules with the group name 'Windows Firewall Control' or 'Temporary Rules'.

Installation notes: Just use the updater to upgrade to this new version.

The following translation strings are new:

Code:

640 = Edge traversal
641 = ICMP settings

Download location: http://binisoft.org/download/wfc4setup.exe
SHA1: 041d613393b810dbaa6578e3d2a2a7681b1ff5ab

Thank you for your support and your feedback.

The following tasks are set in the backlog and are planned for the next releases:

Code:

- IP addresses converter to CIDR when retrieving them from the API
- New blank rule in Manage Rules.
- Custom URL providers selectable from combo boxes instead of text boxes. Not many users know the alternatives.
- Find duplicates or maybe more suitable to find similar rules. The user clicks on a rule and he can search for similar rules based on the program path and direction. This has to be simple to use not with a large number of selections. Suggestions ?
- Automatically set High Filtering profile at shutdown and restore the previous at program start-up.
- Fix any remaining bugs.

Feel free to suggest more items or comment on the existing ones.

Have a great weekend,
Alexandru

 

@alexandrud

Thank you VERY much for the GREAT new Update - well done!

Two problems remains:


1) Notify-System The notification system does no more work correctly

Two examples ...

- If no rule is present for Win-UPD (eg after restore the default settings without WFC recommended rules) = NO NOTIFY!
- If no rule is present for ICMPv4 (eg after restore the default settings without WFC recommended rules) = NO NOTIFY!

It means: svchost AND system notifies are affected!

Of course I have set the Notification-Level to high.


2) Key-Combination/Shortcut problem in the Search-Field

If I type a # char in the search field (this is <AltGr>+3 (NOT on the numeric keypad) here with de-CH keyboard), then the New Rules Wizard opens.
But only CTRL+TAB or CTRL+{1,2,3} should have this function.

So I cannot write this char without copy and paste - ok, it's also possible with the Alt-Code <Alt+35>, but this is not so comfortable


Thank you very much for your work - have a good weekend!

Alpengreis

 

Regarding the notifications, I made the same steps as you did. I restored the default policy and the switched the profile back to Medium Filtering. The notifications were set to High all the time. Now, with this setup and the default set of rules, if I check for updates from Control Panel, a new notification for svchost.exe appears. If I try to ping my router from CMD, I receive a notification for System for ICMPv4 protocol. It must be something else, because it works here. Try to give more details.

Regarding the input, the tabs can be switched from CTRL + TAB and CTRL + {1,2,3} as you described. To insert a char like # I press on my keyboard SHIFT + 3 and it works. Pressing ALT + 3 does nothing on my machine. Even if I change the keyboard language to German, special characters are inserted by pressing the SHIFT key, not ALT. There is no handling for SHIFT or ALT keys in WFC. It looks only for CTRL key combinations.

 

I will try, yes.

EDIT: I have it!

You have right, it wasn't a clean reset, I had already added some rules again. And ONE of these is responsable for this behaviour. It's the following:

Outgoing Block rule:
Location = Domain, Public
Program = Any
Remote = ::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
"Rest" = Any, resp should be not relevate

This rule is to ensure, that no IPv6 Traffic is outgoing in non Private Locations - among other things, to avoid a IPv6 Leak. I have another mechanism too, to avoid such traffic - nevertheless this is a problematic behaviour IMHO.

Not Alt + 3, AltGr + 3 ... a swiss-german keyboard has on the normal 3 the * char (type with Shift + 3) and the # char (type with AltGr + 3). AltGr is similar to Ctrl + Alt + 3 ... and this should not be the same as Ctrl + 3 only. Maybe WFC should look for Alt too to recognize this in combinations?

Alpengreis

EDIT2:
PS: Somehow you look for Alt already in the Search-Field, because the Alt + 35 (Alt-Code with numbers from numeric keypad) types the # char!

 

Feature-Suggestion

[More flexible port info]


a) Notify Window

In the Notify Windows we have the possibility to ask a definable website for infos about the related port ("Read more about port" function).

Unfortunately, this is for the Source Port only. But even the remote port is interesting in much cases.

I know, both mouse keys are assigned to other functions there. But why not make this port-info function to Shift or Ctrl + Left Mouse Key or something like this (should be the same combi for source and remote port)?


b) Connections Log Window

The port-info function could also be extended to the Connections Log Window.


Greetings
Alpengreis

 

Talk about fussy...