Hello Nick, thank you for your suggestions. That gave me new ideas to test. Let me leave my approaches here as food for thought for others:
* Install a new clean VM and test with that. * First, I tested with a self-built guacd. Then with the EPEL package. * Test with minimal config and try to get minimal config working via the text configs. Outcome: New test system worked fine. Next I was trying to repeat the steps on my prod system. Reinstalling didn’t make a difference with the self-build or EPEL package. Next was to re-configure the RDP connection based on the minimal working connection. Eventually I found the issue when deselecting these boxes in the device redirect section of the UI: * Activate Audio input (Microphone) Best wishes, Stefan From: Nick Couchman Sent: Dienstag, 16. Juli 2024 23:07 To: user@guacamole.apache.org Subject: Re: Assistance for troubleshooting RDP connection EXTERNAL: Use caution when clicking on links or opening attachments. On Tue, Jul 16, 2024 at 3:34 PM Stefan wrote: Hello all, since quite a while (not sure when), my previously working RDP connection to a Windows Server 2016 stopped working. When connecting, the screen waits on "Connecting to Guacamole. Please wait" (Original in German: "Verbindungsaufbau zu Guacamole. Bitte warten..."). I somehow do not seem to get a debug or trace from guacd (version 1.5.5 using the Enterprise Linux 9 package) This seems to be a theme on the mailing list these days - a number of folks who have reported issues with Guacamole are using the EPEL packages. I have no idea who maintains these packages (they are not officially pushed by the project), so it could be that one of the recent updates to the packages has broken something. I'd advise that you try to build it yourself and see if that works any better. # guacd -f –L trace guacd[416115]: INFO: Guacamole proxy daemon (guacd) version 1.5.5 started guacd[416115]: INFO: Listening on host ::1, port 4822 guacd[416115]: INFO: Creating new client for protocol "rdp" guacd[416115]: INFO: Connection ID is "$ea2429b9-fc2e-4256-af84-8bef6a72556c" guacd[416194]: INFO: Security mode: TLS guacd[416194]: INFO: Resize method: display-update guacd[416194]: INFO: No clipboard line-ending normalization specified. Defaulting to preserving the format of all line endings. guacd[416194]: INFO: User "@c75ee746-c670-4c9f-921b-b457e906705a" joined connection "$ea2429b9-fc2e-4256-af84-8bef6a72556c" (1 users now present) guacd[416194]: INFO: Loading keymap "base" guacd[416194]: INFO: Loading keymap "de-de-qwertz" As far as I understand, the Windows TerminalServices event logs do not show the connection attempt. Using the linux client Remmina works fine. Is this Linux client situated similarly on the network to the system running guacd? Can you please help me troubleshoot this? Sure, a few suggestions: * As mentioned above, build packages from source and see if that works. * Do a packet capture on either the guacd system, the Windows Terminal Server, or both, and see if you're seeing the connection attempt. * Make sure SELinux isn't blocking anything (audit2why can help with this). Possible changes I can imagine: - Linux update - Windows Update (change in connection methods?) - Expiry of certificates - IPv4/IPv6 changes Certificate expiry seems like something that would show up in guacd logs. Windows Updates - maybe, but I think a lot of other folks would be reporting that (I connect to Server 2016 systems routinely and am not seeing any issues). Linux updates, IP changes, etc., definitely worth tracking down. -Nick
