guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Couchman <>
Subject Re: http as a guacamole protocol
Date Wed, 03 Oct 2018 00:36:07 GMT
Warning - TL;DR.  Summary version: The decision was not made arbitrarily,
there was a reason for it, to keep the features of the project within the
defined scope.

> Hello
> Thanks for your reply, and the link. I did not find that in my googling.
> although i was looking for instruction on how to configure it in today's
> guacamole, since it seemed such a obvious thing to me.

The JIRA issues do not always show up in search results - I don't know how
much indexing is done of the JIRA instance by search providers like
Google.  In the future, if you're ever curious about a feature request,
bug, etc., you can always go to the JIRA page and browser/filter/search
that way.

> very sorry to hear that it have been considered, and found unwanted..  It
> seems a bit odd to me to limit the usefulness of a tool due to some
> arbitrary scope. unless that scope is required in order to secure financing
> the project or something similar.  Since guacamole is an excellent remote
> management tool for the things it supports, it makes it a pity that it can
> not support the other common remote management protocols.

I sense some frustration here :-).  When you say "arbitrary scope" you are
implying that we (the Guacamole Project) have decided not to implement this
feature without any reason at all - "based on random choice or personal
whim, rather than any reason or system."  Your assertion that this decision
was made based on random choice or personal whim is not true.  It was
decided that it was outside the scope of the project - that is, the project
already had a scope and definition, and the maintainers of the project
decided this was not within that scope.  It was not random, or a personal
whim, and it also was not without any consideration or discussion.

> I may have misunderstood guacamoles purpose. what are people use it for if
> not remote management via desktop and ssh... is the intention a VDI
> solution fopr end users?
Apache Guacamole is a clientless remote desktop gateway. (Take from the
home page,

The key that I'd ask you to focus in on, here, is "remote desktop
gateway."  Its goal is to broker remote desktop connections between web
browsers (as the client) and the back-end servers.  Several remote desktop
protocols are supported - RDP, SSH, Telnet, and VNC - with others being
added (Kubernetes console support has recently been merged into the guacd
side, SPICE protocol support has been requested, though not implemented,
and a X(11/free86/org) Guacamole driver is in the works).  All of these,
both supported and in progress, are protocols that are recognized as
"remote desktop" protocols at some level or another.  HTTP does not fall
into that category.

What Guacamole is *not* designed to be is a comprehensive web-based SSL VPN
(e.g. Cisco AnyConnect, FortiNet, PaloAlto Global Connect, etc.).  It's
true that most web-based SSL VPNs implement both a generic reverse proxy,
allowing you to access web pages within the protected network from that
browser session, and also some subset of remote desktop connections, like
RDP or SSH.  Guacamole is not trying to be a web-based SSL VPN, even if it
has features that these software packages routinely implement.

Guacamole could, however, be one piece of a larger, overall solution, for
whatever use you have for a "clientless remote desktop gateway."  It could
certainly be part of a SSL VPN.  I, personally, would love to see a
complete, Open Source, web-based SSL VPN implemented that included
Guacamole as one of its core components, but also included things like
reverse proxy, file sharing/browsing, and port tunneling.  It could be part
of a VDI solution, though, in itself, it is not a VDI solution.  It could
be part of a method for providing centralized access to a server farm,
without requiring additional client installs.  There are many possible ways
that it could integrate into a solution with a broader scope.  At a
previous place that I worked we used it to provide access to legacy
applications that we did not want to (or could not) distribute to
everyone's system.

> I do run both nginx and haproxy as revers proxies for things where this is
> appropriate (web clusters and such) but i was looking for a solution that
> gave me access to a web based management interface that are not meant to be
> available online without a security login with 2FA like guacamole.
> I use openvpn access server today, with 2FA. and it does it's job. I can
> access rdp/ssh/vnc/http/etc  but it is a bit clunky when you connect to
> different gateways all the time. and guacamole was a much "sexier" and
> smoother solution.
On behalf of the project, I'll take the "much sexier and smoother" as a
compliment :-).

> I agree it may not "fit" into guacd, but there should be nothing stopping
> someone from making a gauc-p revers proxy that could be accessed via the
> guacamole web interface. all it needs to do is what ssh -D8080 does today
> in practicality. but since the requirements are small i would think adding
> a guacd client plugin that functioned as a tunnel would be more sane,
> instead a whole new server.
Certainly, there is nothing from stopping anyone from adding this
functionality to Guacamole.  One of the beautiful things about open source
software is that, if you don't like what's already there, you can take the
source code and modify it to fit your needs.  I do realize that not
everyone has the skills to do this, and that puts you somewhat at the mercy
of the community that is developing the project, but those of us developing
the project also have limitations - sometimes skills, but also time and
money - and we have to draw feature lines somewhere and focus on features
and improvements that we feel are important to the current scope of the
project.  You can see from the number of opened JIRA issues for the project
that there is no shortage of directions for us to go at the moment.

I'd also point out that I think you miss a little bit of the complexity
here in what Guacamole is doing behind the scenes.  You assert that
(paraphrasing) it should be as simple as "ssh -D8080", but that's not
really true.  What Guacamole is doing behind the scenes is taking remote
desktop protocols, like RDP, SSH, and VNC, translating those protocols into
the Guacamole protocol (yes, Guacamole is a protocol, not just a
client/server), and then sending that on the web browser (essentially as
either JPEG or PNG images plus audio, clipboard, and file transfers).  This
is different than doing port forwarding or establishing some sort of VPN
tunnel between your browser and the remote server.  Here's some quick (and
very poor) ASCII Art to illustrate the flow (using RDP to a Windows Server
as an example):

Web Browser Client <-- (HTTP and/or WebSocket) --> Guacamole Client <--
(Guacamole Protocol) --> guacd <-- (RDP) --> Windows Server

Essentially, and very simply, adding HTTP support would involve having
guacd render the web pages itself, and then generate the images (+audio,
clipboard, and file transfers) to send via the Guacamole Protocol over to
the Guacamole Client, which would then provide that via HTTP(s) or
WebSocket(S) to the browser.  I've no doubt that it *could* be done, but
this isn't really the function of a remote desktop gateway or client, it's
more like a VPN or reverse proxy.  It's also ever so slightly more complex
than just forwarding a port on the client to the server.

Finally on this point, you mention "adding a guacd client plugin" to do the
port forwarding.  This would go directly against one of the key goals of
the Guacamole Project - *clientless* remote desktop gateway, where
"clientless" is referring to not requiring any additional client or plugin
within the web browser.

> Since guacamole is limited to displaying Is it perhaps possible to do a
> single application of a remote desktop X11 application via guacamole, that
> could open just a single browser, to "cheat" into getting a web page at the
> remote location. that could run the remote "browser" on the guacd linux
> server host.
> Yes, this is certainly a way you could work around the challenge - you
could have a RDP (XRDP, if you like, on Linux) or VNC connection open
Chrome or Firefox, and you could then use that to browse around the
internal network.

Hopefully I've been able to clear up the goals of the project and answer
some of your questions.  I'm sorry that it appears to have frustrated you,
but hopefully now it makes more sense what the project is trying to
accomplish, and, just as importantly, what we're not trying to accomplish,
achieve, or be.


View raw message