0

Having been used to VMPlayer for decades, I experimented with VirtualBox yesterday and spent quite a few hours trying to SSH into an instance, when in VMP it was a breeze.

I understand from these answers that VBox needs port forwarding or alternatively use Bridged (which worked for sometime then broke connectivity on the guest after some time) - then I just gave up on VBox.

Why this difference in implementation between the two ? Why does VMP require no port forwarding while VBox does ? Is it for better security ?

Even cloning a VM was not as easy as it is with VMP (just copy the entire dir!)

To elaborate:

my guest IP: 192.168.124.153; host: (I am assuming 192.168.124.1 (Vmnet1) is the one - so it seems like it IS being bridged (I had earlier not looked at Vmnets, just my WLAN ip 192.168.0.x- my bad) - but it still begs the question - why does it work with the VMPlayer guest in NAT mode while the actual underlying connection looks bridged ? Is VMP doing something under the covers ?) - So when I changed to Bridged, the Guest IP address is now 192.160.0.22 (correctly) - and yes, I did restart after each N/w change

I guess I will accept the answer "the NAT/Bridge setting is largely irrelevant if you're only communicating from the VM Host to one of its guests"

killjoy
  • 123
  • 1
    VirtualBox does not require port forwarding. I'm using a host-only network with a static IP, which I may SSH into, for example. – Kusalananda Jan 03 '17 at 17:33

1 Answers1

1

Your premise is faulty. Neither has to apply the networking in any particular way.

VMware bridges by default (that's the "VM Network") because it's a system geared towards people who run multiple VMs on a group of servers and (mostly) know exactly what they're doing with the network.

VirtualBox NATs by default because it is geared towards people who run one (or so) server on a desktop PC and quite often know little or nothing about networking.

I run a couple of VMs on VirtualBox that both NAT and bridge. (The bridge is on the host-only network so I can get to them trivially from my host. The NAT is so the servers have easy access to the Internet.)

Chris Davies
  • 116,213
  • 16
  • 160
  • 287
  • I am just reporting what I experienced on my W8.1 box.

    I confirmed again before I wrote my question, it wasn't out of the blue.

    That's the way my two VMs communicate with the same guest OS version. I created a brand new guest from same ISO and tested on each of these and saw that VB assigned a 10.0 IP and couldn't connect via NAT while VM assigned a 192.168 IP and it could, without any changes. And BTW, this is VMPlayer, - both are the free versions.

    – killjoy Jan 04 '17 at 18:13
  • @killjoy you're saying that your VB guest couldn't connect to the rest of the network? Or that something on your network couldn't connect to the VB guest? The former would be broken; the latter would be expected with NAT. – Chris Davies Jan 04 '17 at 18:16
  • On VB, when I couldnt ssh to my guest via NAT, obviously as I need port forwarding, I switched to Bridged, and I was able to, then the guest stopped having inet access. Obviously I must be doing something wrong, so I will retest with VB; but my main question is, how does ssh'ing into VM work with NAT without having to do any port forwarding ? – killjoy Jan 05 '17 at 20:01
  • @killjoy you cannot ssh to a guest in through a NAT interface unless it has port forwarding configured. When you switched the guest to Bridged mode it needs either to use DHCP for its network configuration or you must ensure you have created a network configuration that fits the wired LAN your host uses. Note that you probably can't do this with WiFi because WiFi client drivers typically won't allow multiple MAC addresses – Chris Davies Jan 05 '17 at 22:47
  • I appreciate you trying to help me out here; maybe I am not being succinct enough, I CAN SSH into VMPlayer guest VM (whether over wired or WIFI and whether local or remote), even remote cloud VMs, without port forwarding, so again: my main question is, how does SSH'ing into a guest in VMPlayer work with NAT without having to do ANY port forwarding ? - My question is not about how to get it to work in VirtualBox, rather WHY port forwarding is not needed in VMPlayer. Also see Kusalananda's comment where he says PF is not needed. – killjoy Jan 07 '17 at 11:57
  • And to the clowns who are trigger-happy to down-vote, I cannot make it more clear, maybe you need to make a better effort on understanding questions being asked instead of decreasing the usefulness of this site where genuine questions are closed or otherwise put on hold for some stupid reason or the other. – killjoy Jan 07 '17 at 11:57
  • @killjoy are you sure there's a NAT layer between your LAN and the guest? If you can SSH to your guest from outside your host then your guest is either using bridging or a port forward. What might be useful is for you to update your question with IP addresses of the starting point, your VMP host and your guest. If they're all on the same subnet (eg 192.168.55.*/24) then you're bridging. If the guest is on a different subnet you're probably not. – Chris Davies Jan 07 '17 at 18:41
  • @roima - I never said I am SSH'ing from outside my host, it is within. I will update the question since that wasn't mentioned. – killjoy Jan 09 '17 at 13:23
  • Guess I cannot paste images here, my guest IP: 192.168.124.153; host: (I am assuming 192.168.124.1 (Vmnet1) is the one - so it seems like it IS being bridged (I had earlier not looked at Vmnets, just my WLAN ip 192.168.0.x- my bad) - but it still begs the question - why does it work with the VMPlayer guest in NAT mode while the actual underlying connection looks bridged ? Is VMP doing something under the covers ?) - So when I changed to Bridged, the Guest IP address is now 192.160.0.22 (correctly) - and yes, I did restart after each N/w change – killjoy Jan 09 '17 at 13:43
  • @killjoy if you edit that configuration explanation into your question it's more likely to get re-opened (I'm only one voter). – Chris Davies Jan 09 '17 at 14:00
  • @Killjoy the NAT/Bridge setting is largely irrelevant if you're only communicating from the VM Host to one of its guests. There will almost always be a route from the Host to its Guests (but not necessarily from the Guests to the Host), so you'll always be able to connect from the Host to a Guest. – Chris Davies Jan 09 '17 at 14:03
  • That makes perfect sense and I will do like you suggested...thanks !! – killjoy Jan 10 '17 at 15:18