Hi,
I have no familiarity with the internals of Guacamole, but I do have a
pretty strong network knowledge.
Reading this email thread, the symptoms are very similar to something
that has bit me more than once in my career. If there is a statefull
firewall configured somewhere at either end of the connection, there may
be a chance that the firewall is expiring states too quickly.
Given that the web browser is opening a "tunnel" to Tomcat, rather than
a more typical "short lived" https connection, a
(misconfigured/aggressive) firewall may just think that wow, that
connection is taking way too long and close the connection (even though
there is traffic over the tunnel).
I'd probably start on the client running Wireshark to capture packets up
until the first reconnect. Unfortunately, analyzing a Wireshark data
capture takes some very technical networking knowledge.
I have to agree with Nick in that it seems likely to be a network level
issue (either end) with the one ISP.
Cheers,
Steve Williams
PS. I did a quick google and found the following blog post. I have
never used sonic wall, but this is exactly what I was referring to,
except over a VPN rather than a HTTPS tunnel.
https://www.cantarus.com/news/blogs/details/SonicWALL-VPN-Tunnel-Configuration-Best-Practice-for-Remote-Desktop-Services
...
TCP Timeout
In my experience, the single biggest cause of dropped RDS connections
over VPN tunnels is due to TCP timeout settings that are too low.
When creating a firewall rule in SonicWALL firewalls, the TCP Connection
Inactivity Timeout is set to 15 minutes by default. Although one might
consider that an active RDS session should not be considered inactive by
the SonicWALL, in practice this value can indeed cause the RDS
connections to be dropped. Based on experience, I recommend this is
changed to at least 120 minutes.
...
On 16/12/2020 11:22 a.m., Nick Couchman wrote:
On Wed, Dec 16, 2020 at 12:46 PM Pietro <[email protected]
<mailto:[email protected]>> wrote:
Hi Nick,
Honestly we are not convinced the issue is on the network. The 4G
connection
we experienced the issue with is fast and it is used daily with no
issues or
slowdowns. It is used for conference calls and with various remote
desktop
protocols (VNC, RDP) and clients (noVNC, xfreerdp and rdesktop)
with no
issues. We would like to use Guacamole with it as well.
Whether the network is performing well or not does not necessarily
indicate whether they're doing something to the traffic that could
adversely impact the way in which Guacamole works. I'm not saying it's
definitely the network, but, if that's the only network on which you
experience problems, and other networks (like a different 4G network
or WiFi) work fine, then I suspect it's something somehow related to
the network. I'm just looking for common issues that point in one
direction or another.
Do the logs we sent you suggest that there might be problems in the
guacamole code/protocol?
No, the logs you've provided are not indicative of any problems in the
code or protocol. Furthermore, again, the fact that it works fine on
some networks (including other 4G networks), and that there are not
many other users on the mailing list reporting these types of issues
makes me less inclined to believe there's a bug in the code.
The logs you sent indicate that guacd is not receiving the messages it
expects from the client in the timeframe it expects them. This could
be an issue with Tomcat or something else on the server, but it also
could be an issue where the messages from the client are getting
dropped somewhere along the way. Based on the information you've
provided, I lean toward the later, but, again, it's just my guess.
In particular if you check the events timing and their correlation
with the
components involved in the chain (e.g. browser-side and
Tomcat-side) you
should notice that "strange" things happen.
Based on the log messages you provided, what I see is:
- guacd stops receiving messages from the client, for some, as yet
unknown, reason.
- After a timeout period, guacd shuts down the connection, assuming
that the user is no longer there.
- Tomcat complains about the fact that the connection to guacd has
been terminated unexpectedly.
The only thing "strange" about this is why guacd stops receiving
messages from the client, which is what needs to be investigated. The
rest of the messages seem pretty normal to me.
We are evaluating the use of Guacamole in an environment where
there might
be up to 25 concurrent users connected to the same RDP target (or
VM). Users
are spread all over the Europe and access through various
networks, from
here our concerns.
Sure, understand the concern and the need to get it working correctly,
and we're happy to help you work through the issues. But, I'm not
seeing any signs of a bug in the code or protocol at this point.
You might have to do some network packet captures to see if the
traffic is making it all the way through - that is, if you capture the
packets between the Browser and Reverse Proxy, then between Tomcat and
guacd, do you see all of the traffic that you expect to see, or are
things dropping along the way. Note that, because you're doing a
reverse proxy and (likely) encrypting it, you won't be able to see the
contents of the packets themselves, but you should at least be able to
see the number of packages and relative size and correlate it to what
is getting sent on to guacd. It won't be a 1-to-1 correlation (not
every packet to Tomcat should be sent on to guacd), but hopefully some
patterns will emerge.
-Nick
