Kioptrix No IP Address in VirtualBox (Host-Only): The PCnet-PCI II Fix + Reset Checklist (2026)

---

1) Who this is for / not for (don’t waste 30 minutes)

Who this is for

• You see no IP in ifconfig / ip a on Kioptrix using Host-Only.
• You can’t find Kioptrix from Kali because the VM never gets a lease.
• You suspect a NIC model mismatch (older images + modern VirtualBox defaults).

Who this is not for

• You’re using NAT-only and expecting Kali to reach the VM directly without extra wiring.
• You’re on VMware or Hyper-V (the knobs are different).
• Your issue is “I have an IP but can’t ping.” (We’ll cover that later, but it’s not the same root problem.)

A quick personal confession: I’ve lost more time than I want to admit to “just one more toggle.” Promiscuous mode. Cable connected. Random advanced settings. It felt productive. It wasn’t. The win is to move like a surgeon: confirm symptoms, isolate the cause, apply one high-leverage fix, then reset the environment so you don’t fight the same ghost next week—and if you need a guardrail for that exact spiral, keep the OSCP rabbit hole rule somewhere you’ll actually see it.

---

2) The “host-only but no IP” triage in 60 seconds (do this first)

Confirm the symptom (don’t guess)

• Inside Kioptrix, you see an interface, but no IPv4 address assigned.
• Or you see nothing meaningful at all, which is also a clue.

If you have console access, you’re looking for one simple truth: is the guest trying to get an address and failing, or is the NIC itself not usable? Even on older images, kernel messages are often more honest than our assumptions.

The first 3 checks that decide the whole story

• Cable connected is enabled in VirtualBox (it’s easy to miss).
• Correct Host-Only network name is selected (not the orphaned one you made months ago).
• DHCP is available on that Host-Only network, if you’re expecting DHCP.

Oracle’s VirtualBox manual describes Host-Only networking as a private network between host and guests, and it also notes the built-in DHCP server can hand out addresses for Host-Only networks. That’s the mental model: Host-Only is a small, local neighborhood. If there’s no mailbox (DHCP), nobody gets mail (an IP).

Show me the nerdy details

The fastest “prove it” move is to separate layers: (1) is the VM attached to the right Host-Only network object, (2) is the Host-Only network’s DHCP server enabled and scoped correctly, and (3) does the guest have a driver for the emulated NIC model. If you change multiple layers at once, you’ll fix it… and never know why.

Small lived-experience moment: when I see “no IP,” I immediately check whether I’m attaching to vboxnet1 instead of vboxnet0. That one letter can cost you 45 minutes and a mild identity crisis—especially if your lab setup isn’t standardized, which is why a “one-page baseline” like Kali lab infrastructure mastery quietly saves hours.

---

3) The silent culprit: NIC model mismatch (PCnet-PCI II wins on old Kioptrix)

Why “Intel PRO/1000” can fail on legacy images

Newer VirtualBox defaults are usually fine for modern guests. But Kioptrix images are often from an era where “modern defaults” is a polite way of saying “driver support is unpredictable.” You can end up in a situation where the interface exists, but it never behaves properly during DHCP negotiation. It’s not your imagination; it’s compatibility friction.

The fix that works disproportionately often

Switch the adapter type to PCnet-PCI II (Am79C970A). This is one of those rare troubleshooting steps that actually deserves its reputation. It’s not magic. It’s simply an older, widely supported emulated NIC that legacy guests tend to accept without drama.

Curiosity gap: the clue hiding in plain sight

If you can see an interface name (like eth0) but it never leases an address, that often points to a driver/model handshake problem rather than “Host-Only is broken.” In other words: your VM is standing at the door. The lock just doesn’t like the key.

I once chased a “DHCP issue” across three menus and two reboots… and it turned out the guest didn’t like the NIC model. Switching to PCnet-PCI II felt almost insulting in its simplicity. That’s the best kind of fix.

---

4) VirtualBox Host-Only settings that look fine but break DHCP anyway

Pick the right Host-Only network (don’t let VirtualBox “help” you)

