TS Clients can't connect to load balancer IP address

  • Thread starter Thread starter Michael Traylor
  • Start date Start date
M

Michael Traylor

We have 2 domains. One domain for the LAN with the
application we expose to our clients via terminal services
and one internal LAN. The client's domain has 2 terminal
servers (W2K Advanced Server) load balanced. Our external
clients terminal serve to the load balancing IP address.
Up until yesterday our internal LAN workstations terminal
served to the load balancer IP address also. One of the
Terminal Servers raised an error about the registry size
needing to be increased and disconnected all active TS
sessions from that machine. We increased the registry
size and rebooted. Now our internal workstations can't
terminal serve to the load balancing address, but can
terminal serve to either of the Terminal Servers
directly. Any ideas? Thanks.
 
How did you load balance these two terminal servers?
Could the load balancer not be working correctly dur to
the reboot yesterday?

-M
 
That's a good question. I just assumed it is working
correctly as our external clients can still term serve
into the load balancer's IP address. All machines in the
same domain as the terminal servers can do it, too. Only
the machines in our internal domain can't do it.
 
Hmm...so can those internal domain clients ping the load
balancer address, as well as both internal IP addresses of
the terminal servers?

Have you tried a packet trace to see where those packets
are getting stuck when you try to terminal server to the
load balanced ip address?

-M
 
Yes, they can ping the load balancer. We only have one
hop through a router between the domains and we are
99.99999% sure that nothing has changed on the router. It
does appear to be a routing problem, but where? Each
workstation has a route to the load balancer's network
added manually with route add.
 
I dunno...this is pretty weird.

Just so I know, does the load balancer have an address
like 192.168.0.1, and when someone hits that address, it
just routes the connection to one of the two terminal
servers? My only thought here is that somehow the router
is confused on its internal network card (or network IP)
that is causing it to not route the packets correctly.

Will that load balancer also load balance other packets to
different ports other than RDP (3389)? It would be nice
if you could run some diagnostic tests using ping (among
other utilities) just to see where those packets are going.

-M
 
Yep, that is the way it works for everybody in our world,
but us. Did for us up to last Thursday. The only time we
use the LB IP is for Terminal Services and I am not sure
how to test it for other types of traffic other than ping
ICMP packets which it handles just fine. tracert and
pathping show the packets going directly to the router and
then directly to the NLB address. Two hops max. It's
like there is an access list on the rooter blocking RDP or
something, but there's not. Hey, I apreciate your
thoughts on this and am open to more. We are getting by
by bypassing the NLB and going directly to the TS's. It
is a mystery. Machine over man, I guess.
 
Machine over man huh? Well, enter the Matrix my friend...

Let's try to simulate an RDP packet. Try doing a telnet
to port 3389 (telnet <ip_address> 3389) and see if the
load balancer will load balance that request. Try doing
it multiple times to make sure that the LB is throwing the
connection to both TS equally. What happens?

So when you did the ping test, was the ping routed to one
server, and then the other, and so on?

-M
 
Arg...I made a really good reply to this earlier today but
it appears to have been lost in the ether...well, here I
go again...

Machine over man huh? Well, follow the white rabbit...

Let's try to simulate an RDP packet then...try telnetting
to port 3389 on the load balancer and see what happens:

Telnet <load_balanced_TS_IP_address> 3389

This command will telnet to port 3389 of the load balanced
IP address. Will the load balancer send you to a
different terminal each time when you do this? You might
need to run a netstat -an on the terminal server to verify
this, but I just want to make sure that a packet destined
for port 3389 is making it successfully.

When you ran a ping to the load balanced IP address, did
you get replies from both terminal servers? What I mean
is that if the LB address was 192.168.0.1 and the terminal
servers were at 192.168.0.2 and .3, did you get back
replies from 192.168.0.2 and .3 when you pinged .1?

-M
 
Pinging the LB IP returns the LB IP address.
Telnet to either of the TS's opens a session (which in TS
Manager has csrss.exe and winlogon.exe associated with
it). The telnet window times out after 60 seconds and
closes the connection.
Telnet to the LB IP also opens a session on a TS (also
visible in TS Manager with the message that "This session
is not active. There is no information to display.").
The telnet window instantly returns a message that
the "Connection to host lost." I tried this 3 times and
was sent to the same TS each time (this happens to be the
TS with least load, so I am not sure what it means).
When I telnet to the LB IP, netstat reports a 3389 session
with the LB IP from my machines IP is "Established".
After 60 seconds, netstat shows that session is gone.
I am definitely taking the blue pill, when offered......
 
Back
Top