Project

General

Profile

Feature #24884

Add option for VM VNC to listen on localhost only

Added by Ross Morris almost 2 years ago. Updated 10 months ago.

Status:
Done
Priority:
No priority
Assignee:
Marcelo Araujo
Category:
Middleware
Target version:
11.2-BETA1
Estimated time:
(Total: 0.00 h)
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
No
Needs Doc:
No
Needs Merging:
No
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:

Description

I'm using an SSH tunnel to securely connect to VNC from afar but I have concerns about VNC listening on all addresses. Could an option (default?) be added to have VNC listen on localhost?

Subtasks

Bug #29513: VMs -> VNC device "Bind To" option doesn't bind VNC to selected IPClosedMarcelo Araujo

Associated revisions

Revision 730af988 (diff)
Added by Marcelo Araujo almost 2 years ago

feat(vm): Instead of bind VNC in all IFACES, allow users to choose between bind all, or bind to an specific IPv4.

Ticket: #24884

Revision 7fc1df1a (diff)
Added by Marcelo Araujo almost 2 years ago

feat(vm): Instead of bind VNC in all IFACES, allow users to choose between bind all, or bind to an specific IPv4.

Ticket: #24884

Revision 9c85636f (diff)
Added by Dru Lavigne over 1 year ago

Add new VNC options.
Ticket: #23894
Ticket: #24884
Ticket: #23481
Ticket: #23979

Revision 96ef4587 (diff)
Added by Marcelo Araujo over 1 year ago

fix(middlewared/vm): Fix vnc bind interface issue. Now bhyves call vnc_init_server passing IPV4 address attached on fbuf.

Note: It depends of libhyve-remote 0.1.4.1 and also os/pull/53.

Ticket: #24884

Revision 9a615e6f (diff)
Added by Marcelo Araujo over 1 year ago

