Port Forwarding with VirtualBox on Windows

[JonTheNiceGuy]

I have installed MultiPass on a Windows system (Microsoft Windows [Version 10.0.17134.1130]), and configured it to use Virtualbox (multipass set local.driver=virtualbox). All good, so far!

Like others have noted, when using the VirtualBox backend, you don't get an IPv4 address which is fine, but I'm able to configure any port forwarding or bridging, this is because MultiPass on Windows uses the System account, so I can't start the virtualbox user interface, nor can I run any commands using the "Run as Administrator" or "Run as different user" as... well, you can't use the system account like that.

Some have suggested that you should use an SSH tunnel, but as I can't see what port Multipass is connecting to, I'm stuck there too! (Also, I can't work out where the SSH key would be for Multipass either! Hat-tip to #913)

With a Vagrant file I have on this machine, I can run vboxmanage showvminfo vmname and some of the lines I receive include:

NIC 1:                       MAC: 02827A7B5194, Attachment: NAT, Cable connected: on, Trace: off (file: none), Type: 82540EM, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy: deny, Bandwidth group: none
NIC 1 Rule(0):   name = ssh, protocol = tcp, host ip = 127.0.0.1, host port = 2222, guest ip = , guest port = 22

With this data, you'd be able to show that the interface is "NAT"'d, and that there's an SSH port forward available on host port 2222. I'm guessing that Multipass has this detail stored internally somewhere (so you can access primary, for example).

It would be helpful if instead of showing "IPv4" as N/A, instead it showed "NAT to localhost" and perhaps also indicated the port for SSH. Multipass info could also list where the SSH key is stored?

I'd also like to endorse #309 for something similar.

Until this is resolved, I'm unable to use Multipass with Virtualbox for anything other than the most simplistic tasks, and must resort to using Vagrant.

[Saviq]

Hi @JonTheNiceGuy, thanks for a detailed write-up.

There's a balance that we try to maintain between features and usability, thinking hard before we introduce a feature inside Multipass. Most of our hypervisors create a virtual network segment, so port forwarding is not that as much of a requirement as it is for VirtualBox, which is at least part of why it never got done. But we recognize the need for it, we just need to design a good user experience around it.

The SSH port / key is an internal implementation detail that we would like to not expose to users (we want to replace it altogether in the long run), so I'd rather not add it to multipass info.

Would implementing port forwarding indeed solve your issue? If so, can you please say "Duplicate of #309" and close this issue?

[Saviq]

On another note, you can use psexec.exe -s -i VirtualBox.exe or psexec.exe -s VBoxManage.exe … to control the system user's VirtualBox instance.

[JonTheNiceGuy]

I don't think this is exactly a Duplicate - there are separate and fun issues around the privilege model within Windows (like the psexec thing). So, there are some documentation changes I'd like to see off the back of this - noting the psexec part for getting access to VirtualBox would be a big start 😄 I don't know if that's part of this ticket or a separate one.

I've now used psexec, and so when I run psexec -s -i 'cmd.exe' to get a shell that I can see "things" happening in - yep, I can configure the interface on the VM: vboxmanage modifyvm "primary" --nic2 bridged --bridgeadapter2 "DisplayLink Network Adapter NCM" but when I then run multipass start (from a "run as administrator" command prompt session), I get:

C:\WINDOWS\system32>multipass start
start failed: The following errors occurred:
primary: timed out waiting for response

Watching the Virtualbox application at the time this is run, it doesn't seem to start running the VM either. Even manually starting the VM, the "primary" machine seems to struggle to have it's shell opened with that timeout message. I think this is a separate issue, but no logs were showing as to why it was failing, so I don't know if I'd fat-fingered something, or if it was just one of "those things" about "primary".

I tried, instead, doing the same with a "launched" image (multipass launch which created "wired-amberjack", and then multipass stop wired-amberjack so I could do further config) - this time I was able to add an extra interface and bridge it (although, to be fair, it took some faffing around trying to figure out what Virtualbox classes as an "interface name" as it doesn't match the Alias from Windows, nor does it match the name from Get-NetAdaptor - you need to get the proper name from VirtualBox itself, or by running something like this: Get-NetAdapter -Physical | format-list -property "Name","DriverDescription" Yey!) - the exact command now is psexec -s -i "c:\program files\oracle\virtualbox\vboxmanage" modifyvm "primary" --nic2 bridged --bridgeadapter2 "DisplayLink Network Adapter NCM" (pick your adapter alias based on that get-netadapter command before, or by running virtualbox gui and see what your bridge options are)

I now get a VM with the second interface in a "down" state. I think, at this point, it's because I need to do something with a cloud-init to say "Yep, you can use the second interface", either that, or push something into /etc/netplan to say "DHCP is good for the second interface"... but that's not really something for an "easy to use tool" like this.

So, yes, while fundamentally this could be a duplicate of #309, if that's not going to be around for a while, it's worth documenting this work-around until 309 is available, and noting that it's a work around pending the completion of that.

I hope some of these notes above can help towards that documentation? If so, and you want me to create a PR based on those notes - point me to where I should do that, and I'll do what I can.

As an aside, and worth pushing as a comment to someone who's looking at it - I ended up using Multipass because the MicroK8S documentation recommends using Multipass, which I guess assumes that you're using Hyper-V, because if you're using the Virtualbox backend, you need these extra settings otherwise you're stuck with a K8S environment that isn't reachable from well, anything that isn't Multipass!

[kush-daga]

Hi, @JonTheNiceGuy I followed your article for configuring the multipass bridged network, however I'm trying to configure Ubuntu 16 and in the article, you have told how to configure ubuntu 18 (via netplan), sorry I'm a bit new to this and just want to connect my vs code to the shell instance of multipass, if you could help me with configuring for Ubuntu 16.04 it would be great!

[JonTheNiceGuy]

I have updated my blog post with extra details about using the ifupdown config files in Ubuntu 16.04.

[kush-daga]

Thank you!

[aiham]

@JonTheNiceGuy Really awesome article! Thank you for the detailed explanation. All I needed was the IP address then I could port forward via an SSH client since I need to forward different ports on an adhoc basis.

[Saviq]

I published this in our documentation.