VirtualBox can accumulate Host-Only adapters over time—especially if you’ve installed/uninstalled, upgraded, imported appliances, or experimented. The UI will happily show you multiple options that all look equally valid. They are not.

• Use one Host-Only network for labs.
• Name it or at least remember its pattern.
• Attach both Kali and Kioptrix to the same one when you want them to talk.

DHCP server: enabled, scoped, and actually serving

In VirtualBox Preferences (or Tools, depending on version), each Host-Only network has DHCP server settings. The VirtualBox manual explicitly mentions a DHCP Server tab for Host-Only networks and describes the built-in DHCP server as managing IP addresses automatically. Translation: if you want DHCP, it must be enabled, and the scope must match the Host-Only subnet.

Let’s be honest… (micro-check you’ll skip and regret)

If you created multiple Host-Only adapters over time, you’re probably attaching the VM to the wrong one. I’ve done it. You’ve probably done it. VirtualBox even makes it feel normal—like collecting adapters is a hobby.

Here’s the practical operator move: treat Host-Only like a single piece of lab infrastructure. One network. One DHCP scope. One shared expectation. Your future self will thank you with fewer sighs.

---

5) The PCnet-PCI II Fix (step-by-step, no fluff)

Step 1 — Power off (not “Save State”)

Power off the VM fully. “Save State” is convenient, but it can preserve a broken network state the same way a bad dream follows you into the morning. If you’re troubleshooting, you want clean boots, not frozen ghosts.

Step 2 — Adapter 1: Host-Only + correct network

• Network → Adapter 1 → Enable Network Adapter
• Attached to: Host-Only Adapter
• Name: select your intended Host-Only network (the one your Kali VM will also use)
• Check “Cable connected”

Step 3 — Advanced: set PCnet-PCI II (Am79C970A)

In the Advanced section, set Adapter Type to PCnet-PCI II (Am79C970A). This is the compatibility lever.

Step 4 — Boot and request DHCP cleanly

Boot Kioptrix. Then request an address. The exact command varies by image, but the idea is always the same: bring the interface up, then ask for a lease. If the guest is ancient and tools are limited, even a reboot after the adapter change can be enough to trigger DHCP again.

Quick anecdote: the first time I did this, I expected fireworks. Instead, it was just… an IP address quietly appearing. It felt like watching a stubborn door finally open without squeaking.

---

6) Reset checklist: make the fix “repeatable,” not “lucky”

Fixing “no IP” once is nice. Fixing it so it stays fixed is the real flex. This section is about making your lab boring—in the best way.

Reset the VM-side network state

• If the guest keeps stale lease info, clear it (varies by distro/tools).
• If you changed NIC models, treat it like new hardware: reboot cleanly.
• If there’s a network config file that pins MAC/interface names, verify it’s not mismatched.

Reset the VirtualBox-side network state

• Remove unused Host-Only adapters you don’t need.
• Keep one Host-Only network with a clean IP range.
• Enable DHCP only if you want DHCP; otherwise plan for static IPs.

Curiosity gap: why rebooting sometimes “works once”

Because your environment is inconsistent. The VM might momentarily attach to the expected network object, then drift back to the wrong one later. Or DHCP scope overlaps with something else on your host. Random success is a smell. Consistent success is a system—and the “system” part gets easier when you standardize your workflow the same way you would in note-taking systems for pentesting.

My own rhythm: I start with DHCP for speed, then I pin a static IP once the lab is stable. It’s the same way I keep coffee in a travel mug until I’m confident I won’t spill—then I pour it into a real cup.

---

7) Common mistakes (the two that burn the most hours)

Mistake #1 — Mixing NAT and Host-Only without intent

NAT is great when the guest needs outbound internet (updates, tools, downloads). Host-Only is great when you want a private lab network that doesn’t touch your physical LAN. Mixing them is fine—when you’re doing it on purpose. The mistake is mixing them while expecting one mode to behave like the other, which is why having a reference like when NAT, Host-Only, and Bridged each win prevents so much unnecessary menu-clicking.

