VMware Horizon Community
JasonPearceAtRi
Enthusiast
Enthusiast
Jump to solution

VMware View Agent 5.2.0 PCoIP over WAN fails

I recently performed an in-place upgrade of VMware View 4.6 to VMware Horizon View 5.2.

After upgrading the View 4.6.0 agent in my parent virtual machines to the View 5.2.0 agent and rebuilding the desktop pools, external PCoIP doesn't work. I can log into the View 5.2 Client, see a list of desktop pools, select a pool, the desktop at work will close and attempt to open remotely; after 1 second, this error appears:

Error: VMware Horizon View Client: The connection to the remote computer ended.

What Does Not Work:

  • External/WAN via PCoIP to desktops with the View 5.2.0 Agent

What Does Work:

  • Internal/LAN via PCoIP to desktops with the View 5.2.0 Agent
  • Internal/LAN via RDP to desktops with the View 5.2.0 Agent
  • External/WAN via RDP to desktops with the View 5.2.0 Agent
  • External/WAN via PCoIP to desktops with the View 5.1.3 Agent or lower (tested down to View 4.6.0 Agent)

I even attempted to build a brand new Windows 7 desktop pool in a new Active Directory OU without any Group Policies or VDI optimizations. I tried with and without Windows Firewall enabled. In all cases, this brand new desktop pool works externally via just about any View Agent but the View 5.2.0 Agent.

Does the View 5.2.0 Agent have the same firewall/port requirements as the View 5.1.3 Agent? What else can I test or attempt to get external PCoIP working for desktops with the View 5.2.0 Agent?

Tags (3)
Reply
0 Kudos
1 Solution

Accepted Solutions
JasonPearceAtRi
Enthusiast
Enthusiast
Jump to solution

We eventually discovered the problem / solution. We on a security appliance from Palo Alto Networks that was blocking PCoIP 5.2.0 traffic but not PCoIP 5.1.3 traffic.

According to a Vmware backline engineer:

"A change was made to the ephemeral TLS connection that is used to establish trust and negotiate network parameters for the subsequent UDP traffic. This change allows the customer to use their own TLS server certificate for this connection. For details of what happens during PCoIP setup, and how this changed in View 5.2, see KB 1038762."

It appears that Palo Alto Networks didn't like this change. When we removed our Palo Alto appliance from the WAN, PCoIP 5.2.0 connections could be established. We eventually had to create a rule to permit the Category: private-ip-addresses and URL: pcoip-default-sni/. Once that change was made, WAN PCoIP 5.2.0 connections began working.

View solution in original post

Reply
0 Kudos
18 Replies
Linjo
Leadership
Leadership
Jump to solution

Review the external url, it has probably been reset to the hostname of the View Connection server in the upgrade.

// Linjo

Best regards, Linjo Please follow me on twitter: @viewgeek If you find this information useful, please award points for "correct" or "helpful".
Reply
0 Kudos
JasonPearceAtRi
Enthusiast
Enthusiast
Jump to solution

Linjo,

I thought that you'd might have something there regarding the HTTPS Secure Tunnel > External URL, but it doesn't appear to be the case. The help button next to this setting reads:

The setting is disabled if Use Secure Tunnel connection to desktop is unchecked.

View Clients use the External URL to establish a secure tunnel to this View Connection Server instance.

If a server name is specified, it must be resolvable by each View Client.

The External URL must not be load balanced.

In my testing, it doesn't seem to matter if the External URL for the Connection Broker is set to https://desktops.example.com:443 (friendly external URL) or https://viewconnect4.example.local:443 (internal FQDN). In either case, the result remains the same. View 5.1.3 Agents and below can connect externally via PCoIP but the View 5.2.0 Agent cannot.

The last line of the help pop-out concerns me though: "The External URL must not be load balanced."

My objective is to have all employees learn and use a single URL -- https://desktops.example.com:443 -- regardless of location. Internally, I use DNS load balancing by having three A records servers viewconnect1.example.com, viewconnect2.example.com, and viewconnect3.example.com. Externally, I have just one https://desktops.example.com DNS A record that points to just one Security Server that is paired to viewconnect4.example.com.

My concern is that the Connection Broker viewconnect4.example.com is inside the domain and would thus listen to my internal DNS servers that are performing load balancing tasks for desktops.example.com, to servers that do not have the HTTPS Secure Tunnel enabled and are not paired to the external Security Server. While older View Agents were accepting of this configuration, perhaps the View 5.2.0 Agent is not.

If not, how do others use DNS load balancing with View 5.2.0 to present just a single URL for internal and external access? Perhaps modifying the "hosts" file on viewconnect4 be a solution to prevent it from accessing our internal DNS servers.

Reply
0 Kudos
JasonPearceAtRi
Enthusiast
Enthusiast
Jump to solution

