Vagrant: Vagrant Box - eth0 NAT

[marcinpraczko]

Hi,

Vagrant: 1.2.2

As I can see vagrant so far is creating eth0 with NAT (Done a few boxes with 'vagrant package' command). First I thought that this is not issue and I can setup another interface as (private_network, etc).

But I started having issues with this default eth0 (nat) setup. Issue started appearnig when configuration manager started be in place. On production environment I have only eth0, on dev VMs (Vagrant) I have eth0 (NAT) and my own interface eth1.
Linux by default is using outgoing IP from eth0, so any kind of generation conifugration files relay on eth0 in production and eth1 on dev (Double work). But connection from one VM to another is always going via eth0.
And the worse is that every Vagrant VM has the same IP on eth0 - so now nothing is working as epxected.

Is there any way to do on vagrant following things:

• Redefine default interface to not be eth0 but eth1?
  Not bother if VM has additional interfaces, but would like to have configuration like is on production
• Force eth0 to be not NAT, but for example internal connections with my own static IPs?

Best regards,
Marcin Praczko

[mitchellh]

eth0 as NAT is a fundamental requirement of Vagrant in its current state. Perhaps in the future this limitation can be removed, but for the time being it is required.

[pniederlag]

the requirement for eth0 to be managed by NAT really adds a lot of complexity when trying to bring up a multi machine virtual environment where individual machines shall consume network services consumed by others.

Actually with #1922 it's possible to skip the default ssh port forwarding (which in turn required NAT), what else is a fundamental requirement for eth0 being setup as a NAT interface?

[tiadobatima]

I agree with @pniederlag... This limitation is a real pain for anybody using Vagrant to simulate their own network stack, since almost everyone uses eth0 for real application traffic.

How complicated would be to allow NAT to be configured in another interface? I mean something like this (moving NAT to adapter 2 and the private network to adapter 1):

  config.vm.network "forwarded_port", adapter: 2, guest: 22, host: 2222, id: "ssh"
  config.vm.network "private_network", adapter: 1, type: "dhcp"

When I use the config above I get this:

Bringing machine 'mybox' up with 'virtualbox' provider...
==> mybox: Importing base box 'mybox'...
==> mybox: Matching MAC address for NAT networking...
==> mybox: Setting the name of the VM: salt_mybox_1450205958493_75328
==> mybox: Clearing any previously set forwarded ports...
==> mybox: Clearing any previously set network interfaces...
==> mybox: Preparing network interfaces based on configuration...
    mybox: Adapter 1: hostonly
==> mybox: Forwarding ports...
    mybox: 22 => 2222 (adapter 2)
    mybox: VirtualBox adapter #2 not configured as "NAT". Skipping port
    mybox: forwards on this adapter.
==> mybox: Booting VM...
==> mybox: Waiting for machine to boot. This may take a few minutes...
    mybox: SSH address: 127.0.0.1:22
    mybox: SSH username: vagrant
    mybox: SSH auth method: private key
    mybox: Warning: Connection refused. Retrying...
    mybox: Warning: Connection refused. Retrying...
    mybox: Warning: Connection refused. Retrying...

[barrymw]

For anyone else who has stumbled across this feature, there is a hack to get around this limitation.

Software versions:
VirtualBox: 5.1.28
Vagrant: 2.0.0

My requirement is to PXE boot so that I can test katello provisioning templates, which network booting needs to be done on the primary network interface. This is where vagrant wanting the primary interface for SSH access is a problem. In this instance I'm using vagrant up to simply configure a VM, and then I am able to reboot and perform a PXE builds.

By allowing vagrant to _do its thing_ and then customising the VM's network setup, the end goal can be achieved. The only limitation is that the SSH guest port needs to be fixed, i.e. auto_correct: false

