View 7.8 - Behaviour PCoIP through UAG

[srodenburg]

Hello,

I'm working on a customers View 7.8 environment where they have 2 UAG's and only 1 Public IP available. This means everything must go through the Load-balancer. Everything works. Blast ist fast but PCoIP is dreadfully slow.

Several Load-Balancer manufacturers have whitepapers on how to set up such a "multiple UAG, single Public IP" construct (they all follow the same principles) and this customer has implemented it correctly according to spec. Firewalls and Natting are configured correctly too. I cannot find a fault there.

UAG01 (version 3.5) is configured with:

PCoIP External URL = <public ip>:14172

Blast External URL = https://vdi.company.com:18443

Tunnel External URL = https://vdi.company.com:18443

Blast and Tunnel are enabled

UDP Tunneling Server is disabled currently. It makes no difference if we enable it or not.

UAG02 (version 3.5) is configured with:

PCoIP External URL = <same public ip>:24172

Blast External URL = https://vdi.company.com:28443

Tunnel External URL = https://vdi.company.com:28443

Blast and Tunnel are enabled

UDP Tunneling Server is disabled currently. It makes no difference if we enable it or not.

Port 443 goes to the UAG's directly (one is chosen by the LB) and things like SSL Stickyness etc. are configured correctly.

Again, we have NO stability or functional problems. Just that PCoIP is slow, jerky and laggy compared to Blast, especially over higher-latency connections than is typical for LAN. PCoIP used to be fast back in the day when we used Security Servers. All this changed when the UAG was introduced. They seem to handle PCoIP differently.

Focussing on PCoIP:

What I observed by looking at Netstat on the client (a laptop somewhere on the Internet) is that when we use Blast, we see a bunch of permanent TCP sessions to 443 and a single session to 18443 (no UDP, all TCP).

but...

When selecting PCoIP, we again see those couple of sessions to 443 and that very briefly, a single TCP session is established to port 14172 (example using UAG01) which is torn down within a few seconds and disappears.

What is left are only those permanent connections to port TCP 443 and that's it. PCoIP and USB Redirection etc. all work fine. But as said, it's slow.

My assumption is, is that PCoIP is being completely tunnelled through 443 and that it is NOT using it's own permanent TCP session for PCoIP on port TCP 14172 (in case of UAG01) as i'd expect.

(I expect it to behave the same as Blast because it is configured according to the same principle).

Out of curiosity, I disabled tunnelling completely but the behaviour with PCiOP remains exactly the same as when Tunnelling is enabled on the UAG's.

My question is:  is this behaviour of PCoIP when routed through a UAG "by design" or am I missing something?

[Dsanches]

This is quite curious I have almost the same behavior, but when using RDP (since physical boxes doesnt support PCoIP) over high latency networks (200ms+).

The whole experience is great when running PCoIP on VDIs, I'll probably raise a ticket with Vmware, but I'm not feeling confident they will solve, my last experience with the support was terrible.

[srodenburg · Accepted solution]

Got an answer from Horizon Dev through another channel. Here is the answer that I got.

"PCoIP should be direct, not tunnelled through 443.

With PCoIP, the TCP connection is quite short lived, just to exchange keys. The majority is then UDP 4172 from client to server and reply datagrams back. Look for those.

Make sure that port mapping is sending PCoIP 14172 and UDP 14172 to UAG1 as destination port 4172 (i.e. port mapping). Same for the othe PCoIP ports to UAG2"

Of course, those 14172 etc. ports are what I use in my specific situation so replace them with whatever you are using.

---------------------------------------------------------------------------------------------------------

Was it helpful? Let us know by completing this short survey here.