topic Re: NAT Configuration to access Remote Desktop in General Topics

NAT Configuration to access Remote Desktop

feelgood — Mon, 22 Jul 2019 11:09:30 GMT

Hi,

We need to configure an input rule to authorize an public IP address to access at one of our virtual machine on our subnet.

Concretely, I need to authorize public IP address 195.193.194.195 access directly to our virtual machine with the private IP 192.168.1.1 on the port 3389 (Remote Desktop) only via our public IP address (82.83.84.85).

I configured a NAT rule but it didn't work. May be I doing something wrong ?

Can you help us about this topic ?

Thank you for your help.

Re: NAT Configuration to access Remote Desktop

Abdul_Razaq — Mon, 22 Jul 2019 11:30:06 GMT

Hi @feelgood ,

Hope you have configured the NAT and security rule properly. refer below doc for help.

https://docs.paloaltonetworks.com/pan-os/8-0/pan-os-admin/networking/nat/nat-configuration-examples/destination-nat-exampleone-to-one-mapping

Re: NAT Configuration to access Remote Desktop

feelgood — Mon, 22 Jul 2019 11:48:55 GMT

Hi @Abdul_Razaq,

Thank you for your answer, I go test that.

Re: NAT Configuration to access Remote Desktop

BPry — Mon, 22 Jul 2019 12:25:54 GMT

@feelgood,

While this certainly works I would question why you wouldn't simply give whoever's needs access to this device access through the built in GlobalProtect VPN solution.

You are still exposing this desktop to the outside world. You might be limiting it via a security policy but the NAT statement is still there. To avoid issues due to a misconfiguration I would recommend against your current approach.

Re: NAT Configuration to access Remote Desktop

feelgood — Mon, 22 Jul 2019 12:41:18 GMT

@BPry

We have already GlobalProtect configured on our PanOS but it's for our users. This NAT configuration is for a partner who needs to access an environnement via our public IP address.

We don't want grant access at this partner on our VPN access because it's not partitionned correctly at this time.

So, the only solution I founded it's this NAT rules restricted on the IP address of this partner.

Re: NAT Configuration to access Remote Desktop

BPry — Mon, 22 Jul 2019 12:51:33 GMT

@feelgood,

This is a "quick" solution to the problem, but I would seriously look at getting GlobalProtect in a good working state to allow Vendor solutions access to select machines rather than a NAT solution. You already have GlobalProtect exposed to the outside and this solution is just adding another entry point into your network. It might be secure by a source address, but one small configuration mistake would open it up to anyone.

Just my two cents, clearly either is a viable solution.

Re: NAT Configuration to access Remote Desktop

feelgood — Mon, 22 Jul 2019 13:06:44 GMT

@BPry

Thanks for your advices. We need to grant access to partner this week so I need a quick solution. But we are aware that is a dirty solution and we need to more secure our GlobalProtect access in the future.

Re: NAT Configuration to access Remote Desktop

OtakarKlier — Mon, 22 Jul 2019 21:40:32 GMT

Hello,

RDP is unsecure and I do not recommend you use it over the internet. Please use a secure channel like one Bpry suggeted.

Regards,

Re: NAT Configuration to access Remote Desktop

feelgood — Tue, 23 Jul 2019 08:09:09 GMT

Hi @OtakarKlier @BPry

I reconsider my position and you're wright, it's so dangerous to expose RDP on Internet.

So, I search other solution without VPN (for the moment). May be a VNC solution.

Re: NAT Configuration to access Remote Desktop

feelgood — Tue, 23 Jul 2019 13:28:14 GMT

Finally, I think to segregate subnets ont my GlobalProtect configuration but I have a question : Can I apply different segregation by users or users group ?

Re: NAT Configuration to access Remote Desktop

jeremy.larsen — Tue, 23 Jul 2019 17:46:08 GMT

Exposing RDP = BAD BAD BAD!

Use a product designed to do this that can open via a proxy service. Something like teamview or a similar solution that includes some kind of authentication/authorization. This avoids all the NAT goofyness and security implications you are getting yourself into as well.