topic Windows Remote Desktop Application Slow When Access Through PAN Firewall in General Topics

Windows Remote Desktop Application Slow When Access Through PAN Firewall

jeffhooi — Wed, 01 Dec 2010 02:21:30 GMT

Hi Guys,

I am experience some issue with the PA-500. I am having some slowness issue when users connect from remote site to HQ local server via remote desktop ( ms-rdp ) application and sometimes unable to connect or disconnected.

Policy rules are : WAN - LAN Source any Destination 10.0.0.10 and 10.0.0.11 (server ip) any any profiles: none

That is the 1st rules.

I had tried to set the QoS for the ms-rdp application and which is still slow when i applied the QoS. Seems like the QoS is not working too.

When i physically bypass the PA-500, the ms-rdp was working fine and very fast.

Did anyone know what may cause this issue?

Software : PAN OS 3.1.6

Deployment mode : Transparent

WAN link : Load balancer on top bottom that support 3 WAN link (total of 10 Mbps link)

-Sam-

Re: Windows Remote Desktop Application Slow When Access Through PAN Firewall

pantac — Wed, 01 Dec 2010 17:29:21 GMT

I would set up a capture on the palo alto device to stage at receive, transmit, drop, and firewall to see if the palo alto is forwarding the packet in a timely manner. also check to see if there were any packets dropped " show counter global filter delta yes | match drop
". In a previous case we seen that there's a large number of out-of-order frames on the local side, leading to retransmissions. we can modify these tcp settings with the following commands. " set deviceconfig setting tcp out-of-sync ignore "
" set deviceconfig setting tcp drop-out-of-wnd no"

if you need help with any of the above please create a case via the support portal and an engineering will help debug further.

Re: Windows Remote Desktop Application Slow When Access Through PAN Firewall

bjdraw — Tue, 07 Dec 2010 02:48:19 GMT

I had this issue once and also blamed it on the PAN, only to discover that it was another hop along the way. In the end this netsh command on the RDP server fixed it.

netsh interface tcp set global autotuninglevel=disabled

Worth a shot as it can easily be turned back on.