Re: Quacamole broken due to application inspection

[Chris Thompson]

I'll have to give that a try. In addition to Edge, I have the option to use 
Firefox.


Thanks for the tip.


 On Fri, 13 Aug 2021 16:10:06 +0900 Alejandro Hernandez 
 wrote 


It is likely as you says that there is a deep packet inspection in the middle 
(Firewall, ie. Fortinet).

If it's the case, the Firewall opens the packets and then encrypts again with 
its own certificate

If it's the case, perhaps it might work using a different browser (ie. chrome 
doesn't allow add exceptions to that kind of connections but safari does)

Another option may be that since the certificate will always be the same (the 
one from the firewall) add it to the trusted certificates...

 

Hope it helps.

El 2021-08-12 22:12, Chris Thompson escribió:

I realize there is much more to this than is likely something that can be 
solved in Guacamole, but I thought I'd throw it out there anyway. I have a 
Guacamole instance running on a Linux VM behind an Nginx Reverse Proxy with SSL 
via LetsEncrypt. Works great with one exception...

 

I have a problem with access for one user who has very restricted policies for 
Internet Access and Group Policies on his Windows Workstation at work. He 
cannot install any applications or browser plug-ins of any type, and he's 
seemingly behind some sort of Application Layer Firewall that's breaking the 
SSL handshaking and somehow issuing their own certifications (presumably to 
inspect the application traffic as it traverses the network). 

 

Wondering if anyone has run into this sort of thing and managed to find a 
workaround? I was hoping that it would just work being that everything would 
run in the browser, but somehow that's not the case.

 

Re: guacamole broken on Safari

[Mike Jumper]

OK - after installing a copy of OS X "Catalina" within VirtualBox, I'm now
able to reproduce this on the included older version of Safari. I'll start
digging into what CSS changes are needed to un-break older Safaris.

Michael Jumper
CEO, Lead Developer
Glyptodon Inc .


On Fri, Aug 13, 2021 at 6:03 AM Leo Nikolaev  wrote:

> Okay, I think this could be closed.
>
> I’ve done the tests, only the old versions of Safari are affected: 14.0
> and below. As long as we have a relatively small share of old Safafi
> browsers.
>
> Btw, I’ve tracked down the bug in current master, it all comes to wrong
> heigth, which is not firing from somewhere deep inside tiles.
>
> Mike, thanks for your help :)
>
> Cheers,
> Leo
>
> > On 13 Aug 2021, at 00:42, Mike Jumper  wrote:
> >
> > On Wed, Aug 11, 2021 at 2:52 PM Leo Nikolaev 
> wrote:
> > You mean I should not see this issue on latest master? Is there a
> different code there?
> >
> > The code on master should be the same code that you bisected - it just
> happens that code from the specific commit that you found through the
> bisect was already effectively undone by a later commit that would also
> have been in the history when you did the bisect.
> >
> > All this means is that the result of the bisect is not as
> straightforward as would be ideal.
> >
> > - Mike
> >
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
> For additional commands, e-mail: user-h...@guacamole.apache.org
>
>

Re: Connection to guacd timed out

[Victor Martinez]

Yes, the guacd is running and listeing in port 4822 in the systems.

tcp0  0 0.0.0.0:48220.0.0.0:*   LISTEN
 1073/guacd

Victor J. Martínez
RHCE
Cel.: (595)972-918-550
Asunción - Paraguay



El lun, 16 ago 2021 a las 11:33, Nick Couchman ()
escribió:

> On Mon, Aug 16, 2021 at 10:33 Victor Martinez 
> wrote:
>
>> After conecting to RDP-Cliente, in the tomcat log file, I see a error
>> about guacd daemon timeout.
>> But the connection to RDP found whitout problem.
>>
>> What could be the problem, for that error to be generated?
>>
>> 10:14:33.153 [http-nio-8080-exec-5] DEBUG o.a.i.d.pooled.PooledDataSource
>> - Testing connection 12045593 ...
>> 10:14:33.153 [http-nio-8080-exec-5] DEBUG o.a.i.d.pooled.PooledDataSource
>> - Connection 12045593 is GOOD!
>> 10:14:33.154 [http-nio-8080-exec-5] DEBUG o.a.i.d.pooled.PooledDataSource
>> - Returned connection 12045593 to pool.
>> 10:14:33.154 [http-nio-8080-exec-5] ERROR
>> o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request failed: Connection
>> to guacd timed out.
>> 10:14:33.158 [http-nio-8080-exec-5] DEBUG
>> o.a.g.s.GuacamoleHTTPTunnelServlet - Internal error in HTTP tunnel.
>> org.apache.guacamole.GuacamoleUpstreamTimeoutException: Connection to
>> guacd timed out.
>> at
>> org.apache.guacamole.io.ReaderGuacamoleReader.read(ReaderGuacamoleReader.java:180)
>>
>
> This is definitely an issue. Is guacd installed and running on your system?
>
> -Nick
>
>>

