Black screen [and where did the FAQ go, BTW?]

  • Thread starter Thread starter Lucvdv
  • Start date Start date
L

Lucvdv

I know this must be the number one FAQ, but the FAQ URL I found in a
previous reply no longer works.

I've got two Win2000 servers with a VPN tunnel between them.
I can access network shares and copy files across in both directions,
even though there's only name resolution in one direction (in the
other direction I connect by IP address).

Now I'm trying to connect to TS in remote administration mode through
the same VPN tunnel, using XP's RDP client (this works without any
problem over the LAN). It won't work in either direction.

A connection is established, but the TS window remains black.
After some time a "connection was broken" error follows.

What I tried:

- I verified (by 'ping -l 1472 -f <address>') that the maximum
Ethernet packet size gets through the tunnel unfragmented (1473 bytes
fails, as expected).

- It's not a user profile unload problem: it happens from the first
connection attempt after boot; and I can connect to one of the servers
over the LAN (on the other side there's nothing I could use to test
that).

- The event log doesn't show any TS errors on either side.

- I though it might be a name resolution problem (there is name
resolution through the tunnel in one direction, but not the other), so
I added the other machine to the hosts file for the direction where
there's no name resolution, but that doesn't help either.

- In another message in this group it was said that disabling bitmap
caching in the client helps, so I disabled it: no change.

- I disabled all automatic mapping of drives, printers etc.: no
change.


I'm really at the end of my rope. Does anyone have an idea what I
could try next?
 
A connection is established, but the TS window remains black.
Click to expand...

Could it be a routing issue?

All IP's are fixed.

Side A is 10.13.9.0/24
Side B is 192.168.0.0/24

Multiple tunnels are planned, each will get its own small subnet (of a
subnet of 10.0.0.0): 10.254.254.0/30, --.4/30, --.8/30 etc.

The only one in use now is between A and B, 10.254.254.4/30.

Side B is multihomed (meaning it already was, before the tunnel was
added): it also has an adapter with address 10.1.0.23/24.

Side A has routing to 192.168.0.0/24 through the tunnel, and 0.0.0.0/0
through a firewall at 10.13.9.1.

What I was thinking is: is it possible that connections are always set
up in both directions, and side B tells side A to contact it back at
10.1.0.23?



[anecdotic]
I can't check if it's the situation above right now: it's a bit too
far to hop over to the other side of the tunnel, there's nobody there
to do it for me, and I just made the most stupid mistake in my life.

I connected from side B to side A through the tunnel (just not TS,
everything else works), and to make sure all traffic was routed to me,
I added a static route 0.0.0.0/0 - through the tunnel. Which
immediately collapsed of course, because it was coming through the
default gateway already, and it ain't easy to establish a tunnel
through itself.

In other words: I cut the branch, and the tree started falling upward
until the ground hit me :-{

Lucky that it's only a test setup.
 
Reduce the MTU size on the TS.

--
Cláudio Rodrigues, MVP
Windows 2000/NT Server
Terminal Services

http://www.terminal-services.NET

-> The only Terminal Services Client for DOS.
-> The only customized RDP5.1 client with the close button disabled! :-)
-> Developers of SecureRDP, the BEST security utility for TS!

Do NOT email me directly UNLESS YOU KNOW ME or you are a Microsoft
MVP/Employee.
Use my support page on my website to submit your questions directly.
 
Rob said:
Is the URL below the one you tried? It still works for me.
Click to expand...

Thanks.

It looks the same AFAIR, and here at home it works for me too.


But what I found there is what I expected to find, and I don't
think that's it.
The tunnel is completely open on all ports, and I can ping
unfragmented packets of any size up to 1472 bytes (MTU 1500)
through it. I let ping run with -t -f -l 1472 for a couple of
minutes and had 0% packet loss with a fairly constant 45 to 50
msec delay, but TS just stuck on a black screen immediately
before and after.

Network monitor, running on the client side, shows that there
effectively was traffic going both ways when the RDP client was
trying to connect, but nothing shows up.

In the mean time I also tried with the Win2000 TS client instead
of XP's Remote Desktop client, with the same result.



By the way, there's a minor error in the FAQ, question 37 about
black hole dropouts: the flag for no fragmentation is -f, not -n.

The new url is (the one you gave redirects to it):
http://www.microsoft.com/windows2000/community/centers/terminal/terminal_faq.mspx
 
I let ping run with -t -f -l 1472 for a couple of
minutes and had 0% packet loss with a fairly constant 45 to 50
msec delay, but TS just stuck on a black screen immediately
before and after.
Click to expand...

This morning I repeated the ping test in the other direction, also
with 0% packet loss.

I got it to work, but in one direction only, by disabling local
caching of bitmaps (that was the _only_ change). I had already tried
that in the other direction, and there it didn't work.

But then I lowered the MTU anyway just to try it, and that solved it
for the other direction.

This means that ping can't be used to determine the optimal MTU?
 
Exactly.

--
Cláudio Rodrigues, MVP
Windows 2000/NT Server
Terminal Services

http://www.terminal-services.NET

-> The only Terminal Services Client for DOS.
-> The only customized RDP5.1 client with the close button disabled! :-)
-> Developers of SecureRDP, the BEST security utility for TS!

Do NOT email me directly UNLESS YOU KNOW ME or you are a Microsoft
MVP/Employee.
Use my support page on my website to submit your questions directly.
 
Back
Top