vistafirewallcontrol.freeforums.org

[Alex]

This one took a bit of tracking down. I've managed to get it working, after a lot of tinkering, but I'd like to know what went wrong, if possible.

I've installed copSSH [itefix.no] on my Windows 7 Ultimate machine. TCPView [sysinternals.com] shows that sshd.exe is listening on port 22 on all interfaces; it is not bound to a specific interface. I can use PuTTY to connect to 127.0.0.1 successfully, but I cannot connect from other machines on my network (including Linux and OS X).

If I use nmap to scan my Windows machine from either my Linux or Mac computer, it triggers the WFC popup alert. If I choose "EnableAll" (for testing; eventually I'll put a more restrictive rule in place) then "EnableAll" appears in the Zone column next to sshd.exe, but nmap still reports port 22 as filtered instead of open.

Here's how I got it working: I configured a rule in wf.msc, allowing inbound connections to %ProgramFiles%\ICW\bin\sshd.exe on port 22. After I made that change, I could then connect via SSH to my Windows 7 machine.

So here's my question: why did I have to delve into Windows Firewall with Advanced Security to get this to work? I thought that WFC was meant to eliminate the need for fiddling with the Windows Firewall directly. Whenever I've previously chosen to apply permissions in WFC they've worked without any further changes. Why did WFC not work completely this time?

Is this a problem with WFC? Is this a problem with how I'm using WFC? Am I doing something wrong?

[VistaFirewallControl]

You have found the best solution and it’s not a problem of W7FC.
SSHD was actually blocked at WindowsFirewall (WF) “level”.
Most probably you would be able to find the solution checking W7FC blocking events notifications. W7FC should display something like
IPv4 TCP:…..:..(22) sshd WindowsFirewall: Disabling-rule-name-from-WF Incoming,
So the WF mentioning could help with finding the solution sooner.
“Disabling-rule-name-from-WF” could point you to the problem precisely.

The behavior background is the following.
Imagine you have several firewall in chain. Evidently to allow an activity, the activity must be allowed by all the firewalls. If a firewall from the chain blocks the activity, the activity will not reach the application. So a single firewall in the chain is able to make the final verdict of the activity rejection.
So regardless W7FC enables the activity, the activity can be (and was) blocked by WF.

Why you did not face the problem before.
Most probably that is the first _incoming_ activity you have met.
WF is (by default) very tolerant to outgoing connections, all the tricks are mostly done to incoming ones. WF also is smart enough and policy dependent, for instance, the default policy supposes blocking any incoming that is not _explicitly_ enabled.
That’s why an incoming traffic to a non-listed (in WF) application is blocked (by WF), and you have to explicitly specify/list the application to pass WF with the incoming request.

Localhost (127.0.0.1) was just beyond WF scope. W7FC is interface insensitive (with the current version) at all.
So localhost connections were always successful.

If you need any other explanations, please do not hesitate

[brainscott]

Are you comfortable with Linux/Unix and want SSH access to your Windows 7 machine? Cygwin provides this functionality and gives you a familiar environment to work with in a few simple steps.

[VistaFirewallControl]

Access to SSH server running on Windows side can be permitted with W7FC as the access to any other application/service