Re: RDP From Guac in Docker to LXC Container

[Ivanmarcus]

Matthew,

Great analogy, do you mind if I pinch it? I could use something like 
that a lot! ;-)


To simply try what you've got, on the same host IP, here's a suggestion 
from a terminal on your host machine:


docker run -it -h cn1 --net host -p 3389:3389 cn1 /bin/bash

This should start up the cn1 container with the same IP address as your 
host, expose 3389 internal to 3389 external, and drop you in a bash 
shell on that container. Once you're happy with that just ctrl-p ctrl-q 
to exit, but leave the container running.


I've assumed the name 'cn1' for your container here, but you can 
obviously use whatever is correct. The -h parameter will name the 
running container 'cn1' too, otherwise it'll just give you a weird name 
(which is fine, you'd just need to use docker ps to find it!).


Then:

docker run -it -h guacamole --net host -p 8080:8080 guacamole /bin/bash

Same as with cn1, except this'll expose internal port 8080 to external 
port 8080.


Again, once running & checked you can just ctrl-p ctrl-q to exit.

From there you should now be able to access both containers on their 
respective ports. First using Remmina to cn1 (host IP address, port 
3389) then, assuming cn1 is working, browse to host IP address port 8080 
and see if you get Guacamole, the rest should follow from there.


Using the parameters I've given means you should later be able to 
connect in to the containers from a terminal using something like:


docker container exec -it [container name] /bin/bash

Then you can do/check whatever you need and just type 'exit' whenever 
you're finished to be dropped back to the host terminal *without* 
closing the container.


Note I've *not* tried this and I could be leading you up a long and 
winding path so perhaps asking some real girls and boys on those forums 
is advisable - still no harm in trying this I guess...




On 17/08/21 3:04 am, Matthew Lawson wrote:
You may not be a Docker expert, but you know more than me about it.  
What I know about docker and networking can be summed up as follows:


user:~$ cat ~/network-and-docker-knowledge.txt
cat: /home/user/network-and-docker-knowledge.txt: No such file or directory
user:~$

I'll give your suggestion a try once I find some resources to explain 
how I might do it.


In the meantime, I think I'll cross-post this question on the Docker and 
LXC/LXC forums.



~ML

On Monday, August 16, 2021, Ivanmarcus  wrote:

Great, that's made it a bit easier to fault-find.

Unfortunately I'm not a Docker expert, and have never had anything
to do with LXD, so I'd treat anything I say from here with suspicion!

In the interests of keeping things simple, I've tended to try and
keep any Docker containers as standalone instances on the same
common subnet as I might normally. This may not be the strictly
approved way, but it works for me.

To that end I would restart the Guacamole and cn1 Docker instances
with their own ip address on your normal subnet (eg. 192.168.1.xxx).
This would avoid the need to go through any routing drama and should
mean that everything, including your host machine, can see
everything else.

I've done this in the past either via the cli, or alternatively with
a docker-compose file uisng macvlan.

Alternatively you could also use the host option and just assign
different ports as you need to the Docker instances and keep them
all on the same IP address. For instance cn1 may only need port 3389
accessible, and Guacamole port 8080 which means both can be on the
(same) host IP. It's also possible to alias the ports too, but
probably no need here.

With luck someone with a lot more clues than me will come along
shortly and suggest a better way, but in the meantime you could give
this a try as I've had good success with this methodology.


On 16/08/21 1:20 pm, Matthew Lawson wrote:

Remmina connected to cn1 right away.

Does the routing path look something like this:
Guac on Docker ==> Docker Bridge ==> Host Network ==> LXD Bridge
==> cn1?


~ML
On Aug 15, 2021, 8:24 PM -0400, Ivanmarcus
, wrote:

Matthew,

There could be a few reasons for this issue, but in
fault-finding I
guess I'd start with first trying a direct RDP connection to
cn1 (ie.
not via Guacamole).

Not sure if you're using a Linux or Win machine, but I find
Remmina is a
good Linux tool for testing RDP and VNC connections.

That should at least give you an idea if cn1 is performing
as it should,
and therefore potentially narrow down where you need to look
for the
problem. All that said, given you mention the Docker
containers are
using their default IP range, I do wonder if there's simply
a routing
issue...

Re: Connection to guacd timed out

[Nick Couchman]

On Mon, Aug 16, 2021 at 10:33 Victor Martinez  wrote:

> After conecting to RDP-Cliente, in the tomcat log file, I see a error
> about guacd daemon timeout.
> But the connection to RDP found whitout problem.
>
> What could be the problem, for that error to be generated?
>
> 10:14:33.153 [http-nio-8080-exec-5] DEBUG o.a.i.d.pooled.PooledDataSource
> - Testing connection 12045593 ...
> 10:14:33.153 [http-nio-8080-exec-5] DEBUG o.a.i.d.pooled.PooledDataSource
> - Connection 12045593 is GOOD!
> 10:14:33.154 [http-nio-8080-exec-5] DEBUG o.a.i.d.pooled.PooledDataSource
> - Returned connection 12045593 to pool.
> 10:14:33.154 [http-nio-8080-exec-5] ERROR
> o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request failed: Connection
> to guacd timed out.
> 10:14:33.158 [http-nio-8080-exec-5] DEBUG
> o.a.g.s.GuacamoleHTTPTunnelServlet - Internal error in HTTP tunnel.
> org.apache.guacamole.GuacamoleUpstreamTimeoutException: Connection to
> guacd timed out.
> at
> org.apache.guacamole.io.ReaderGuacamoleReader.read(ReaderGuacamoleReader.java:180)
>

This is definitely an issue. Is guacd installed and running on your system?

-Nick

>

Re: RDP From Guac in Docker to LXC Container

[Matthew Lawson]

You may not be a Docker expert, but you know more than me about it.  What I
know about docker and networking can be summed up as follows:

user:~$ cat ~/network-and-docker-knowledge.txt
cat: /home/user/network-and-docker-knowledge.txt: No such file or directory
user:~$

I'll give your suggestion a try once I find some resources to explain how I
might do it.

In the meantime, I think I'll cross-post this question on the Docker and
LXC/LXC forums.


~ML

On Monday, August 16, 2021, Ivanmarcus  wrote:

> Great, that's made it a bit easier to fault-find.
>
> Unfortunately I'm not a Docker expert, and have never had anything to do
> with LXD, so I'd treat anything I say from here with suspicion!
>
> In the interests of keeping things simple, I've tended to try and keep any
> Docker containers as standalone instances on the same common subnet as I
> might normally. This may not be the strictly approved way, but it works for
> me.
>
> To that end I would restart the Guacamole and cn1 Docker instances with
> their own ip address on your normal subnet (eg. 192.168.1.xxx). This would
> avoid the need to go through any routing drama and should mean that
> everything, including your host machine, can see everything else.
>
> I've done this in the past either via the cli, or alternatively with a
> docker-compose file uisng macvlan.
>
> Alternatively you could also use the host option and just assign different
> ports as you need to the Docker instances and keep them all on the same IP
> address. For instance cn1 may only need port 3389 accessible, and Guacamole
> port 8080 which means both can be on the (same) host IP. It's also possible
> to alias the ports too, but probably no need here.
>
> With luck someone with a lot more clues than me will come along shortly
> and suggest a better way, but in the meantime you could give this a try as
> I've had good success with this methodology.
>
>
> On 16/08/21 1:20 pm, Matthew Lawson wrote:
>
>> Remmina connected to cn1 right away.
>>
>> Does the routing path look something like this:
>> Guac on Docker ==> Docker Bridge ==> Host Network ==> LXD Bridge ==> cn1?
>>
>>
>> ~ML
>> On Aug 15, 2021, 8:24 PM -0400, Ivanmarcus ,
>> wrote:
>>
>>> Matthew,
>>>
>>> There could be a few reasons for this issue, but in fault-finding I
>>> guess I'd start with first trying a direct RDP connection to cn1 (ie.
>>> not via Guacamole).
>>>
>>> Not sure if you're using a Linux or Win machine, but I find Remmina is a
>>> good Linux tool for testing RDP and VNC connections.
>>>
>>> That should at least give you an idea if cn1 is performing as it should,
>>> and therefore potentially narrow down where you need to look for the
>>> problem. All that said, given you mention the Docker containers are
>>> using their default IP range, I do wonder if there's simply a routing
>>> issue...
>>>
>>> On 16/08/21 12:48 am, Matthew Lawson wrote:
>>>
 I could use some pointers (advice/resources) about establishing an RDP
 connection between Guacamole set up with Docker containers and a Linux
 container running ubuntu 20.04.

 Since Brian Mullan's CIAB setup inspired this endeavor, the Linux
 container is named 'cn1'.

 When I try to connect to cn1, I receive an error message telling me that
 cn1 is taking too long to respond.

 cn1 has xrdp installed, but no Guac elements.

 The host for the containers is running Ubuntu 20.04 (newly-installed).

 The Docker containers have their own network (172.xxx), which is
 visible to the host. The LXC's ip address is 10.xxx..., also visible to
 the host.

 I can ping between all three elements: host to containers, Docker to
 cn1, cn1 to host, etc.

 In Guac's 'Connections' setup, I used cn1's
 ip address and port 3389.

 No joy when I try to connect though.

 Thoughts anyone?  References to tutorials?  Has this question already
 been answered on the mailing list?

 ~ML

