Best Practices for allowing MS Terminal Services RDP sessions
Please bear in mind that this is a topic that I am trying to learn more about and the Watchguard configuration is just one of my many hats. The facts: we have an external office with a dynamic WAN IP, this location has about 6 users that access an application server in the main office location. Currently, they access the app server by initiating a remote desktop session at each workstation to run the needed program. Back at the main office those sessions are handled by the terminal services server (RDP) with adequate licenses, which is installed on a VM application server which is hosted by a HyperVM host server 2012R2. I just setup a T35W and have configured the basic settings. I would like to be able to setup a secure session from the external office to the main office that will allow the RDP connections to work. Since I do not have a static IP at the external office to allow only traffic from that IP address to pass to the application server, I am not quite sure of how to accomplish this configuration and are looking for some input ? If you have something to add, please provide me your thoughts and specific configuration details along with any reference to Watchguard FAQs. I appreciate any help.
Thanks HB3
Comments
Best practice is DO NOT OPEN port 3389 to the whole Internet, period. Require firewall login first or a VPN first, both requiring 2FA.
A "remote office" for me is usually a random Starbucks (pre-COVID!), so what I did was to set up my remote office (which is my laptop) with a DynDNS name. Now, in the firewall, I set the allowed inbound connections from an alias named "FQDN-TrustedSites" and in that alias, I have the laptop's DynDNS name, along with a few other trusted locations' FQDNs.
I also have dynamic IP at my home office, so I set up vpn.mypublicdomainname.net in my public DNS, where "vpn" is a CNAME that points to the DynDNS name that I have in my home office firewall. I use vpn.mypublicdomainname.net as the target for my VPN or RDP connections. That resolves via public DNS to the DynDNS name, which resolves to my current IP address. It works perfectly.
For RDP, I do NOT have it open at all times. I have it set to require logging into the firewall first, authenticating with AuthPoint, and THEN it opens the inbound port, which is NOT 3389. I have a "HackAttacks.In" polciy that includes commonly-attacked ports, including 3389, so if anything hits one of those ports, it gets put on the Blocked Sites list to prevent further port scans.
Gregg Hill
How about having a Branch Office VPN between these 2 sites?
I'd err with @Bruce_Briggs suggestion, so long as at least one of those sites has a static IP, the Branch Office VPN should be reliable.
For remote access from a mobile user, any of the Mobile VPNs should do the trick, and keep the terminal server secure. For the dynamic side, you'd just specify an option other than IP (usually domain name)
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/bovpn/manual/define_gateway_endpts_vif_c.html
Gregg's option to authenticate to the 4100 page does also work, but isn't as transparent to the users -- using a VPN keeps that traffic secure.
-James Carson
WatchGuard Customer Support
The only problem I have with a VPN (especially a mobile VPN) is the potential for something malicious to come through the VPN to attack the corporate network.
Regarding my option to authenticate to the 4100 page, it is as transparent for MOBILE users as is a Mobile VPN.
Gregg Hill