Mark
asked on
Need multiple Remote Desktop Connection functionality
Our office currently has SBS2008, which we are losing. The Remote Web Workplace menu has a 'Connect to Computer' box which provides a list of Domain computer to which one can connect. We need a replacement for this functionality to let workers connect from outside the office.
We have a Linux host on the LAN acting as a firewall/router. I can accomplish what I want on a per-workstation basis using the following iptables command:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3389 -j DNAT --to-destination 192.168.0.100:3389
This example routes any Remote Desktop Connection requests (port 3389) from eth0 (Internet connected interface) to the workstation at 192.168.0.100. That's all well and good, but I can only get to one workstation at a time. I would like something like the RWW's computer list where I could select from among workstations.
I'm going to check the VPN Topic for this question, but don't really know what I'm talking about in doing that.
How can I accomplish what I want?
We have a Linux host on the LAN acting as a firewall/router. I can accomplish what I want on a per-workstation basis using the following iptables command:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3389 -j DNAT --to-destination 192.168.0.100:3389
This example routes any Remote Desktop Connection requests (port 3389) from eth0 (Internet connected interface) to the workstation at 192.168.0.100. That's all well and good, but I can only get to one workstation at a time. I would like something like the RWW's computer list where I could select from among workstations.
I'm going to check the VPN Topic for this question, but don't really know what I'm talking about in doing that.
How can I accomplish what I want?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
If you're used to RWW I'd just install RD Gateway, as Aaron said. It'll make the users feel like it's something they're used to, but they'll lose the access to resources via the website as the SBS is going.
ASKER
Re: RWW and MS server ... We do currently use RWW, but we are losing the SBS server. The replacement server will be Linux with Samba4, so MS server based solutions won't work anymore.
Arnold:
Actually, I thought of that idea, but couldn't figure out how to alter the port used by Remote Desktop Connection? I didn't see any settings for this. Is that doable? If so, it might be the simplest solution.
It seem like, other than a Windows solution, VPN is the best route. I really know nothing about VPN other than the basic concept. Do users have to download an application to run on their remote computers? Is it accessed via a web page? Is there some kind of terminal server hosted on the office (Linux) server? Any recommendations on VPN software that will work with Windows/MAC remote hosts and a Linux office server?
Arnold:
You can duplicate the rule you have for one, by simply altering the port on the linux box which will forward to another workstation's port 3389.
Actually, I thought of that idea, but couldn't figure out how to alter the port used by Remote Desktop Connection? I didn't see any settings for this. Is that doable? If so, it might be the simplest solution.
It seem like, other than a Windows solution, VPN is the best route. I really know nothing about VPN other than the basic concept. Do users have to download an application to run on their remote computers? Is it accessed via a web page? Is there some kind of terminal server hosted on the office (Linux) server? Any recommendations on VPN software that will work with Windows/MAC remote hosts and a Linux office server?
when you use mstsc host:port will do the trick. when :port is missing, 3389 is implied.
There are different types of VPN implementations IPSEC, PPTP, L2TP over IPSEC, OPENVPN, etc. ipsec, I think the newer windows/macs include those in and would need only to be configured. A VPN might be needed, but it might be included in some of the windows/macs.
this would be a remote VPN (client to server)
There are feature that enhance security/control using a connection to establish the tunnel, but to complete/authorize and pass traffic, the user is required to provide a username/password that can be centrally managed, i.e. user deactivated so does the ability to establish a VPN.
You could add to your ongoing project to have your linux box function as the VPN end point, ipsec/pptp openvpn will require a client which is availble, be installed on the client system. Sorry can not post links, but a search for "make your linux box a VPN server" will provide you several examples.
There are different types of VPN implementations IPSEC, PPTP, L2TP over IPSEC, OPENVPN, etc. ipsec, I think the newer windows/macs include those in and would need only to be configured. A VPN might be needed, but it might be included in some of the windows/macs.
this would be a remote VPN (client to server)
There are feature that enhance security/control using a connection to establish the tunnel, but to complete/authorize and pass traffic, the user is required to provide a username/password that can be centrally managed, i.e. user deactivated so does the ability to establish a VPN.
You could add to your ongoing project to have your linux box function as the VPN end point, ipsec/pptp openvpn will require a client which is availble, be installed on the client system. Sorry can not post links, but a search for "make your linux box a VPN server" will provide you several examples.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Arnold:
craigbeck:
I have been exploring and reading up on OpenVPN in particular. At http://openvpn.net/ I can download a client for Windows workstations. What I'm not finding in my search is, once the VPN connection is established between e.g. my home desktop and the office server, how I then can connect to my office workstation. Does OpenVPN or other such tools also provide some kind of terminal manger program to let users select from among configured workstations and lot on (like RWW)?
when you use mstsc host:port will do the trick. when :port is missing, 3389 is implied.Wow, that's simple. Didn't know that. That could be good for a small office setup with less than a dozen workstations. I could also not use 3389 at all and thus throw some hackers off the track.
craigbeck:
You don't really want to allow RDP to machines on your LAN direct from the internet - that's a big security issue.Hmmm, but this article, https://security.berkeley.edu/node/94, says, "Remote Desktop sessions operate over an encrypted channel, preventing anyone from viewing your session by listening on the network." Do you disagree?
The other alternative with way less overhead is just like arnold said... use 3rd-party solutions which allow secure desktop sharing/connectivity via app or web.I'm a little fuzzy on the 3rd party thing. How does a 3rd party provide access to workstations behind MY office server LAN?
I have been exploring and reading up on OpenVPN in particular. At http://openvpn.net/ I can download a client for Windows workstations. What I'm not finding in my search is, once the VPN connection is established between e.g. my home desktop and the office server, how I then can connect to my office workstation. Does OpenVPN or other such tools also provide some kind of terminal manger program to let users select from among configured workstations and lot on (like RWW)?
3rd party like logmein or teamviewer.
Yes rdp sessions are encrypted, but the computer is listening to anything on that port. So not only can they brute force guess, but possibly get in though some security hole. If you have a direct ip:port->workstation, thats something that can be possibly exploited.
Yes rdp sessions are encrypted, but the computer is listening to anything on that port. So not only can they brute force guess, but possibly get in though some security hole. If you have a direct ip:port->workstation, thats something that can be possibly exploited.
RDP doesn't have to be encrypted - it's optional in older versions of Windows.
Opening holes in your firewall always increases the risk of a breach especially when forwarding to a user machine. You need to be absolutely sure that the service you're allowing is what's listening on the port you open.
Opening holes in your firewall always increases the risk of a breach especially when forwarding to a user machine. You need to be absolutely sure that the service you're allowing is what's listening on the port you open.
Typically, you do not want to put port 3389 as the standard listening port when you do a port forward. (This goes for ssh port 22 as well, unless it's a general access server) The script kiddies start attacking you constantly and your logs fill up. I've always port forward that to some other port and their standard scripts won't find it. It's security through obscurity, but stops 99% of the access attempts on your port and works well enough for a home connection with obscure IPs.
You can still do it for a small business, but if you have a static IP and host servers, you can still easily become a target. You're still forwarding the port so anyone that really wants to target you can still scan for your ports and find them. If you're willing to spend some money, a VPN firewall device, like a Juniper SRX or Fortigate, would be a better way to go. It provides access to your internal networks as if your inside and allows you to set up user specific access and monitor traffic for attempted attacks and block them.
You can still do it for a small business, but if you have a static IP and host servers, you can still easily become a target. You're still forwarding the port so anyone that really wants to target you can still scan for your ports and find them. If you're willing to spend some money, a VPN firewall device, like a Juniper SRX or Fortigate, would be a better way to go. It provides access to your internal networks as if your inside and allows you to set up user specific access and monitor traffic for attempted attacks and block them.
ASKER
Aaron Tomosky:
craigbeck:
serialband:
3rd party like logmein or teamviewer.Oh, right. That's probably not the route we want to go.
Yes rdp sessions are encrypted, but the computer is listening to anything on that port. So not only can they brute force guess, ...True, but I can certainly monitor that port via iptables with --limit and --hitcount, and by examining log files looking for repeated attempt and shut them down. The advantage with RDC is the user can connect from anywhere they happen to be and need to get in, even if they don't have the VPN client installed.
craigbeck:
RDP doesn't have to be encrypted - it's optional in older versions of Windows.That can't be enforced or possibly detected at the server end? I suppose enforcing encryption is the point of VPN, eh?
serialband:
Typically, you do not want to put port 3389 as the standard listening port when you do a port forward.Agreed!
a VPN firewall device, like a Juniper SRX or Fortigate, would be a better way to go. It provides access to your internal networks as if your inside and allows you to set up user specific access and monitor traffic for attempted attacks and block them.OK, so help me to understand ... If I had a VPN on the server end, the user would connect with VPN client software (installed up using security certificates or some such thing). Then ... what? The user has to at that point use RDC or something similar to connect to his/her workstation, right? What do you mean exactly by, "allows you to set up user specific access and monitor traffic for attempted attacks and block them"?
Open vpn as part of the configuration it includes a push directive where you "advertise" to the remote clients the Lan IPs as well as the local DNS along with a search domain from the lan
This way when the openvpn client connects to the server, all they do is use the name or the ip of the system on the LAN to which they want access.
The short answer to the third party tools is that when they are installed, they run as a service when the system boots up, as part of their mechanism they connect to the respective provider. The outgoing connection is commonly not blocked on firewalls.
The client connects to the provider which then connects the existing session from the LAN system to the user who would then need to logon onto the LAN system.
This way when the openvpn client connects to the server, all they do is use the name or the ip of the system on the LAN to which they want access.
The short answer to the third party tools is that when they are installed, they run as a service when the system boots up, as part of their mechanism they connect to the respective provider. The outgoing connection is commonly not blocked on firewalls.
The client connects to the provider which then connects the existing session from the LAN system to the user who would then need to logon onto the LAN system.
ASKER
Open vpn as part of the configuration it includes a push directive where you "advertise" to the remote clients the Lan IPs ... This way when the openvpn client connects to the server, all they do is use the name or the ip of the system on the LAN to which they want access.Ah, so the client *does* get a list of computer names to choose from?! That wasn't clear from what I've read so far. Then what? the VPN client connects using ... RDC?
I'll see if I can find some client screenshots and more details on how it works.
The client does not get a list of computers to choose from, the client gets a network routing table entry that tells the computer how to get to the Company LAN.
i.e. home system LAn 192.168.0.0/24
Company LAN is 10.0.0.0/16
See examples: server config example http://openvpn.net/index.php/open-source/documentation/howto.html#server
client config example
http://openvpn.net/index.php/open-source/documentation/howto.html#client
on the server side look at the push options
push "route 10.0.0.0 255.255.0.0"
push "dhcp-option dns 10.0.12.10" #LAN DNS server
push "dhcp-option wins 10.0.10.15" # LAN WINS server
If you want to force the client once this VPN is establish to route all its outgoing traffic through the VPN, there is a route directive in the server example.
Difficulty to lookout for deal with the use of the same LAN IP segment at both locations.
IP overlap will get the VPN connected, but the user will not be able to access anything on the remote LAN since those requests will be seen and treated as local on that computer and will never be directed through the VPN tunnel.
Creating a separate batch file, vbscript to distribute to users that will initiate the openVPN client connection as well as prompt the user to which system they would like to connect to.
The script will be static initially. and potentially could be dynamic i.e. if he openVPN connection is established, will get the list of available systems to connect to and then present these options to the user to choose from.
one maintaining a single text file with system available for connection. The other redstributing a static script with changes of available systems to connect to.
i.e. home system LAn 192.168.0.0/24
Company LAN is 10.0.0.0/16
See examples: server config example http://openvpn.net/index.php/open-source/documentation/howto.html#server
client config example
http://openvpn.net/index.php/open-source/documentation/howto.html#client
on the server side look at the push options
push "route 10.0.0.0 255.255.0.0"
push "dhcp-option dns 10.0.12.10" #LAN DNS server
push "dhcp-option wins 10.0.10.15" # LAN WINS server
If you want to force the client once this VPN is establish to route all its outgoing traffic through the VPN, there is a route directive in the server example.
Difficulty to lookout for deal with the use of the same LAN IP segment at both locations.
IP overlap will get the VPN connected, but the user will not be able to access anything on the remote LAN since those requests will be seen and treated as local on that computer and will never be directed through the VPN tunnel.
Creating a separate batch file, vbscript to distribute to users that will initiate the openVPN client connection as well as prompt the user to which system they would like to connect to.
The script will be static initially. and potentially could be dynamic i.e. if he openVPN connection is established, will get the list of available systems to connect to and then present these options to the user to choose from.
one maintaining a single text file with system available for connection. The other redstributing a static script with changes of available systems to connect to.
ASKER
OK, I'm beginning to see the picture. So, the VPN basically makes the attaching workstation as if it were part of the office LAN, right? It then has access to LAN resources such as NAS files, probably printers, etc. One of your links even talked about routing all network traffic through the VPN such as http requests. I had a customer that used a VPN via a Cisco product and once connected, even my browser when through the VPN -- wherein they had restrictions on sites!
So, coming full circle back to the RDC question, our users would really only use this to connect to their office personal computers. I assume to do this the user, after connecting via the VPN, would still have to launch RDC in order to get to their office workstation, right? They could then possible connect via computer name (assuming the VPN is able to get the hostname of LAN computers, which your links indicated was possible), or at least via IP (e.g. 10.9.0.x)
Do I have that right?
So, coming full circle back to the RDC question, our users would really only use this to connect to their office personal computers. I assume to do this the user, after connecting via the VPN, would still have to launch RDC in order to get to their office workstation, right? They could then possible connect via computer name (assuming the VPN is able to get the hostname of LAN computers, which your links indicated was possible), or at least via IP (e.g. 10.9.0.x)
Do I have that right?
Yes, the VPN will make the remote user appear as though they are on the LAN.
yes, the option exists as part of the VPN establishment protocol that you push/set the VPN IP as the default gateway on the client computer routing any and all external requests through the VPN. It does not seem you wish to go this route and I would not recommend it.
At times,the implementation of the VPN default gateway deals/presumes that the remote client is the weakest point and if they can access external resources without restriction and the lan, they might get compromised (if the system is already compromised, the routing through the VPN will sever that ......) and through that the LAN will be compromised.
Yes, IP access will be without issues. Using the push "dhcp-options DNS IP_of_LAN_DNS_Server" You should also push the search domain
will mean that RDP systemname.addomain can be used, the wins push may help in resolving the RDP systemname.
yes, the option exists as part of the VPN establishment protocol that you push/set the VPN IP as the default gateway on the client computer routing any and all external requests through the VPN. It does not seem you wish to go this route and I would not recommend it.
At times,the implementation of the VPN default gateway deals/presumes that the remote client is the weakest point and if they can access external resources without restriction and the lan, they might get compromised (if the system is already compromised, the routing through the VPN will sever that ......) and through that the LAN will be compromised.
Yes, IP access will be without issues. Using the push "dhcp-options DNS IP_of_LAN_DNS_Server" You should also push the search domain
will mean that RDP systemname.addomain can be used, the wins push may help in resolving the RDP systemname.
ASKER
OK, I think I've got that sorted out.
One last question (hopefully). craigbeck metioned RD Gateway. In reading a bit about that it sounds like it would more-or-less work like the "Connect to a Computer" box in RWW. The docs also mentioned that it is accessed via port 443, not 3389 meaning, I suppose, the user accesses it via a browser.
Is that a possibility in this mix (even with VPN, the users need some way of accessing their remote workstations)? If so, does that need to run on an MS Server, or can it run on e.g. a dedicated WIN7. I suppose the RD Gateway server has to be running IIS, right? I'm thinking I could have the router/VPN server redirect these https request to the Gateway server computer. If that's possible, I've closed the loop on my problem!
One last question (hopefully). craigbeck metioned RD Gateway. In reading a bit about that it sounds like it would more-or-less work like the "Connect to a Computer" box in RWW. The docs also mentioned that it is accessed via port 443, not 3389 meaning, I suppose, the user accesses it via a browser.
Is that a possibility in this mix (even with VPN, the users need some way of accessing their remote workstations)? If so, does that need to run on an MS Server, or can it run on e.g. a dedicated WIN7. I suppose the RD Gateway server has to be running IIS, right? I'm thinking I could have the router/VPN server redirect these https request to the Gateway server computer. If that's possible, I've closed the loop on my problem!
You can have both as they are not mutually exclusive and are not in conflict, though that is not really an option for your current plan.
RD Gateway explained: https://technet.microsoft.com/en-us/library/dd560672%28v=WS.10%29.aspx
Requires a windows server OS.
RD Gateway explained: https://technet.microsoft.com/en-us/library/dd560672%28v=WS.10%29.aspx
Requires a windows server OS.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
serialband:
arnold:
If you're going to use a VPN, just have the users enable it on their desktops ...Right, because they can access any IP on the LAN once connected.
arnold:
Requires a windows server OS.Yes, I figured that out, but here is a remote desktop that does not: https://www.nomachine.com/ and a how-to: http://www.techrepublic.com/blog/tr-dojo/set-up-a-free-and-secure-terminal-server-with-linux/. I might check into those later as it would help support some of our home Mac users.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
NoMachine is still a bit slow compared to Remote Desktop for Windows, at least it was when I tried it several years ago for ubuntu. It wasn't available for OSX until about 3 years ago. You'll probably want to set a lower resolution screen size for it to work well.
There is a free open source version of NoMachine at opennx.net, but they haven't advanced past 32 bit Lion support since 2012. There is a version of opennx in Homebrew, but I haven't tried it yet, since I'm always on the command line these days.
I only port forward ssh and rdp for my home systems. I use a hardware VPN at work, as that makes it much easier to support all non-tech users when they need to connect. How many users are you supporting?
There is a free open source version of NoMachine at opennx.net, but they haven't advanced past 32 bit Lion support since 2012. There is a version of opennx in Homebrew, but I haven't tried it yet, since I'm always on the command line these days.
I only port forward ssh and rdp for my home systems. I use a hardware VPN at work, as that makes it much easier to support all non-tech users when they need to connect. How many users are you supporting?
ASKER
serialband:
My current inclination is to research and "play around" with OpenVPN, and likewise with NoMachine for the MAC users, but in the short term do the port-forward approach at the server end using iptables as suggested by Arnold in post ID 40562774. Or ...
Arnold:
I think you guys have really given me a lot of good information and advice. I'll leave this open a bit longer for any additional comment, but I'm pretty satisfied with these insights into my question.
NoMachine is still a bit slow compared to Remote Desktop for WindowsIn fact I've found most things slower than RDC including logmein and teamviewer. RDC was one of Microsoft's better efforts!.
How many users are you supporting?Only 9 but 2 of those are MAC and one never connects remotely, so really 6 including me.
My current inclination is to research and "play around" with OpenVPN, and likewise with NoMachine for the MAC users, but in the short term do the port-forward approach at the server end using iptables as suggested by Arnold in post ID 40562774. Or ...
Arnold:
Another way to handle VPNmis using ssh tunnelsThat looks interesting also -- ssh would insure a secure connection. I'll check into that as well.
I think you guys have really given me a lot of good information and advice. I'll leave this open a bit longer for any additional comment, but I'm pretty satisfied with these insights into my question.
Try not to use SSH tunnels instead of VPN. That is just asking for trouble IMO, and it won't perform as well as VPN anyway.
ASKER
Thanks all! I'm going to keep this listing for future reference. All good comments, points awarded based on number of posts. Wish I could give you all 500!
Workstation2
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3301 -j DNAT --to-destination 192.168.0.101:3389
Workstation3
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3351 -j DNAT --to-destination 192.168.0.102:3389
This mechanism does not validate the access until it hits the workstation.
The SBS workplace you have to provide credentials before the available workstations were listed.
etc. note though a VPN is a more secure way.
Is a VMed Terminal Service an option/considered?
The other option is to use the external services such as from logmein, teamviewer, gotomypc, etc. where you would establish an account and users will loginto it and then access the workstations that are on and connected.