When creating a virtual machine (VM), you have a lot of options regarding networking. You can set up your VM to act as just another computer on your network, secure it behind an internal router and firewall, or even simulate a fully custom real world network.
This guide will specifically cover the networking options found in VirtualBox, but the same concepts will apply to other virtualization programs as well.
Network Address Translation (NAT)
This network type is the default for new VirtualBox instances, and is fairly simple to understand. It simply enables the guest OS to access the internet, in the same way that your computer accesses it behind your home router.
For example, your computer may have IP address 192.168.1.5 on your home network. Your router will have an IP assigned by your ISP, such as 73.45.123.123. When you connect to an external service, your router translates your internal IP address into the public-facing external IP you use to communicate with. (Technically, it uses an extension of NAT, called Port Address Translation, but the concept is the same.)
In a way, this is exactly like putting your VMs behind an additional router. Packets sent from the VMs will go through two translations—first, to translate the VM’s private IP address into the host’s private IP address, and then to translate the hosts’s private address into your gateway’s public address. In the end, this enables internet connectivity for the virtual machine. As far as the VM is aware, it’s exactly like a device on a home network.
NAT mode does not give the host (or any other local machine) access to services running on a VM, in much the same way that a service running on your local network isn’t publicly accessible from the open Internet. If you want an application to be accessible, you must port forward the ports that it runs on, and bind them to the host’s local ports. This is both a good and bad thing—on one hand, it’s far more secure this way, as even local devices can’t access the VM’s services, but manually opening ports may not be what you want. If this seems like an issue, Bridged mode is a potential solution. You can also expose guest services to the openinternet by port forwarding your router to forward a port to the host machine, which will forward the connection further to the guest.
While all other directions of communication are possible, NAT mode does not give guest-to-host access.
You should choose NAT if you need basic internet access, but still want to keep the VM separate from other machines on your network.
NAT Network
In NAT mode, the internal router is configured for each virtual machine. One VM cannot access services running on another virtual machine. In fact, each machine can have the exact same private IP address, because it all gets translated out in the end.
NAT Network mode follows the same principle of NAT, but instead of logically separating each VM into its own network, NAT Network uses one network for all VMs configured on the same NAT Network (though nothing stops you from having multiple separate networks).
This enables guest-to-guest access via a virtual switch, much like how a computer plugged into your router’s first ethernet jack can access a machine plugged into the second jack. Otherwise, this mode operates exactly the same as NAT; host-to-guest access can only be accomplished via port forwarding (though, this time you’ll have to choose which VM to forward to).
The only major difference is that because there are multiple VMs in one network, each VM must have a different address. This requires the host to run a DHCP server (again, much like you’d find in your home router), which dynamically assigns internal IP addresses to each VM on the network. This can be disabled and manually configured if you desire.
You should choose NAT Network over basic NAT if you need guest-to-guest access.
Bridged
Bridged mode is unique among the network modes, as it’s the only mode that does not isolate the virtual machines in some way. In Bridged mode, your VM communicates with external services directly, using the host’s network interface.
This means that VMs will appear to your router as entirely separate IP address, although routed to the same machine. This enables you to host services on the VMs and access them on your local network using an address and port number, which makes bridged networking very flexible.
This networking mode is used by many VPS providers, like AWS, as it allows them to partition a large powerful server into multiple smaller servers that can be sold to customers. Each machine will have its own unique IP address on the network. Though, for services like AWS, a lot of additional protections and systems are put in place to prevent you from accessing the virtual machines of other customers, and its orders of magnitude more complicated than this.
While the host is used to route the packets back to the server, it doesn’t interfere with them in any way, making the guest OS appear as just another computer on your network. However, because there’s nothing isolating the VM from the outside network, there’s no inherent firewall or protection in place other than your gateway’s firewall, and any firewalls manually configured on the guest OS.
Most servers will come with many ethernet ports, and multiple physical interfaces. Because Bridged mode simply bridges one of these physical interfaces, it can be used to run virtual machines on entirely separate networks, depending on your real-world cabling.
You should choose Bridged networking if you want full unhindered access. Also useful if you just want to run multiple “virtual” servers using the same hardware, much like how a VPS provider would.
Host-Only Adapter
In Host-Only mode, the virtual machines have no way of accessing the internet. However, host-to-guest and guest-to-host communication is still possible, and is the primary reason for using this mode.
In this mode, a DHCP server is usually ran to give out IP addresses to the guests, and guest-to-guest communication is also easy using the internet network.
You should choose Host-Only mode if you need a lot of bidirectional communication between host and guest but don’t want internet access on the host. If you need bidirectional communication but need external access, you can accomplish the same effect with bridged mode, which allows full access.
Internal (Simulated) Network
Internal Network is used to model real networks. Out of the box, it’s entirely separate from the outside world; multiple guests deployed in the same network can access each other, but not the host, or the internet, or vice versa. This is useful in its own right by being able to simulate networks that are entirely disconnected from the world, but Internal Network can be configured to give internet access to the private machines.
By creating a new virtual machine and configuring it as a router (such as with iptables), you can tell all other machines on the virtual network to use the new router VM as their default gateway. In order to actually access external networks, you’ll need to create a seperate network interface using an internet-connected mode (NAT, Bridged, etc), and attach it to the router. Technically, Internal Network on its own isn’t what gives internet access, but VM1 and VM2 in this example won’t have any network interfaces enabling direct internet access.
In a way, this setup isn’t much different from NAT Network mode, but everything is handled manually.
You should choose Internal Network if you’re looking to simulate or model a virtual network, or if you just need the flexibility of setting everything up yourself. Internal Network is very useful for training purposes, as it allows anyone to configure their own network without heading down to Radioshack to buy the hardware they need.