Changing the "C:\Windows\System32\drivers\etc\hosts" file on viewconnect4.example.local didn't make a difference. I tried both of these values (not at the same time):

127.0.0.1desktops.example.com
172.22.55.55desktops.example.com

I then flushed my DNS cache "CMD > ipconfig /flushdns" and made sure that if I pinged desktops.example.com on viewconnect4.example.local that it responded correctly and did not respond with an IP from viewconnect1, 2, or 3.

In View Admin > View Configuration > Servers > Connection Servers > viewconnect4 > Edit > General > HTTPS Secure Tunnel > External URL > I tried both https://desktops.example.com:443 and https://viewconnect4.example.local:443.

Same result for all four tests. Desktops with the View Agent 5.1.3 and below all work. Desktops with the View Agent 5.2.0 fail to connect via PCoIP.

Reply
0 Kudos
cgrubbe
Enthusiast
Enthusiast
Jump to solution

I haven't made the move to 5.2 as of yet (on 5.1.X), but the first thing that came to mind were the PCoIP Secure Gateway settings on the paired CM and SS.  Have you verified your settings for "PCoIP Secure Gatway" did not get changed during the upgrade?

-Chris

Reply
0 Kudos
JasonPearceAtRi
Enthusiast
Enthusiast
Jump to solution

Chris,

Thanks for offering to help. Here's my configuration...

Security Server

  • Server Name: viewsecure2
  • Paired With: viewconnect4
  • HTTPS Secure Gateway > PCoIP External URL: https://desktops.example.com:443
  • PCoIP Secure Gateway > PCoIP External URL: 68.xxx.xxx.xxx:4172 (help says "An IP address must be specified, not a server name.")
  • Blast Secure Gateway Blast External URL: https://desktops.example.com:8443

Connection Server

  • Server Name: viewconnect4
  • Paired With: viewsecure2
  • HTTPS Secure Tunnel > External URL: https://desktops.example.com:443
  • PCoIP Secure Gateway > PCoIP External URL: 172.xxx.xxx.xxx:4172 (I also tried the same external IP 68.xxx.xxx.xxx:4172 as the Security Server)
  • Blast Secure Gateway Blast External URL: https://desktops.example.com:8443

I restart the VMware View Connection Server service on viewconnect4 after making changes. Results are the same. View 5.1.3 agents can connect with all attempted settings. View 5.2.0 agents via PCoIP fail all attempted settings.

Reply
0 Kudos
JasonPearceAtRi
Enthusiast
Enthusiast
Jump to solution

Following this KB Troubleshooting PCoIP Secure Gateway (PSG) issues (1034825) I'm still unable to resolve my issue:

Resolution

To troubleshoot issues starting a PCoIP session using PSG:

1. Check the operating system's version of the Security Server and Connection Server.

  • Security Server OS: Windows 2008 R2 SP1
  • Connection Server OS: Windows 2008 R2 SP1

2. Check if the correct Security or Connection server is configured for PSG.

  • VMware View PCoIP Secure Gateway service is present and started on both the Security Server and the Connection Server
  • View Admin > View Config > Servers > Security Servers > viewsecure2 reports PCoIP Secure Gateway is Installed
  • View Admin > View Config > Servers > Connection Servers > viewconnect4 reports PCoIP Secure Gateway is Installed

3. Check that the Security Server and Connection Server are paired.

  • View Admin > View Config > Servers > Security Servers > viewsecure2 is paired with viewconnect4

4. Ensure that the PSG is enabled in the Connection Server.

  • View Admin > View Config > Servers > Connection Servers > viewconnect4 > General > PCoIP Secure Gateway is Enabled (checked)

