2 Replies Latest reply on Aug 17, 2019 9:58 AM by srodenburg

    View 7.8 - Behaviour PCoIP through UAG

    srodenburg Hot Shot
    vExpert

      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?

        • 1. Re: View 7.8 - Behaviour PCoIP through UAG
          Dsanches Novice

          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.

          • 2. Re: View 7.8 - Behaviour PCoIP through UAG
            srodenburg Hot Shot
            vExpert

            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.