Why Does a Local Client Device Break RDP Connection to Cloud-VM Platform when Connecting to a GlobalProtect Gateway?
28926
Created On 09/21/20 22:48 PM - Last Modified 09/24/20 17:13 PM
Question
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?
Environment
- 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
Scenario
The RDP Client at 1.2.3.4 connects to 5.6.7.8:3389 for RDP to 10.1.0.5. The Router uses a Destination NAT to translate the IP from 5.6.7.8: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 1.2.3.4 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.
Answer
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
Option A
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 1.2.3.4.
- Click OK and OK to keep your changes.
- Commit and Push.
NOTE
You will need to reset your GlobalProtect Connection from the Cloud VM. The Cloud VM will now exclude 1.2.3.4 from using the VPN tunnel and thus keep the RDP session from the 1.2.3.4 Client connected.
Option B
This option is best if the RDP Client could be from any IP address or there are too many RDP clients to add as an exclusion. This config example assumes you are using a Palo Alto Networks Cloud VM Firewall as your router. If you are using another method for your Destination NAT, please consult that guide on how to do both Source and Destination NAT in the same policy.
- 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.
- Commit.
- Reconnect the RDP session from 1.2.3.4 to 5.6.7.8:3389
Option C
Nested RDP is explained in full detail from Microsoft. This option assumes you have a second Cloud VM at IP 10.1.0.6/24 in your Cloud environment with a Destination NAT for RDP.
- 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.
Additional Information
NOTE
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.