<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>