For a local Kioptrix lab, place Kali and the vulnerable target on a deliberately chosen virtual network. Start with either host-only networking when host access is needed, or an internal VM network when communication should stay between the VMs. Confirm addressing separately: an isolated network does not automatically provide DHCP.
A consumer VPN does not create this VM boundary. This guide focuses on local hypervisor networking, target identity and troubleshooting. It does not certify an environment as secure.
Choose a mode with the access paths in mind
The table describes typical VirtualBox mode behavior. VMware names and defaults differ; inspect the actual configuration rather than relying on a familiar label. “No default outbound path” still depends on the absence of extra adapters, routing and sharing.
| Mode | VM-to-VM | Host access | Outbound path | Lab consideration |
|---|---|---|---|---|
| Host-only | On the same host-only network. | Yes, through the host’s virtual interface. | No default external route provided by the mode. | Includes the host in the lab boundary. |
| Internal network | Between VMs on the same named network. | No host network interface by default. | No default external route provided by the mode. | Addressing still needs configuration. |
| NAT, individual VM adapter | Separate default NAT instances do not provide a shared VM segment. | Depends on direction and forwarding configuration. | Yes. | Two VMs both labeled NAT may not reach one another. |
| NAT Network | Within the same configured NAT Network. | Depends on direction and forwarding configuration. | Yes. | Shared VM connectivity with outbound access. |
| Bridged | Via the physical network, subject to its controls. | Via the physical network. | Via that network. | Connects the target to a real network; avoid as the default for a vulnerable appliance. |
See VirtualBox’s networking details for mode behavior, DHCP and configuration. Hypervisor version and platform can affect available options.
Set up both VMs, then audit every adapter
- Finish the import first. Confirm a stable guest boot. Use the import guide for disk or architecture problems.
- Choose the boundary. Write whether the host should be reachable and whether any outbound route is intended.
- Attach both lab adapters to the same network. Match the exact internal network name or host-only network object, not merely the mode label.
- Inspect all adapter slots. Check enabled adapters, cable-connected state, network identity, port forwards and any additional physical or NAT connections.
- Provide addressing. Confirm the intended DHCP service or assign compatible static addresses according to the lab’s requirements.
- Verify identity before scanning. Match discovered addresses to the intended VM, then save the resulting configuration.
A second adapter on Kali can create a path outside the lab if forwarding, connection sharing, bridging or proxies are enabled. Treat a dual-homed VM as part of the boundary review. For routine Kali maintenance, a simpler workflow is to power off the target, connect Kali to its update network, complete maintenance, then remove that connection and recheck the lab configuration before resuming.
Network isolation also does not remove risks from shared folders, clipboard integration, USB passthrough or hypervisor vulnerabilities. Enable integrations deliberately and keep the host and hypervisor maintained.
Separate DHCP, subnet membership and target identity
DHCP must exist on the selected segment if the guests depend on it. An internal network can connect the VMs without supplying addresses. A host-only network may have a configurable DHCP server; inspect whether it is enabled and which range it serves. Do not add a second DHCP service without understanding the existing one.
On Kali, inspect the local configuration:
ip -br addr ip route nmap --iflist
Record the lab interface, address and prefix. Check which interface and route apply to the target. Similar-looking private addresses do not prove that two VMs share a segment, and an address left over from a previous network is not evidence of current connectivity.
Use the hypervisor’s VM MAC address and, where available, DHCP lease information to establish target identity. On a confirmed dedicated local segment, optional ARP discovery can provide a further comparison; see the Kali tools guide. Do not scan a broader physical network to compensate for an unknown target address.
Diagnose the earliest unproven connection
| Symptom | Next check |
|---|---|
| No usable lab address on Kali | Adapter enabled, cable connected, exact network and intended DHCP/static configuration. |
| Kali has an address; target not identified | Target boot state, target adapter and MAC, DHCP lease or image-specific addressing requirements. |
| Both appear addressed; no communication | Prefixes, route selection, common network object and relevant filtering. |
| Ping fails | Do not treat ICMP silence alone as proof the VM is down. Compare identity and a scoped protocol observation. |
| Unexpected internet access from the target | Stop testing and inspect extra adapters, NAT, forwarding, sharing and host routing. |
| VMs work until a VPN connects | Compare route tables and interface selection before and after the VPN change. |
Change one item at a time and record its previous value. A complete reimport erases useful diagnostic context when the actual problem is a network-name mismatch or missing DHCP.
When is a VPN relevant?
A remote training platform may provide a specific VPN connection to its own lab network. Follow that platform’s scope and routing instructions. That arrangement differs from a commercial privacy VPN and from a local internal network. No VPN product is required merely to connect two VMs on the same local lab segment.
Copy this boundary record before the first scan
Hypervisor and version: Target VM identity, MAC and snapshot: Kali lab interface and MAC: Mode and exact shared network name: Every enabled adapter on each VM: DHCP service or static addressing plan: Observed addresses and prefixes: Route to the target: Host access intended / observed / untested: Outbound access intended / observed / untested: Forwarding, sharing, port forwards and integrations reviewed: Evidence and remaining uncertainty:
Use “untested” where you have not verified a property. Checking boxes or generating a record cannot prove isolation. Once the boundary and target identity are established, continue to service enumeration and preserve the baseline in your lab notes.