• If you want Kali to reach Kioptrix directly: they must share a network (Host-Only is perfect).
• If Kioptrix needs internet: add a second adapter on NAT (optional, and often unnecessary for Kioptrix).

Mistake #2 — “Fixing” it by changing random Promiscuous Mode settings

Promiscuous mode can matter in certain sniffing/bridge scenarios, but it rarely solves “no IP address.” If your guest can’t lease an address, promiscuous mode is like turning your car stereo volume up to fix a flat tire.

Don’t do this (printable)

• Don’t troubleshoot from a Saved State when networking is broken.
• Don’t keep three Host-Only adapters “just in case.” That’s how you attach the wrong one at 2 a.m.
• Don’t assume “link up” means “DHCP reachable.”

Small, honest moment: I’ve absolutely tried “reinstall VirtualBox” out of frustration. It’s a dramatic gesture. It also usually avoids the real cause. We’re going to be calmer than that.

---

8) If it still won’t lease: isolate DHCP vs driver in 3 moves

This is where you stop being a person clicking menus and become an operator. We’re going to isolate the layer that’s failing. Three moves. No chaos.

Move 1 — Does the host have a Host-Only IP on that adapter?

Your host should have an IP on the Host-Only interface (the “host” side of the network). If that interface is missing or misconfigured, guests can’t reach DHCP reliably. Host-Only is host-managed by design—if the host network object is unhealthy, guests suffer.

Move 2 — Does any VM get a lease on this Host-Only network?

Spin up a known-good VM (even a tiny Linux live image) and attach it to the same Host-Only network. If that VM gets a lease, your Host-Only DHCP is fine and the issue is likely inside Kioptrix (driver/model/tooling). If no VM gets a lease, your problem is VirtualBox Host-Only plumbing.

Move 3 — Read the boot messages like a detective

Look for lines about the NIC driver, link status, and DHCP attempts/timeouts. You don’t need to be a kernel archaeologist. You just need to see whether the guest recognizes the NIC and tries to negotiate an address.

Here’s what no one tells you…

Many “Kioptrix no IP” issues are VirtualBox Host-Only wiring, not the VM. Prove which side is failing before you tweak anything else. When you isolate first, the fix feels almost obvious.

Short Story: I once built what I thought was a “clean” pentest lab before a weekend sprint. Kali ready. Notes open. Coffee working overtime. Kioptrix boots and shows an interface—so I assume DHCP is broken. I toggle settings like I’m defusing a bomb: promiscuous mode, cable, NAT, host-only, different adapter names. I even rename a host-only network like that will make it behave.

Two hours later, I notice the VM is attached to a different host-only adapter than Kali. It’s the kind of mistake that doesn’t feel stupid until you see it written down. I switch to the correct network, set the NIC to PCnet-PCI II, reboot cleanly, and the IP appears like it was always willing to be there. The lesson wasn’t “be smarter.” It was “be systematic.” (120–180 words)

---

9) “I got an IP… but Kali can’t reach it” (the next failure mode)

Getting an IP is progress. But if Kali still can’t reach Kioptrix, you’ve moved from DHCP/driver issues into connectivity alignment. This is where most people panic and start changing everything again. Don’t. You’re one checklist away from clean traffic.

Confirm both VMs are on the same Host-Only network

• Kali Adapter: Host-Only → the same network name as Kioptrix
• Kioptrix Adapter: Host-Only → the same network name as Kali
• Subnet: both IPs should live in the same range (same netmask)

Basic connectivity checklist (minimal but decisive)

• Ping from Kali → Kioptrix IP.
• If you can, ping from Kioptrix → Kali IP (even one successful ping tells you the path exists).
• Verify netmask consistency (a mismatched netmask can make neighbors look “far away”).

Curiosity gap: when the IP is real but the route isn’t

Host-Only is simple—until you attach the wrong interface on Kali or your Kali has multiple adapters and you’re testing from the wrong one. If you’re running Kali with NAT + Host-Only, make sure you’re using the Host-Only IP as your source path for lab traffic.

I’ll admit it: I’ve typed the right target IP and still wondered why nothing responded—because my Kali was talking out of the NAT interface. It’s like calling the right number from the wrong phone and blaming the person for not answering.

