15.1 Network Installation with PXE Boot

Physical media does not scale. When you need to install Kali on a rack of lab machines, a classroom of laptops, or a VM template farm, booting each machine from a USB stick is wasted effort. Preboot Execution Environment (PXE) — pronounced "pixie" — lets a machine boot straight from the network: the firmware downloads a bootloader from a server and runs it, no local media required. On the KLCP exam you should be able to name every component in a PXE transaction and describe a working dnsmasq-based setup.

How PXE Works

A PXE boot is a conversation between the client firmware and two network services:

1. DHCP (Dynamic Host Configuration Protocol): the client broadcasts a DHCPDISCOVER that includes PXE vendor-class information. The DHCP server replies with an IP address lease plus two extra pieces of boot information: the address of the boot server (the BOOTP next-server/siaddr field, or the separate option 66 "TFTP server name" string when a tool uses that instead) and the filename of the bootloader to fetch (option 67, e.g. pxelinux.0).
2. TFTP (Trivial File Transfer Protocol): the client contacts the TFTP server named in the DHCP reply and downloads the bootloader over UDP port 69. TFTP is deliberately minimal — no authentication, no encryption — which is why it lives only on trusted provisioning networks.

Once the bootloader (typically PXELINUX from the SYSLINUX project for BIOS clients, or GRUB/shim for UEFI clients) is running, it downloads the Linux kernel and initrd the same way, and the installer starts.

Setting Up dnsmasq

dnsmasq is the lightweight choice because it bundles a DNS forwarder, a DHCP server, and a TFTP server in one daemon — ideal for an isolated lab subnet. Install it on any always-on Linux box:

apt update && apt install -y dnsmasq

A minimal /etc/dnsmasq.d/pxe.conf looks like this:

interface=eth1
dhcp-range=192.168.101.100,192.168.101.200,12h
dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/srv/tftp

Line by line: interface confines DHCP to the lab NIC so you never fight the corporate DHCP server; dhcp-range defines the lease pool; dhcp-boot is the filename clients request over TFTP; enable-tftp plus tftp-root turn on the file-serving half. Restart with systemctl restart dnsmasq and watch journalctl -u dnsmasq -f while a client boots — every DHCPDISCOVER and TFTP GET appears in the log, which is your first debugging tool.

• Exam trap: a DHCP proxy setup (dhcp-range=...,proxy) is for when another DHCP server already exists; on a dedicated lab net you run dnsmasq as the authoritative DHCP server.

Booting the Kali Installer Over the Network

Kali publishes a ready-made netboot image for exactly this purpose. Grab it from the installer tree on the Kali mirror:

cd /srv/tftp
wget http://http.kali.org/kali/dists/kali-rolling/main/installer-amd64/current/images/netboot/netboot.tar.gz
tar xzf netboot.tar.gz

The tarball drops in a debian-installer/ directory containing the kernel (linux), the initial ramdisk (initrd.gz), and a pxelinux.cfg/ configuration, plus the pxelinux.0 bootloader itself in the netboot tree. When a client PXE-boots, it loads pxelinux.0, reads pxelinux.cfg/default, and boots the Kali installer kernel with a menu that mirrors the USB installer: Install, Graphical install, Advanced options, and so on.

Understand this split, because the exam tests it: only the bootloader, kernel, and initrd come over TFTP. The installer then downloads the actual packages from a configured Kali mirror over HTTP, exactly as a normal install would. PXE replaces the boot media, not the repository. That also means the machine needs a working route (and usually a second DHCP answer or a static mirror) to reach the packages.

• BIOS clients boot pxelinux.0; UEFI clients need a different filename such as bootx64.efi (GRUB or shim). Serving both means using DHCP option 93 (client architecture) to pick the right file — know that the distinction exists.

Fully Automated Installs with Preseed

PXE alone still leaves you clicking through installer prompts. Combine it with preseeding — the Debian installer's answer-file mechanism — and the install becomes unattended. You pass the preseed file's location as a kernel parameter. At the PXELINUX boot prompt press TAB (or ESC) to edit the append line and add:

auto=true priority=critical url=http://192.168.101.1/kali.preseed

The url= points at a plain text file served by any web server; auto=true postpones the questions the installer would otherwise ask before networking exists (locale and keyboard) so the fetched preseed can answer them, and priority=critical suppresses every remaining lower-priority prompt. A trimmed-down preseed might contain:

d-i netcfg/choose_interface select auto
d-i mirror/http/hostname string http.kali.org
d-i mirror/http/directory string /kali
d-i passwd/root-password-crypted password $6$...
d-i partman-auto/method string regular
d-i partman/confirm_write_new_label boolean true
d-i partman/confirm boolean true
d-i pkgsel/include string openssh-server kali-linux-default
d-i preseed/late_command string in-target systemctl enable ssh

Every d-i line answers one installer question in advance; preseed/late_command runs inside the target system at the end — the classic hook for dropping SSH keys or a Salt minion config so the box phones home for configuration the moment it first boots.

The Lab Use Case

Why does an OffSec-minded organization bother? Because offensive security labs are disposable. The workflow the Kali Linux Revealed book describes is: stand up one small provisioning VM running dnsmasq, Apache, and (later) Salt; net-boot a batch of bare-metal or virtual machines; preseed them through a hands-off install; and have a known-good, identically configured Kali fleet in under half an hour. Tear it down, re-image, repeat for the next exercise. Once you have PXE plus preseed working, adding configuration management (next section) is what turns "identical installs" into "identical installs that stay identical."