Link to home
Start Free TrialLog in
Avatar of Posthumous
PosthumousFlag for Canada

asked on

RD Session Broker + NLB doesn't work for external users internal users on network are OK

I have a strange little nagging issue that I hope you all can help with.

TS1 - Guest VM on Hyper V (Server 1 hardware) Server 2008 R2
TS2 - Guest VM on Hyper V (Server 2 hardware) Server 2008 R2
TSsec - Guest Vm on Hyper V (Server 1 hardware) Server 2008 R2

TSsec contains the security and Broker components.
TSFARM - both TS1 and TS2 are farm members

If connecting from outside the network:

User attempts to login, when he connects TS2 recieves the request and redirects it to the broker who directs it to TS1 and its fails, time out listed in the Session broker event logs.


If TS1 has a user on it, the TS2 directs to broker, who directs it back to him and he logs in fine.
If TS1 is offline, once the broker recognizes this fact it directs the session to TS2 and log fine.
Bring TS1 back online, once the broker recognizes this fact it directs the new session to TS1 and logs on fine.
However IF the broker directs the user to login to TS2 while TS1 is online and has more sessions then TS2 it sends the user to TS2 but nothing ever happens.  The RDP client just fails out and there's no information logged in events on TS2 or the broker or any of the other sub event logs dealing with Terminal Services on either server.
The broker even still thinks the connection was made if you try to reconnect it gives you the line about a disconnected session and sends the user right back into the blackhole of TS2 that goes.. nowhere.

Still in testing phases here obviously so during working hours i can direct the test users onto Ts1 and just turn off Ts2 however that won't help me much down the road!

