Troubleshoot VMware View Security Server PCoIP port problems

Recently I had to troubleshoot a VMware View Client connection problem.  In a new VMware View environment the customer has installed a VMware Horizon View Security Server for the external connections.  When a external View Client tried to connect through the Security Server using the PCoIP protocol to the View desktop the following appeared:

The connection to the remote computer ended

When the users connects to the View Desktop using the LAN (without the Security Server) everything worked fine. I suspected that a PCoIP port (4172 TCP and UDP) is blocked between the Security Server and desktop pool or vice versa. 

To troubleshoot this problem I used the tool “Netcat”. With Netcat TCP and UDP ports can be checked (Telnet can only check TCP ports). So I used Netcat  to check the TCP and UDP ports between the Security server and View Desktop (1) and the View Desktop to the Security Server(2).



Here is an example how to use Netcat:

On the View desktop  run Netcat  to listen to UDP port 4172:

nc –l –u –p 4172

On the security server run Netcat to connect to the View Desktop on UDP port 4172:

nc –u ipaddress 4172

You can type some text and press enter. The text typed in the screen must be displayed on both sides, If not the port is blocked.


So I discovered that the 4172 UDP protocol from the View desktop pool to the Security server was blocked by a firewall. After opening this port in the firewalls the problem was solved.

More information:  Netcat for Windows can be downloaded here.

VMs with dropped packets %DRPRX

During a health check of a vSphere environment i notices dropped packets on several VMs. In ESXTOP the %DRPRX value showed dropped receive packets on several VMs. In the screenshot an example:


The customer uses vSphere 4.0 build 244038. All the VMs that experiencing the dropped packets problem were Windows 2008 with an  E1000 NIC.

E1000 — An emulated version of the Intel 82545EM Gigabit Ethernet NIC. A driver for this NIC is not included with all guest operating systems. Typically Linux versions 2.4.19 and later, Windows XP Professional x64 Edition and later, and Windows Server 2003 (32-bit) and later include the E1000 driver.

On of the Windows 2008 VMs had no packets drops. The only difference with the other VMs was that the IPv6 protocol binding on the NIC was disabled. After disabling the IPv6 protocol binding on all the other VMs the packet drops is disappear.


Some services require the IPv6 binding, so disabling the IPv6 binding was no option for the customer.  All the other Windows 2008 machines with the VMXNET3 NIC and IPv6 enabled had no packet drops. After changing all the VMs with Windows 2008 and the E1000 NIC to the VMXNET3 NIC solves the problem.

The VMXNET 3 adapter is the next generation of a paravirtualized NIC designed for performance, and is not related to VMXNET or VMXNET 2. It offers all the features available in VMXNET 2, and adds several new features like multiqueue support (also known as Receive Side Scaling in Windows), IPv6 offloads, and MSI/MSI-X interrupt delivery.

Whenever possible i suggest to use the VMXNET3 driver for Windows 2008 Operating Systems.