I'm evaluating Royal TS and it looks awesome! However there is one feature missing that would be mandatory for my use-case: using multiple security gateways in series.
In our case, we need to login to a central security gateway. This 'tunnel' login is extremely restricted (e.g. cannot allocate a tty). It can only be used to tunnel another connection to a select range of internal security gateways (one for each department). Again, this departement security gateway does not allow allocating a tty and can only be used for tunneling. Once this second tunnel is established, it's possible to connect to the internal machines.
I've seen a few similar requests on the forum, but they are already 2 years old.
Is this a feature that is still somewhere on the roadmap?
we don't have it on the roadmap right now. I've done some research on our forum and noticed that there are quite some requests like that. I will see if we can squeeze it in our V6 roadmap.
Can you provide a sample, workflow or product you use right now with your setup?
We currently use DoffenSSHTunnel ( https://sourceforge.net/projects/doffensshtunnel/ ).
It makes it very easy to create tunnels inside tunnels (inside tunnels....).
The authentication we use is purely key based with kageant (part of KiTTY SSH). The security gateways are defined as branch nodes in a tree structure and the individual ssh sessions are the leaves of the tree.
DoffenSSHTunnel uses putty's plink cmdline tool in the background to setup the required tunnels.
This setup has a few drawbacks regarding maintainability.
- Adding new ssh servers often requires modifying the security gateway nodes (e.g. adding an extra tunnel). Ports are assigned statically at creation of the node.
- Very difficult to maintain and synchronize ssh server leaf nodes if multiple intermediate paths are possible (basically, each path requires a separate node)
- Not possible to customize configuration file path
- Not possible to use shared configurations
- Some other (irritating) bugs in doffenSSHTunnel itself
Royal TS seems to provide a solution to all of them, except the 'chaining' of security gateways :-)
thanks for the information. Just to be clear about the 'chaining', you are looking for something like this:
Host A is your client (Royal TS)
Host B is a gateway server which is reachable from Host A
Host C is another gateway server which is only reachable from Host B
Host D is your target machine you want to connect to but can only be reached from Host C
To 'chain' this together, Royal TS would ideally do the following:
Host A opens a tunnel (local port forwarding) to Host B. A dynamic local port (let's say 5422) is allocated.
Host A then opens another tunnel to Host C through the local port forwarding on 5422. A new dynamic local port is allocated (let's say 5602).
Host A can then connect to the target machine through port 5602.
Is this what you have in mind?
We will definitely look into it. Thanks for the feedback!
Just out of curiosity and because I have no idea about your planning or release schedule:
Do you have any guesses about a time frame for this feature? Couple of weeks, months, year...?
this feature is under investigation and we're not sure if or how exactly we can implement that. If we implement it, it will be in the next major version and since we are switching to net5 and have some dependencies there, it will probably be at the end of the year (November/December) at a minimum. We are working on beta releases but since we haven't got the linker for net5 working, the output of the app plus the framework is roughly 440 MB - which is kind of high ;)
We're almost at the end of the year now. Do you have by any chance an update about this feature request?
it's still on our list to do a prototype/POC. We are currently working hard finalizing the beta release. There's a good chance that this feature will not make it into the first beta but we really hope to have it on board before we release V6.
Sorry for the delay.