<div dir="ltr">You're right: dconf-editor is great for this..<br><br>Well, to confirm a theory, the problem lies in the "require-encryption" setting. I did a couple of hops through some other machines to bring the VM up in VMM, opened dconf-editor and I can fix or break TightVNC's ability to connect from work by turning "require-encryption" off or on. So the problem is encryption.<div><br></div><div>Normally not having encryption on would upset me but it's easy for me to run through a VPN tunnel anyway, so it's no biggie for the time being.</div><div><br></div><div>For future reference, turning off the VM's encryption requirement is as easy as:</div><div><br></div><div><div><span style="color:rgb(0,0,0);font-family:Tahoma;line-height:normal;text-align:-webkit-auto;font-size:medium">gsettings set org.gnome.Vino require-encryption false</span></div></div><div><br></div><div>or going through dconf-editor.</div><div><br></div><div>Thanks alot for your helpful suggestions, though. They really helped, and I think I need to do some more research on using dconf-editor. It's handy!</div><div><br></div><div><br></div><br><div class="gmail_quote">On Thu Feb 12 2015 at 10:24:37 PM Nick Guenther <<a href="mailto:nguenthe@uwaterloo.ca" target="_blank">nguenthe@uwaterloo.ca</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
<div>On 12/02/15 02:44 PM, CrankyOldBugger
wrote:<br>
</div>
</div><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr">First off, to do a sort of cleaning I got rid of
the existing VIRBR0 (with the troublesome 192.168.122.x address)
on the host machine using:
<div><br>
</div>
<div><span>#
virsh net-destroy default</span><br>
<span>#
virsh net-undefine default</span><br>
<span>#
service libvirtd restart</span><br>
</div>
<div><br>
</div>
<div>Then I created a new VIRBR1 with an address in the right
subnet (10.x.x.x) .</div>
<br>
</div></blockquote></div><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr"><div>So at this point, I can SSH to the VM from a remote
location. This is a good milestone.</div>
</div></blockquote></div><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr"></div>
</blockquote>
<br>
So it was just a subnet problem! Hooray! I'm happy I was able to
help. VMs like popcorn sound tasty... I've always only used qemu as
a toy because networking is such a pain.</div><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>However, VNC is still giving me some grief. If I try to
log in remotely using TightVNC (from a Windows client), I get
the error "Error in TightVNC Viewer: No security types
supported. Server sent security types, but we do not support
any of their". This is strange as the same TightVNC
configuration works on other Ubuntu boxes at home. In fact, I
did much of the above goofiness over a TightVNC connection to
an existing Ubuntu desktop with similar configuration. Most
of the results I found in Google say to disable encryption but
that's not in my plans. If I get past this issue I'll let you
know.</div>
<br>
</div>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
I think I've run into this before because I remember having the same
grossed out reaction to what passes for good advice as you did. Let
me see if I can help.<br>
<br>
Since you're running Ubuntu, I assume VNC is handled by Vino? Check
out dconf folder
org.gnome.desktop.remote-<u></u>access.authentication-methods (the
dconf-editor GUI really helps with exploring this and I entirely
recommend you skip the command line for this part). If that doesn't
help, the nearby keys can; for example, temporarily turning off
encryption can't hurt if you're just on your LAN and can help you
debug if something is deeply broken or if it's just that the
handshake is going wrong. You could also look at this dconf key on a
working system to compare.<br>
</div>
</blockquote></div></div>