Connection Server ports for load balancing

[casperinmd]

Hello all,

I am trying to troubleshoot a connection server issue with my load balancer. We use haproxy to balance, and it used to work fine but now it isn't. What changed was an upgrade to 4.5. Let me clarify what is not working, the view agent. I can connect to the https://mybroker just fine with the load balancer, and if I point the agent to a broker direct, it works, so it seems like I am missing a port.

I used to just balance 443, do I need to do any other ports? If not, I can further troubleshoot and take some traces, but I want to ensure I have the ports needed covered. I read about 4001 but that I think is just for security server to connection broker comm's.

Thank you

[daemonchild]

The agent? Or do you mean the client?

You should only need to balance 443..

When you upgraded, did you keep the certificates for your connection servers the same?

VCP, VCI, MBCS CITP

http://www.daemonchild.com - VMware Geekiness

[casperinmd]

OOps, yes sorry, I meant the View Client fails. It states: The View Conneciton Server connection failed. Network error. Contact your network administrator

I thought maybe it was a cert issue based on this: http://communities.vmware.com/thread/290473

But I am still using the self signed certs, I did not generate new ones after the upgrade. There will be a cert error though b/c my load balanced name does not match the connection servers self signed name, is that the issue?

[casperinmd]

One more note, a WYSE Thin O/S device setup for the connection broker fails when connecting to the load balancer too, so not just a Windows 7 issue which is where my View Client is running. XP gives a different error, it fails and states: The View Connection Server authentication failed. You are not authenticated to perform this operation.

[casperinmd]

Hi, me again

Ok, So i went dabbling around the cert thoughts and found in my old documentation I had I noticed under the Connection Server settings, my old settings did not have "Use Secure connection to desktop" enabled, so I disabled that and restarted the services, now my WYSE Thin O/S works and now my Win XP, but my Win 7 View Client still fail. I believe I am falling into that "bug" that was mentioned in the other article, except I am using self signed certs.

[Bill_Fleury]

Hi Casper,

I realize this post is quite old- but I'm wondering if you ever found a resolution to this issue?  I'm experiencing the same problem connecting to our connection servers through our Cisco ACE 4710 load balancer.

Any light you may be able to shed would be fantastic!

Thanks!

[casperinmd]

Bill...man you are pushing me way back!

IIRC, ths specific issue was with view 4.6, where there was a bug in View/Windows 7 that was quite deep. I sent some VM's with the client to VMware and tey worked with Microsoft on the issue for a few months before finding the issue. I never was told of the fix but that it would be fixed in View 5.

I worked fine after that, and XP always worked. Are you on View 5 or higher?

[Bill_Fleury]

Hi Casper,

Thanks for the response!  We are on View 5.1, but our symptoms are identical to what you were experiencing.

Sounds like I'll be opening a support case for it!  If we get a resolution I'll post what was found for other Googlers.

[casperinmd]

In my case, a packet capture on the client was showing problems with the SSL connection, see if that is similar for you. That is definitely where my problem was.

[Bill_Fleury]

Thanks! We are using http between our load balancer and our connection servers, which is supposed to be supported, but perhaps we should try enabling SSL. Sounds like a reasonable thing to try!

[DrDobsG]

I am seeing the same problem with our newley installed 5.2 conneciton servers.  Also a load balanced between two connection servers..  Did you ever find a good solution to this?  Is there a recommended load balancer configuration?

[Bill_Fleury]

We have resolved this particular problem, and now have another problem which appears to be related to session stickiness settings that we haven't fixed yet.

The resolution to this problem for us was that our load balancer was presenting the certificates to the client in an out-of-order fashion- rather than presenting in the order of the certificate chain, they were swapped around.  In the cisco gui the load balancer admin was using (sorry, I'm not a cisco guy, don't know much about that gui)  it showed them in the correct order, however when he logged in with the CLI it showed out of order.  So we removed the certificates from the load balancer, and reimported in the right order.

Apparently Windows clients are smart enough to reorder into a valid chain of authority, but the P25 is not.