Port Forwarding: Can't connect to any 127.0.0.X forwarded IPs

[Daemon]

On our corporate network, the only way to reach certain production
machines is through SSH tunnels via an intermediary box.
The company has supplied us with entunnel and accounts on that
intermediary unix server, and this setup appears to work for everyone but
me. The standard configuration is to map several local IPs and the
standard https ports
ala.. 127.0.0.9 443 to point to remote production machine on same port.
Then we set up a list of hostnames in hosts file to point at each
respective 127.0.0.X IP.
So for instance..
127.0.0.9 443 points to someprodbox.ourdomain.com 443
and there's a local hosts entry for
someprodbox.ourdomain.com mapped to 127.0.0.9
Again, all this works for everyone but me. Our own desktop support
folks are mystified.

I happen to also have SecureCRT 5 so I've tried all this with both entunnel
and SecureCRT with the same results. A netstat -na shows that several
127.0.0.x addresses and ports are bound properly when the SSH
connection is first established, but no application
(IE, Firefox, telnet, putty, SecureCRT itself in telnet mode).. can connect
to any of the local IPs or ports. Telnet reports:
"Connecting To 127.0.0.9...Could not open connection to the host, on port 80: Connect failed."
The console in entunnel shows that the initial SSH connection has been
established but it shows nothing when I try to connect to the
local forwarded IP/port. SecureCRT has no console, but the
symptoms are the same.

This is on my work laptop running XP Pro, with windows firewall turned off.
If I turn firewall on and logging on and try to connect to local IPs, and
ports, the firewall sees nothing, as though the connection attempt
was never even made. The laptop has no other firewalls installed
and no group polices.

In desperation I tried mapping a local IP/port the same way
on a different XP Pro machine (home computer) and it works normally
(but that box has no access to work network so is of no use to me).

Has anyone experienced same or similar behavior and know what
the cause it? It feels like the OS is simply preventing connections
from being established to localhost IP other than 127.0.0.1. Only thing that
springs to mind with the laptop is that it has 3 NICs.. wired, wireless
and some virtual bluetooth thing, and I'm wondering if that's somehow
confused it with regard to those local mapped 127.0.0.X (where X is not 1)
IPs.

Any help would be appreciated.

BTW, I'd test to see if this works with any other SSH apps with port forwarding
but Entunnel and SecureCRT are the only ones I know of that allow binding to an
alternate local IP in addition to the port. Because we have to access over a dozen
different remote machines all on the same port, the ability to use 127.0.0.X binding
is critical.

ian

[mekanik]

Originally Posted by Daemon

On our corporate network, the only way to reach certain production
machines is through SSH tunnels via an intermediary box....
[--removed--]
Any help would be appreciated.

BTW, I'd test to see if this works with any other SSH apps with port forwarding
but Entunnel and SecureCRT are the only ones I know of that allow binding to an
alternate local IP in addition to the port. Because we have to access over a dozen
different remote machines all on the same port, the ability to use 127.0.0.X binding
is critical.

ian

hi ian,

i use winXP-sp2 and port-forward all day long with SecureCRT using 127.0.0.127 as my loopback address of choice. i've have SSH forwarded through SSH, HTTP through SSH, HTTPS through SSH, MySQL through SSH, telnet through SSH, etc, etc, etc...and have no problems whatsoever...

review the following Entunnel FAQ 10 along with the MSKB 884020 and the Release Notes for WinXP SP2 at MSKB 835935 as these may assist in your problems.

/mekanik/

[Daemon]

Thanks. The fix in 884020 resolved the problem.
I actually had looked at the entunnel FAQ but missed that item for
some unknown reason.

Both computers have XP SP2 (which caused the problem), but it looks like
the one that was working had security update 893066 which fixes the
same thing 884020 does.

ian