Data limit for (website) entries through the Devolutions Gateway
3 votes
I am opening this feature request on behalf of a customer regarding bandwidth performance for Website sessions routed through Devolutions Gateway.
The main topic is file transfer throughput when using a Website session through the Gateway compared to a direct connection.
Customer-reported results:
During internal testing, we also observed a notable difference in bandwidth results:
Could the team review the current bandwidth behaviour for Website sessions through Devolutions Gateway and evaluate whether performance improvements, configuration recommendations, or documentation updates could be considered?
Thank you.
Patrick Ouimet
Hi there!
We use Remote Desktop Manager and Devolutions Gateway from within a jump zone to effectively limit open ports and accesses to server and management VLANs by the firewall. This might not be the original intended use case for the Gateway. However, that provides an effective way to protect our systems and avoids bypassing RDM.
Updating our Dell VxRail vSAN Cluster requires uploading large Dell VxRail update bundles (>16 GB) over https to the VMware Virtual Center Service Appliance. With the Gateway's low bandwith those uploads take forever and tend to fail. Either because of timeouts or certifcate issues. Additionally, the vCenter Client Web-UI isn't accessible after an upload failed.

Would be great if the developers at Devolutions could find a solution to get rid of this Gateway's limitation.
Best regards
Roman
ca8e3e6c-e907-496f-86f6-4d6a4cca8b3f.png
59ced3f4-ee9f-405e-ac6b-0f3db74a0bb1.png
5ce2d052-a098-4429-84e2-44b5e630e3cc.png
ceb51e6b-799d-4419-ba49-e56031f15972.png
fbc32200-8a93-40ec-b1d4-7ac12079b729.png
We use DVLS with RDM to manage Applianes, Switches, Firewalls and therefor need a useable upload speed for firmware images and so on. The current speed is unusable and causes a lot of frustration for administrators. They need to bypass for these use cases, but this is bad for security.
Please fix this very soon - this request is internal open since over a year.