Forum Discussion

Ryan_34424's avatar
Ryan_34424
Icon for Altostratus rankAltostratus
Nov 23, 2016

APM :: VMware View :: PCoIP & UDP/0

Has anybody ran into an issue where the virtual machines reply back with UDP/0?

 

After I log-on and am presented the webtop, I click the VMware View desktop link, I click to launch the VMware View Client, and then the client opens and connects. I'm shown the infamouse black/grey screen, and then it errors-out. If I look at the firewall logs, I see the following:

 

  • The F5 floating IP connects to the virtual machine on TCP/4172 (for PCoIP I presume)
  • Data is transmitted between the two and it finishes FIN/ACK
  • The virtual machine then attempts an outbound connection to the F5 floating IP from UDP/4172 destined to UDP/0

Of course, the outbound connection-attempt to UDP/0 is dropped by the firewall since it's invalid.

 

Any ideas on what could be causing this? I would anticipate the virtual machine would connect to UDP/4172 and not port 0.

 

Thanks -Ryan

 

application delivery
BIG-IP
BIG-IP Access Policy Manager (APM)
pcoip
udp
view
vmware
vmware view
  • Ryan77777's avatar
    Ryan77777
    Icon for Altocumulus rankAltocumulus
    Jan 06, 2017

    Further troubleshooting: I setup an interface on the desktop wire (bypassing the firewall), and the PCoIP connection still does not work. The same behavior is present with UDP/0, only this time it is not dropped by a firewall and makes it to the F5. The F5 then responds ICMP type 3 code 3 and the Horizon client eventually times-out (no further data from the BigIP).

     

    A note was added to the case stating that he doesn't think the issue is with the iApp deployment or it's config. He said it's the "backend server at x.x.x.x" (the desktop virtual machine) that is resetting the TCP connection. So he thinks the problem is with the "backend server" at that address.

     

    Anyway... I'm getting nowhere with support. This is actually one of the worst experiences I've had with F5 support. I'm usually their top cheerleader. The guys I'm dealing with really don't care and frankly the initial support engineer I'm working with is rather combative making dealing with him extremely aggravating. I'll likely end-up closing the case and figuring it out on my own (somehow).

     

  • Ryan77777's avatar
    Ryan77777
    Icon for Altocumulus rankAltocumulus
    Dec 21, 2016

    Still trying to figure this out...

     

    An inside source says:

     

    “Yes, this is expected behavior. From what I was told by a developer who is no longer with F5 the PCoIP server (virtual desktop) will send these initial UDP packets to the bigip during initial PCoIP connections and there is no way to stop the PCoIP server from doing this. We found that the port(s) used by the PCoIP server in these initial requests led to an intermittent problem described in bug ID457865-1. The fix for this bug included the behavior of what you/the customer is reporting now where bigip tells the PCoIP server to make these initial UDP to port 0 and so you will see the PCoIP server sending bigip initial UDP packets (src port 4172, dst port 0) and bigip responding with ICMP unreachable. The bigip has no problems with port 0. This behavior cannot be changed.”

     

    The ENE on the case states:

     

    "The overall issue stems from PCoIP client/server behavior, they simultaneously start sending each other UDP packets when switching from TCP to UDP (likely for overcoming NATs) and once one of them reaches out to another, they agree on ports to use."

     

    But in my case, I'm not using NAT... and the latter is not happening regardless... and therefore a port is not agreed upon and the PCoIP connection times out.

     

    More to come...