---
{
  "title": "Virtual-machine network modes",
  "summary": "Networking choices determine which systems a lab can reach and expose.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "Kali Linux documentation",
      "url": "https://www.kali.org/docs/"
    },
    {
      "title": "Oracle VirtualBox: Virtual Networking",
      "url": "https://docs.oracle.com/en/virtualization/virtualbox/7.1/user/networkingdetails.html"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Common VM network modes include NAT, bridged, host-only, and internal networks, with details varying by hypervisor. NAT usually gives a guest outbound connectivity through a translation layer. Bridged mode places it on a connected network. Host-only commonly connects guests with the host on a private virtual segment, while internal modes can limit communication to selected guests. Verify actual behavior and any port forwarding.

## In practice

A training target on a host-only segment is tested for isolation. A separate controlled update connection is used only when needed.

## A common misunderstanding

NAT does not guarantee total isolation; outbound access and configured forwarding still matter.

## Check your understanding

Why avoid bridged mode for a deliberately vulnerable target by default?

**Think it through:** It can expose the target to unrelated devices on the physical network.

## Describe who can reach whom

A fictional training lab has a learner VM, a vulnerable target, the host laptop, and the household network. Choosing a network mode changes the possible communication between those participants. Write the intended reachability first, then select and verify a mode that fits it. Product labels are not a substitute for that map.

Multiple adapters can defeat a simple assumption. A target may have a private lab adapter and a second adapter with external connectivity. Port forwarding can also expose a service that would otherwise be unreachable from outside the guest. Inspect the complete VM configuration and host listening rules.

NAT commonly supports outbound access, so it should not be described as total isolation. Host-only networking commonly includes the host, which means vulnerable services may still be reachable from it. Internal networking can provide a different boundary between selected guests. Exact details depend on the hypervisor and configuration.

## Create a reachability matrix

For the lab example, make rows for the learner, target, host, and external network. Mark which connections should work and which should fail. Verify only against systems you own or are explicitly authorized to use. Explain any difference between the intended matrix and the observed behavior before beginning vulnerability exercises.

Record temporary changes, such as enabling an update adapter, and restore the intended configuration afterward. Recheck the matrix when importing a VM or changing hypervisors because defaults can differ. This approach teaches networking as an explicit security boundary: the important result is the permitted communication, not merely a mode name selected in a settings dialog.

## Keep exploring

- [[virtual-labs]]
- [[network-segmentation]]
- [[nat]]