7.1 Configuring the Network

NetworkManager on the Kali Desktop

On a standard Kali desktop installation, networking is handled by NetworkManager, the same service used by most Debian-based desktop distributions. It runs as the NetworkManager.service systemd unit and exposes three interfaces you should know for the exam:

• nmcli — the command-line tool, scriptable and the most important for the KLCP exam
• nmtui — a terminal-based menu UI, useful on systems without a desktop
• The GNOME/Xfce panel applet — the graphical front end in the system tray

Start by inspecting state. nmcli device status lists every network device with its type, state, and active connection profile. nmcli connection show lists saved connection profiles (NetworkManager stores profiles in /etc/NetworkManager/system-connections/). A device can be connected, disconnected, or unmanaged; unmanaged usually means another tool (like ifupdown) claims the interface in /etc/network/interfaces, and NetworkManager deliberately leaves it alone — a classic exam trap when nmcli seems to ignore an interface.

Essential nmcli operations:

nmcli device status
nmcli connection show
nmcli connection up "Wired connection 1"
nmcli connection down "Wired connection 1"
nmcli device wifi list
nmcli device wifi connect "SSID" password "secret"

Adding a Static IP with nmcli

To create a new Ethernet profile with a static address instead of DHCP:

nmcli connection add type ethernet con-name static-eth0 ifname eth0 \
  ipv4.method manual ipv4.addresses 192.168.1.50/24 \
  ipv4.gateway 192.168.1.1 ipv4.dns "8.8.8.8 1.1.1.1"
nmcli connection up static-eth0

Key point: ipv4.method manual means static, ipv4.method auto means DHCP. To convert an existing profile, modify it instead of recreating it: nmcli connection modify static-eth0 ipv4.method auto switches it back to DHCP. Changes only apply after you bring the connection down and up again.

ifupdown and /etc/network/interfaces

Debian's traditional mechanism is ifupdown, driven by the file /etc/network/interfaces plus drop-in files in /etc/network/interfaces.d/. Kali installs this file even on desktop systems, usually containing only auto lo and iface lo inet loopback so the loopback interface comes up while NetworkManager handles everything else. On servers or minimal installs without NetworkManager, you configure interfaces directly:

auto eth0
iface eth0 inet static
    address 192.168.1.50/24
    gateway 192.168.1.1
    dns-nameservers 8.8.8.8 1.1.1.1

For DHCP the stanza shrinks to auto eth0 and iface eth0 inet dhcp. Apply changes with ifup eth0 / ifdown eth0 or systemctl restart networking. The keywords matter: auto brings the interface up at boot, allow-hotplug brings it up when the kernel detects the device, and inet static versus inet dhcp selects the address method.

A critical rule: an interface declared in /etc/network/interfaces is marked unmanaged by NetworkManager. Do not configure the same interface in both systems.

systemd-networkd: the third mechanism

Kali Linux Revealed documents a third option alongside NetworkManager and ifupdown: systemd-networkd, the systemd-native network manager. It is small, scriptable, and not Debian-specific, which makes it the usual choice in containers, cloud images, and headless VMs. Configuration lives in .network files under /etc/systemd/network/ (packaged files in /lib/systemd/network/), where a [Match] section selects interfaces and a [Network] section describes the configuration:

# /etc/systemd/network/50-static.network
[Match]
Name=enp2s0

[Network]
Address=192.168.0.15/24
Gateway=192.168.0.1
DNS=8.8.8.8

Three exam-relevant caveats: systemd-networkd is disabled by default, so it must be enabled explicitly (systemctl enable --now systemd-networkd); DNS integration depends on systemd-resolved, which means replacing /etc/resolv.conf with a symlink to /run/systemd/resolve/resolv.conf; and it has no built-in Wi-Fi support, so wireless still needs a separate wpa_supplicant configuration.

DHCP vs Static Addressing

DHCP (Dynamic Host Configuration Protocol) leases an address, gateway, and DNS servers automatically — the default for Kali desktop installs and live sessions. Static addressing pins the configuration manually, which you want for machines others must reach reliably: servers, jump boxes, and targets in a lab. On a penetration test you will frequently switch your own machine to a static address on an isolated lab network where no DHCP server exists, so the nmcli connection add ... ipv4.method manual workflow above is practical, not just theoretical.

DNS and /etc/resolv.conf

Name resolution is configured in /etc/resolv.conf, which contains nameserver lines (up to three are used), plus optional search and domain directives:

nameserver 8.8.8.8
nameserver 1.1.1.1
search lab.local

The exam-relevant subtlety: /etc/resolv.conf is frequently a symlink or a generated file rewritten by NetworkManager, resolvconf, or systemd-resolved. Hand-editing it may work until the next DHCP renewal or connection bounce wipes your change. The durable fix is to set DNS where the manager reads it — ipv4.dns in nmcli, or dns-nameservers in an interfaces stanza. The resolver library consults /etc/nsswitch.conf (the hosts: line, normally files dns) to decide the lookup order: /etc/hosts first, then DNS.

Hostname Management

View and set the hostname with hostnamectl. hostnamectl alone shows the static hostname, chassis, and operating system; hostnamectl set-hostname kali-lab sets it persistently by writing /etc/hostname (and updates the pretty hostname in /etc/machine-info when used with --pretty). The legacy hostname command changes the name only until reboot. After renaming, check /etc/hosts — you typically want an entry mapping 127.0.1.1 to the new name so local services resolve it.

Diagnostic Commands: ip, route, ss

The net-tools suite (ifconfig, route, netstat) is deprecated upstream but still ships on Kali — the Debian net-tools package carries Priority: important, so it is part of the base system — yet all new work should use the iproute2 replacements:

• ip addr show (or ip a) — interfaces and their addresses; ip link set eth0 up toggles link state
• ip route show (or ip r) — the routing table; add a default gateway with ip route add default via 192.168.1.1
• ss -tuln — listening TCP/UDP sockets without name resolution; the modern netstat -tuln
• ping -c 4 192.168.1.1 and dig example.com / host example.com — connectivity and DNS verification

A standard troubleshooting order: check link and address with ip a, check the gateway with ip r, ping the gateway, ping an external IP, then test DNS with dig. This isolates whether the fault is layer-2, routing, or name resolution.