vistafirewallcontrol.freeforums.org

[rfinney]

A clarification: The widget was operable with WF turned off or on. It was when W7FC was turned on that it would not work, unless Mode:EnableAll was turned on. I am not sure if this affects what you are saying or not. Please advise and then I will try what you suggest. Thanks.

[VistaFirewallControl]

The details affect the hypothesis slightly because of three facts
- WindowsFirewall (WF) is just a control panel to WindowsFilteringPlatform (WFP, the main traffic processing engine). Obviously a control panel state can not affect the presence of filtering. The filtering rules are mostly persistent regardless of the control panel.
- There known cases of WFP can set/remove (enable/disable) some filtering rules automatically on its own. The details are not documented; however there are registered cases of filtering rules inserted/deleted while switching W7FC modes. The probable logic is – when WFP check globally enabling rule (Mode:EnableAll for instance), WFP suggests a security hole and reacts accordingly.
- Depending on the filtering rules internal grouping (so called filtering layers), Mode:EnableAll may override a non-W7FC disabling rule. So an application may be blocked by non-W7FC disabling rule under Mode:Normal only.

[rfinney]

First, I set HostProcess to EnableAll . . . the result was a change in the log, but no change in the gadget (still didn't work)
Second, I set WF back on, set WF to enable HostProcess incoming, set W7FC "Windows Desktop Gadgets" to WebBrowserZone and "HostProcess" to Local+DNS+DHCP+Update(svchost) . . . the result was the gadget now worked.
Third, I turned WF back off and left all the other settings in previous step the same . . . the gadget continued to work

I don't really understand what is happening and why. Here are a sample of the new log:

7/9/2010|1:48:58 PM|IPv4 TCP 127.0.0.1:55159(56114)|Host Process for Windows Services| Incoming
7/9/2010|1:48:59 PM|IPv4 TCP 127.0.0.1:55160(56114)|Host Process for Windows Services| Incoming
7/9/2010|1:49:00 PM|IPv4 TCP 127.0.0.1:55161(56114)|Host Process for Windows Services| Incoming
7/9/2010|1:49:12 PM|IPv4 UDP 65.55.158.118:3544(54713)|Host Process for Windows Services|Local+DNS+DHCP+Update(svchost) Outgoing
7/9/2010|1:49:13 PM|IPv4 UDP 65.55.158.118:3544(54713)|Host Process for Windows Services|Local+DNS+DHCP+Update(svchost) Outgoing
7/9/2010|1:49:15 PM|IPv4 UDP 65.55.158.118:3544(54713)|Host Process for Windows Services|Local+DNS+DHCP+Update(svchost) Outgoing
7/9/2010|1:49:18 PM|IPv6 UDP [fe80::ac09:b018:2c27:a272]:3540(3540)|Host Process for Windows Services|Local+DNS+DHCP+Update(svchost) OutgoingV6
7/9/2010|1:49:19 PM|IPv4 UDP 65.55.158.118:3544(54713)|Host Process for Windows Services|Local+DNS+DHCP+Update(svchost) Outgoing
7/9/2010|1:49:20 PM|IPv6 UDP [fe80::ac09:b018:2c27:a272]:3540(3540)|Host Process for Windows Services|Local+DNS+DHCP+Update(svchost) OutgoingV6

It contains some of the same entries as before. It seems as if nothing should be blocking those Incoming entries, since I allowed them in WF and they don't appear to be set by W7FC. I am guessing those Outgoing entries are related to the gadget but I don't know what they are about. They don't seem to be needed for this gadget but I suppose they could be necessary for other gadgets.

[VistaFirewallControl]

>First, I set HostProcess to EnableAll . . . the result was a change in the log, but no change in the gadget (still didn't work)

That confirms the hypothesis – the HostProcess was not blocked by W7FC

>Second, I set WF back on, set WF to enable HostProcess incoming, set W7FC "Windows Desktop Gadgets" to WebBrowserZone and "HostProcess" to Local+DNS+DHCP+Update(svchost) . . . the result was the gadget now worked.
Third, I turned WF back off and left all the other settings in previous step the same . . . the gadget continued to work

That confirms the hypothesis – WF (actually the underlying core, not WF control panel itself) is smart enough and have some undocumented hints.
Also that confirmed
W7FC "Windows Desktop Gadgets" to WebBrowserZone and "HostProcess" to Local+DNS+DHCP+Update(svchost) are enough from W7FC point.

>I don't really understand what is happening and why. Here are a sample of the new log:

Actually it’s hard to understand network activity of an application in full till you have the source code of the application (or a related support) and enough spare time.
Often the complete understanding could take too much time beyond solving a specific an application related problem.

>7/9/2010|1:48:58 PM|IPv4 TCP 127.0.0.1:55159(56114)|Host Process for Windows Services| Incoming

Not by W7FC (no blocking zone specifications). 55159(56114) could hardly explain the activity purpose. Looks like an inter process communication…. No strict ideas.
However most probably it is exactly what was required (till there are no other suspects)

>7/9/2010|1:49:12 PM|IPv4 UDP 65.55.158.118:3544(54713)|Host Process for Windows Services|Local+DNS+DHCP+Update(svchost) Outgoing

3544 – Teredo port (a way to establish IPv6 communication over IPv4 connection).
65.55.158.118 belongs to Microsoft Corp
It could hardly be gadget related.


>7/9/2010|1:49:18 PM|IPv6 UDP [fe80::ac09:b018:2c27:a272]:3540(3540)|Host Process for Windows Services|Local+DNS+DHCP+Update(svchost) OutgoingV6
Peer discovery (3540) for IPv6. It’s hard to believe it’s a gadget related. Most probably you have no IPv6 from you internet provider at all. Moreover FE80:: is the local address, can not be used for public communications.
You have just IPv6 bound to the network adapter. The state is default for Vista and Windows7.

[rfinney]

I am starting to understand a bit better. I want to clarify that when I said the log had changed, it did change. And the last sample I posted was essentially from that log. If WF was blocking a critical HostProcess, then wouldn't turning it off disable the blocking? This type of entry has been constant, no matter the setting for WF or W7FC:
7/9/2010|1:48:58 PM|IPv4 TCP 127.0.0.1:55159(56114)|Host Process for Windows Services| Incoming

Since I keep seeing this same localhost entry, I looked at my HOSTS file. And I discovered a couple of statements that must have been added by some software. So, do you think that is what is generating all these identical entries? If so, the servers on the other end are trying every second to connect . . . persistent buggers.

Finally, let's say that at some point I stop running any of these Win7 Gadgets. Should I then reset the W7FC zones you had me change back to their defaults? However, I forgot those defaults.

Thanks for all your help and explanations.

[VistaFirewallControl]

>And the last sample I posted was essentially from that log. If WF was blocking a critical HostProcess, then wouldn't turning it off disable the blocking? This type of entry has been constant, no matter the setting for WF or W7FC:
7/9/2010|1:48:58 PM|IPv4 TCP 127.0.0.1:55159(56114)|Host Process for Windows Services| Incoming

Well… Everything we could invent as the explanation is actually conjectures. We have no information about the gadget internals and we have no information on such WindowsFilteringPlatform (WFP) details either.
Why the gadget requires (regardless of explicitly or implicitly) the incoming to HostProcess is still foggy. Most probably the activity is very indirect and caused by a gadget intermediary/third party.
However WF is just a control panel to WFP. So turning off WF does not turn off WFP. Also senseless to rely that everything modified (by WF in WFP) on WF switching on is cleared on WF switching off.
Most probably WF running/switching state means nothing at all to WFP. WFP is smart enough and able to manage the security rules on its own. We have confirmed cases of such behavior.
For instance on several systems with Windows7 if W7FC tries to set a globally enabling rule (Mode:EnableAll for instance) and WF is switched off, WFP “understands” that all the most dangerous incomings are enabled as well, and sets the corresponding blocking rule on its own. The remedy is switching WF on and enabling the incomings (if required). Looks like it happens not every time on switching Mode:EnableAll on selected systems


>Since I keep seeing this same localhost entry,

The activity may be required only once for probing something. If the probe attempt was blocked everything the rest stopped working. If the probe was passed everything works as expected regardless of whether the blocks were made. Actually it’s the third party application (the gadget + the processing engine) behavior. We are still not sure that the HostProcess|Incoming blocking is the genuine reason. It was just a “hook” we used to mesh with to diagnose the problem. It’s just a visible part of the “iceberg”. There is no documentation for how the gadget processing engine interacts with the entire system including HostProcess, which is actually a stub for multiple different system services.

I looked at my HOSTS file. And I discovered a couple of statements that must have been added by some software.

>Could there be some the gadget related?

>So, do you think that is what is generating all these identical entries?

One of the HostProcess instances. We will hardly be able to know the genuine reason. Actually the Windows “world” is famous of similar depencies.
Do you know any other system whose the first (and the most efficient, the most recommended) remedy to solve any serious problem is reboot.

>If so, the servers on the other end are trying every second to connect . . . persistent buggers.

No,no. The activity is local only. 127.0.0.1 is the local address. And an application from your own system tries to connect to HostProcess with the incomings.
Most probably the application is the same or another instance of HostProcess as well. It’s so called inter process communication.

>Finally, let's say that at some point I stop running any of these Win7 Gadgets. Should I then reset the W7FC zones you had me change back to their defaults? However, I forgot those defaults.

Seems you have already set everything to default/recommended - "Windows Desktop Gadgets" to WebBrowserZone and "HostProcess" to Local+DNS+DHCP+Update(svchost) (re-apply the zone, get the unmodified zone from the repository, just in case)
If you do not need Windows Desktop Gadgets listed in W7FC you can delete it from the list.

[rfinney]

One final question . . . earlier in this thread you had me do the following:

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 Win7 Gadgets will work with this modification on or off. Since it is not needed, should I just delete it?

Thanks very much for all time you took to provide such detailed responses. I love W7FC and the support you provide is first rate!

[VistaFirewallControl]

>The Win7 Gadgets will work with this modification on or off. Since it is not needed, should I just delete it?
The gadget should work without the modification. The initial (mistaken) supposition was the block made by W7FC.
After you provided us with the logs the blocking reason became clear - W7FC was not involved.
So if the blocking reason is beyond W7FC, the corresponding enabling rule is senseless and may be deleted.