Kali Wi-Fi Not Detected (No wlan0): Fix for VirtualBox, VMware & Bare Metal

If Kali Linux shows no wlan0 at all, the fix depends on where Kali is running. In a virtual machine (VirtualBox, VMware, QEMU), a laptop's built-in Wi-Fi card is a PCI device, and hypervisors virtualize the entire PCI bus for the guest — your real wireless chip is never handed over, no matter which driver you install. The fix there is a USB Wi-Fi adapter passed through by device filter, not a driver search. On bare metal, the cause is almost always a missing firmware package, a soft rfkill block, or a NetworkManager service that isn't running — all fixable without new hardware.

Why Your Wi-Fi Adapter Isn't Showing at All

Jake runs a phone repair shop, and he installed Kali in VirtualBox on a Saturday morning to check whether his shop's guest Wi-Fi router was leaking WPS PINs before a corporate client's site visit that afternoon. Three hours later he still had no wlan0, and the client walked in to find him staring at a terminal instead of the demo he'd promised.

Ethan, who's fixed this exact ticket for half his mentoring calls, puts it more bluntly to Jake: "You could install every wireless driver ever written and it wouldn't matter. There's nothing there for the driver to attach to. The card physically stays with Windows or macOS on the host — the VM only ever sees what the hypervisor decides to hand it, and PCI Wi-Fi chips aren't on that list." That's the one thing worth knowing before you spend an afternoon chasing firmware packages that were never the problem.

The one exception: USB Wi-Fi adapters. USB is a bus that hypervisors are built to redirect device-by-device, so a USB dongle plugged into the host can be handed to the guest almost like plugging it in directly. That's the entire reason penetration-testing guides tell you to buy an external adapter — it isn't a recommendation for better antennas, it's the only category of Wi-Fi hardware a VM can use at all.

Step 1: Find Out What Kali Can Actually See

Before touching any settings, run these three commands in a terminal. They tell you whether you're dealing with a VM visibility problem, a missing driver, or a soft block — and they take under a minute.

1. Check if the OS sees any wireless hardware at all: run lsusb for USB adapters and lspci | grep -i network for internal/PCI cards. If a USB adapter is plugged in but doesn't show in lsusb inside the VM, it hasn't been passed through yet — that's a hypervisor setting, not a Kali problem. If you're on bare metal and lspci shows nothing under Network controller, the card itself may be disabled in BIOS/UEFI.
2. List every network interface: run ip link show. Look for anything besides lo (loopback) and your wired interface. It may not be named wlan0 — see the naming section below.
3. Check the kernel log for driver errors: run dmesg | tail -50 right after plugging in the adapter or booting. dmesg prints the kernel's own running log of hardware and driver events, so a line naming your chipset (the specific wireless chip inside the adapter — Realtek, Atheros, Broadcom, Intel) followed by a firmware-loading failure tells you exactly which package to install.

If lsusb/lspci show nothing and you're in a VM, skip straight to the VirtualBox or VMware sections below — no amount of driver work fixes a device the guest was never given. If hardware does show up but there's still no wireless interface, the firmware and NetworkManager sections further down are where the fix lives.

Fixing No wlan0 in VirtualBox

VirtualBox cannot pass through your laptop's internal card under any configuration. What it can do is hand over a USB adapter plugged into the host. Oracle's own documentation describes USB support as controller-plus-filter: you enable a controller, then add a filter so the device is captured automatically every time it's connected.

1. Shut the VM down completely. USB controller settings can only be changed while the machine is powered off.
2. Install the Extension Pack if you haven't already — go to File > Preferences > Extensions inside VirtualBox and add it. The USB 2.0 (EHCI) and USB 3.0 (xHCI) controllers ship as part of this separate download; without it, VirtualBox only offers the slower USB 1.1 (OHCI) controller.
3. Open the VM's Settings > USB tab and tick Enable USB Controller. Choose USB 3.0 (xHCI) if your adapter supports it — USB 2.0 (EHCI) is the safer fallback for older or flaky dongles.
4. Plug the adapter into the host, then click the Add Filter (+) icon and select it from the list. It usually appears under its chipset name (Realtek, Atheros, MediaTek) rather than the box's brand name — don't be thrown by that.
5. Start the VM. The adapter should now show up in lsusb inside Kali, and a new wireless interface should appear in ip link show.

Fixing No wlan0 in VMware Workstation or Player

Same underlying limit, different menu. VMware exposes USB devices through a Removable Devices menu rather than filters, and it will often auto-connect a plugged-in USB adapter to whichever VM window has focus — which is convenient until two VMs are open and it grabs the wrong one.