>>>
>>> -
>>> To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
>>> For additional commands, e-mail: user-h...@guacamole.apache.org
>>>
>>>
> -
> To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
> For additional commands, e-mail: user-h...@guacamole.apache.org
>
>

Connection to guacd timed out

[Victor Martinez]

After conecting to RDP-Cliente, in the tomcat log file, I see a error about
guacd daemon timeout.
But the connection to RDP found whitout problem.

What could be the problem, for that error to be generated?

10:14:33.153 [http-nio-8080-exec-5] DEBUG o.a.i.d.pooled.PooledDataSource -
Testing connection 12045593 ...
10:14:33.153 [http-nio-8080-exec-5] DEBUG o.a.i.d.pooled.PooledDataSource -
Connection 12045593 is GOOD!
10:14:33.154 [http-nio-8080-exec-5] DEBUG o.a.i.d.pooled.PooledDataSource -
Returned connection 12045593 to pool.
10:14:33.154 [http-nio-8080-exec-5] ERROR
o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request failed: Connection
to guacd timed out.
10:14:33.158 [http-nio-8080-exec-5] DEBUG
o.a.g.s.GuacamoleHTTPTunnelServlet - Internal error in HTTP tunnel.
org.apache.guacamole.GuacamoleUpstreamTimeoutException: Connection to guacd
timed out.
at
org.apache.guacamole.io.ReaderGuacamoleReader.read(ReaderGuacamoleReader.java:180)

