Security server timeouts

[jornlux]

We are currently establishing a client environment pilot with View 4.5 on top of vSphere 4.1.

To force security and control upon desktops, we wish to assign all connected clients to a "closed" vlan, with a successful view authentication as the only option to achieving access to local and remote resources.

We boot off desktops with thinstation via pxe, and run View Open Client on top.

Since Connection Server does not support two NICs, we've established a Security Server with one foot in the same vlan as our desktops. Connecting goes fine, we're able to log in and perform a selection among the established desktop pools. However - as the pool selection is made, the view client tries to connect to [the ip of] a given desktop, and just hangs there until it reaches a timeout.

"Use secure tunnel connection to the desktop" has been deselected from connection server configuration, as has been pointed out in misc articles as a fix - but no luck.

[kgsivan]

I do not understant that why do you say View connection server dot not support two nics ?

The security server has to configure with an external URL and DNS should resolve that name appropriately for client ot lauch the desktop.

To know more about View Deployments with security server configuration, refer 5th chapter of View 4.5 Architecture Planning Guide

[npeter]

Hi,

Which protocol are you using. RDP or PCoIP? If it is RDP then enable tunneled connection to desktop.

If it is PCoIP make sure you have routing enabled between client and agent machine subnets.

[jornlux]

Can't recall where I read about connection server not supporting two NICs.  It was either here on the official community or elsewhere.

As our goal is to have a non-routed vlan for desktop connections, security server seems to be a valid solution as it offers a proxy connection to the connection server.

I've read the guide you're referring to earlier, and as far as I can see this theoretically would be a plugnplay deployment. Connections on the inside to the connection server works fine - both routed and non-routed. Why isn't my deployment with a security server working as it should ?

[jornlux]

I've tried both.

But given this is a security server, and we want to use it as a proxy/forwarder - there won't be a direct route between the vdesktops and the clients.

Hence, connections made by a client on the 'outside' would have to cause a second connection between the security server and the vdesktop to pass the traffic through.

[npeter]

Are you using RDP or PCoIP?

PCoIP won't work for your scenario as it is not supported through security server. I don't think setting up a vpn for PCoIP will work as you don't have routing between vlans.

For RDP, it should work for you if tunelled connection is enabled and both connection & security servers  are reachable from agent machine.

Also all these servers should be able to resolve each others FQDN. I have tried such scenarios and it works.

check your connection/security server and agent machine logs for specifc indications.

[jornlux]

Thanks for following me up on this.

The current config is set to RDP with tunneled connection enabled. Still, clients time out when trying to connect to vdesktops.

Got a Wyse zeroclient alongside my thinstations, and connection log shows error containing unsuccessful arp lookups for the ip of the vdesktop. This implicates that the client does not try to create the connection through the security server, and since it's not routed it fails.

Do I have to recompose desktop pools after changing these connection settings in global config ?

[npeter]

Are you using all thin clients? I doubt wyse zeroclient or thin client supports tunneled connection. Please verify the model you use support it.

Have you tried connecting from a View client?

[jornlux]

As of now I have both view clients and the Wyse box connected to the same vlan, giving the same results.

[npeter]

Can you tell me how you enable tunneled connection? Is it possible for you to tr with an evaluation version of View client (not open view client) ?

Also can you please share the debug logs from client and security server? Find log locations  http://kb.vmware.com/kb/1027744

[jornlux]

Had to put this case on hold for a while due to more critical operational matters.

Anyhow - here's an update of the situation:

• secure tunneling via rdp worked fine via Open Client after an external DNS fix. Still no action for the Teradici zeroclients (neither RDP nor PCoIP)
• an update to 4.6 (which supports tunneled PCoIP) solved the zeroclient trouble

Again - thanks for following me up on this.