possibly you may use Royal Server in combination with Secure Gateway to securely tunnel your RDP connections? Basically the Secure Gateway is a SSH tunnel where active connections will get tunnel'ed through. Probably this may solve your audit requirements? Furthermore this is also possible on connection level, as you wrote (as you can have multiple Secure Gateways). May this help you in that case?
Probably not... In order to audit the connection we do not want the additional encryption. We are using a security product that acts as a man-in-the-middle for Remote Desktop connections... It supports connections via SOCKS5 for transparent encryption and decryption, but would probably not be able to decrypt the SSH tunnel to perform the audit.
Royal TS is using the Microsoft RDP ActiveX control which ships with Windows. We checked the API and it seems there's no SOCKS5 support or any other proxy support available in RDP except for Remote Desktop Gateway servers.
Correct me if I'm wrong, but to implement the Security Gateway functionality you probably create a tunnel that forwards a local port to the target, and then use the Microsoft RDP ActiveX control to connect to the local port. Implementing SOCKS5 support would work exactly the same... You would open a Socket via the proxy server to the target, open another socket on the localhost and forward all traffic from each Socket. For examples in C# see:
Note that I have purchased RoyalTS for my own personal use already... But I would like to convince my company to purchase the global license so that others can use it, and this would be key functionality.
I'm not sure that's correct. The links you provided are samples on how to create a proxy server. With our Royal Server as Secure Gateway / SSH tunnel you already have a SOCKS5 capable proxy (see Chrome web page connection's proxy support). The issue is that the RDP ActiveX control only accepts a server name and port. There's no way to specify which proxy to use and the TCP communication from the ActiveX control can not be changed as the ActiveX is a black box where we don't have the source code.
You are missing the point. The Secure Gateway does not meet the need because it adds an additional layer of encryption.
What I am suggesting doesn't require any changes to the ActiveX control.
We need support for a non-secure Gateway, i.e. a non-encrypted tunnel so that we can audit it for regulatory compliance. We have software in place that will decrypt both SSH and RDP protocols if they are passing through a specific software package that behaves as a SOCKS5 proxy server, but not if they are passing through a SSH tunnel or a different SOCKS5 proxy that is provided dynamically by a ssh connection. The auditing software is CryptoAuditor ( https://www.ssh.com/products/cryptoauditor/ ). There are several competing audit packages that provide similar functionality, they are very common in extremely large companies that are subject to regulatory compliance such as PCI-DSS, Sarbanes-Oxley, HIPAA, etc...
The links I sent do not show how to create a proxy server. They show how to use a SOCKS5 proxy server to create a non-encrypted tunnel from a local port to a remote server and port via a SOCKS5 proxy server.
You would set this up to listen on a random unused local port for each connection which would forward to the true target, and simply use the RDP ActiveX control to connect to the localhost and local port. Since the RDP ActiveX control doesn't support SSH tunnels either, I expect this is exactly what you are doing with the SSH tunnels in the Secure Gateway feature.
The difference, which is critical, is that the connection via the SOCKS5 proxy server isn't encrypted again, and it is using a SOCKS5 proxy server that we specify, not one that is created dynamically by SSH.
If this still doesn't make sense, I can probably mock up some code in C#.
I'm sorry, I'm now more confused than before. If you can hack some C# code to demonstrate how this would work, we can definitely take a look at it. Please send us the code and some instructions on how we can easily test the implementation to firstname.lastname@example.org
I also wished RDP in Royal TS for Windows had support for SOCKS5 proxies. My interpretation of Jody's request is that you should implement pretty much the same thing you already did with the Secure Gateway feature. Secure Gateway opens an SSH connection to the "proxy" and creates a tunnel which listens on localhost on a random port. Royal TS then instructs RDP to connect to localhost and that port and ssh forwards the connection to the real target. What Jody suggests is that instead of ssh you use a SOCKS client which does the same work in principle. Listen on localhost on a random port, let RDP connect to that port and then forward the connection through the SOCKS proxy.
Since Remote Gateway already provides the framework for this it should be very simple to replace the ssh client with a socks client and to provide an option to switch between the two.
Just to clarify, we use the MS RDP ActiveX control which ships with Windows and the limitation is the MS implementation. Since the RDP ActiveX control doesn't support SOCKS proxies, we can't do anything about it as it's a closed source binary we are using. As mentioned in the other thread, we are working on a FreeRDP implementation although I'm not sure if the windows CLI supports SOCKS proxy parameters. At least according to the wiki page, SOCKS cannot be passed through command line arguments: https://github.com/FreeRDP/FreeRDP/wiki/CommandLineInterface
I am well aware that MSRDP ActiveX is closed source and does not support the use of proxies. The point I am trying to make and I believe Jody was pointing out was that you do not need built-in support for proxies. Royal TS can use ssh proxies in the Secure Gateway feature. This obviously works with the ActiveX version. The way I understand it this is done by the following steps:
Are you really sure FreeRDP doesn't support /proxy args on Windows? There is a specific issue for it in 2020-12 saying it used to work, and then FreeRDP claims to have fixed it.
I still think it would be great to have SOCKS as an available type on Secure Gateways, like my original post here in order to centralize management, but the "Default or Alt-key" did work for what I was doing.
Side Note: I would be pretty excited to have the FreeRDP version, though for slightly different reasons.
I'm still missing something, I guess because I don't understand how this should work. If you can provide some working code (preferably in c#), I may get a better understanding what you are trying to achieve. As you pointed out, port forwarding using SSH is already possible. For SOCKS support, the RDP client needs to support it directly on a protocol level - to my knowledge. I'm not sure how I can "teach" MS RDP to use a proxy otherwise.
The SOCKS support for RDP works wonderfully in Royal TSx for OSX. I use it extensively every day.
The FreeRDP libraries support this and royalapps have impemented it in the TSx application.
please check out this topic:
The FreeRDP plugin we use in Royal TS V7 beta (https://support.royalapps.com/support/solutions/articles/17000128632-royal-ts-v7-beta) supports SOCKS5 and HTTPS proxy already.
The argument above is related to Microsoft's RDP ActiveX control. Since this is a black box (closed source binary shipping with Windows), we can't really support proxy configurations without MS implementing it in the ActiveX.
Is there a way to configure the use of a SOCKS5 proxy for connection to RDP targets? Ideally on a per connection level as can be done with SSH?
I'm aware of the TS Gateway, Royal Server, and Secure Gateway options, but we have a requirement to pass connections through several proxy server to meet audit requirements. There are separate proxy servers for development and production environments, so we would like to configure this at the connection level, not the system level.
1 person likes this idea