Ive got the following DNS records setup:
TSFARM 192.168.2.2 (Broker's IP address)
TS1 192.168.2.3
TS2 192.168.2.4

resolution of DNS looks fine and if I do an internal connect frpm the LAN to TSFARM it seems to alternate them back and forth fine. 3 users connect to two different servers with no problems.

I am testing this current issue from a machine outside the LAN being routed through a Cisco firewall, but again it connects those server TS1 connections no problem, its only when it tries to load balance off to the 2nd server that it gets confused and the connection dies.

On the LAN side if I try to connect the TS1 troubled user directly to TS1 using RDP, no problem.
Same premise but use TS2 troubled user direct and we get:

The Terminal Server farm Ts2 that you are trying to connect to is redirecting you to the server ts1.domain.com.  Remote desktop cannot verify that this server belongs to the server farm. This can occur if there is a server on your network with the same name as the server farm.

I've checked DNS twice and can't see any duplication of TSFARM TS1 or TS2 on forward or reverse lookups.

Under Active directory there is no Computer object for TSFARM however there's only 1 TS1 TS2 and TSsec.




Hopefully the wall of text isn't overwhelming and I'll provide all details I can about the setup if there are any questions.
Any help would greatly be appreciated!

Thanks,
Post

Edit 19052011
Ive tested this system now exclusively from the local environment to the servers.
Inside the LAN it works fabulously, I had 6 different user id's connecting and balanced across the two servers with no errors and no complaints.

Now from what i can track TS2 is properly redirecting service requests to the session broker, however i noticed in all the redirector requests are coming exclusively from the TS2 server to the Session broker, none are coming from TS1 .. not sure if that's intended or not but seems a bit strange that no requests are going to TS1 to be redirected.

My suspicions are all over the place at the moment, when it comes to the WAN connections failing I was thinking it might have something to do with security.

If a Packet from the NAT is forwarded to TS2, then the request is forwarded to the broker who forwards the request to TS1, perhaps the packet identifiers arnt matching up when they get back to the machine on the outside of the Router and thus why the connection never proceeds.

Still stuck I guess, but hopefully its narrowing down the problem.
Post

Avatar of lamaslany
lamaslany
Flag of United Kingdom of Great Britain and Northern Ireland image

You don't state it but would I be correct in assuming that the NLB you refer to is Windows NLB?  If so how is it configured?  Unicast or multicast?

Is the Connection Broker configured to redirect using tokens or by IP address?  Which IP address(es) are configured to be used for redirection?


At this point I would suspect that your connection broker is returning an internal IP address to an external client.  As the external client cannot route the traffic to the internal IP address it fails.  
Avatar of Posthumous

ASKER

Its set to unicast for windows nlb.
Using IP redirection not token.first address in list (local ip).

I believe your assessment is correct however I am not sure how to solve.  Is it something adjusted at the router to properly address the responses from the server or is it something changed in the server side?
ASKER CERTIFIED SOLUTION
Avatar of lamaslany
lamaslany
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Router is a Cisco 2800 Series with enterprise security package on it.
I have the ability to change/adjust without needing another segment thankfully so if something needs to be changed it can be.  I'd prefer not to have the Session Host servers internet facing if at all possible so if there's a way to make sure that traffic is being routed properly that would be prefered.

The outside connection is initiating properly, my suspicion (if this is the problem) is that the original request is being routed to the session broker by the Cisco router on ip 192.168.2.2 however the response to the request is being sent by either TS1 or TS2 on .3 or .4 ip.  Since the original addressing doesn't match the outgoing packets this is causing the connection to fail at the routing point specifically with the session broker reroutes the request from the original recieving server to the alternate.  

example:
Session across wan to RDP 3389 to Internet facing IP address .164.
Cisco Forward request on 3389 to internal address 192.168.2.2 (Session broker/Cluster address)
Cluster address directs to available Terminal Server (TS2) 192.168.2.3, server verifies balancing with the session host at 192.168.2.2 who then forward to (TS1) as the primary available terminal server.
TS1 routes response back to Router...
Router fails to match outgoing 3389 session to originally directed Ip address of TS2, and block packet.

That's my guess, how that gets fixed is a whole new story.

As for RDG server, I do have it installed on the Session host server, i did that his afternoon trying to find a solution to the issue.  However I'm unfamiliar with the certificate process and backed away to do some extra research.  Specifically if we purchase a global cert, will the RDP users outside the local LAN need to have it manually installed on the local machine or will the server provide it on request?  Obviously If we need to manually install the certificate on all remote users, that will increase our roll out timeline and will need to be scheduled properly.


Any thoughts on how to repair the forwarding through the router?

Perhaps this needs to be moved to the cisco routing forum since it seems more likely a routing issue?

Looks like the right way to do this in 2008 R2 is with the RDG server, which just makes me even more confused but I'll trundle through.
If you can spare an couple answers regarding RDG?

1) Does the RDG need to have an internet facing IP or can it be NAT'd
2) When forwarding RDP requests are they forwarded to the Session Host Cluster Ip, the RDG or to a TSH?
3) In RDG certification, if you can use a local IP as the RDG, how do you setup the 3rd party certificate or can you? For 3rd party certification does the server need to have an internet facing IP.

Thanks,
Post
1.  It can use NAT; yes.  So long as the RDG can route to the LAN IP of the RDSH servers you should be fine.
2.  It should be forwarded to the RDSH Cluster IP but as mentioned the RDG should also be able to resolve and route to each RDSH.  
3.  Use of a trusted third-party certificate is supported regardless of whether it uses a public or private IP address.  If I recall I created the CSR using IIS, submitted it to the 3rd-party Cert Authority and then imported the cert using IIS again.

Well Perhaps I was wrong to accept this answer right off the bat, was a bit of an assumption.
Sadly even with a working internal RDG server (internal LAN connectors using the RDG and get onto the server correctly even with disabling the bypass local address requiremetns)
However i have the exact same issue from the outside world to the inside.

Looks like they authenticate to the server fine, get passed off to the session broker who directs it to say TS1 when it was originally directed to TS2 by the router and boom, same hang, same eventual error and same result.

:(
Avatar of jziolek
jziolek

Was this issue resolved... I have the same issue.
We split the Remote Desktop Gateway and Remote Desktop Connection Broker to run from different servers, which resolved our issue. Previously they ran on the same server, which resulted in issue described above.

Simon, Knowall IT