After connecting to Global Protect unable to use RDP

[Monicashree]

Hi Friends,

We have a customer who is facing issues while accessing RDP via Global Protect.

User is not able to access the RDP machine after connecting to RDP. We have tried by adding the RDP ip in the include list.

We have also tried by creating a specific policy for ms-rdp. It is hitting the correct rule but unable to access.

For the logs we could see that application is showing as incomplete.

We have tried by taking packet captures. Surprisingly we got all four packets drop, transmit, firewall and Transmit packets.

I have merged all the four packets to see. I could see that TCP Port reused messages.

Kindly help where and what could be done to solve this.

I am attaching the screenshot for your reference.

Regards

Monica.

[Raido_Rattameister]

At initial look I would say routing issue.

[TomYoung]

Hi @Monicashree ,

If the NGFW captures packets in the drop stage, then it is dropping the packets. First, check the traffic logs to see the drops.  (Make sure logging is enabled for interzone default.)

If you don't see anything there, you may be able to see why with the last command in this article -> https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CloNCAS.

Thanks,

Tom

[Raido_Rattameister]

Screenshot seems to show:

Packet 1 - SYN arrives to Palo
Packet 2 - SYN goes through firewall stage in Palo
Packet 3 - SYN is sent out from Palo
Packet 4 - SYN ACK arrives back to Palo
Packet 5 - SYN ACK goes through firewall stage in Palo
Packet 6 - ??? Either captured from "transmit" stage or "drop" stage

If packet 6 is captured from "transmit" stage then you need to figure out if 172.16.10.70 receives it and why it does not send ACK back.

Most likely it is captured from "drop" stage.

This means that either routing back to 172.16.10.70 is broken, return traffic is routed to different zone compared where it came from or if some zone protection settings is dropping it.

I suggest to add 2 packet capture filters one where source is 172.16.10.70 and destination 192.168.45.31 and second filter line with source/destination IPs flipped around.

Run command:

> show counter global filter delta yes packet-filter yes

Generate some traffic and then run same command again.

This shows reason why packets are dropped.

[AbdulAzim]

I notice that the packet is not reaching its destination from the basic flow. Is it possible for you to capture the same packets on the DC firewall? I think that firewall is causing the same issue that you are seeing.

So the route cause analysis is that this is a down stream network issue.