Definition of the VM that has eth0 as private and eth1 as NAT.

  config.vm.define 'pxe', autostart: false do |test|
    test.vm.provider 'virtualbox' do |vb|
      vb.customize ['modifyvm',:id, '--boot1', 'net', '--boot2', 'disk'] # I want to network boot
      vb.customize ['modifyvm',:id, '--nic1', 'intnet', '--nic2', 'nat'] # swap the networks around
      vb.customize ['modifyvm', :id, '--natpf2', "ssh,tcp,127.0.0.1,52222,,22" ] #port forward
    end
    test.vm.network "forwarded_port", id: 'ssh', guest: 22, host_ip: '127.0.0.1', host: 52222, auto_correct: false, adapter: 1
  end

NOTE: nic1 could also be set to hostonly but I'm using intnet so that I know that the katello capsule (DHCPD/TFTPD) are on the same network as I have several hostonly adapter setups and only one internal network.

D:\> vagrant up pxe
Bringing machine 'pxe' up with 'virtualbox' provider...
==> pxe: Cloning VM...
==> pxe: Matching MAC address for NAT networking...
==> pxe: Checking if box 'centos' is up to date...
==> pxe: Setting the name of the VM: vagrant-katello_pxe_1507811444608_64253
==> pxe: Clearing any previously set network interfaces...
==> pxe: Preparing network interfaces based on configuration...
    pxe: Adapter 1: nat
==> pxe: Forwarding ports...
    pxe: 22 (guest) => 52222 (host) (adapter 1)
==> pxe: Running 'pre-boot' VM customizations...
==> pxe: Booting VM...
==> pxe: Waiting for machine to boot. This may take a few minutes...
    pxe: SSH address: 127.0.0.1:52222
    pxe: SSH username: vagrant
    pxe: SSH auth method: private key
    pxe: Warning: Connection reset. Retrying...
...
[truncated]
...
    pxe:
    pxe: Vagrant insecure key detected. Vagrant will automatically replace
    pxe: this with a newly generated keypair for better security.
    pxe:

So vagrant still believes that port forwarding is enabled, but its been switched over via the vm.customize
instructions.

Then checking the network configuration of the host:

D:\>"c:\Program Files\Oracle\VirtualBox\VBoxManage.exe" showvminfo vagrant-katello_pxe_1507811444608_64253
[truncated]
...
NIC 1:           MAC: 080027F9F440, Attachment: Internal Network 'intnet', Cable connected: on, Trace: off (file: none), Type: 82540EM, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy: deny, Bandwidth group: none
NIC 2:           MAC: 0800271FB358, 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 2 Settings:  MTU: 0, Socket (send: 64, receive: 64), TCP Window (send:64, receive: 64)
NIC 2 Rule(0):   name = ssh, protocol = tcp, host ip = 127.0.0.1, host port = 52222, guest ip = , guest port = 22
NIC 3:           disabled
...

[a0s]

On fresh Ubuntu Minimal 16.04.2 only first interface was dhcp'ed during boot, so NAT (second) interface never getting ip. My config:

%w(node1 node2 node3).each_with_index do |name, idx|
    ssh_host = "522#{'%02d' % idx}".to_i

    node.vm.provider "virtualbox" do |vm|
        vm.customize ['modifyvm', :id, '--nic1', 'bridged', '--bridgeadapter1', 'en0', '--nic2', 'nat']
        vm.customize ['modifyvm', :id, '--natpf2', "ssh,tcp,127.0.0.1,#{ssh_host},,22"]
    end

    node.vm.network :forwarded_port, id: 'ssh', guest: 22, host_ip: '127.0.0.1', host: ssh_host, auto_correct: false, adapter: 1
    node.vm.network :public_network, bridge: 'en0: Wi-Fi (AirPort)', use_dhcp_assigned_default_route: true, adapter: 0
end

[grantcurell]

Are there plans to make it so you can disable this? In my scenario I need no post boot configuration. If I understand correctly that's the whole purpose of this interface.

[prologic]

We run into the same set of problems as described here too. I'm finding Vagrant + Virtualbox to be the wrong set of tools for simulating a multi-machine virtual environment to be honest. Its probably better to use Proxmox or libvirt as Vagrant was originally designed as a "Development Environment" where networking requirements are significantly less complex.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.