Does vWorkspace support use of (outbound) proxys for client connections?

Looks like I will be the first (and probably only reply)

I have continuted to investigate, and it is starting to look like the "unhelpful option" of sending the users out to an Internet cafe as a solution, well until the provider changes their virtual environment (we don't have this issue with any of the competitor products).

Localised proxy settings can be configured as part of the pit file, however as the pit files are delivered on the fly from the desktop, then this is no help.

The settings available can be seen by running the PNTSC.exe directly under the connectivity options. The default is "Use the default proxy from the system Internet settings". As to what this actually means is not easy to determine, it may mean it looks at the local machine setting as configured by "PROXYCFG", which if so is not helpful, as proxy settings are normally user based.

The only thing that is certain is that "Use the default proxy from the system Internet settings" does not mean the more normal "Use settings specified in Internet Explorer" and therefore does not allow for auto configuration, which allows users to roam across sites with different Internet access provisions.

It appears that the answer to my question is "NO" if anything other than a manual proxy configuration for a non roaming PC is required.

Looks like I will now be looking into the best corporate deal we can get at a local coffee shop for these users. Previous experience has shown it takes companies like Sun (now Oracle) many years to get this (sorta) right for JAVA after pressure from banks and trading companies. Based on the JAVA experience and the current status of the Quest client, I estimate about 6 years for a fix if progressed in the Sun way.

Hi Karl,

The vWorkspace client uses local user proxy settings but when things break it is usually the proxy server that is at fault. If you connect to the SSL Gateway, you are using SSL http which most proxy servers handle without problems. However the challenge comes with SSL/TLS encapsulated RDP which is simply not handled properly or at all by some proxy servers. So you can connect thtough the SSL gateway to the web portal, but when you launch the client by clicking on an icon, the connection fails. If you bypass the proxy server, it connects. Some proxy servers (eg ISA 7) handle the encapsulated RDP/EOP without problems some don't.

Obviously the format of the SSL encryption used for the RDP/EOP connection is partly at fault but there are other issues as well, such as the performance impact of running through a proxy server. I'm not arguing that the proxy server should be by-passed in large organizations but configuration of the proxy server so it can deal with encapsulated RDP properly is certainly desirable. That would allow you to bring your staff back out of the internet cafe.

regards,

Rick

Hi Rick, thank you for your reply, apologies if I sound a bit off, but I think you missed the point that the client does not understand/parse the local proxy settings if automatic detection is used (rather than a manual proxy with exceptions, which is what the vWorkspace client probably uses as the easy to program option).

The client is not failing compatibility with our proxy, as once it is launched from the desktop it never goes near it, just keeps banging away at the firewall. We are effectively in the position of having bypass proxy configured because the client has not been coded to understand "automatically detect", so doesn't use the proxy, just goes direct.

Looks like we are at not going anywhere quickly (other than for a coffee), even if the vWorkspace client did understand automatically detect, from what you are saying the encapsulation of vWorkspace (unlike competitors) is not likely to go through the (ISA 2006) proxy anyway.

"but configuration of the proxy server so it can deal with encapsulated RDP properly is certainly desirable. That would allow you to bring your staff back out of the internet cafe.", sorry, but can't see how this helps, you are saying using a proxy won't work due to the protocol unless we happen to be running one variation of proxy out of the many out there?

The conclusion with the information you have added does seem that the current vWorkspace client is not fit for purpose from the networks of many commercial (proxy using) potential users.

Sorry to repeat, but what I need is:

• vWorkspace client to read that "automatic detect" is configured in IE, then process that correctly with dhcp and DNS requests, then correctly parse the returned WPAD file (not the old JAVA cop out out of finding the first server line).
• vWorkspace client protocol to be compatible with the majority of proxy servers, particularly the ones that are actually installed in the wild like ISA 2004/2006 and blue coat, not those likely to be rolled out at a future tech fresh sometime in the next several years.

Until the client is sorted, we will have to deal with too much caffeine, and lobby providers to use one of the many useable competing products

Regards

Karl

Hi Karl,

I can't quite agree with you, and I guess I'd better also clarify my comments on the protocol, particulary since I'm not at my best wording replies when I'm too tired.

Firstly the vWorkspace client is most definitely parsing local proxy settings. It doesn't need to be sorted provided it is configured properly.

If you want to confirm this, set your web interface > connectivity > proxy > to "use default from system internet settings". Run process monitor (http://live.sysinternals.com/procmon.exe) and set the filter for process name pntsc.exe. Then launch a client connection from the web portal. You will see the client (pntsc.exe) parsing machine and local user proxy settings.

The vWorkspace client is definitely proxy aware if configured (Useproxy=1 in pit file) to use the local proxy settings.

But let's cover the other stuff properly.

The vWorkspace client encapsulates RDP in SSL, delivered over TCP port 443, like http wrapped in SSL (https).

As you would know, port 443 is the official registered port for https so any traffic over port 443 is assumed to be https by firewalls and proxy servers.

Unfortunately RDP differs from http in several ways:

(1) RDP is a real-time interactive connection-oriented protocol that does not tolerate interruptions in the TCP connection.

    - Http is not as sensitive to TCP connection interruptions, which is just as well since TCP connections can disconnect/reconnect several times during a typical Web application session.

(2) RDP is relatively much less latency tolerant than http which is only a near-real-time protocol and does not for example require individual keystrokes and mouse clicks to be sent to the server.

Simply proxying an SSL/RDP connection through a proxy server, even if it worked, would result in slow, unreliable connections. You'd still be sending your people to the local internet cafe because things would be so awful otherwise.

The proxy/firewall has to be configured to forward outbound SSL-tunneling. This could be an issue with older proxy servers, but not any more.

Rather than being "(unlike competitors)" we have the same issues as our competitors. Citrix have proxying challenges with ICA/Citrix Secure Gateway and if you've tried using a VPN product out through your corporate gateway if SSL-tunneling hasn't been enabled you would have had exactly the same experience as with the vWorkspace client, no connection. If the proxy/firewall can't handle forwarding and SSL-tunneling we have a problem, but so does everyone else.

regards,

Rick

Just to add my experience with Proxies...

ISA server, if the connection is set to bridge the ssl connection, then the RDP tunneling will not work.  ISA is decrypting the SSL traffic, inspecting the session, and will block tunneled applications (since thats not part of the https spec).

If you have configured outbound SSL in tunneling mode, then it is NOT decrypting the SSL tunnel and will allow the RDP session to connect.   I've tested this with Citrix, RDP over SSL (MS Gateway), as well as vWorkspace and even using an ssl tunneling program.

Websense also breaks any RDP and ICA tunneling over SSL when its specifically configured to inspect https traffic (as it also decrypts the SSL session, sees the RDP traffic and drops it).  The Websense implementation is for a client with over 1000 nodes and everytime a vendor comes in with a Citrix portal, it needs to be setup to bypass websense to work.