DVLS Server & Gateway & Session Recording

Hello Andreas,

When you have a session configured to pass through a Devolutions Gateway, the recording will be automatically saved on that Devolutions Gateway. In your situation, if I understand correctly, you have one Devolutions Gateway configured per customer so all sessions with that customer pass through a different Devolutions Gateway and will be saved on that Devolutions Gateway. And if the session doesn't use a Devolutions Gateway, the default one will be used to save the recording.

It is important to note that when you want to access those recording via RDM or the web interface, it doesn't matter where the recording has been saved. They will be played from the right Devolutions Gateway without any problem. If you want to uninstall a Devolutions Gateway and don't want to lose your recording, it is possible to move them on a different Gateway and index the recordings here in the web interface. And after that, you should be able again to play all recording from RDM or web interface.




I hope it helps to understand how it works. Let me know if you have other questions on how it works

Best regards,

Hi Francois

No, we would like to use only a central Gateway as Recording Server only, and other Gateway Servers on Customer Side only as VPN Server.
So when a Customer has a Gateway for VPN configured, im not able to select our central Recording Server for Session Recordings.

In your case our Customers would be able to access those Recordings, and this is a No-Go for our ISO Certification.
So we need to specify a single central Recording Server which is valid for all Vaults, but also each Vault will have one or more DVLS GW Server as VPN Server for Connections only. For Recordings, nothing else can and should be used as the central defined Recording Server.

Is that achievable?

Best regards,
Andreas

Hi Andreas,

While I can understand from your description the reasons why you would like to make the connection go through a specific Gateway while the recording is sent to a different Gateway, this is not something currently achievable, and poses a few challenges with the current way we've designed things. For instance, it is possible to automatically disconnect a session going through a Gateway if the same Gateway is being used for recording and the recording is cut off, something which becomes harder to do if the connection and recording are independent.

This being said, thank you for your feedback. We don't have a solution right now, but we'll consider it as we further improve the product to handle more use cases.

Best regards,

Hi Andreas,

We are currently designing an extension to our existing recording server to accommodate more cases like yours.
If you don’t mind, can you answer a few questions to help me understand what is acceptable and what is not on your side?

Devolutions Gateway is able to check that a recording is being pushed for a running session, ensuring no one is bypassing the recording policy.
This is harder to achieve when the recording is not being pushed to the same Devolutions Gateway instance.

We are considering extending Devolutions Gateway to allow pushing the recording files from one instance to another once the session is terminated.
This means the recordings will still be pushed to the "VPN Gateway", and only later moved to a specific "Recording Gateway" (or a "Recording Farm" sharing the storage via a VFS).
Recording transfer may also be delayed based on the Recording Gateway’s current load.
This design allows for backpressure, avoiding overloading the Recording Gateway in setups with many VPN Gateways and a single or very few Recording Gateways.
It’s also possible to start new sessions even if the Recording Gateway is down, as the recordings may be pushed later.
Eventually, all recordings are removed from the VPN Gateways and archived at a centralized location.
This design is expected to accommodate some users very well.
It has the benefit of requiring less resource, reducing the chance of experiencing instability due to an overloaded Recording Gateway.

With that in mind, here are my questions for you:

• Is it fine if the files are stored temporarily on the VPN Gateway, or is it a no-go for you?
• Is the recording policy enforcement something you need?
• Are you expecting usage spikes across many VPN Gateways?

I’m confident we can come up with a solution to accommodate you. Your answer will be used to help us decide the direction where efforts should be directed.

Thank you,

Hi Benoit

Thank you for your answer. I will try to explain our scenario.

We are an IT Provider and we only use RDM/DVLS to connect to our Customer Environments and for internal purposes.
Currently we are using just a single DVLS Gateway at all which is configured as Recording Server and this is working very good for our use cases.

What we need is only an option to force all Recordings to be stored on a single Recording Server. Without this Function we are not able to use other DVLS Gateways for VPN Servers and are still forced to use our SSH Tunnels.

To your Questions:

• Is it fine if the files are stored temporarily on the VPN Gateway, or is it a no-go for you?

No. Our Recordings should only available and accessible for our Company employees.

• Is the recording policy enforcement something you need?

Yes, we are using the enforcement allready for several Vaults.

• Are you expecting usage spikes across many VPN Gateways?

Due the Problem with the Recording locations on external Gateways we have only a single GW at the moment. And this is working very good so far.

Were still looking forward for an option to implement DVLS GW as VPN Servers.

Thanks and best regards,
Andreas

Hi

Are there any Updates regarding our Problem?

Best Regards,
Andreas

Hi Andreas,

I’m sorry for the silence so far.

Since then we’ve discussed about this internally, but unfortunately this did not make it on our roadmap for now.
I drafted a proposal, and it got clear that the associated work is quite significant, so this can’t just be squeezed into a minor release either.

I’ll make sure to keep you updated when this gets prioritized.

Best regards,