Detailed per-connection logging for Gateway Tunnels with dynamic targets (socks/http proxy listener)

Hello,

You're absolutely right, the Devolutions Gateway Tunnel behaves similarly to SSH port forwarding, with the key difference being that it doesn't require an SSH server. Like SSH tunnels, the details of individual connections within the tunnel are not currently tracked or visible in DVLS.

That said, since both Devolutions Gateway and DVLS are our products, I agree there's room for improvement in this area. While you can inspect the Devolutions Gateway Tunnel entry to see which destinations are allowed, this isn't ideal: it doesn't tell you which destinations were actually accessed, or when.

As you suspect, it's feasible to capture several useful details, such as the user initiating the session, start and end times, target host and port, and data transfer volumes (inbound and outbound bytes). However, identifying the protocol is less straightforward. Like with SSH port forwarding, we simply relay traffic to the target host and port, without interpreting the payload, meaning the protocol is opaque to us.
Protocol inference based on port numbers (e.g., 80 for HTTP, 443 for HTTPS, 3389 for RDP) is possible, but not reliable. However, given that you’re familiar with your own infrastructure, it's likely you can determine the protocol based on the destination host and port if needed. In that case, the information we can provide may still be sufficient for your needs.

That said, this isn’t so simple either. For example, a single browser session, opening even a single web page, might result in hundreds of brief sub-connections, raising questions about how best to represent or aggregate this data. We'll need to consider how to handle such cases.
I'll bring this topic up internally for further discussion.

Best regards,

For auditing purposes it is fully sufficient to protocol just the protocol as TCP or UDP and port used. I did not mean actual L7 protocol that was used.
Of course HTTP/HTTPS Connections are another beast, but as there is a native way of logging those via Web Session entry that just logs start and end of the session being used i rather doubt someone would get the idea to log each single http request via socks/http listener.

However, threre are external tools like terraform that use indeed http/https traffic. I do not think it is reasonable to protocol each single request in such case.
I guess the best implementation would be if the logging would be done on a filter entry level. Therefore it could be individually enabled for some targets and disabled for some other ones...

Or at least aggregate the informations and log on session close just for each target protocol(udp/tcp), ip and port the number of connections, total data sent and total data received. That way you do not run into flooding logs with extensive amount of entrirs yet still being able to proove that someone did make a connetion to a given target system...

For auditing purposes it is fully sufficient to protocol just the protocol as TCP or UDP and port used. I did not mean actual L7 protocol that was used.

Makes sense, sorry for the misunderstanding. In that case it’s definitely not a problem at all.

Of course HTTP/HTTPS Connections are another beast, but as there is a native way of logging those via Web Session entry that just logs start and end of the session being used i rather doubt someone would get the idea to log each single http request via socks/http listener.

However, there are external tools like terraform that use indeed http/https traffic. I do not think it is reasonable to protocol each single request in such case.
I guess the best implementation would be if the logging would be done on a filter entry level. Therefore it could be individually enabled for some targets and disabled for some other ones...

Configuring a SOCKS5/HTTP listener from a Devolutions Gateway Tunnel is actually useful when using browsers that are not necessarily supported by RDM directly. There are also tools like you mention that are behaving like browsers.

Or at least aggregate the informations and log on session close just for each target protocol(udp/tcp), ip and port the number of connections, total data sent and total data received. That way you do not run into flooding logs with extensive amount of entrirs yet still being able to proove that someone did make a connetion to a given target system...

Indeed.

I see we have a few options here:

1. Do not log all the details for Web Session entries
2. Do not log all the details for connections on ports 80 and 443
3. Aggregate the information such that we only have one entry per target (a target being defined as "protocol://ip:port" with protocol "tcp" or "udp")

We do not support UDP yet, but I’m thinking that, if we ever support it, aggregating the information will be necessary for UDP anyway since it’s not connection-based.

Right now I’m thinking that combining options 1 and 3 would give the best overall experience, but we’ll have to experiment a bit.

Incidentally, we just had an internal discussion about this, and we agreed on a solution that could be implemented in the next development iteration, and you can expect the feature to be delivered by the 2025.3 release.

The solution would be as follow:

• During the session, aggregate data on Devolutions Gateway side, persisting it into a SQLite database.
• Once the session is terminated, make this data available via a new HTTP endpoint.
• DVLS uses this endpoint to "pump" the information. The data is removed from Devolutions Gateway and persisted on DVLS side, as session activity logs.

Properties of this solution:

• Since the data is persisted in a database on the Devolutions Gateway, even if the Gateway is shut down, the data remains and can be pumped later on by DVLS when up again.
• The activity logs will not be visible in real time. But since it’s for auditing purpose, "eventually visible" is typically fine.

I’ll create an ticket and link this thread to it.

I think that the best choice would be to leave the choice for the user :) You cannot know whether this is http/https just based on ports, because it is very common to have http on ports like 8000, 8080 etc. the same for https. 8443 being one of the most often used ones.

If you could however decide per filter entry to either do not log details at all, or log individual connections or just aggregate logging data on session close this would be the most universal and fit all solution. That way you could for exampe log every individual connection to port 22, and just aggregate targets for port 8443 and maybe not even try to log for something that is not needed...

And having (together with user name and maybe client IP) target IP, port, protocol(tcp/udp) time started/ended and number of bytes sent/received would be just awesome. For aggregated connections just add number of connections within this time frame. And keep default ad do not log details.

It is also great news to have this implemented pretty soon, as we need this for compliance reasons and until this feature is not there we cannot allow proxy tunnel type entries at all.

Best Regards,
Bart

Thank you for your message.

I think that the best choice would be to leave the choice for the user :) You cannot know whether this is http/https just based on ports, because it is very common to have http on ports like 8000, 8080 etc. the same for https. 8443 being one of the most often used ones.

If you could however decide per filter entry to either do not log details at all, or log individual connections or just aggregate logging data on session close this would be the most universal and fit all solution. That way you could for exampe log every individual connection to port 22, and just aggregate targets for port 8443 and maybe not even try to log for something that is not needed...

You are right. This is something we’ll need to discuss with the team. The initial version may not be so granular, but we can imagine many future improvements like this. We’ll start with something we are confident we can deliver in a timely fashion and work from there.

Best regards,