[master] fix(middlewared/vm): Fix vnc bind interface issue. Now bhyves call vnc_init_server passing IPV4 address attached on fbuf. (#568)

  • fix(middlewared/vm): Fix vnc bind interface issue. Now bhyves call vnc_init_server passing IPV4 address attached on fbuf.

Note: It depends of libhyve-remote 0.1.4.1 and also os/pull/53.

Ticket: #24884

  • - Make the method name more explicit as well as add docstring.
  • Forgotten to commit the django changes.

History

#1 Updated by Marcelo Araujo almost 2 years ago

  • Status changed from Unscreened to Screened
  • Target version set to 11.1

#2 Updated by Marcelo Araujo almost 2 years ago

  • Status changed from Screened to Fix In Progress

#3 Updated by Marcelo Araujo almost 2 years ago

  • Priority changed from No priority to Important

#4 Updated by Marcelo Araujo almost 2 years ago

Hi,

Thanks for the suggestion! Nice request!
So, it will appears in 11.1-RELEASE, now the feature is in Nightlies already.

Best,

#5 Updated by Marcelo Araujo almost 2 years ago

  • Status changed from Fix In Progress to Resolved

#6 Updated by Ross Morris almost 2 years ago

Awesome - thanks!

#7 Updated by Dru Lavigne over 1 year ago

  • Subject changed from VMs: Option for VNC to listen on localhost only to Add option for VM VNC to listen on localhost only

#8 Updated by Dru Lavigne over 1 year ago

  • Target version changed from 11.1 to 11.1-BETA1

#9 Updated by Nick Wolff over 1 year ago

  • QA Status Test Fails FreeNAS added
  • QA Status deleted (Not Tested)

There is no option for localhost in drop down list of ip addresses only 0.0.0.0 and interfaces on system currently

#10 Updated by Marcelo Araujo over 1 year ago

Nick Wolff wrote:

There is no option for localhost in drop down list of ip addresses only 0.0.0.0 and interfaces on system currently

You can't add VNC on localhost or otherwise external users can't access it.
So, the ticket title is a bit wrong, but before it was binding to all interfaces 0.0.0.0 and after these changes you can choose what IP you want to bind.

Best,

#11 Updated by Ross Morris over 1 year ago

Hey Marcelo,

I’m the one who opened the issue — I specifically wanted a localhost (127.0.0.1 and/or ::1) option for those of us using a SSH tunnel to securely connect to VNC from abroad instead of shuttling that VNC traffic over a non-secure connection. With SSH’s built-in tunneling option users (administrators) would still able to connect — even if bound to localhost. It also has the benefit of protecting the VNC instance from having its short (8 character maximum!) password bruteforced by the local network.

Marcelo Araujo wrote:

Nick Wolff wrote:

There is no option for localhost in drop down list of ip addresses only 0.0.0.0 and interfaces on system currently

You can't add VNC on localhost or otherwise external users can't access it.
So, the ticket title is a bit wrong, but before it was binding to all interfaces 0.0.0.0 and after these changes you can choose what IP you want to bind.

Best,

#12 Updated by Nick Wolff over 1 year ago

With the case that was being requested he was doing ssh forwarding which is also included in many vnc clients which would would work with only binding to localhost.

Also after investigating this further this appears to only affect the web-vnc portion and not standard vnc binding and additionally when 0.0.0.0(wildcard) is set the web-vnc link leads to http://0.0.0.0:5801/vnc_auto.html which doesn't work.

Thanks for the quick responses and hard work on this.

#13 Updated by Marcelo Araujo over 1 year ago

Nick Wolff wrote:

With the case that was being requested he was doing ssh forwarding which is also included in many vnc clients which would would work with only binding to localhost.

Also after investigating this further this appears to only affect the web-vnc portion and not standard vnc binding and additionally when 0.0.0.0(wildcard) is set the web-vnc link leads to http://0.0.0.0:5801/vnc_auto.html which doesn't work.

Thanks for the quick responses and hard work on this.

For the case "http://0.0.0.0:5801/vnc_auto.html" seems a bug at django side (specifically at the link), it should point to NAS IP instead of 0.0.0.0.

If you don't mind, could you open a bug report about it?

Best,

Thanks,

#14 Updated by Ross Morris over 1 year ago

I see the ticket was updated to show resolved — was localhost added? I’m new to the FreeNAS workflow so not sure where I’d look for commits

#15 Updated by Marcelo Araujo over 1 year ago

  • Status changed from Resolved to Screened
  • Target version changed from 11.1-BETA1 to 11.1-RC1

OK, I'm reopen this ticket, because seems I misunderstood the request.

Thanks guys.

#16 Updated by Dru Lavigne over 1 year ago

  • Target version changed from 11.1-RC1 to 11.1

#17 Avatar?id=14398&size=24x24 Updated by Kris Moore over 1 year ago

  • Target version changed from 11.1 to 11.2-BETA1

#18 Updated by Marcelo Araujo over 1 year ago

  • Status changed from Screened to Needs Developer Review
  • Assignee changed from Marcelo Araujo to William Grzybowski

#19 Updated by William Grzybowski over 1 year ago

  • Status changed from Needs Developer Review to Reviewed by Developer
  • Assignee changed from William Grzybowski to Marcelo Araujo

#20 Updated by Dru Lavigne over 1 year ago

  • Status changed from Reviewed by Developer to Ready For Release

#21 Avatar?id=13649&size=24x24 Updated by Ben Gadd about 1 year ago

  • Status changed from Ready For Release to Done

#22 Updated by Dru Lavigne about 1 year ago

  • Needs Merging changed from Yes to No

#23 Updated by Dru Lavigne about 1 year ago

  • Needs Doc changed from Yes to No

#24 Updated by Dru Lavigne about 1 year ago

Bonnie: in the old UI, 127.0.0.1 is an option in the drop-down menu.

#25 Updated by Bonnie Follweiler 12 months ago

  • Status changed from Done to Passed Testing
  • Needs QA changed from Yes to No
  • QA Status Test Passes FreeNAS added
  • QA Status deleted (Test Fails FreeNAS)

Test passed in FreeNAS-11-MASTER-201805010407

#26 Updated by Dru Lavigne 10 months ago

  • Severity set to New

#27 Updated by Dru Lavigne 10 months ago

  • Status changed from Passed Testing to Done

Also available in: Atom PDF