Win XP SP2 alternate localhost broken
Dicky Stafford
Has anyone experienced this? Or even better, got a fix?
Right up until RC2 of Win XP SP2 I was able to use PuTTY to forward
127.0.0.1:2222 to remoteip1:2222 and 127.0.0.2:2222 to remoteip2:2222 etc.
(This feature arrived in PuTTY somewhere between 0.53b and 0.54 - see
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/portfwd-loopback-choice.html)
Now I'm trying out the RTM SP2 it seems that all traffic to the alternate
loopback addresses simply goes nowhere.
Cheers,
Dicky
Richard E. Silverman
Perhaps there is now a local firewall in place dropping the traffic, as
part of SP2's big security emphasis? Not sure what the point of blocking
loopback connections would be, but still...
--
Richard Silverman
r...@qoxp.net
Dicky Stafford
Thanks for your rpely. Yeah, that was my first port of call. Sadly it
makes no difference whether the firewall is turned on or off, although you
can only choose to have the firewall active on specified interfaces of which
the localhost 'adapter' is not one.
Do you, or anyone else, know of any other SSH client that can perform
similar forwarding? I don't think for a minute that PuTTY is broken but it
would be nice to eliminate it from my enquiries.
Cheers,
Dicky
"Richard E. Silverman" <r...@qoxp.net> wrote in message
news:m2llgnu...@darwin.oankali.net...
ch...@bluestream.org
This is killing my software packages also. Anyone have any
information about this yet?
Thx
Chad Amberg
www.wissh.com
Owen Dunn
> This is killing my software packages also. Anyone have any
> information about this yet?
We (the PuTTY team) have had a few messages about this. One
correspondent suggested that the problem didn't occur with any of the
betas of SP2, but only with the final released version.
Beyond that, not a lot. None of us has a copy of Windows XP or a
computer to run it on, so we can't do much first-hand diagnostic work.
(S)
Nic Sarginson
we tend to use 127.0.0.2 for our tunneled connections, especially on
XP where you can't RDP to 127.0.0.1.
What I've seen the last two days is on a box that has been running
fine and was then upgraded I cannot talk to 127.0.0.2 at all, even
though it will respond to a ping.
On a fresh XP pc immediately upgraded to SP2 I can't connect to
127.0.0.2 using embedded apps such as the Mindterm SSH Java client but
can connect using a locally installed client such as putty.
Like the previous poster said having the firewall disabled or enable
makes no difference. I did think it was a IE security setting but
doesn't seem to be.
Not sure if that is any help but at least its nice to know its not
just me (our support department insist it all works ok).
Cheers
Nic
Owen Dunn <ow...@chiark.greenend.org.uk> wrote in message news:<83pt5yk...@chiark.greenend.org.uk>...
Andre Broers
try this, it worked for me...
http://ccfaq.valar.co.uk/modules.php?name=News&file=article&sid=230
Cya
Jacob Nevins
>We are having the same problem here, I work for a SSL VPN vendor and
>we tend to use 127.0.0.2 for our tunneled connections, especially on
>XP where you can't RDP to 127.0.0.1.
Right, so it's not just PuTTY that's broken as a listener by this.
>What I've seen the last two days is on a box that has been running
>fine and was then upgraded I cannot talk to 127.0.0.2 at all, even
>though it will respond to a ping.
You can't connect to 127.0.0.2 even with PuTTY on this non-"fresh"
box? Is the configuration otherwise the same (firewall, etc) as the
box you mention below?
>On a fresh XP pc immediately upgraded to SP2 I can't connect to
>127.0.0.2 using embedded apps such as the Mindterm SSH Java client but
>can connect using a locally installed client such as putty.
Ooh, how intriguing. Can you definitely get data through when
successfully connected?
Can anyone who's using PuTTY to create a listening tunnel on 127.0.0.2
also successfully connect to that listening port with another PuTTY
and get data through? (Does it make a difference whether it was
"freshly installed"?)
ch...@bluestream.org
From my testing that is what I've seen also. The betas and release
candidates are fine, but the RTM is not.
If you have any thing you would like to check out or test, I'll be
happy to assist. I use PuTTY tunneling all the time for this feature
also.
Some other information:
The routing table is exactly the same.
Pings to 127.0.0.2 come back from 127.0.0.1, but it has done that on
all XP versions. Win2k and prior work correctly.
Software can still bind successfully to the ports on 127.0.0.2 with no
errors. Netstat shows them listening:
TCP 127.0.0.2:25 0.0.0.0:0 LISTENING
TCP 127.0.0.2:143 0.0.0.0:0 LISTENING
but nothing can ever reach them from the client, everything will just
time out.
Even while a "net view \\127.0.0.2" will work fine on non SP2 systems,
it times out on SP2.
Hope this helps some...
Chad
Owen Dunn
> Nic Sarginson <ni...@sarginson.com> writes:
> >We are having the same problem here, I work for a SSL VPN vendor and
> >we tend to use 127.0.0.2 for our tunneled connections, especially on
> >XP where you can't RDP to 127.0.0.1.
>
> Right, so it's not just PuTTY that's broken as a listener by this.
A bit of googling reveals this, which might be relevant:
(S)
ch...@bluestream.org
True, but if you are hitting a real terminal server, running in
compatability mode won't work, because you can't get your licensing
information inserted into the registry. So the best answer is to bind
to 127.0.0.2
Chad
ch...@bluestream.org
"Good" news in that MS is releasing a fix. See:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=ONu5EZogEHA.384%40TK2MSFTNGP10.phx.gbl
Dicky Stafford
Indeed, good news! I've applied the updated 'tcpip.sys' (KB884020) and this
resolves the problem. All my existing PuTTY configurations can stay the
same as they were prior to SP2 RTM.
Cheers,
Dicky
Richard E. Silverman
> Wrong directory after chdir
Find this message in authfd.c -- it's from the code that tries to check
the sanity/security of the agent socket. It does some very convoluted
stuff to assure that the socket is genuine; perhaps some of that weirdness
is incompatible with HPUX somehow...
--
Richard Silverman
r...@qoxp.net
Jacob Nevins
>Indeed, good news! I've applied the updated 'tcpip.sys' (KB884020) and this
>resolves the problem. All my existing PuTTY configurations can stay the
>same as they were prior to SP2 RTM.
For reference, this KB article is now available from MS' web site.
<http://support.microsoft.com/default.aspx?scid=kb;en-us;884020>
It suggests that this fix will be rolled into the next service pack.
Dicky Stafford
should be due sometime late 2006. ;)
"Jacob Nevins" <jac...@chiark.greenend.org.uk> wrote in message
news:lSf*G1...@news.chiark.greenend.org.uk...
Jacob Nevins
>"Jacob Nevins" <jac...@chiark.greenend.org.uk> wrote in message
>news:lSf*G1...@news.chiark.greenend.org.uk...
>> <http://support.microsoft.com/default.aspx?scid=kb;en-us;884020>
>> It suggests that this fix will be rolled into the next service pack.
>
>should be due sometime late 2006. ;)
Well, yes.
Out of interest, what's involved in J. Random getting this hotfix out of
Microsoft? Do you have to have an MS Passport? (I'm not likely to need
it, but it might be useful to be able to tell our users, since we've
received a number of queries.)
Jacob Nevins
>True, but if you are hitting a real terminal server, running in
>compatability mode won't work, because you can't get your licensing
>information inserted into the registry. So the best answer is to bind
>to 127.0.0.2
We've had one user report that this circumlocution is no longer
necessary for Remote Desktop - he said that with SP2 applied, you can
happily set PuTTY up to bind to 127.0.0.1, connect to 127.0.0.1 with
RDP, and it will Just Work.
He referenced the following KB article:
<http://support.microsoft.com/default.aspx?kbid=817293>
Can people confirm this? If so I'll put it in our FAQ.
Dicky Stafford
Yes, this definitely is the case. So the options are...
Standard localhost 127.0.0.1, alternate localhost 127.0.0.0/8 except
127.0.0.1.
XP RTM, SP1, any SP2 beta, in fact anything prior to SP2 RTM.
To connect to standard localhost. Create a shortcut to
'%SystemRoot%\systems32\mstsc.exe'. Edit the properties of this shortcut
and choose 'Run this program in compatibility mode for Win 2000' (on the
'compatibility' tab).
Or just forward ports on alternate localhost addresses. Source
'127.1.2.3:3389', destination '127.0.0.1:3389'. Don't be put off by the
PuTTY interface: the 'source' field, despite being only a third of the size
of the 'destination' field, accepts this input.
XP SP2 RTM
Connect to standard localhost works with 'mstsc.exe' build 5.1.2600.2180 and
beyond.
Connect to any other localhost address times out.
XP SP2 RTM + KB844020
Use the unmodified 'mstsc.exe' client to connect to any localhost address.
I think this is the complete story, hope this helps,
Cheers,
Dicky
"Jacob Nevins" <jac...@chiark.greenend.org.uk> wrote in message
news:X5d*Z+...@news.chiark.greenend.org.uk...
Dicky Stafford
once the standard regression testing procedures have been completed. In the
meantime, anyone can get the hotfix emailed to them FOC by contacting MS
support. Nothing is required save for a telephone to make the request and
an email address to which the file will be sent. Mr Random is entitled to
log two incidents every six months before getting into paid-for support.
"Jacob Nevins" <jac...@chiark.greenend.org.uk> wrote in message
news:1Ay*kT...@news.chiark.greenend.org.uk...