Plug the USB Wi-Fi adapter into the host, power the VM on, then go to VM > Removable Devices and select the adapter's name from the list — again, likely a chipset name rather than a brand. Clicking it disconnects the device from the host and connects it to the guest. If it doesn't appear in that menu at all, open Edit > Preferences > USB and confirm a USB controller is present on the VM's hardware list; if it's missing, add one from the VM's own Settings before retrying.

Fixing No wlan0 on Bare Metal (Laptop or Desktop)

If Kali is installed directly on the machine — no VirtualBox, no VMware — a missing wlan0 is a software problem, and it's fixable. Kali's own troubleshooting documentation frames the check in a specific order: confirm the device shows up on lspci/lsusb, then check dmesg for driver load failures, and only then suspect firmware.

Most built-in cards (Intel, Realtek, Broadcom) need a firmware package that isn't installed by default because it's non-free (meaning it's a binary blob the manufacturer released without source code, which Debian and Kali keep separate from the main repository for licensing reasons). If dmesg shows something like "firmware: failed to load" next to your chipset's name, that confirms it. Enable the non-free repository if it isn't already, then install the matching package — firmware-iwlwifi for Intel cards, firmware-realtek for Realtek, or firmware-b43-installer for older Broadcom chips — and reboot.

If the card shows up in lspci but never becomes an interface

That's a driver-load failure, not a missing-device problem. Run dmesg | grep -i firmware and dmesg | grep -i wlan right after boot. A kernel that can't find the firmware blob will log it clearly rather than fail silently — read that line before searching for anything else.

Raspberry Pi and ARM: Built-in Wi-Fi Is Different Here

Everything above assumes a laptop or desktop. If you're running Kali's official ARM image on a Raspberry Pi, the built-in Wi-Fi story is genuinely different — and it's worth flagging separately so you don't waste money on a USB adapter you don't need.

This is unrelated to the VM limitation described earlier — a Raspberry Pi running Kali directly on its own hardware isn't virtualized at all, so its built-in chip was always visible to the OS. The historical problem on the Pi was driver capability, not visibility, which is the opposite of the laptop-in-a-VM case.

"wlan0" Isn't Always the Name Anymore

This trips up more people than a genuinely missing adapter. Modern Linux uses predictable network interface naming based on the physical bus location, so a built-in card might appear as wlp2s0 or wlp3s0 instead of wlan0, and a USB adapter might show as wlx followed by its MAC address. The hardware is working; the name just changed.

Always confirm with ip link show rather than assuming the name — if you see any interface that isn't lo or your Ethernet port, that's your Wi-Fi adapter regardless of what it's called. Tools like iwconfig and airmon-ng will also list it under its real name, and it's safe to substitute that name anywhere this article says wlan0.

NetworkManager Not Running or Not Managing the Adapter

If your interface shows up in ip link show but there's no Wi-Fi icon in the desktop and nmcli device wifi list returns nothing, the NetworkManager service itself (the background process, or "daemon," that discovers and connects networks on your behalf) may not be running. Check with systemctl status NetworkManager. If it's inactive, start it with sudo systemctl start NetworkManager and enable it at boot with sudo systemctl enable NetworkManager.

Ethan's take on this one is unambiguous: "People reinstall Kali over a one-line service problem constantly. Before you nuke anything, just check whether the service is even on." If the package itself is missing rather than just stopped, install it with sudo apt install network-manager and then start and enable the service as above.

The rfkill Soft-Block Trap

Some laptops ship with a hardware kill switch or a function-key combination that disables the radio at the firmware level, and the OS respects it as a "soft block" — a software-level lock rather than a physical one. Run rfkill list, which is the tool for checking and toggling that lock. If you see Soft blocked: yes next to your wireless device, clear it with sudo rfkill unblock wifi (or sudo rfkill unblock all to clear every radio, including Bluetooth). A Hard blocked: yes line means a physical switch or BIOS setting, and no command will override that — you have to flip the switch or check the BIOS wireless setting yourself.

Automating the Fix So It Doesn't Come Back

If you're unblocking the radio with rfkill every single boot, don't reach for a custom always-run script before checking what's already there. Two separate mechanisms already try to remember the radio's state across reboots: systemd-rfkill.service, which restores the saved kill-switch state from /var/lib/systemd/rfkill/ at early boot, and NetworkManager, which keeps its own last-known radio state in /var/lib/NetworkManager/NetworkManager.state.

When a soft block returns after every reboot despite you unblocking it manually, the usual cause is one of those two persistence mechanisms saving a "blocked" state from a previous shutdown, or a laptop's BIOS asserting the block again before the OS even loads. Confirm which one by running rfkill unblock all, rebooting, and checking rfkill list immediately — if it's blocked again before you've touched anything, look at the saved state files above rather than writing a new systemd unit that will just fight the ones that already exist.

Adapter Shows Up But Won't Connect

This is a different problem from a missing interface, and it's worth separating clearly because the fixes don't overlap. If ip link show and nmcli device wifi list both work and show your networks, but connecting fails or drops immediately, check these in order:

Command	What it tells you
rfkill list	Whether the radio is soft- or hard-blocked before anything else is tried.
ip link show	The real interface name and whether it's UP or DOWN.
dmesg | tail -50	Driver and firmware load errors right after boot or plug-in.
nmcli device wifi list	Whether NetworkManager can see nearby networks at all.
systemctl status NetworkManager	Whether the service managing connections is even running.

Wrong Wi-Fi password, a captive portal that needs a browser login before it releases traffic, or a 5GHz-only network hitting a 2.4GHz-only adapter are the three most common causes once the interface itself is confirmed healthy. None of those are fixed by reinstalling drivers, and none of them are the fault of the interface being renamed or the adapter itself.

Monitor Mode and Injection Are a Separate Question

Getting wlan0 to appear and getting it into monitor mode (a radio state that captures every nearby Wi-Fi frame instead of only ones addressed to you, which is what tools like airodump-ng require) for security tools are two different milestones. A working interface that connects to normal Wi-Fi does not guarantee monitor mode or packet injection — that depends on the chipset's driver supporting it, not just being detected. Kali's documentation is direct about this: many manufacturer-provided ("STA") drivers, and anything using ndiswrapper, will never support monitor mode, regardless of how well they handle a normal connection.

If your interface connects fine but airmon-ng start wlan0 fails to produce a working wlan0mon, check for chipset-specific driver issues rather than repeating the steps above — this is where an unsupported built-in card (even a USB one with the wrong chipset) hits a hard wall that firmware or NetworkManager fixes can't cross.

Before You Point a New Adapter at Any Network

Once monitor mode works, it's tempting to point it at the nearest visible network to confirm everything's functioning. Don't, unless it's a network you own or one you have clear, written permission to test — scanning or attacking Wi-Fi networks you don't control can be illegal depending on where you live, and "I was just testing my new adapter" is not a defense anyone should have to rely on. Jake's shop guest network is his to test because it's his; a neighbor's network, or a client's network without a signed authorization, is not.

Two practical habits worth building in from day one: switch the adapter back to managed mode with sudo airmon-ng stop wlan0mon (or the equivalent for your interface) as soon as you're done, rather than leaving it in monitor mode indefinitely, and remember that monitor mode itself can expose your own device's MAC address to anything you're capturing, since 802.11 management frames aren't encrypted. Neither of those is a Kali-specific quirk — they're just good practice for anyone running wireless tools regularly.

Built-in vs USB Adapters in Kali: What Actually Works

Setup	Built-in Wi-Fi	USB Wi-Fi adapter
Kali in VirtualBox / VMware (laptop)	Not usable — never passed to the guest	Usable, with USB passthrough configured
Kali installed on bare metal (laptop/desktop)	Usable, if firmware is installed and unblocked	Usable, same conditions
Kali ARM on Raspberry Pi (supported board)	Usable, including monitor mode via nexmon packages	Also usable, if preferred
Kali Live USB (no install)	Usable — real hardware, no virtualization	Usable — same conditions

When Nothing Works: The Live-Boot Escape Hatch

If you don't have a spare USB Wi-Fi adapter and you're stuck in a VM, there's one path that sidesteps the entire problem: boot Kali's Live image directly from a USB drive instead of running it inside a hypervisor. With no virtualization layer between the OS and the hardware, your laptop's built-in card is visible exactly as it would be under any other Linux install — no passthrough, no filters, no driver gymnastics.

This costs you persistence between reboots unless you set up a persistent Live USB separately, but for a one-off check — auditing a Wi-Fi network before a client visit, say — it's often faster than fighting VirtualBox settings. For a permanent setup instead of a live session, see the guide on installing Kali in VirtualBox linked below, which covers the install path this article assumes as a starting point.

The Full Checklist, in Order

1. Are you in a VM on a laptop? If yes, and you're relying on the built-in card, stop — get a USB adapter instead.
2. On a Raspberry Pi image, check whether nexmon packages are already installed before assuming you need external hardware.
3. Run lsusb/lspci to confirm the OS sees hardware at all.
4. Run ip link show and check for any non-loopback, non-Ethernet interface, regardless of its name.
5. Run rfkill list and clear any soft block; if it returns after reboot, check the persisted state files instead of writing a new script.
6. Run dmesg | tail -50 for firmware or driver errors and install the matching firmware package.
7. Check systemctl status NetworkManager and start/enable it if inactive.
8. Once connected, treat monitor mode as a separate, chipset-dependent question if that's your goal — and confirm you have authorization before scanning anything but your own network.

Back at the shop, once Jake plugged in a spare Atheros dongle and added the USB filter, wlan0 appeared within a minute — the whole detour had cost him a morning chasing a driver that was never missing.

Frequently Asked Questions

How do I get wlan0 in Kali Linux?

Check whether Kali is running in a VM. If so, plug in a USB Wi-Fi adapter and pass it through via your hypervisor's USB settings — a built-in card will not appear. On bare metal, confirm the adapter shows in lspci or lsusb, clear any rfkill block, and install the matching firmware package if dmesg shows a load failure.

Why is my Kali NetworkManager not running?

The service may be disabled by default or the package may be missing. Check with systemctl status NetworkManager, then start and enable it with sudo systemctl start NetworkManager and sudo systemctl enable NetworkManager. If the package itself is absent, install it with sudo apt install network-manager first.

Why is wlan0 not showing in Kali Linux even though my laptop has Wi-Fi?

If Kali is a virtual machine, this is expected — built-in Wi-Fi is a PCI device and hypervisors don't pass PCI hardware to guests. If Kali is installed directly on the laptop, check rfkill list for a block and dmesg for a firmware load failure.

Why does Kali say no network connection at all?

Start with nmcli device wifi list. If it returns nothing, NetworkManager may not be running or the interface may not exist yet — work through the checklist above from the top rather than guessing at individual settings.

Why is my Wi-Fi adapter not showing in Kali Linux inside VirtualBox specifically?

Unless it's a USB adapter with passthrough enabled, VirtualBox never exposes it. Enable the USB controller under Settings > USB, add a device filter for the adapter, and make sure the VM was fully shut down before changing that setting.

Can I use my laptop's built-in Wi-Fi inside a Kali virtual machine?

No. Built-in Wi-Fi cards connect over the internal PCIe or M.2 bus, and hypervisors virtualize that bus rather than passing individual devices through it. Use a USB adapter, or boot Kali as a Live USB directly on the hardware instead.

Does VirtualBox support Wi-Fi passthrough at all?

It supports USB passthrough, which is how external Wi-Fi adapters reach the guest. It does not support passing through internal PCI Wi-Fi hardware to a VM.

What USB Wi-Fi adapter should I buy for Kali?

Buy by chipset, not brand — Atheros AR9271 or Realtek RTL8812AU/8814AU-based adapters have well-documented Linux support for both normal connectivity and monitor mode. A "Wi-Fi 6" adapter with no known chipset compatibility can leave you back at square one.

What's the difference between iwconfig and ip link for checking Wi-Fi?

ip link show lists every network interface the kernel knows about, wireless or not, which is why it's the first thing to check. iwconfig lists only wireless interfaces and their radio settings, useful once you already know the interface name.

Why is my interface called wlp2s0 instead of wlan0?

Modern Linux assigns predictable names based on the device's physical bus location rather than the old generic wlan0 numbering. The hardware and driver are unaffected — use whatever name ip link show reports.

My adapter appears but monitor mode won't turn on. What's wrong?

That's a chipset or driver limitation, separate from the adapter simply appearing. Many manufacturer-supplied drivers, and anything relying on ndiswrapper, never support monitor mode regardless of how well normal Wi-Fi works on them.

rfkill shows "Soft blocked: yes" — how do I fix it, and why does it come back?

Run sudo rfkill unblock wifi, or sudo rfkill unblock all to clear every radio at once. If it shows "Hard blocked: yes" instead, that's a physical switch or BIOS setting no command can override. If the block returns after every reboot, check the saved state in /var/lib/systemd/rfkill/ and /var/lib/NetworkManager/NetworkManager.state — one of them is likely remembering an old blocked state.

Does the Raspberry Pi's built-in Wi-Fi support monitor mode in Kali?

On supported boards, yes — Kali's nexmon-patched driver packages (brcmfmac-nexmon-dkms and firmware-nexmon) add monitor mode and injection to the on-board Broadcom chip, no USB adapter required. This is specific to the Raspberry Pi ARM image, not laptops.

Is it legal or ethical to scan Wi-Fi networks with my new adapter?

Only scan or test networks you own or have explicit, documented permission to test. Laws on unauthorized wireless scanning vary by location, so get written authorization before pointing monitor mode at any network that isn't yours.

Can NetworkManager and airmon-ng conflict with each other?

Yes. NetworkManager can interfere with tools that need exclusive control of the interface for monitor mode. Running airmon-ng check kill before starting monitor mode stops the processes that commonly get in the way.

I don't have a spare USB adapter. Is there any way to use Wi-Fi in a VM?

Not with the built-in card. The practical alternative is booting Kali as a Live USB directly on the laptop instead of inside a hypervisor, which removes the virtualization layer entirely.

Revision note. Written September 2026,but please not This will need a refresh if a future VirtualBox or VMware release changes USB controller defaults, if Kali moves to a different default network stack, or if nexmon support expands to more Pi boards. If you've spent an afternoon chasing a driver that was never the problem, you're not the only one — hopefully this got you back online faster than it took Jake.