Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

PCoIP not passing through APM

We are trying to perform a proof of concept for using the F5 APM with our VMWare view environment. I have used the f5.vmware_view.v1.2.0 iApp in 11.5.1 HF7. We have allowed port 4172 through our firewall all the way through to our connection server and pools. When we have users access the website within the network we have no issues. But when we attempt to access the website from the outside the user can authenticate through to the webtop and see the pools but only receives the black screen of death. I ran a tcpdump for 4172 on both tcp and udp and receive nothing from external clients. We seem to have everything that is listed in the deployment guide but still are not having any luck. Any insight or possible solutions, would not be surprised if I am missing a checkbox somewhere.

0
Rate this Question
Comments on this Question
Comment made 10-Mar-2015 by Greg Crosby
Are you using BIG-IP APM as your gateway to proxy ICA traffic or are you configuring BIG-IP for LTM only deployment?
0
Comment made 10-Mar-2015 by jtlampe 78
We are using the APM as the gateway to Proxy pcoip traffic. The setup we are using is only a connection server (no security server).
0
Comment made 10-Mar-2015 by Greg Crosby
Just read the post title. If you are not seeing traffic from client to the big-ip on udp 4172 then I would verify your connection servers have options "Use Secure Tunnel", "PCoIP Secure Gateway", and "Blast Secure Gateway" unchecked. You do not need to direct clients back to a specific gateway address since APM will be handling PCoIP traffic (APM inserts it's ip address as assigned VD address and proxys to actual assigned virtual desktop address). I would run a tcpdump on the client to see where it is sending PCoIP connection requests, hopefully it is sending them to the BIG-IP. If so, then run tcpdump on BIG-IP to see client request. If you are not seeing the request on the big-ip then something in the middle needs to be configured to allow 4172 to the big-ip. Last step of connection request is to watch for big-ip self ip to make PCoIP request to the assigned virtual desktop (or RDS hosted app). Hope this helps, Greg
0
Comment made 10-Mar-2015 by jtlampe 78
I ran a packet capture on the client device watching all 443 and 4172 traffic. There is plenty of 443 going back and forth between the client and the F5 as well as the F5 and connection server and pool memeber. however I do not see any 4172 (PCoIP) traffic being sent from the client once the desktop is launched. nor do I see any 4172 traffic hit on the F5 from the pool member (which I'm told would start the 4172 traffic).
0
Comment made 11-Mar-2015 by jtlampe 78
I was able to have our VMware team set up a pool for me to test solely with. I ran wireshark there and when I attempted to log in externally to the same pool member I saw a lot of 4172 traffic being sent to the F5 but rejected due to checksum not matching.
0
Comment made 11-Mar-2015 by jtlampe 78
Also we verified that all checkboxes on the connection server are cleared.
0

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

You don't have analytics or logging profiles attached to the VS do you?

I had the same issues...

H

0
Comments on this Answer
Comment made 11-Mar-2015 by jtlampe 78
I do not believe we do as this was setup very bare bones. How would I confirm that we do not have any analytics or logging profiles?
0
Comment made 11-Mar-2015 by Hamish 3344
Have a look at the VS config...
0
Comment made 11-Mar-2015 by jtlampe 78
Found it under advance configuration. And no we do not have any logging profiles or Analytics profiles set to any of the virtual servers.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I would check these things:

1) Do you have a forwarding IP VIP. I just used a any any Forwarding VIP.

2) I don't think it would be rejecting it due to a checksum, but possibly a missing route. Make sure you have proper routes to reach your Connection Servers and make sure they have proper routes to reach the F5. Windows Server does not have telnet by default, but turn it on or use putty, to telnet to the F5 using 4172 and make sure it's open.

3) Use the "sessiondump" on the CLI when logging in for troubleshooting to see how far the user is getting.

4) And most importantly, in Vmware Horizon View, double check your PCoIP Secure Gateway. Vmware strongly recommends you use a seperate NAT (Public IP) I know, I know, you are supposed to be able to go back through the F5 for everything, but you may want to cut your loses and test this.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Also

  1. Check your SSL profiles are setup correctly. There's specific setting required (And an iRule) to fixup everything
  2. Enable debug logs for APM and check what comes up in /var/log/apm

H

0
Comments on this Answer
Comment made 11-Mar-2015 by jtlampe 78
the Server SSl is set to have the server name as pcoip-default-sni and I tried the iRule but according to the solution SOL15409 this was fixed in version 11.5.1HF5. We are running 11.5.1HF7. So still the black screen remains.
0
Comment made 11-Mar-2015 by jtlampe 78
According to the APM debug users are getting all the way through to having resources assigned but I am seeing the following error: {3b8.S} An exception is thrown: Bad cast: got AnyRef<12StreamClosed> instead of AnyRef<9HttpEvent>
0
Comment made 27-Mar-2015 by Thomas Schockaert 188
Hi jtlampe, We're having the *exact* same problem here, we're not seeing any PCoIP traffic exiting the F5. The same error is given for the webclient as for the horizon view client itself. Did you go any further with this by any chance? Kind regards, Thomas Schockaert
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I have seen that error but I have only seen it when connections are made using a HTML 5 client which might explain why you are not seeing any PCoIP traffic. Are users connecting using Horizon View client or HTML 5 client?

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

We were able to find the solution. TCP 4172 traffic was being passed between the F5 and VMWare box but not establishing the UDP session. Only after modifying the access policy of right before the resource assign we put a variable assign of view.proxy_addr = expr {"public IP address"}.

So in turn we have it set-up so that we use two-factor authentication of NT-Login and OTP. That then opens the landing page to the VMWare Pools a user can access.

Thank you all for the valuable input in helping us find the root cause of our issue.

0
Comments on this Answer
Comment made 16-Mar-2015 by Greg Crosby
The iApp for View will add the proxy address expression; the question in the iApp is "If external clients use a network translated address to access View, what is the public-facing IP address?".
0
Comment made 15-Sep-2015 by Greg 103
This is only if you have a firewall in front of APM as the public address of the VS correct? Not if the destination address of the VS for PCoIP is the public address? I am having a similar issue where we can connect using a Wyse client just fine but when clicking on the desktop we want to launch it times out, I am assuming at the beginning of the PCoIP communication, still need to verify via a pcap.
0