About David_Avery

Thanks Brianhill88 ,   Your reg key seems to fix the issue. While my RDP client feels more sluggish I'm not experiencing the Freeze anymore.   To All, if you have a rule which only allows [ms-rdp {app-default}], you should consider adding an [any {udp-3389}] rule below it, this initially helped make my problem less frustrating but I would still experience freezes if I did the below:   If this helps anyone from Palo Alto Networks support if they come across this issue, I found in pcaps at the firewall that it was dropping RST packets from the remote terminal server (my windows 10 desktop in this case) when under heavy screen redraw load while trying to scroll wheel through either the start menu, a folder with large images and the view set to Extra Large Icons, or the way I could always force it to freeze would be to grab a full screen window such as my browser open to my pan firewall UI and flail it around the screen wildly. I would see a massive amount of TRANSMIT and FIREWALL stage (as expected with RDP Experience options set to everything on), then when it froze about three dozen of TCP,RST packets capped in the DROP stage.   In looking at the session through a second VDI connection to our Horizon View I noticed the UDP session showed this: c2s flow: source: <rd> [user_vpn-L3] dst: <rd> proto: 17 sport: 55450 dport: 3389 state: ACTIVE type: FLOW src user: <rd> dst user: <rd> s2c flow: source: <rd> [Inside-L3] dst: <rd> proto: 17 sport: 3389 dport: 55450 state: ACTIVE type: FLOW src user: <rd> dst user: <rd> DP : 2 index(local): : 1203093 start time : Wed Jul 22 05:38:09 2020 timeout : 36000 sec time to live : 35992 sec total byte count(c2s) : 330115 total byte count(s2c) : 52126669 layer7 packet count(c2s) : 1926 layer7 packet count(s2c) : 42793 vsys : vsys1 application : ms-rdp rule : davery-wfh-limited service timeout override(index) : False session to be logged at end : True session in session ager : True session updated by HA peer : False layer7 processing : completed URL filtering enabled : True URL category : any session via syn-cookies : False session terminated on host : False session traverses tunnel : True captive portal session : False ingress interface : tunnel.<rd> egress interface : ae2 session QoS rule : N/A (class 4) tracker stage l7proc : ctd err sw end-reason : unknown   Sometimes I would see an unknown-udp session start on the same rule, as I suspect the client side was trying a new session start but most times I did not see that though.   Normally I would expect my second rule which follows this one 'davery-wfh-limited-1' which is not app-specific on port udp-3389 to pickup the traffic that was unknown-rdp and allow but it seems like whatever is happening in the packets that the appID engine is hitting a problem identifying and then the stream breaks. Since it's udp the client would just keep sending AND since the firewall was dropping the server side TCP RST packets, the client side was unaware the server side wants the session to disconnect and start over. I've been dealing with this problem since probably October 2019 and my users have been very frustrated to say the least. It took me about 2 months to find that I needed the non-app specific udp-3389 rule, and most clients we ended up turning off UDP. Thanks again  Brianhill88 ... View more

Thanks  Fhewiufhwefhwe,   Your reg key seems to fix the issue. While my RDP client feels more sluggish I'm not experiencing the Freeze anymore.   To All, if you have a rule which only allows [ms-rdp {app-default}], you should consider adding an [any {udp-3389}] rule below it, this initially helped make my problem less frustrating but I would still experience freezes if I did the below:   If this helps anyone from Palo Alto Networks support if they come across this issue, I found in pcaps at the firewall that it was dropping RST packets from the remote terminal server (my windows 10 desktop in this case) when under heavy screen redraw load while trying to scroll wheel through either the start menu, a folder with large images and the view set to Extra Large Icons, or the way I could always force it to freeze would be to grab a full screen window such as my browser open to my pan firewall UI and flail it around the screen wildly. I would see a massive amount of TRANSMIT and FIREWALL stage (as expected with RDP Experience options set to everything on), then when it froze about three dozen of TCP,RST packets capped in the DROP stage.   In looking at the session through a second VDI connection to our Horizon View I noticed the UDP session showed this: c2s flow: source: <rd> [user_vpn-L3] dst: <rd> proto: 17 sport: 55450 dport: 3389 state: ACTIVE type: FLOW src user: <rd> dst user: <rd> s2c flow: source: <rd> [Inside-L3] dst: <rd> proto: 17 sport: 3389 dport: 55450 state: ACTIVE type: FLOW src user: <rd> dst user: <rd> DP : 2 index(local): : 1203093 start time : Wed Jul 22 05:38:09 2020 timeout : 36000 sec time to live : 35992 sec total byte count(c2s) : 330115 total byte count(s2c) : 52126669 layer7 packet count(c2s) : 1926 layer7 packet count(s2c) : 42793 vsys : vsys1 application : ms-rdp rule : davery-wfh-limited service timeout override(index) : False session to be logged at end : True session in session ager : True session updated by HA peer : False layer7 processing : completed URL filtering enabled : True URL category : any session via syn-cookies : False session terminated on host : False session traverses tunnel : True captive portal session : False ingress interface : tunnel.<rd> egress interface : ae2 session QoS rule : N/A (class 4) tracker stage l7proc : ctd err sw end-reason : unknown   Sometimes I would see an unknown-udp session start on the same rule, as I suspect the client side was trying a new session start but most times I did not see that though.   Normally I would expect my second rule which follows this one 'davery-wfh-limited-1' which is not app-specific on port udp-3389 to pickup the traffic that was unknown-rdp and allow but it seems like whatever is happening in the packets that the appID engine is hitting a problem identifying and then the stream breaks. Since it's udp the client would just keep sending AND since the firewall was dropping the server side TCP RST packets, the client side was unaware the server side wants the session to disconnect and start over. I've been dealing with this problem since probably October 2019 and my users have been very frustrated to say the least. It took me about 2 months to find that I needed the non-app specific udp-3389 rule, and most clients we ended up turning off UDP. Thanks again  Fhewiufhwefhwe , and thanks to the solution OP Brianhill88 ... View more