vistafirewallcontrol.freeforums.org

[rfinney]

Just got the Plus version of the program. One problem . . . I am running a Windows 7 desktop gadget and it is now blocked from updating. I have tried a number of things to get it to work but all are no go, including any way to get a pop up window. Hoping you can provide me with a firewall rule or some other help. Thanks in advance.

[VistaFirewallControl]

So the gadget is not listed in the firewall and no pop was shown for the gadget. Correct?
Most probably the gadget (unfortunately we have no enough related information) is just a script executed (and network connected) in the name of a gadget processing engine.
So the gadget has no its own network activity, the engine does have.
If so the processing engine should be given with more network permissions.

The best way to determine the engine application and the required (but missing) permissions is forcing the gadget to update and checking the firewall blocking notifications.
The notifications show the blocked application and the blocking reason precisely. Most probably the engine has to be put in WebBrowserZone or EnableAll.

Note:
A connectivity problem may be caused by another firewall, internet provider or the peer.
You could try to temporarily set TrayIcon/RightClick/Mode:EnableAll to switch the firewall off entirely.
If the problem remains under Mode:EnableAll, the firewall is not involved in the problem.

[rfinney]

Thanks for the very quick response. I had already tried Mode:EnableAll and found that it indeed fixed the problem. From looking at my blocked notifications file, it looks as though it is a Host Process for Windows Services request that is coming from the gadget. Is there some way I can avoid enabling all for svchost?

[VistaFirewallControl]

Expecting svchost (“host process for…” ) specific blocking is the only blocked and required activity you could try to customize the zone set to svchost.
Extract the blocked protocol (TCPor UDP) and IP:port from the blocked notifications
Then ProgramsTab/HostProcess/RightClick/Zone(F3)
In the shown dialog:
- New (on the toolbar), check “Name” and give a proper name.
- Check Protocol and choose the protocol
- Check IPv4/v4 and set the IP in the form x.x.x.x/32
- Check Port and set the port
- Check Direction and choose Outgoing (most probably the required direction is outgoing)
- Set result to Enable
- Click OK

The above gives you minimal additional permissions.
We believe the gadget will not vary IP/ports of the destination. Otherwise the added rule should be not so strict.

[rfinney]

