Choosing a Network Configuration Tool on Debian 12: systemd‑networkd vs. NetworkManager vs. ifupdown

Why the Decision Matters

Debian 12 offers three fully supported network configuration frameworks. They target different environments and use cases:

• systemd‑networkd – lightweight, daemon‑only, ideal for headless servers or minimal desktops.
• NetworkManager – feature‑rich, GUI and D‑Bus API, best for laptops and workstations that need Wi‑Fi, VPN, and mobile broadband.
• ifupdown – legacy script‑based system, still useful for custom or older setups that rely on /etc/network/interfaces.

Choosing the wrong tool can lead to duplicate IP assignments, DNS misconfiguration, or dropped links. This guide gives you a quick decision matrix, explains trade‑offs, and provides a concrete example of setting up systemd‑networkd on a Debian 12 server.

Decision Guide

Answer these questions to narrow down the best tool for your environment:

1. Is the system headless or a minimal server? → Prefer systemd‑networkd.
2. Does the user need automatic Wi‑Fi, VPN, or mobile broadband? → Use NetworkManager.
3. Are you maintaining a legacy script or need the /etc/network/interfaces format? → Stick with ifupdown.
4. Do you need to control multiple interfaces with different tools? → You can mix them if you keep each interface exclusive to one manager.

Feature Comparison Table

Feature	systemd‑networkd	NetworkManager	ifupdown
Daemon type	systemd unit, no GUI	systemd unit with GUI tools	Legacy scripts, no systemd unit
Configuration format	.network files in /etc/systemd/network	nmcli or GUI, D‑Bus API	/etc/network/interfaces
Dynamic config (hotplug)	Yes – via systemd‑udev rules	Yes – auto‑connect Wi‑Fi, VPN, mobile	No – static or ifup/ifdown
IPv6 support	Full, modern	Full, modern	Full, but limited to static/DHCP
VLAN / bridge / bond	Native, declarative	Native via nmcli	Scriptable via vlan and bonding modules
Wi‑Fi (without wpa_supplicant)	Requires external wpa_supplicant	Built‑in, auto‑wpa	No native support
VPN integration	No – use systemd‑networkd + systemd‑resolved	Built‑in (OpenVPN, WireGuard, etc.)	No – external scripts
DNS handling	systemd‑resolved (optional)	systemd‑resolved or resolvconf	resolvconf or manual /etc/resolv.conf
Resource footprint	Low – ~1 MB	Higher – ~5 MB + GUI	Low – scripts only
Conflict avoidance	Must disable other managers on same iface	Same principle	Same principle

Trade‑Offs and Practical Considerations

• Systemd‑networkd is perfect for static, predictable topologies. It lacks a GUI, so remote servers are fine. It requires you to write .network files, which can be verbose but are declarative.
• NetworkManager shines on laptops that switch between Ethernet, Wi‑Fi, and VPN. Its GUI and nmcli make quick changes easy, but it can override systemd‑resolved DNS unless configured with dns=none.
• ifupdown is still useful if you have existing scripts or need to run ifup in init scripts. It is not ideal for dynamic environments and lacks native Wi‑Fi support.
• Running two managers on the same interface is a recipe for failure. Only one should own the interface; otherwise, you can see duplicate IP addresses or link flapping.
• For mixed setups (e.g., wired via systemd‑networkd, Wi‑Fi via NetworkManager), ensure that each interface is listed in /etc/systemd/network/*.network or nmcli con show but not both.

Concrete Implementation: systemd‑networkd on a Debian 12 Server

Below is a step‑by‑step guide to configure a static Ethernet interface eth0 with systemd‑networkd, verify the configuration, and ensure DNS works via systemd‑resolved.

Prerequisites

• Debian 12 system with root or sudo privileges.
• Physical or virtual machine with an Ethernet NIC named eth0 (use ip link to confirm).
• Static IP address: 192.168.1.10/24, gateway 192.168.1.1, DNS 8.8.8.8.

Step 1 – Enable and Start systemd‑networkd

# systemctl enable --now systemd-networkd
# systemctl status systemd-networkd

Run as root or with sudo. The status command should show Active: active (running).

Step 2 – Create the .network File

# mkdir -p /etc/systemd/network
# cat > /etc/systemd/network/10-eth0.network <<EOF
[Match]
Name=eth0

[Network]
Address=192.168.1.10/24
Gateway=192.168.1.1
DNS=8.8.8.8
EOF

Each section is self‑explanatory: [Match] selects the interface, [Network] defines the static configuration. No other manager should own eth0.

Step 3 – Disable Conflicting Managers on eth0

Check for other managers:

# nmcli device status | grep eth0

If NetworkManager shows connected on eth0, disable it for that interface:

# nmcli con delete id eth0
# nmcli con add type ethernet con-name eth0 ifname eth0 autoconnect no

For ifupdown, ensure eth0 is not listed in /etc/network/interfaces or remove any auto eth0 lines.

Step 4 – Reload systemd‑networkd

# systemctl restart systemd-networkd

Step 5 – Verify IP Assignment

# ip addr show eth0 | grep inet
# ping -c 3 8.8.8.8

The ip addr output should show 192.168.1.10/24. The ping should succeed, indicating routing and DNS are functional.

Step 6 – Check systemd‑resolved Status

# systemctl status systemd-resolved
# systemd-resolve --status

The resolved status should list 8.8.8.8 as the DNS server and the correct IP for eth0. If DNS is not working, ensure systemd‑resolved is enabled and /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf:

# ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Validation Checklist

• systemctl status systemd-networkd – active.
• ip addr show eth0 – correct static IP.
• ping -c 3 8.8.8.8 – succeeds.
• NetworkManager or ifupdown not managing eth0 (no duplicate entries).
• systemd‑resolved shows the DNS server and interface IP.

When to Use a Mixed‑Manager Setup

If you need Wi‑Fi on a laptop but keep a static wired connection on a server, you can run systemd‑networkd for eth0 and NetworkManager for wlan0. Just make sure each interface is owned by only one tool and that systemd‑resolved is configured to merge DNS from both.

Common Pitfalls and How to Avoid Them

• Duplicate IPs – caused by both NetworkManager and systemd‑networkd claiming the same interface. Resolve by disabling one manager for that interface.
• DNS leaks – NetworkManager may override systemd‑resolved DNS unless you set dns=none in the connection profile.
• Interface naming – predictable names (e.g., eth0, wlan0) are assumed. On systems with predictable network interface names, adjust Name= accordingly.
• Legacy scripts – if you rely on /etc/network/interfaces, migrating to systemd‑networkd may require rewriting scripts.

Conclusion

Debian 12 gives you three fully supported network managers. Pick systemd‑networkd for lightweight, static server setups; choose NetworkManager for dynamic desktop or laptop environments; keep ifupdown for legacy or highly custom scripts. Always keep a single manager per interface and validate with the checklist above to avoid configuration clashes.