Using host networking and NAT with VirtualBox

Leonardo, this setup puts the VMs on a virtual bridge, and then instructs your host machine to forward the traffic out whichever interface it is currently using, while NATting the addresses. You can have multiple VMs on the bridge in this method.

If you want to have the VMs instead bridge directly to a real physical interface, you won’t do this. Instead you’ll add the physical interface to the bridge with something like “bridge_ports eth0″ in the bridge setup, and skip setting up IP forwarding and dnsmasq. Now your VMs will request an IP from the DHCP server on your LAN and directly access the network. The advantage is avoiding a NAT layer. The disadvantage, especially for Windows VMs, is avoiding a NAT layer, since that exposes them to the usual array of exploits and viruses.

Manuals for older versions are kept in named trees here. I plan to test 3.0 soon.

Justin, here are some tips on that:

http://my.opera.com/irootx/blog/show.dml/1760271
http://www.samlesher.com/fedora/bridge-network-interface-on-virtualbox-in-fedora

Neither is exactly what I do here, and you’ll still have to do the firewall stuff in /etc/sysconfig/iptables, but this is the right track.

Hi Dani,

You say that the VM is getting an IP from VirtualBox, which means you are using NAT networking on the VM. VirtualBox -> Settings for your VM -> Network -> “Attached to: NAT”. But you are trying to put the VM on the same subnet as your host’s eth0. That won’t work.

It sounds like what you want to do is bridge the VM to the host’s eth0. Once you do that, Virtualbox will no longer give the VM an IP, so you’ll have to configure it in /etc/network/interfaces or get it via DHCP from the same source as your host does. To set this, change the VM’s network settings in VirtualBox to “Attached to: Bridged” and “Name: eth0″.

Tiago,

You cannot put vnet0, the bridge you created, in “Host-only networking”. That’s for the virtual bridges that Virtualbox creates, only. You can only have it in “Bridged networking” mode.

Hi Georgios,

What you want is a “DMZ Host” setup, like some home routers offer. You want to run something like this:

iptables -A PREROUTING -i eth0 -p tcp -m multiport –dports 22 -j ACCEPT
iptables -A PREROUTING -i eth0 -m state –state NEW -j DNAT –to-destination 172.16.0.2
iptables -A POSTROUTING -o eth0 -j MASQUERADE

Hi Georgios,

As long as your VMs and VirtualBox config files have migrated to the latest xml format (read the XML files to see what I mean), you should be fine. Half of my VMs have been migrated from VirtualBox 1.6.2.

I have had no trouble with Host-Only, but I didn’t try using DHCP, only static assignments. Not sure if DHCP is offered in that mode, as Host-only mode is useful for simulating networks between VMs. For instance, I test router setups that way, and I wouldn’t want a DHCP server on such a network.

Hi MheAd,

I could probably help you a little better if you posted the output of “iptables-save”. It’s more readable, at least to me.

The first question I would ask is: Why use a firewall on FORWARD, if you are doing NAT? NAT acts as a perfectly effective firewall anyway.

Here is what I use for my default FORWARD rules on any router:

:FORWARD DROP [0:0]
-A FORWARD -i vnet0 -j ACCEPT
-A FORWARD -p tcp ! –syn -m state –state NEW -j DROP
-A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -p icmp -m icmp –icmp-type 0 -j ACCEPT
-A FORWARD -p icmp -m icmp –icmp-type 3 -j ACCEPT
-A FORWARD -p icmp -m icmp –icmp-type 4 -j ACCEPT
-A FORWARD -p icmp -m icmp –icmp-type 8 -j ACCEPT
-A FORWARD -p icmp -m icmp –icmp-type 11 -j ACCEPT
-A FORWARD -p icmp -m icmp –icmp-type 12 -j ACCEPT

Default is drop. The first rule allows all outgoing traffic (incoming from vnet0, and out via any interface). The next drops incoming bad TCP traffic (IE, those claiming bad TCP flags like ACK when there is no record of a SYN). The next allows established and related, as you are doing. The remainder allow the 6 ICMP types you probably want to allow.

These rules have always worked for me.

Dave,

Your first rule will NAT incoming connections, and it will NAT the related return traffic. If it is not, there is something else wrong. Make sure “nf_conntrack” module is loading, which will track connections like that.

If you want to NAT new outgoing connections from port 22, that alone won’t do it. You’ll also need:

iptables -t nat -A POSTROUTING -o eth0 -p tcp -m tcp --sport 22 -j SNAT --to-source 10.0.0.1:10022

Where 10.0.0.1 is your IP on eth0. But this is an unusual case.

Hi Abe,

If you want your XP guest to be visible from the rest of your network, you don’t want to do what I’m suggesting. My design intentionally leaves the guest behind a NAT layer, where my host can access it but nothing else.

From your results (“I obtain the exact same result if I select ‘bridged connection’ and I link it to my ‘eth1′ wireless interface.Guest ping host, host can’t ping guest.”), I think the problem is more likely the Windows firewall in the guest.

Hi Abe,

I don’t understand what you want to do. Do you want your VMs to be directly accessible to the rest of your LAN, with an IP from the same subnet as your host OS? If so, what you want to do is set your guest networking to “bridged” and select eth1. However, this usually only works on wired interfaces, as wireless doesn’t usually respond well to being told to transmit two different MAC addresses. It depends on the wireless hardware you are using.

If you do try to do that, don’t do anything that I recommend in this post – just make it a bridged interface on eth1. If it doesn’t work, it probably won’t. See the VirtualBox documentation.