Post cover image

November 2, 2026

Linux Inside Windows: A Friendly WSL Guide for Security Folks

Originally published on huseyinkalkan.net (also available in Turkish).

By Huseyin KALKAN

4 min read

Not long ago, a security person on Windows had two choices: split the laptop in two and reboot every time (dual boot), or live with a virtual machine that eats a few GB of RAM and takes ages to start. WSL (Windows Subsystem for Linux) opened a third way: run Linux inside Windows, as easily as opening an app.

In this post I cover what WSL is, how to get Kali running in a few minutes and, most importantly, the networking trap that costs people hours during pentests. The terminal output in the images comes from my own machine.

So what exactly is WSL?

In short: the official way to really run Linux programs on Windows. There are two versions, and the difference decides what will and will not work:

None
  • WSL 1 translates Linux system calls for the Windows kernel. There is no real Linux kernel, so low-level work such as raw sockets is limited.
  • WSL 2 runs a real Linux kernel in a lightweight VM on the Hyper-V platform that starts in about a second. SYN scans with sudo nmap -sS, Docker and tools that need kernel features work here.

For security work the answer is clear: WSL 2. Today wsl --install installs it by default anyway.

Installing it in 5 minutes

An administrator PowerShell is all you need:

# Install WSL (the first run may ask for a reboot)
wsl --install
# See the available distributions, add Kali
wsl --list --online
wsl --install -d kali-linux
None

Kali on WSL comes almost empty; you pick the tools:

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y kali-linux-default     # nmap, burp, impacket, metasploit...
# or something lighter:
sudo apt install -y kali-linux-headless

GUI tools (Burp, Wireshark) need nothing extra: thanks to WSLg on Windows 11, Linux windows open on the Windows desktop like normal apps. For a full Kali desktop: sudo apt install -y kali-win-kex and then kex --win -s.

What life looks like inside

The sweetest part: the two worlds can see each other.

None
  • Windows files from Linux: the C:\ drive lives under /mnt/c.
  • Linux files from Windows: type \\wsl.localhost\kali-linux into the Explorer address bar, or run explorer.exe . from Linux.
  • Programs both ways: powershell.exe from bash; wsl nmap -sV 10.10.10.5 from PowerShell.

The real trap for security folks: networking

Look at the 172.31.45.208 address above. By default WSL 2 lives in its own small NAT network behind Windows. Connecting out is fine, but incoming connections (reverse shells!) do not reach WSL.

None

The classic scenario: you start the HTB/PG VPN on Windows, listen with nc -lvnp 443 in Kali, give the target your VPN IP as LHOST… and nothing arrives. The connection hits Windows, nobody listens there, and it is dropped. Two clean fixes:

Fix 1: run the VPN inside WSL. The tunnel ends where your listener is, so this works even in NAT mode.

sudo apt install -y openvpn
sudo openvpn lab.ovpn          # tun0 now lives in Linux
ip -4 addr show tun0           # use this IP as LHOST

Fix 2: mirrored networking. On Windows 11, create %UserProfile%\.wslconfig:

[wsl2]
networkingMode=mirrored
memory=6GB        # optional: RAM cap for WSL
processors=4      # optional

Run wsl --shutdown and start WSL again. Kali now sees Windows' tun0 too. The Hyper-V firewall may block inbound traffic; allow only your listener port instead of everything (administrator PowerShell):

New-NetFirewallHyperVRule -Name WSL-443 -DisplayName "WSL reverse shell 443" `
  -Direction Inbound -VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' `
  -Protocol TCP -LocalPorts 443

Shortcut:_ in labs, Fix 1 gives the fewest surprises. Mirrored mode is nice when Windows tools and WSL need to share the same network._

Small but sweet tweaks

  • Keep working files on the Linux side (~/). File operations through /mnt/c are noticeably slower, and payloads kept in Windows folders invite Defender to delete them.
  • When things get weird: wsl --shutdown — WSL's two-second reboot.
  • Make Kali the default profile in Windows Terminal; tabs and split panes are comfortable even without tmux.
  • VS Code + the WSL extension: code . in a Kali folder opens the editor on Windows while files and terminal stay in Linux.
  • Back it up: wsl --export kali-linux kali-backup.tar, and wsl --import on another machine.

Where WSL is not enough

  • Wireless testing: monitor mode means passing USB into WSL (usbipd-win) and building the right driver. A separate Kali install or VM is less hassle.
  • Exam environment: for exams like the OSCP, OffSec recommends a Kali virtual machine. Use WSL for daily work and labs; you do not want surprises on exam day.
  • Corporate devices: EDR and company policy may restrict or monitor WSL. Check the rules first.

Cheat card

  • Install Kali → wsl --install -d kali-linux
  • List distributions and versions → wsl -l -v
  • Restart WSL → wsl --shutdown
  • Open Linux files in Explorer → explorer.exe .
  • Get reverse shells to arrive → VPN inside WSL, or networkingMode=mirrored
  • Back up the install → wsl --export kali-linux kali.tar

WSL answers "Linux or Windows?" with "both". Once the networking trap is solved, most of the work happens on one computer without rebooting.

Preparing for the OSCP?

I keep a free, interactive OSCP+ exam guide in English and Turkish: exam rules and scoring, enumeration, web, Active Directory, Linux and Windows privilege escalation, pivoting and reporting, with copy-ready commands and live LHOST substitution.

👉 OSCP Ultimate Guide on huseyinkalkan.net