View client can only make a connection in certain locations for users

[JoeLSN]

I setup some view desktops for remote users that work at various client sites so they always have a desktop on our network. I have view using external url using port 80 and secure connection to the desktop checked. The view connection server, vcenter and virtual desktops all reside in our data center. I am just using a connection server with the RDP protocol.

I can connect fine to view sessions from my location (not at data center) as well as at home.

They can connect from their office which is on a domain, but not from another office that is on a different domain.

In the field they can connect from some clients and not from others. (They can connect from some clients that are on a domain and not from others that are on a domain)

They can not connect from our ISP's free wifi either.

When they can't connect, they get up to where you enter your username and password. Once they enter in their credentials they get hung on establishing a secure connection. After 5 or 10 mins it times out and gives up.

When i look at the firewall i see them obviously make the connection and it shows accepted.

Any ideas on this?

[Glenn77]

Where you have machines in same location and one works and one doesn't see what is running (firewall, anti-malware) on the one that doesn't.  When it works from your home I assume you are not using a VPN; as long as you're not using a VPN we can say that the config at the datacenter is OK.  So it has to be something between the datacenter and the client that is blocking some required traffic.  Are you sure they are not trying to use PCOIP which requires some extra ports ?

Good luck - wish I could be more specific.

[mittim12]

Are they all connecting back to the same pool or di we have multiple pools involved.   Just for verification I have included a list of ports that VMware View uses.   This list is from 4.5 but should suffice since you aren't using 4.6 and PCOIP for remote access.

http://kb.vmware.com/kb/1027217

[JoeLSN]

For the most part they are using a laptop that works in some locations and then doesn't in others. I don't believe it to be the machines, I am thinking maybe it is the firewalls of the clients that they are blocking something.

But since I am only using port 80 and using the secure connection i would think i would have to worry the least about different ports being blocked... 

[JoeLSN]

Yes they are all connecting to same pool i connect to. The vcenter server and connection server and DC are all on same subnet with no firewalls between them, so i don't have to worry about back end firewall rules. 

[Glenn77]

I agree it sounds like your backend rules are fine.  Is there a location where LaptopA works but LaptopB doesn't ?  Or is it a case of LaptopA works at location1 but not at location2?  If the former look at LaptopB, if the latter look at the firewall at location2.  If the firewall is outside your control at location 2 (eg it is at a client site) then you can at least try to find out if they have an application aware firewall and if so open a dialog with their firewall folks to see if they will be so gracious as to unblock the view traffic (whatever application the firewall sees it as) or at least confirm that their firewall is blocking your traffic.

[mittim12]

I've seem some issues in our environment where the client was using a proxy server.   Any proxy servers being used at some of these environments where the user can not connect?   

[JoeLSN]

I just asked, no proxy server, I am thinking it has to be something with their firewalls.

We have one location, uses same isp, but 2 different firewalls for 2 seperate subnets (same manufacturer)  it works on one subnet but not the other. Waiting for admin to get back so i can see if something might be different between two of them.

[markbenson]

Is the hostname in the "External URL" resolvable by the clients in all locations? Is there a load balancer?

The View Client logs should tell you what's wrong.

What is failing is the second HTTPS connection - this is the secure tunnel connection which is made after the user authenticates. It is made to the configured "External URL" for the Connection Server (or Security Server if you have one.

Mark.

[JoeLSN]

There is no load balancer, and external clients can resolve the external url.

This is what i am getting in the log file on the client that can not connect.

10:05:44,375 INFO  <Main Thread> [wswc] Windows Client started
10:05:50,890 INFO  <MessageFrameWorkDispatch> [wswc_tunnel] Data frame policy set to NEGOTIATE (proposing 0 bytes)
10:05:50,890 INFO  <MessageFrameWorkDispatch> [wswc_tunnel] Received chunk window set to 2
10:06:17,953 ERROR <TunnelRead> [MessageFrameWork] Socket: Socket::recv: read nothing
10:06:17,953 INFO  <TunnelRead> [wswc_tunnel] Tunnel Unnamed: Could not start server view.ourdomain.com, reason: Socket: Socket::recv: read nothing
10:06:17,984 ERROR <MessageFrameWorkDispatch> [wswc_ui] Unable to start the tunnel. Error message displayed was 'The View Connection Server authentication failed. Initialization failed while connecting to server 'http://view.ourdomain.com:80'.', proxy used to connect was '(null)', connection server was 'http://view.ourdomain.com:80'.

And this is what i get from mine that does connect fine

10:04:54,854 INFO  <Main Thread> [wswc] Windows Client started
10:05:02,436 INFO  <MessageFrameWorkDispatch> [wswc_tunnel] Data frame policy set to NEGOTIATE (proposing 0 bytes)
10:05:02,436 INFO  <MessageFrameWorkDispatch> [wswc_tunnel] Received chunk window set to 2
10:05:02,482 INFO  <TunnelRead> [wswc_tunnel] Tunnel Unnamed: connected to server 'view.ourdomain.com', start tunnel protocol
10:05:02,498 INFO  <TunnelRead> [wswc_tunnel] Tunnel Unnamed authenticated Ok, set state = running
10:05:04,027 INFO  <DesktopWindow> [wswc_rdp] RDP control version = 6.1.7601
10:05:04,901 INFO  <DesktopWindow> [wswc_ui] Connecting client to agent via socket channel

[cmartin24]

Just wanted to add to this...I've been fighting an issue with similar errors other users have posted in the View logs.

Our environment is  Client>Lan>Firewall>View Security>Firewall>Lan>Connection Manager.

User   "A" was able to connect to the external View Portal and authenticate   successfully. The entitled desktops would display however the "Status"   displayed "Not Connected". So the tunnel never appeared to be building   correctly.

The users machine had multiple NIC's. Once I adjusted the provider order so that the active nic was at the top of the list - whala!..I was able to connect successfully. So - if you have multiple NIC's on your client machine. Check the provider order.

Hope this helps someone.