Why Does a Local Client Device Break RDP Connection to Cloud-VM Platform when Connecting to a GlobalProtect Gateway?
Why Does a Local Client Device lose an RDP Connection to a Cloud-VM Platform when the Cloud-VM platform Connects to a GlobalProtect Gateway on a NGFW or Prisma Access?
- GlobalProtect Client Application on the Cloud VM
- Cloud Platform (Azure, AWS [Amazon Wed Servers], GCP [Google Cloud Platform], etc.)
- Client device with RDP Application
- RDP connection from Client to Cloud VM
- Palo Alto Networks GlobalProtect Gateway on NGFW or Prisma Access configured in "tunnel all" mode
- Disable Local Subnet Access (DLSA) "No direct access to local network" is turned off on the Gateway
The RDP Client at 18.104.22.168 connects to 22.214.171.124:3389 for RDP to 10.1.0.5. The Router uses a Destination NAT to translate the IP from 126.96.36.199:3389 to 10.1.0.5:3389. When the Cloud VM establishes a GlobalProtect VPN Tunnel to the Global Protect Gateway, all traffic routes through the tunnel except local subnet traffic (10.1.0.0/24). This will thus break the RDP connection as the destination for 188.8.131.52 is now set to route through the Tunnel to the GW 192.168.1.1 instead of through the original next hop of 10.1.0.1.
To prevent this, we have 3 options:
- A: Configure GlobalProtect Gateway with an Access Route to Exclude the RDP Client Public IP
- B: Configure a Source NAT on the Router
- C: Nested Remote Desktop Connection
This option is best if there are only a couple of IPs that need to be excluded from the VPN Tunnel.
- From Panorama, go to your Gateway's Client Configuration Split Tunneling: Network>GlobalProtect>Gateways>[Gateway Config]>Agent>Client Settings>[Client Config]>Split Tunnel>Access Routes
- In the Exclude section, add 184.108.40.206.
- Click OK and OK to keep your changes.
- Commit and Push.
You will need to reset your GlobalProtect Connection from the Cloud VM. The Cloud VM will now exclude 220.127.116.11 from using the VPN tunnel and thus keep the RDP session from the 18.104.22.168 Client connected.
- Bring-up your existing Destination NAT policy in Policies>NAT.
- In the Translated Packet>Source Address Translation section, change Translation Type to Dynamic IP and Port.
- Change Address Type to Translated Address.
- Add 10.1.0.1 as the Source Translated Address that is on the same subnet as the Cloud VM.
- Click OK to confirm your changes.
- Reconnect the RDP session from 22.214.171.124 to 126.96.36.199:3389
- RDP from Public RDP Client to the second Cloud VM.
- From this RDP session, open a new RDP connection to Cloud VM (10.1.0.5)
- This connection will not drop when the Cloud VM connects to the GP Gateway.
Any Clients on the same subnet as the Cloud VM (10.1.0.0/24) will NOT experience a break in RDP connection when the Cloud VM connects to the GP Gateway.