After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 596190 - Misleading message about reachability from public network
Misleading message about reachability from public network
Product: vino
Classification: Applications
Component: Preferences Dialog
Other Linux
: Normal critical
: 3.2
Assigned To: Vino Maintainer(s)
Vino Maintainer(s)
: 604053 (view as bug list)
Depends on:
Reported: 2009-09-24 14:05 UTC by Marc Deslauriers
Modified: 2019-09-29 18:18 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Marc Deslauriers 2009-09-24 14:05:39 UTC
Vino displays "Your desktop is only reachable over the local network." after performing a connectivity test. It appears the connectivity test doesn't try with IPv6, resulting in a misleading message. This may lead to someone thinking their installation is secure, when in fact it is open to IPv6 traffic. This could be considered a security issue.

Ubuntu bug report:
Comment 1 Michael Trausch 2010-01-21 20:44:34 UTC
I can confirm this bug report.  I have IPv6 functionality (both a site local and a global IPv6 address).  In my case it tells me that vino can only be connected to from or fennel.local, when in fact, it is also reachable by the following slightly redacted IPv6 numbers (the host portion is removed):

  inet6 addr: fdf3:950f:4983:0:XXXX:XXXX:XXXX:XXXX/64 Scope:Global
  inet6 addr: 2001:470:1f11:3f:XXXX:XXXX:XXXX:XXXX/64 Scope:Global

The system is in DNS but I see no need to actually publish its name since it is nonrelevant to the bug report save for the fact that it exists and properly resolves to the global address (the 2001:470:1f11:3f address, that is).

Note that the first address is roughly equivalent to 10/8, 172.16/12, and 192.168/16 in IPv4. These addresses are generated in response to RAs being sent on the network as part of stateless autoconfiguration, so the host is aware of its status being on the IPv6 network. Furthermore, the system is actually on the IPv6 Internet and can reach e.g., Google's IPv6 site at
Comment 2 David Woodhouse 2010-11-12 01:26:58 UTC
It doesn't need IPv6. It doesn't work right for Legacy IP either.

For example, my workstation has the public Legacy IP address, as well as a couple of bridges for virt-manager. Sometimes it picks the private IP address on a virt-manager bridge and tells me:

 "Your desktop is only reachable over the local network. Others can access your
  computer using the address or i7.local."

Other times it *does* pick the right interface and tell me that the machine is globally reachable, but it screws up the reverse DNS lookup:

 "Others can access your computer using the address or i7.local."

Seriously, if you want to pick just one interface to check on global routing, then make a UDP socket and connect() to or something, then use getsockname() to work out which local interface is used for that public-facing connection. And don't forget to do with IPv6 as well as Legacy IP. And get the reverse DNS right (and check that forward DNS matches the reverse, of course).

Adding 'security' keyword, since telling people that their VNC server is only reachable from the local network when that's not true is really quite a naughty thing to do. If it can't be fixed in short order, this 'feature' should be disabled completely.
Comment 3 David King 2011-03-20 10:10:27 UTC
*** Bug 604053 has been marked as a duplicate of this bug. ***
Comment 4 David King 2011-03-21 16:53:24 UTC
Vino 2.99.4 removes the network reachability message from the UI. I will add it back when a fix is available. This is highly unlikely before 3.0 is released, so expect the fix for 3.2, and a backport to 3.0 (and older).
Comment 5 Tobias Mueller 2017-08-05 17:46:18 UTC
So what's the status here?
Is this bug report OBSOLETE because the message is gone?
Comment 6 André Klapper 2019-09-29 18:18:53 UTC
No reply; let's assume so.