5. Check the configuration of PSG settings.

  • View Admin > View Config > Servers > Connection Servers > viewconnect4 > General > HTTPS Secure Tunnel > Use Secure Tunnel connection to desktop is Enabled (checked) > External URL > https://desktops.example.com:443
  • View Admin > View Config > Servers > Connection Servers > viewconnect4 > General > PCoIP Secure Gateway > Use PCoIP Secure Gateway for PCoIP connections to desktop is Enabled (checked) > PCoIP External URL > 68.xxx.xxx.xxx:4172 (same IP found at View Admin > View Config > Servers > Security Servers > viewsecure2 > PCoIP Secure Gateway > PCoIP External URL (e.g. 68.xxx.xxx.xxx:4172)

6. Check communicating and firewall rules.

  • Front-end and back-end firewall rules are vaild since View 5.1.3 Agents and lower can estabilish external PCoIP connections to the same resources
Reply
0 Kudos
markbenson
VMware Employee
VMware Employee
Jump to solution

Is the Security Server and Connection Server at 5.2?

Reply
0 Kudos
JasonPearceAtRi
Enthusiast
Enthusiast
Jump to solution

Thanks markbenson. Yes, VMware View Composer, Connection Servers, and Security Servers were all upgraded from View 4.6.0 to View 5.2.0.

Next I began upgrading the View Agents from 4.6.0 to 5.2.0 in my parent virtual machines and rebuilding those desktop pools when I discovered that external PCoIP stopped working for the desktops with the newest agent.

I eventually downgraded to the View 5.1.3 Agent, which works and is holding me over as I troubleshoot getting the View 5.2.0 Agent to work.

Reply
0 Kudos
meyner22
Enthusiast
Enthusiast
Jump to solution

I had a problem with some linked clones not working on 5.2.  Instead of doing an upgrade of the agent I removed the old agent completely and then installed the 5.2 agent.  Also just for testing purposes turn off Windows firewall and see if you can connect.  I had a windows update reset the firewall rules that were created for connection server.

Reply
0 Kudos
markbenson
VMware Employee
VMware Employee
Jump to solution

The fact that PCoIP access remotely via Security Server works to your 5.1.2 Agent pools suggests that the firewall rules, PCoIP External URL and connection server settings are correct. It is therefore odd that you can connect to your 5.2 Agent pools internally. Check that your firewall rules in any external firewall will allow communication from your Security Server to the 5.2 Agent pools. This assumes we are talking about the same Connection Server, Security Server and network in both cases.

PCoIP connection failures with a brief black screen are usually either caused by incorrect remote access setup (PCoIP External URL, Connection Server settings or firewall rules blocking PCoIP). The 3 steps required are described here - Setting up PCoIP Remote Access with View 4.6 and Newer - A config error in any of the 3 steps will give a PCoIP black screen.

General PCoIP black screen problems (internal or remote) are usually caused by the customer downgrading the graphics driver after View Agent is installed (e.g. by installing Tools after installing the Agent), configuring insufficient video RAM or some other factors such as color depth or 3D settings etc. Can you carefully check these things between your working View 5.1.2 Agent VMs vs your 5.2 Agent VMs. Having an insufficient display resolution between these different pools can cause a black screen. Recheck the firewall rules on your 5.2 Agent VMs to make sure the TCP rule and UDP rule for 4172 is present. Blocking these ports will certainly cause the black screen problem. Uninstall and reinstall the View 5.2 Agent to make sure the graphics driver is correct and that the firewall rules are set up correctly.

When you say connection works to the new View 5.2 Agent VMs internally but fails externally, is this from the same client device? Similarly when you say remote access works to 5.1.2 Agent VMs but fails to View 5.2 Agent VMs is this also with the same client device?

We do know that View 5.2 Agents work with View 5.2 Connection Server and Security Server. Many people have upgraded to this version since release in February and are operating this with internal access and remote access.

If you still can't set it up correctly, you'll need to start looking at PCoIP traffic flows in your environment to see if PCoIP is being blocked or misrouted somewhere. Wireshark or similar can help here.

From what you've said, I assume there are no load balancers involved in this setup. This is happening when connecting to just one Security Server.

Please post back to let us know what it was. Thanks.

Reply
0 Kudos
JasonPearceAtRi
Enthusiast
Enthusiast
Jump to solution

Meyner22: Thanks for responding. At first, I performed an in-place upgrade of the View Agent in my Parent Virtual Machine from 4.6.0 to 5.2.0. When that failed (externally, internal PCoIP works) I build a brand new Windows 7 PVM with a fresh install of the View 5.2.0 Agent. I tried having the Windows Firewall Service started with profiles disabled, as well as the Windows Firewall Service started with profiles enabled, before installing the View 5.2.0 Agent. I then skipped all Windows 7 optimization scripts and put the new pool in a new Active Directory OU with no Group Policies. No luck. External/WAN PCoIP connections fail. If I downgrade to the View 5.1.3 Agent (uninstall, reboot, install), external/WAN PCoIP connections work.

Markbenson: Thanks for sticking with me.

I agree. If external/WAN PCoIP connections work to desktops with the 5.1.3 Agent, then my DMZ/firewall rules, Security to Connection Server pairing, SSL Certs, and even Windows Firewall rules should all be correct. My test desktop pools are in the same VLANs/subnets as my production desktop pools. I even recomposed my production virtual machine (just my machine, not the entire department’s pool) to the View 5.2.0 Agent. Same result. I can connect internally but not externally.

I have only one Security Server to Connection Server pairing, so all tests are going through the same servers and network paths.

Regarding the PCoIP black screen, I don’t quite make it to a black screen. I get the dark gray remote desktop border with a hollow/transparent inside (it’s not filled with black and instead shows my desktop) for 1 second before the connection is closed. I am certain that the last thing that I install on my PVMs is the View Agent, but thank you for reminding everyone that the Agent must be installed after Tools.

For display resolution, here’s how I have things configured.

  • vSphere > PVM > Edit Settings > Hardware > Video Card > Auto-detect video settings
  • View Admin > Inventory > Pools > Test 5.2.0 pool > Edit > Pool Settings > Max number of monitors = 2 AND Max resolution = 1920x1200

Most of my external testing has been done via a Windows 8 x64 virtual machine I have at home. When I perform the test I select “Windows – Small” for the display. I’ve also tested externally via my iPad and iPhone, both with the newest VMware View Client. My iPad is able to connect internally to a 5.2.0 desktop at work but not externally from home.

I have provided VMware Support eight Wireshark packet captures:

  • Security Server > External Client to a 5.1.3 Agent
  • Security Server > External Client to a 5.2.0 Agent
  • Virtual Desktop with 5.2.0 Agent > Internal connection via a 5.2.0 Client
  • Virtual Desktop with 5.2.0 Agent > External connection via a 5.2.0 Client
  • Work Laptop/Client > Internal connection to a 5.1.3 Agent
  • Work Laptop/Client > Internal connection to a 5.2.0 Agent
  • Home Lab/Client > External connection to a 5.1.3 Agent
  • Home Lab/Client > External connection to a 5.2.0 Agent

What we find is no UDP traffic for external attempts to the 5.2.0 Agents. VMware Support is still reviewing this data.

I appreciate everyone’s ideas. If you have any more, I’ll be happy to test. In the meantime, I’ll continue to work with VMware Support. Thank you.

Reply
0 Kudos
meyner22
Enthusiast
Enthusiast
Jump to solution

Can you send a screen shot of your servers?  Connection, Security like the image below.  I just want to see what you have currently.  I'm sure what you have set is accurate.

Servers.jpg

Reply
0 Kudos
JasonPearceAtRi
Enthusiast
Enthusiast
Jump to solution

Sure meyner22. Here are the settings for my Security and Connection servers.

View Admin > Security Server (only ***SECURE2 is in use):

view-52-security-server.png

View Admin > Connection Server (***CONNECT4 is paired to ****SECURE2, others are internal):

view-52-connection-server.png

Reply
0 Kudos
slricogisd
Contributor
Contributor
Jump to solution

We had a similar issue and went through this:

VMware KB: Connecting to a View desktop with the View Client displays the error: The connection to t...

Not sure if you had seen this yet or not. Did not see it referenced.


JasonPearceAtRi
Enthusiast
Enthusiast
Jump to solution

slricogisd. Thanks for the KB. I've provided VMware Support two desktop pools (5.1.3 and 5.2.0), Wireshark, and netcat. So far, we've been unable to resolve this issue. I will post the resolution once we figure it out. Thank you all for the help.

Reply
0 Kudos
JasonPearceAtRi
Enthusiast
Enthusiast
Jump to solution

We eventually discovered the problem / solution. We on a security appliance from Palo Alto Networks that was blocking PCoIP 5.2.0 traffic but not PCoIP 5.1.3 traffic.

According to a Vmware backline engineer:

"A change was made to the ephemeral TLS connection that is used to establish trust and negotiate network parameters for the subsequent UDP traffic. This change allows the customer to use their own TLS server certificate for this connection. For details of what happens during PCoIP setup, and how this changed in View 5.2, see KB 1038762."

It appears that Palo Alto Networks didn't like this change. When we removed our Palo Alto appliance from the WAN, PCoIP 5.2.0 connections could be established. We eventually had to create a rule to permit the Category: private-ip-addresses and URL: pcoip-default-sni/. Once that change was made, WAN PCoIP 5.2.0 connections began working.

Reply
0 Kudos
tohoken
Enthusiast
Enthusiast
Jump to solution

Jason,

I am also having trouble with PCoIP 5.2 traffic.  We use Palo Alto as well.  I see that you were able to get it working.  Could you provide a little more detail about how you got it to work?  I see that you created a rule for category and URL but how did you create that?

Thanks,

Ken

Reply
0 Kudos
JasonPearceAtRi
Enthusiast
Enthusiast
Jump to solution

The root cause of our problem was the fact that the consolidation of our ASAs into a single physical platform resulted in there being "trusted internal" addresses appearing on our "untrusted external" ports on Palo Alto. Previous versions of the VMware View Agent were not encrypting all packets, so Palo Alto could recognize the PCoIP application, which made correlations easy. However, the new VMware View Agent v5.2 has more encrypted content, so the amount of searchable information that Palo Alto can access is limited. We ended up creating a new Palo Alto policy to specifically allow SSL traffic from our two VMware View Security Servers.

Reply
0 Kudos