VMware view

Thank you for the update. The "view.proxy_addr" is the user-facing IP address of the NAT the users connect through for access to the VMware View deployment on the APM. Since the "view.proxy_addr" is supposed to be an IP address that exists on a device outside the BIG-IP, there is no need to add the route domain notation to the "view.proxy_addr" variable assignment. However, in this case you have entered "172.30.224.94", which is also the IP address of the "vdi_test" virtual server. I cannot think why this would be a problem, but as a test please remove the "view.proxy_addr" variable assign setting from the Access Policy and test again. Please report on the results. In the earlier packet capture, collected from the client machine, we see the PCoIP traffic to/from the client attempting to start until a client sends a FIN and the other end sends a Reset. Unfortunately this capture doesn't include any of the XML transferred between the Client and BIG-IP. If the issue continues after removing the "view.proxy_addr" variable assign setting from the Access Policy, I suggest we perform a more complete packet capture collecting VMware View traffic on the BIG-IP APM. Please use the following steps to perform the packet capture: 1) Modify the "SSL-Efteling.nl-noauth" client-ssl profile to increase our chances at decrypting the traffic: a) In the "Common" partition, navigate to "Local Traffic >> Profiles : SSL : Client" b) Select the "SSL-Efteling.nl-noauth" profile c) Set "Configuration:Advanced" d) Set the "Ciphers" to DEFAULT:!ECDHE e) Set the "Cache Size" to 0 f) Click [Update] to save the changes 2) Enable Access Policy Informational logging, VDI Debug logging and TCP Reset Cause logging: tmsh modify sys db log.accesscontrol.level { value "informational" } tmsh modify sys db log.vdi.level { value "debug" } tmsh modify /sys db tm.rstcause.pkt value enable 3) Start a TCPDump with the following syntax: tcpdump -vvv -nni 0.0:nnn host 172.30.224.94 or host 172.30.224.193 or port 4172 -s0 -w /var/tmp/C1874865_PCoIP_failing.pcap 4) Complete the steps that result in the failure. 5) Record the following information: -) Username used to authenticate on the APM -) APM Session# for the test -) Name of VMware View resource requested that resulted in the failed PCoIP connection. 6) Once the issue has been reproduced, stop the TCPdump 7) Use the following SSLdump syntax to decrypt the TCPdump: ssldump -nAr /var/tmp/C1874865_PCoIP_failing.pcap -d -k /config/filestore/files_d/Common_d/certificate_key_d/:Common:STAR.efteling.nl-2015.key_42706_1 -M /var/tmp/C1874865_PCoIP_failing.pms > /var/tmp/C1874865_PCoIP_failing.output-ssl.txt **please confirm the "/full/path/to/ssl/key" is the same as that in the above command 8) Use the following Bash command at the BIG-IP CLI to generate a QKview on the APM system that will include all of the logs from the BIG-IP: qkview -s0 -f /var/tmp/"$HOSTNAME"_"$(date +%d-%m-%y)".qkview 9) Return logging to normal: tmsh modify sys db log.accesscontrol.level { value "notice" } tmsh modify sys db log.vdi.level { value "notice" } tmsh modify /sys db tm.rstcause.pkt value disable 10) Return the "SSL-Efteling.nl-noauth" client-ssl profile to normal by _unchecking_ the "Ciphers" and "Cache Size" settings, then click [Update]. Now reply with the Username, APM Session# and VMware View resource information recorded in step 5.

kees4IP