Victor J. Martínez
RHCE
Cel.: (595)972-918-550
Asunción - Paraguay

Re: RDP From Guac in Docker to LXC Container

[Ivanmarcus]

Great, that's made it a bit easier to fault-find.

Unfortunately I'm not a Docker expert, and have never had anything to do 
with LXD, so I'd treat anything I say from here with suspicion!


In the interests of keeping things simple, I've tended to try and keep 
any Docker containers as standalone instances on the same common subnet 
as I might normally. This may not be the strictly approved way, but it 
works for me.


To that end I would restart the Guacamole and cn1 Docker instances with 
their own ip address on your normal subnet (eg. 192.168.1.xxx). This 
would avoid the need to go through any routing drama and should mean 
that everything, including your host machine, can see everything else.


I've done this in the past either via the cli, or alternatively with a 
docker-compose file uisng macvlan.


Alternatively you could also use the host option and just assign 
different ports as you need to the Docker instances and keep them all on 
the same IP address. For instance cn1 may only need port 3389 
accessible, and Guacamole port 8080 which means both can be on the 
(same) host IP. It's also possible to alias the ports too, but probably 
no need here.


With luck someone with a lot more clues than me will come along shortly 
and suggest a better way, but in the meantime you could give this a try 
as I've had good success with this methodology.



On 16/08/21 1:20 pm, Matthew Lawson wrote:

Remmina connected to cn1 right away.

Does the routing path look something like this:
Guac on Docker ==> Docker Bridge ==> Host Network ==> LXD Bridge ==> cn1?


~ML
On Aug 15, 2021, 8:24 PM -0400, Ivanmarcus 
, wrote:

Matthew,

There could be a few reasons for this issue, but in fault-finding I
guess I'd start with first trying a direct RDP connection to cn1 (ie.
not via Guacamole).

Not sure if you're using a Linux or Win machine, but I find Remmina is a
good Linux tool for testing RDP and VNC connections.

That should at least give you an idea if cn1 is performing as it should,
and therefore potentially narrow down where you need to look for the
problem. All that said, given you mention the Docker containers are
using their default IP range, I do wonder if there's simply a routing
issue...

On 16/08/21 12:48 am, Matthew Lawson wrote:

I could use some pointers (advice/resources) about establishing an RDP
connection between Guacamole set up with Docker containers and a Linux
container running ubuntu 20.04.

Since Brian Mullan's CIAB setup inspired this endeavor, the Linux
container is named 'cn1'.

When I try to connect to cn1, I receive an error message telling me that
cn1 is taking too long to respond.

cn1 has xrdp installed, but no Guac elements.

The host for the containers is running Ubuntu 20.04 (newly-installed).

The Docker containers have their own network (172.xxx), which is
visible to the host. The LXC's ip address is 10.xxx..., also visible to
the host.

I can ping between all three elements: host to containers, Docker to
cn1, cn1 to host, etc.

In Guac's 'Connections' setup, I used cn1's
ip address and port 3389.

No joy when I try to connect though.

Thoughts anyone?  References to tutorials?  Has this question already
been answered on the mailing list?

~ML


-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org