Creating an Isolated Internal Network for Virtual Machines 💻
Virtualization offers powerful tools for creating isolated environments. This post will walk you through setting up a custom internal network that’s completely cut off from the host operating system (OS) and the internet. This is perfect for testing, development, or in the case of Whonix, enhancing security by ensuring no direct connections can be made outside the virtual network.
The Power of Isolation 🛡️
A typical virtual machine might use NAT (Network Address Translation) to share the host’s internet connection or a host-only network to communicate with the host OS. A truly internal network, however, is different. It’s a closed system. VMs on this network can talk to each other but cannot reach the internet or the host. This configuration is sometimes called an “isolated” or “private” network.
Walkthrough: Setting Up a Private Virtual Network ⚙️
We’ll use a hypervisor like libvirt on Linux, which manages virtual machines and networks, to create this internal network. The process involves creating an XML file and then defining the network using the virsh command-line tool.
Step 1: Understanding the XML Configuration 📝
To create an XML configuration for an internal network but with no connection to the host OS, you can add an <name>, <bridge> and <dns>.
<network> <name>internal-net55</name> <bridge name="virbr55" stp="on" delay="0"/> <dns enable="no"/> </network>
Why the XML Lacks L3 Information 🤔
- Explicit Isolation: The
<dns enable="no"/>tag is key. It’s a deliberate choice to prevent the hypervisor from automatically providing any L3 services like DHCP, which would assign IP addresses. This ensures the network is truly isolated from the host’s L3 routing and prevents accidental internet access. - Flexibility: By leaving out L3 details, the network becomes more flexible. A user can manually configure static IP addresses on the guest OSs, use their own virtual DHCP server within one of the VMs, or even rely on IPv6 stateless autoconfiguration if they choose. This is common in more advanced network setups.
The provided XML does not include IP addresses, a subnet mask, or a DHCP server because this configuration is for a layer 2 (L2) network, not a layer 3 (L3) network. This means the network is defined at the data link layer, which handles communication between devices on the same local network using MAC addresses, not IP addresses.
How Guest OSs Communicate on the Same Network 🤝
Even without a DHCP server or defined subnet in the XML, guest OSs on the same virtual bridge (virbr55 in this case) can communicate because they are on the same broadcast domain.
- Layer 2 Communication: When a guest OS wants to find another device on the same network, it sends out an ARP (Address Resolution Protocol) request. This broadcast message asks, “Who has the IP address 192.168.1.10?”
- Virtual Bridge’s Role: The
virbr55 virtual bridge acts like a physical network switch. It receives the ARP broadcast and forwards it to all connected virtual machines. - MAC Address Lookup: The target guest OS receives the broadcast, recognizes its own IP address, and sends back a response containing its MAC address. The first guest OS then caches this MAC address and can send future traffic directly to the second guest OS’s MAC address.
- Manual Configuration: The guest OSs still need to be configured with an IP address and subnet mask within the guest itself. For example, you would manually set one VM to
10.0.0.1and another to10.0.0.2, both with a subnet mask of255.255.255.0. The virtual bridge simply facilitates this L2 communication.
Step 2: Creating the Network 🛠️
Assuming you have a hypervisor like libvirt installed, you can create a file (e.g., internal-dhcp-net.xml) with the XML content.
Next, you’ll use the virsh command to define and start the network:
- Define the network:
sudo virsh net-define internal-net55.xml - Start the network:
sudo virsh net-start internal-net55 - Set the network to autostart on boot:
sudo virsh net-autostart internal-net55
After these steps, your Whonix-Internal network is ready to be used.
Step 3: Attaching VMs to the Network 🔗
When you create or modify a virtual machine, you can now attach its virtual network interface card (NIC) to this new network. You’d specify internal-dhcp-net as the source network for the VM’s network adapter. The XML snippet for a VM’s network interface would typically look something like this:
<interface type='network'> <source network='internal-net55'/> <model type='virtio'/> <target dev='vnet21'/> </interface>
Let’s break down the key parts:
<interface type='network'>: This defines a virtual network interface card (NIC).<source network='internal-net55'/>: This is the most important part. It tells the hypervisor to connect this virtual NIC to the network you defined earlier, which is namedinternal-dhcp-netin this example.<model type='virtio'/>: This specifies the type of network card to present to the guest OS.virtiois a paravirtualized driver that offers the best performance.<target dev='vnet21'/>: This specifies the name of the network device on the host system.
To use this XML, you would either include it directly in the main XML file for the virtual machine or, if the VM already exists, use a command like virsh attach-device with this XML to add the new interface.
Any VM connected to this network will be able to communicate with other VMs on the same network, but they won’t have a gateway to the outside world. This is by design, providing maximum isolation.
Final Thoughts and Use Cases 🤔
Creating a custom internal network is a fundamental skill for anyone working with virtualization for security or development. It provides a clean, predictable environment where you control all the network traffic.
Whether you’re building a multi-tier application stack, simulating a corporate network for penetration testing, or simply trying to lock down a sensitive VM. It’s a powerful tool in your virtualization toolkit, offering both security and control.