I am having trouble creating a zone modification rule that allows the process. Here is a sample of my log:
6/29/2010|6:32:25 AM|IPv4 TCP 127.0.0.1:65306(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:26 AM|IPv4 TCP 127.0.0.1:65307(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:27 AM|IPv4 TCP 127.0.0.1:65308(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:28 AM|IPv4 TCP 127.0.0.1:65309(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:29 AM|IPv4 TCP 127.0.0.1:65311(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:30 AM|IPv4 TCP 127.0.0.1:65312(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:31 AM|IPv4 TCP 127.0.0.1:65313(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:32 AM|IPv4 TCP 127.0.0.1:65314(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:33 AM|IPv4 TCP 127.0.0.1:65315(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:34 AM|IPv4 TCP 127.0.0.1:65316(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:35 AM|IPv4 TCP 127.0.0.1:65317(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:36 AM|IPv4 TCP 127.0.0.1:65318(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:37 AM|IPv4 TCP 127.0.0.1:65319(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:38 AM|IPv4 TCP 127.0.0.1:65320(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:39 AM|IPv4 TCP 127.0.0.1:65321(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:40 AM|IPv4 TCP 127.0.0.1:65322(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:41 AM|IPv4 TCP 127.0.0.1:65323(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:42 AM|IPv4 TCP 127.0.0.1:65324(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:43 AM|IPv4 TCP 127.0.0.1:65325(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:44 AM|IPv4 TCP 127.0.0.1:65326(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:45 AM|IPv4 TCP 127.0.0.1:65327(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:46 AM|IPv4 TCP 127.0.0.1:65328(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:47 AM|IPv4 TCP 127.0.0.1:65329(56114)|Host Process for Windows Services| Incoming
6/29/2010|6:32:48 AM|IPv4 TCP 127.0.0.1:65330(56114)|Host Process for Windows Services| Incoming

I am not sure how to set the port , , , I tried 56114 but that didn't work. So I guess I have to set some range?

[VistaFirewallControl]

W7FC shows all the blocking notifications regardless of the origin. The mentioned notification does not specify the blocking reason (what is typical for W7FC).
Most probably the block was made by WindowsFirewall (not by W7FC), moreover blocking all incomings is the default behavior of WindowsFirewall.
Please configure WindowsFirewall. Hopefully that will be the last missed permission required by the gadget.

[rfinney]

The problem is not with Windows Firewall. Even if i completely disable it, Windows 7 desktop gadgets do not update. I must set W7FC to enable all in order to get them to update. Can you test this yourself on a Windows 7 machine? I am quite sure you will see the same thing.

[VistaFirewallControl]

Why we do think the problem is not in W7FC and probably in WindowsFirewall (WF)

- WF is just a control panel to WindowsFilteringPlatform (WFP), the network security core of Windows7/Vista. Switching WF off does not affect WFP, which still filters the network traffic and may block.

- WFP is smart enough to add/remove self-generated rules when a control panel (WF or W7FC) changes the behavior. There are confirmed cases of changing the minor behavior of WFP when settings Mode:EnableAll in W7FC is made.

- The blocked notification shown by W7FC confirms the block is not made by W7FC, W7FC specifies name of the blocking zone always.
Try to block IE (for instance) and check the notification in the form “Internet Explorer | TheZoneName Direction”.
Try to block “HostProcess…” and check the notification in the form above.
Also you can set “HostProcess…” to EnableAll (not the entire firewall into Mode:EnableAll) to enable “HostProcess…” entirely and only to check the problem is not in W7FC with “HostProcess”.
So WF is the most reasonable candidate for the blocking (till you have no other WFP control panels installed).

- We just tried to check “Whether” (randomly chosen, you did not specify the causing problem) desktop gadget with “Windows Desktop Gadgets” set to WebBrowserZone, “HostProcess…” set to “Local+DNS+DHCP+Update(svchost)” (default recommended for HostProcess) and WF switched off and no problems were found.

If you would like we could provide you with the logging version of W7FC, which could point to the blocking rule fullname/identifier extracted from WFP precisely. The rule fullname will allow to determine whether W7FC is involved precisely. Hopefully the rule name could indirectly point us to the rule generating application.

[rfinney]

I am not sure I really understand your explanation. I will go over things again and try some of what you suggest. It does seem as though the logging version could be helpful so I would definitely like to try it. Thanks.

[VistaFirewallControl]

The logging version is the final remedy. We believe the problem is less complex.

So here is the logic we follow, most probably the logic explanation would make our previous suggestions more clear.

So initially you have found the widget operable under Mode:EnableAll only with WindowsFirewall (WF) switched off.
Any widget permissions settings under Mode:Normal blocked the widget.
Your conclusion was very reasonable – the firewall has a problem with the specific widget.
Later you provided the logs showing svchost (HostProcess) was blocked, not the widget.
The log details, however, revealed the block is made not by W7FC, most probably by WF.
Actually it’s hard to believe the block could be made by turned off WF…….
So here is some way to investigate under Mode:Normal (Mode:EnableAll can indirectly affect the underlying security core)

- The logs showed HostProcess is blocked (while trying to update the widget under Mode:Normal).
Set HostProcess to EnableAll. If you see the same (*) logs , HostProcess could hardly be blocked by W7FC.
It’s an argument for W7FC does not block the widget and the required/related HostProcess activity.
(*) the logs without the blocking reason specified. In order to check what is the blocking reason specification you could temporary set your browser to DisableAll and try to browse. You should see
“…..BrowserName | DisableAll Outgoing” as the notification. Your logs came without a blocking zone specified.

-Regardless of the following looks senseless at first sight please try (it should not take too much of your time):
-switch WF on back.
-configure WF to enable HostProcess incomings (revert the firewall rules to the factory defaults if required and restart the PC)
- set in W7FC “Windows Desktop Gadgets” to WebBrowserZone, “HostProcess…” to “Local+DNS+DHCP+Update(svchost)” (we expect the zones were not customized by you)
- retry the gadget update.

Why the logging version would be the final remedy.
The logging version will show the blocking filter internal ID and the filter name only. We definitely will be able to determine whether the rule belongs to W7FC.
Imagine (as we suspect) the rule is not from W7FC. We know only the ID/name, we will hardly be able to determine the rule generating application; there are no rule-to-generating-application back references.
The most habitual rule generator in WF and we will have to ask you to reconfigure WF. Why we would not start from WF configuration at once….
The logging version can be sent you personally, please contact support [at] sphinx-soft [dot] com referring this thread for that.