VirtualBox for Network Labs: Free Virtualization for EVE-NG & GNS3

What VirtualBox is (and why people start here)

VirtualBox is a type-2 hypervisor: it installs like a normal application on Windows, Linux, or an Intel Mac and lets you run other operating systems as virtual machines. It's free and open-source, which is exactly why it's the default first hypervisor for a lot of home labs — there's nothing to buy and it runs almost everywhere.

For network study you don't usually run Cisco images directly in VirtualBox. Instead you run an emulator — EVE-NG or GNS3 — as a VM inside VirtualBox, and that emulator runs the network device images. VirtualBox is the host; the emulator does the networking.

Running EVE-NG or GNS3 on VirtualBox

EVE-NG Community Edition ships as an OVA file — in VirtualBox you choose File → Import Appliance, point it at the OVA, boot it, and reach its web UI in a browser. GNS3 works a little differently: you install the GNS3 client on your host and pair it with the 'GNS3 VM', which is offered as a VirtualBox appliance so the heavy lifting runs in the VM rather than on your desktop OS.

The setting that matters most is nested virtualization. To run real device images (which are themselves small VMs) inside the emulator VM, VirtualBox has to pass your CPU's hardware-virtualization features through to the guest — enable 'Nested VT-x/AMD-V' in the VM's Processor settings. Without it, many images either won't boot or crawl.

Where VirtualBox falls short

Cisco Modeling Labs is the big exception: CML is validated on VMware (ESXi, Workstation, Fusion) and a few server hypervisors, not on VirtualBox. If your plan is specifically CML, use VMware instead — see the VMware guide below.

Apple Silicon (M-series) Macs are the other catch. The classic Cisco lab images are x86, and an ARM Mac can't run x86 guests at native speed; VirtualBox's Apple-Silicon build is an early, ARM-only preview. On an Apple Silicon Mac a cloud option like Cisco's DevNet Sandbox, or a separate x86 machine, is usually a better path than local virtualization.

Even on supported hardware, VirtualBox's nested-virtualization performance trails VMware's, so large topologies feel heavier. For a handful of nodes it's fine; for big multi-site labs, expect to want more RAM and CPU — or a stronger hypervisor.

Should you use it?

Use VirtualBox if you're on Windows, Linux, or an Intel Mac, you want a zero-cost start, and you're running EVE-NG or GNS3 — it's the friendliest on-ramp to a home lab. If you're set on Cisco Modeling Labs, or you're on an Apple Silicon Mac, look at VMware or a cloud sandbox instead. Whatever hosts your topology, Goldfish Networks labs import the same way — build them on real IOS, then grade your own config.

Picking the right VirtualBox network mode for your lab

VirtualBox assigns a mode per network adapter, and the one you pick decides whether you can even reach your emulator. NAT (the default) gives the VM outbound internet through the host but hides it from inbound connections, so a browser on another machine can't open the EVE-NG web UI without port-forwarding. Host-only creates a private wire between just your host and the VM and is the most reliable way to reach the EVE-NG or GNS3 web UI from the same PC. Bridged puts the VM directly on your physical LAN with its own DHCP address, so any device in the house can reach it.

A practical pattern is to give the emulator VM two adapters: keep NAT (or a NAT Network) as the first adapter so the VM can pull updates and images, and add a Host-only or Bridged adapter as the management path you actually browse and SSH to. Both EVE-NG and the GNS3 VM print their management IP on boot — note that address and point your browser at it. If you want a real switch, access point, or a second laptop to touch the lab, Bridged is the mode that makes the lab visible on your home network.

The trap with Bridged mode is address overlap. Because the VM and its inner lab devices can land on the same subnet as your home router, keep lab addressing distinct from your home LAN — if your house uses 192.168.1.0/24, build the lab on something like 192.168.50.0/24 (a /24 gives 2^8 − 2 = 254 usable host addresses) so lab DHCP and home DHCP never fight. Isolating the lab subnet also stops a misconfigured routing protocol inside the lab from leaking a route toward your real gateway.

Worked example: reaching a lab router from your host over SSH

Once the emulator VM is reachable, the first genuinely useful skill is opening a management session into an actual device. Suppose EVE-NG is bridged to your LAN and, inside it, R1's GigabitEthernet0/0 sits on a management segment of 192.168.50.0/24. You want to SSH from your Windows or Mac terminal straight to R1 at 192.168.50.10 — the same workflow you'll use on real gear. This is where many beginners stall, because SSH on IOS has two prerequisites that aren't obvious from the interface config alone.

IOS won't generate the RSA key that SSH depends on until the device has both a hostname and a domain name, and the key-generation command itself runs from privileged EXEC, not from global configuration. Set the hostname and 'ip domain-name' first, then run 'crypto key generate rsa' at the R1# prompt — skipping the domain name produces the classic 'please define a domain-name first' refusal. Finish by adding a local username, restricting the VTY lines to SSH, and enabling 'login local' so your username is actually checked.

Then verify from both ends. On the router, 'show ip ssh' confirms SSH is enabled and 'show ip interface brief' confirms Gi0/0 is up with the right address; from your host, 'ssh netadmin@192.168.50.10' should drop you at the R1> prompt. If the session is refused but ping works, it is almost always a missing key or a VTY line still limited to telnet. Keep in mind this is a management interface, not routing — if you later add OSPF and advertise a loopback for router-ID or reachability, remember IOS advertises that loopback as a /32 host route by default.

R1# configure terminal
R1(config)# hostname R1
R1(config)# ip domain-name lab.goldfish
R1(config)# username netadmin privilege 15 secret C1sco!lab
R1(config)# interface GigabitEthernet0/0
R1(config-if)#  ip address 192.168.50.10 255.255.255.0
R1(config-if)#  no shutdown
R1(config-if)# exit
R1(config)# line vty 0 4
R1(config-line)#  transport input ssh
R1(config-line)#  login local
R1(config-line)# end
R1# crypto key generate rsa modulus 2048   ! run from EXEC, needs hostname + ip domain-name
The name for the keys will be: R1.lab.goldfish
% Generating 2048 bit RSA keys, keys will be non-exportable ...[OK]
R1# show ip ssh
SSH Enabled - version 2.0
R1# write memory