On Thu, Oct 26, 2017 at 5:53 PM, Steven Pollock <[email protected]>
wrote:

> I have tried this with both the noauth and mysql configs, as I thought it
> might be a noauth issue initially.  The network is not blocking, lets not
> go there.
>
>
The authentication backend in use has no bearing on whether Guacamole can
connect via VNC to a particular machine. It is guacd which actually
performs the network connection to the VNC server.


> Single interface guac sitting on 10.80.100.x/24
>    VNC to 10.80.100.10 -- works
>    RDP to 10.80.100.11 -- works
>    RDP to AWS (amazon) -- works
>
> Move the guac to another network and change the IP address to
> 10.80.160.x/24
>    VNC to 10.80.100.10 -- fail
>    RDP to 10.80.100.11 -- works
>    RDP to AWS (amazon) -- works
>
> Use a standard off the shelf VNC client in 10.80.160.x
>    VNC to 10.80.100.10 -- works
>
> Simply changing the subnet causes guac VNC to fail in either noauth or
> mysql configs.
>
> Any ideas? Maybe a way to troubleshoot?
>
>
If you are able to connect to other machines, and only connections to a
particular subnet fail, that strongly suggests that there is an issue with
the network configuration on either of the machines in question, or in the
network between them. There is no magic within guacd nor within the
authentication extensions which would result in connections failing only
for a particular subnet. Routing of packets between subnets is handled by
the system's networking stack, not by guacd.

To troubleshoot, I suggest looking strictly at the network configuration
and behavior of the machines where you're seeing this issue. Don't draw
conclusions from connecting from another machine that happens to be in the
same subnet; connect strictly from the machine hosting guacd.

On another note, you mention NoAuth - beware that this extension has been
deprecated. Its use is no longer recommended. See:

http://guacamole.incubator.apache.org/releases/0.9.13-incubating/#noauth-now-deprecated

- Mike

Reply via email to