MX68 Port forwarding for remote desktop access by another company

[tantony]

I need to give another company access to one of our computer.  I know I can give them a temporary VPN account, but then I was thinking about port forwarding.  The internal IP of the computer is 172.16.2.220.  This is the computer that I want to give access to the other company.

Do I just go into port forwarding, then use port 3389 (remote desktop), for both the public and local ports, then use the 172.16.2.220 for the LAN IP?

Would this work?  Is there a way to use DDNS?

My home router is a Netgear, and I'm using DDNS to connect to my home camera from work.  Does Meraki have a DDNS?

This is what I'm doing on my home Netgear router for DDNS.

https://kb.netgear.com/23930/How-to-setup-Dynamic-DNS-on-a-NETGEAR-router-using-www-no-ip-com

[Raj66 · Accepted solution]

@tantony Yes, configuring port forwarding on port 3389 to direct traffic towards the private IP should allow the traffic from outside to your computer in the LAN. Yes, you can use DDNS, As long as the traffic is coming to the MX wan IP and a port forwarding rule is configured to allow that traffic inbound, the traffic will be directed to the computer in the LAN. 

More information about how port forwarding works in MX can be found in this doc
https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX

Cheers!

Raj

[tantony]

Thank you, so I found an article on Meraki DDNS.  My deployment setting is "Routed", and I have a link to the  Security & SD-WAN > Monitor > Appliance status page.  But, I don't have the next screen.

https://documentation.meraki.com/MX/Other_Topics/Dynamic_DNS_(DDNS)

[tantony]

Ok, I see the DDNS settings now.  I think its working, but I need to double check.

[SoCalRacer]

From a security standpoint this is a terrible idea. 3389 is a widely known and scanned port. Then using Meraki DDNS is known and makes you more vulnerable. Even with a port forward like 33899 and changing the local RDP port on the machine to 33899 so it is true forwarding and not translating the traffic on that port can easily be sniffed and determined to be RDP traffic. I am guessing this is why AMP is now detecting any RDP traffic not from the VPN as a threat.

Recommendation:

1) Make them use the VPN to use RDP

2) Use a different more secure platform for long term remote use

3) If this is a once in a while kind of thing, setup the session for them with a different platform (TeamViewer or similar)

[kYutobi]

I agree with @SoCalRacer you don't want to overcomplicate things when it comes to remote access. 

[Raj66]

Agree with @SoCalRacer that this is not the best of the security methods out there but want to make one correction. While configuring port forwarding we can restrict the allowed remote IPs to the IPs that we trust. Again, not the best of the security options will just get the job done if you are using it once in a while

[SoCalRacer]

@Raj66 

Since that traffic from the trusted IPs can be sniffed easily, then the attacker can spoof the IP easily and get around it. Again another reason I see AMP detecting this as a threat even with trusted IPs. I also would not recommend disabling AMP or turning the settings down to detection only as you have added then more vulnerabilities to your device/network.

[tantony]

Thank you, I'll use the VPN.  

[tantony]

This is a one time thing, but I agree VPN is more secure than port fwd.  The reason I selected port fwd is because from a user point of view, its a one step process.  They just need the host name.  For VPN, they need to configure the VPN client first.

[PhilipDAth]

>Since that traffic from the trusted IPs can be sniffed easily, then the attacker can spoof the IP easily and get around it. 

RDP traffic is encryted, so sniffing is not really an issue in this case.

Spoofing the IP address and maintaining a TCP stream is non-trivial for a connection that runs over the Internet when you don't hace access to the source (aka you are a remote man in the middle).  For a start you don't get any of the return traffic.  Just forming the TCP session is a mission.