VM management · Network modes

Network modes

Each VM has exactly one network mode. The mode decides what the guest can reach, what the host can see, and which other VMs are on the wire. Pick the right one before you introduce hostile workloads.

On this page

Mode comparison

ModeInternet?Host reachable?VM-to-VM?Best for
NATYes (via host)No (NAT'd)NoGeneral use, dev VMs, distros that need to apt update.
Virtual NetworkNoNoYes (L2)Air-gapped lab. Multiple VMs on a private switch.
Router VMThrough Kali gatewayNoYes (via router)Malware analysis. Every byte goes through an instrumented router.
FakeNetFaked (sinkholed)NoYes (via router)Capturing C2 behaviour without letting the sample phone home.

Modes are configured per-VM in the new-VM sheet, and changeable at any time when the VM is stopped (see Switching modes).

NAT

The default. Apple's Virtualization framework attaches the guest to a NAT network managed by the host. The guest gets DHCP, can reach the internet, but is invisible to anything outside the host.

  • What the guest sees: a private subnet (typically 192.168.x.0/24) with the host as gateway.
  • What you see on the host: standard internet usage attributed to your machine — outgoing traffic looks like it came from your IP.
  • What other VMs see: nothing. NAT VMs are isolated from each other.
NAT is not analysis-safe. The guest has unrestricted internet access through your host. Anything it downloads, beacons, or scans appears to come from your IP address. Use Virtual Network or Router VM mode for malware.

Virtual Network

SecVF's VirtualNetworkSwitch implements a software L2/L3 switch in the host process — pure Swift, no kernel extensions. Guests in this mode connect to the switch, which:

  • Forwards Ethernet frames between attached VMs.
  • Learns MAC addresses on each port (standard L2 switching).
  • Has no uplink to the host's network — guests can't reach the internet, can't reach the host.
  ┌────────────────────────────────────────────────────┐
  │              VirtualNetworkSwitch                  │
  │  ┌──────────┐    ┌──────────┐    ┌──────────┐      │
  │  │  port 0  │    │  port 1  │    │  port 2  │      │
  │  └────┬─────┘    └────┬─────┘    └────┬─────┘      │
  └───────┼────────────────┼────────────────┼──────────┘
          │                │                │
       VM "alpha"       VM "beta"      VM "gamma"

Use this when you want to test how multiple guests behave together — e.g. a web service in one VM, a client in another — but you don't want either to reach the internet.

Statistics & the MAC table

Monitoring → Switch Statistics (⌘⇧3) shows:

  • Frames forwarded, dropped, broadcast.
  • The MAC address table — which MAC was last seen on which port.
  • Per-port byte counters for graphing throughput.

Router VM

This is the workhorse for malware analysis. A dedicated Kali Linux VM acts as the gateway for every other VM in the lab.

  [ Malware VM ] ──┐
  [ Analysis VM ] ─┼──▶ [ Virtual switch ] ──▶ [ Kali router ] ──▶ Internet
  [ AI Sandbox  ] ─┘                            │
                                                ▼
                                       tcpdump / tshark

The Kali router is configured by scripts/kali-router-setup.sh (lives in the repo, copied into the guest via the Scripts USB) and provides:

  • Static IP 10.0.100.1/24 on the LAN side.
  • IP forwarding + iptables NAT so other VMs can route through it.
  • DHCP for the LAN side — guests just plug in and get an address.
  • Pre-installed traffic-analysis tools: tcpdump, tshark, nmap, tcpflow.
  • Helper commands: secvf-status, secvf-monitor, secvf-capture.

See the dedicated Router VM page for the full setup walkthrough.

Why route through a VM instead of the host?

  • Better filtering surface. iptables in the guest gives you Linux's full netfilter stack — DNAT, mangle, conntrack, all without touching the host.
  • Tooling parity with on-host analysis. Run tcpdump on the router and you're capturing exactly what malware sees.
  • Reproducibility. The router's state is in ~/.avf/Linux/Kali-Router.bundle/ — snapshot it, share it, replay it.
  • Defense in depth. If the malware exploits the network stack, the explosion is contained inside the router VM, not on the host.

FakeNet

FakeNet is a router-VM variant that simulates the internet. The Kali router runs DNS, HTTP, HTTPS, FTP, IRC, and SMTP responders that satisfy any outbound request without actually reaching anything.

  • DNS: all queries resolve to the router itself. Malware "phones home" — to the router.
  • HTTP/HTTPS: any URL returns plausible-looking pages or files. C2 protocols often unmask themselves on response parsing failures.
  • Other protocols: banner-grabbed responders pretend to be real servers.

FakeNet is configured by scripts/kali-fakenet-setup.sh on top of the regular router. See FakeNet for the full setup.

When to use FakeNet: for full behavioural capture of an unknown sample. The malware reveals every domain it tries to contact, every URL pattern it requests, every user-agent it forges — without ever leaving the lab.

Switching modes

Network mode is editable from the VM's settings, but only when the VM is stopped:

  1. Stop the VM (graceful shutdown preferred — see First VM).
  2. In the VM Library, right-click the VM → Edit configuration…
  3. Change Network mode in the dropdown. Save.
  4. Start the VM. The guest gets a fresh interface in the new mode — old ARP tables, leases, and any in-VM /etc/network/interfaces tweaks may need adjusting.

The mode is persisted in ~/.avf/<family>/<name>.bundle/metadata.json:

{
  "name": "ubuntu-test",
  "cpu": 2,
  "memory": 4294967296,
  "diskBytes": 21474836480,
  "networkMode": "router"
}

VM-to-VM communication

For two guests to talk, they must share a network. Quick reference:

VM A modeVM B modeCan they talk?
NATNATNo — each NAT'd guest sees a private subnet behind the host.
NATVirtualNo — different network domains.
VirtualVirtualYes — both attached to the same software switch.
RouterRouterYes — both behind the same Kali gateway.
VirtualRouterYes — the router VM is on the virtual switch too. Use the router's LAN address as gateway.

Diagnostics

When a VM can't reach what you expect, work down this checklist:

  1. Check the mode. VM Library → row → mode column. NAT vs Virtual is a frequent confusion source.
  2. Open Network Logs (⌘⇧2) — every connection on the virtual switch is logged with source/dest.
  3. Open Switch Statistics (⌘⇧3) — verify the VM appears in the MAC table on the expected port.
  4. Inside the guest: ip addr show, ip route show, resolvectl status. The interface should be up, have an IP, and (in router mode) point its default route at 10.0.100.1.
  5. Start a packet capture (⌘⇧P) — see Packet analysis. ARP and DHCP traffic at the start of a session is usually enough to pinpoint where the chain breaks.
Behaviour change between modes is expected. An app that works in NAT and breaks in router mode often relies on a host-only resolver or expects a specific gateway IP. Adjust inside the guest, not by reverting the mode.
Previous ← Managing VMs