On Mon, May 12, 2025 at 8:14 AM Zujian YU <[email protected]> wrote:
> Hello Nick, > > > > Thank you for the comment. > > > > In our installation, end user (On-Prem) <> AWS load balancer <> AWS > Guacamole EC2, and AWS Guacamole EC2 joined AWS managed AD with one-way > trust to On-Prem AD. > If you're using a load balancer, please be aware that Guacamole does not currently have any native support for coordinating sessions among multiple instances, so your load balancer will need to be configured to consistently send users to the same Guacamole instance based on something deterministic about that user. I haven't used AWS load balancer in a while, but I'm sure there are some various options to configure session "stickiness" that you can employ. > > > It’s unlikely any issue between AWS load balancer <> AWS Guacamole EC2 and > AWS Guacamole EC2 <> AWS managed AD which we managed subnet NACL rules and > security group rules. Can you suggest which path to be checked? > All of the things I already mentioned: * Validate resource utilization on the EC2 systems - make sure you're not running out of RAM, using excessively high CPU, etc. * Validate traffic flow in the VPC - verify that all of the traffic you expect is making it from client to AWS EC2, and from AWS EC2 to RDP servers. Check for dropped packets, routing issues, traffic not making it to the destination, replies not making it back to the source, etc. * Valid traffic flow between the VPC and your on-premise environment - similar to above - is all the traffic making it between the two environments, is anything being dropped, etc.? * Validate connection parameters, particularly with respect to security config. This is less about LDAP and more about the RDP error you were seeing - something is blocking that communication, either network or security-related, and you'll need to dig in to figure out what it is. I'd suggest putting guacd into debug logging mode and reproduce the issue, and see if you get any more information. > > > And as below error logs show: > *00:36:16.119 [http-nio-8080-exec-26] INFO > o.a.g.tunnel.TunnelRequestService - User "userid-***" connected to > connection "1787".* > > *00:36:16.119 [http-nio-8080-exec-26] INFO > o.a.g.t.h.RestrictedGuacamoleHTTPTunnelServlet - Using HTTP tunnel (not > WebSocket). Performance may be sub-optimal.* > > *00:36:26.010 [http-nio-8080-exec-27] INFO > o.a.g.tunnel.TunnelRequestService - User "userid-***" disconnected from > connection "1787". Duration: 9891 milliseconds* > > *00:36:32.609 [http-nio-8080-exec-19] INFO > o.a.g.tunnel.TunnelRequestService - User "userid-***" connected to > connection "1787".* > > *00:36:32.609 [http-nio-8080-exec-19] INFO > o.a.g.t.h.RestrictedGuacamoleHTTPTunnelServlet - Using HTTP tunnel (not > WebSocket). Performance may be sub-optimal.* > > *00:36:50.343 [http-nio-8080-exec-2] INFO > o.a.g.tunnel.TunnelRequestService - User "userid-***" disconnected from > connection "1787". Duration: 17734 milliseconds* > > *00:36:50.555 [http-nio-8080-exec-23] WARN > o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request rejected: No such > tunnel.* > > *00:37:33.522 [http-nio-8080-exec-27] INFO > o.a.g.tunnel.TunnelRequestService - User "userid-***" connected to > connection "1787".* > > *00:37:33.522 [http-nio-8080-exec-27] INFO > o.a.g.t.h.RestrictedGuacamoleHTTPTunnelServlet - Using HTTP tunnel (not > WebSocket). Performance may be sub-optimal.* > > *00:37:49.866 [http-nio-8080-exec-2] INFO > o.a.g.tunnel.TunnelRequestService - User "userid-***" disconnected from > connection "1787". Duration: 16344 milliseconds* > > *00:37:50.071 [http-nio-8080-exec-21] WARN > o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request rejected: No such > tunnel.* > > What’s those GuacamoleHTTPTunnel error means? Is that something inside > guaca service? > There are a couple of things going on, here. First, it looks like the AWS load balancer either does not support or is not configured to support WebSocket tunnels. As the log messages say, this can impact performance - the HTTP tunnels should work, but the performance will be lower than it would if WebSockets worked. I don't know if the AWS load balancer supports WebSockets at all - probably it does if you're using a Layer3/4 method, but it's possible the Layer7/HTTP load balancer just does not support it. Second, I suspect you're actually seeing the results of what I mentioned above - that the load balancer is sending sessions to different Guacamole Client back-ends (Tomcat instances) and not persistently assigning sessions to the correct server. So a user logs in with one Guacamole Client instance, opens a connection, and then gets sent to another instance that has no knowledge of the connection that has been opened. Again, you need to check the session persistence (stickiness) configuration of the load balancer and adjust so that clients consistently get sent to the same Guacamole Client back-end. -Nick >