---

FAQ

Why does Kioptrix show an interface but no IP in VirtualBox Host-Only?

Most commonly, the VM is attached to the wrong Host-Only network object, the Host-Only DHCP server is disabled/mis-scoped, or the guest doesn’t play nicely with the emulated NIC model. That’s why switching to PCnet-PCI II is such a high-success step for older images.

Which VirtualBox NIC type works best for legacy Kioptrix images?

For many older Linux guests, PCnet-PCI II (Am79C970A) is a reliable compatibility choice. It’s an older emulated NIC that legacy kernels tend to support without extra work.

Do I need Host-Only DHCP enabled, or can I set a static IP?

You can do either. DHCP is faster to set up and fine for casual practice. Static IPs reduce friction when you revisit labs, write notes, or run scripts. Pick one approach and stay consistent to avoid chasing “moving targets.”

What’s the difference between Host-Only, NAT, and Bridged for pentest labs?

Host-Only gives you a private network between host and guests—great for isolated labs. NAT gives guests outbound internet access, but it doesn’t automatically let Kali talk to Kioptrix as peers. Bridged puts the VM on your physical LAN, which is often unnecessary (and sometimes risky) for vulnerable lab targets.

Why does “Save State” make networking problems come back?

Save State preserves the VM’s exact state, including networking quirks. If the VM is “stuck” in a bad handshake or lease state, restoring it can bring the problem right back. When troubleshooting, prefer a full power off and clean boot.

How do I find Kioptrix’s IP if it doesn’t display at boot?

If you have console access, check interface output (like ifconfig or ip a). If you don’t, you can often discover it from Kali by scanning the Host-Only subnet—once you’ve confirmed DHCP is working and both VMs are on the same Host-Only network. When you get to scanning, use a repeatable approach like how to use Nmap in Kali for Kioptrix so you don’t confuse “no host found” with “wrong subnet.”

Can I run Kioptrix on VirtualBox 7.x without networking weirdness?

Yes, but older guests can be sensitive to defaults. Treat compatibility as a first-class step: choose a NIC model the guest likes (often PCnet-PCI II), keep Host-Only networks clean and minimal, and avoid restoring old saved states when troubleshooting.

How do I make Kali and Kioptrix talk without exposing the VM to my LAN?

Use Host-Only for both VMs on the same Host-Only network. If Kali needs internet updates, add a second adapter on NAT for Kali only. Keep Kioptrix isolated unless you have a specific reason to give it outbound access.

---

Wrap-up: your known-good lab in 15 minutes

Let’s close the loop from the beginning: the reason this problem feels “mysterious” is that it’s quiet. VirtualBox will happily let you attach a VM to the wrong Host-Only network object. Old guests will sometimes accept a NIC interface name but refuse to behave during DHCP negotiation. And saved states can freeze the whole mess in amber. None of that is your fault—just the price of mixing modern hypervisor defaults with legacy training images.

The antidote is to make your lab boring:

• One Host-Only network you trust.
• DHCP enabled and scoped if you want DHCP (or a clear static plan if you don’t).
• PCnet-PCI II (Am79C970A) for Kioptrix when “no IP” shows up.
• Power off during troubleshooting—avoid Save State until things are stable.

Your concrete next step within 15 minutes: pick one Host-Only network, attach both VMs to it, set Kioptrix to PCnet-PCI II, and do a clean power-off boot. If you want extra polish, save that working setup as a reusable “known-good” baseline (snapshot after you confirm a lease). The next time “no IP” appears, you won’t feel stuck—you’ll feel mildly amused.

And once the network is stable, your momentum comes back fast: you can move straight into discovery with easy-to-miss Nmap flags, avoid misleading banners with Nmap service-detection false positives, and—if Kioptrix is your next box—continue cleanly with Kioptrix Level 1 without Metasploit and the Kioptrix Level 1 privilege escalation checklist. When you finally land a shell, keep your terminal usable with the Kioptrix TTY upgrade checklist—because a stable lab isn’t just networking; it’s the whole chain staying calm.

Last reviewed: 2026-01.