External Clients cannot connect with PCOIP (Blast Ok) Not your normal PCOIP Issue NEED HELP from the EXPERTS

[Super6VCA]

i have 3 VMware techs totally stumped so that is why i need the experts and this has to be the place.  Her is the scenario..

Had a View 7.0.1 environment that was working just fine.  I updated to View 7.4 (all servers and agents) and all hell broke lose.  The only way that users can  connect from outside the office is with BLAST of HTML.  PCOIP will not work.  Gets slow login to desktop then black screen then timeout message. The odd thing is that i cannot get any desktop to listen on Port 4172.  The stranger thing is that if i try to connect to the same desktop from within my office it works fine with PCOIP.  So there is no tunneling with the internal users. If i do a netstat -a it doesn't show 4172 LISTENING on UDP or TCP.  With a connection internally with teh same netstat command it shows them listening.  Had my firewall tech look at teh logs on the ASA and it shows 4172 traffic going through all subnets. However I can telnet from the security server to any subnet PC and the connection is good.  When i try that same test from the security server to teh 10.0.15.0 subnet the connection get refused,

I have been on the phone with vmware for a total of 6 hours with no luck yet.  i just uploaded the log bundles from all devices for them to view.

Here is what i think i know...

Computers in the 10.0.15.0 subnet all wok fine internally

Computers Externally work only with Blast and HTML

No iPad or Android devices work Externally but do internally via wifi

Firewall is Passing 4172 per my  Cisco tech

Security server is passing 4172 to other subnets

Question...Do you think that placing another Security server paired with another broker on a different public IP would give me any valid info??

Any Comments, Questions, Ideas, or thoughts are welcome.  Thanks for taking the time to read this.

[HussamRabaya]

this is not a normal behavior , what other security appliances or network traffic control in the traffic way you have? sand-boxing, packet shaping......

is there any policy in the firewall; to control the session termination

[Super6VCA]

Nothing at all!  Just an ASA and we confirmed that 4172 is passing thru to that subnet

[mmonkman]

A long shot from me as I don't have much experience in this area, but did you upgrade from v6.x to get to 7.01 in the past?  Is there a chance the TLS1.0 was being used?

TLS1.0 is disabled by default in later versions, but I do have experience of Horizon retaining "legacy" settings that do survive upgrades.  This setting could have been wiped out totally by the 7.4 upgrade.  Could explain why you are seeing the inbound connections, but it's the cipher that's causing the issue.

Compatibility Notes

• For the supported guest operating systems for Horizon Agent on single-user machines and RDS hosts, see Supported Operating Systems for Horizon Agent in the View Installation document.
• If you use Horizon 7 servers with a version of View Agent older than 6.2, you will need to enable TLSv1.0 for PCoIP connections. View Agent versions that are older than 6.2 support the security protocol TLSv1.0 only for PCoIP. Horizon 7 servers, including connection servers and security servers, have TLSv1.0 disabled by default. You can enable TLSv1.0 for PCoIP connections on these servers by following the instructions in VMware Knowledge Base (KB) article 2130798, Configure security protocols for PCoIP for Horizon 6 version 6.2 and later, and Horizon Client 3.5 a....

Release Notes for VMware Horizon 7 version 7.4

[Super6VCA]

Thanks for the reply.  Nope, updated from 7.0.1 to 7.4. 

[sjesse]

Are you using instant clones or linked clones, I see this too.

[techguy129]

I would consider rolling back to 7.3.

Have you tried using a UAG instead of a security server? That seems the way Horizon architectures are moving. With a UAG, you don't have to tie it to a connection server.

[TechMassey]

First, I would review your security server settings in the View Administrator. See screenshot below. It is possible the PCOIP secure gateway is misconfigured from the update. The external URL should be External IP:4172

Second, I didn't see you mention if the clients were updated. Let us know if you have and tested it.

Third, logs, logs, logs. Logs are the only thing thats going to help us here. You need to review the client logs, agent logs, and security server logs. Good news is VMware made a nice KB that gives you all that info. I suspect the security server log will clearly show why the connection dropped.

Here is the Horizon View Logs KB: VMware Knowledge Base

[Super6VCA]

Thanks for all the input guys!  Techmassey, #1 - i checked the URL's in the setup multiple times and even tried using IP address instead with no luck.  #2 All of out clients are running ver 4.7 across the board.  And for #3 me and vmware looked at the logs for 6 hours with nothing sticking out.  i finally sent them the full log bundle 2 days ago and still haven't heard back.  Thanks for the input.

[Super6VCA]

Techguy129,

Not sure what UAG is.  Would love to try it if it's an option.

[sjesse]

Unified Access Gateway, its the linux appliance replacement for the security servers. I'm not sure that will help, since I see the same problem with our enviornment, pcoip won't connect externally.

[TechMassey]

Thanks for the detailed info! Can you confirm if the logs show the incoming connection at the security server or agent level? Is there any evidence any component at all sees the incoming connection in the logs?

[PaulMurphyCO]

Are you using the same parent VM/snapshot for all users? I experienced similar symptoms for a pool once after upgrading versions a couple of years ago. I ended up uninstalling the VMware tools and the View Agent from the parent VM, reinstalling them (with tools first, then the agent) and connectivity was successful.

[sjesse]

So I see this too and its odd. All connections no matter where they come from come through our F5 Loadbalancers. Depending on the source ip you get redirected to a certain connection server. Our deployment isn't that big so we have 1 external, 1 internal, and 1 dedicated server for some secure desktops. The odd part is if I'm coming from a network we consider as external, but still on premise pcoip works, but if I'm actually external then I can't connect at all with pcoip.For me at least it has to do something with the pcoip quality of the connection, or how its routed, since I end up going through the same connection server in both instances.

[Super6VCA · Accepted solution]

Well, Vmware support finally helped me track it down.  Come to find out that UDP traffic passing thru my security server was getting stopped and that was causing the issue.  Uninstalled the NIC and reinstalled and things were back up and running.  pretty strange if you ask me.  Anyhow, thanks for the replies.  Much appreciated.

[Super6VCA]

When i fianally put a wireshark on all the connections is when i found out that all traffic was getting in but not getting back out.