Configure the network with NetworkManager

On a RHEL 9 or 10 server, and on its derivatives Rocky Linux and AlmaLinux, the network configuration goes neither through /etc/network/interfaces nor through Netplan: it goes through NetworkManager, driven from the command line with nmcli. By the end of this page, you will know how to create a connection with a static IP address, make it persistent across reboots, build a bridge or a bond, and diagnose an interface that refuses to come up. The guide is for intermediate administrators who run Red Hat family servers, and it covers a skill directly assessed at the RHCSA exam.

What you will learn

• Identify which manager really drives your interfaces before touching anything.
• Create an Ethernet connection over DHCP, then with a static IP address, with nmcli.
• Check that a configuration is really persistent and survives a reboot.
• Assemble a virtualisation bridge and a bond of two physical links.
• Diagnose an unmanaged interface, a missing gateway or broken DNS resolution.

Prerequisites and scope

This page is a procedure: it assumes you already have sudo access on a Red Hat family machine and that you can read the output of systemctl. The manipulations touch the network of the machine, so work on a disposable VM or keep a fallback console access, never only an SSH session.

Item	Value
Course / block	Operate, networking
Level	L2 (operational), RHCSA
Scope	RHEL-specific (common core when NetworkManager is installed elsewhere)
Versions tested	nmcli 1.56.0 on AlmaLinux 10.2 (measured on 2026-09-30), 1.54.3 on Rocky Linux 9
Demonstrated capability	Configure a persistent static IP and check it after a reboot

Swipe to see more

RHCSA skill

The objective "configure networking and hostname resolution statically or dynamically" of the EX200 exam is handled entirely with nmcli. The grader checks persistence: an address set by hand with ip addr add disappears at reboot and is worth no points. Everything that follows therefore targets the NetworkManager connection, not the volatile state of the interface.

Why NetworkManager is the server standard

Many administrators still associate NetworkManager with the workstation, because of the small Wi-Fi icon in the taskbar. That view is outdated: since RHEL 8, the old ifcfg scripts of the network-scripts package have been deprecated, then removed from RHEL 9. On a minimal installation of Rocky 9 or AlmaLinux 9, with no graphical environment at all, NetworkManager is the only manager present and it starts by default.

The model it imposes is worth understanding before typing the first command. NetworkManager separates the device (the physical card, enp1s0) from the connection (the configuration profile, for example enp1s0-static). You never configure a card: you create a persistent profile, and you activate it on a card. This decoupling is what lets you have several profiles for the same interface and switch between them without rewriting a file.

And on Debian or Ubuntu Server?

NetworkManager is available there, but it is not the default path: Ubuntu Server goes through Netplan, which delegates to systemd-networkd. If you run those machines, the guide Configure the network with Netplan describes the right tooling. The nmcli commands of this page stay valid on Debian or Ubuntu if NetworkManager really is the active manager, which the next section teaches you to check.

Check which manager drives your interfaces

Before any change, find out who holds the wheel. Two managers active at the same time fight over the same cards and produce configurations that "jump" for no apparent reason. The following command settles it in one pass:

if systemctl is-active --quiet NetworkManager; then
  echo "NetworkManager manages the network"
elif systemctl is-active --quiet systemd-networkd; then
  echo "systemd-networkd manages the network"
elif [ -d /etc/netplan ]; then
  echo "Netplan is probably used as a frontend"
else
  echo "No known network manager is active"
fi

This test first queries the two candidate daemons, then falls back on the presence of the /etc/netplan directory, a hint of a Netplan frontend. On a freshly installed Rocky 9 server, the expected output is:

NetworkManager manages the network

If that is what you read, you are in the nominal case of RHEL, Rocky, Alma and Fedora: follow this guide as is. If another manager answers, systemd-networkd or the old ifupdown of a historical Debian, it is the one driving your interfaces, and the nmcli commands of this page will have no lasting effect.

Do not disable a manager blindly

Disabling the manager that currently drives your interfaces cuts the network of the machine. On a remote server you lose control, and you need console access to get it back.

Before switching from one manager to another, prepare the target configuration, keep a console access (cloud console, IPMI, hypervisor), and switch during a planned window. On a machine that works, the right reflex is to use the manager already in place, not to replace it.

How NetworkManager works

One daemon, several clients

At the centre of the setup runs a system daemon called NetworkManager. It holds the network state, applies the connection profiles, reacts to hardware events (cable plugged in, card detected) and talks to side services such as DHCP or DNS. None of the tools you use, nmcli, nmtui or the Cockpit web console, configures anything itself: they are clients that send orders to this daemon.

This communication goes through D-Bus, the inter-process message bus of Linux. It is what lets a VPN plugin or Cockpit manipulate your connections without ever writing directly into the configuration files.

ConnMan and Wicd are not NetworkManager clients

You sometimes read that ConnMan or Wicd would talk to NetworkManager over D-Bus. That is wrong: they are competing network managers, which replace NetworkManager instead of plugging into it. ConnMan is still used in embedded systems and on some lightweight distributions; Wicd is an abandoned project (stuck on Python 2) that must no longer be deployed. Running NetworkManager and ConnMan side by side on the same machine creates exactly the conflict described above.

The driving tools, by server usefulness

On a server, the hierarchy is clear and it does not look like the one of a workstation. nmcli is the reference tool: scriptable, exhaustive, usable over an SSH session, it is the only one that matters for the RHCSA and for automation. nmtui is a text interface that helps on a fallback console or when a less confident colleague must fix an IP in a hurry. The graphical applets (GNOME, KDE, nm-applet) exist, but assume a desktop environment: they have no place on a minimal server installation.

The side services handled along the way

NetworkManager does more than set addresses. It pushes the DNS servers obtained over DHCP or defined in the profile into /etc/resolv.conf, the file applications read to resolve names, often in coordination with systemd-resolved. It also ships VPN plugins (OpenVPN, WireGuard, IPsec) and can expose a Wi-Fi interface as an access point, two functions that are more marginal on a rack server.

Install and enable NetworkManager

On a standard RHEL, Rocky or Alma installation, NetworkManager is already present and active: this section only concerns you on a minimal system, a container image or a distribution where it must be added. Always check before installing anything:

systemctl status NetworkManager

An Active: active (running) line means the service already runs: go straight to the configuration. If the command answers Unit NetworkManager.service could not be found, install the package.

RHEL/Rocky/Alma

sudo dnf install NetworkManager

Debian/Ubuntu

sudo apt update
sudo apt install network-manager

openSUSE

sudo zypper install NetworkManager

The package name changes from one family to another (NetworkManager with capitals on the Red Hat side, network-manager on the Debian side), but the systemd unit name stays NetworkManager everywhere. Enable it so it starts at boot, then start it:

sudo systemctl enable --now NetworkManager

The --now option combines enable (automatic start at boot) and start (immediate start). Then check both dimensions, the activation at boot and the current state:

systemctl is-enabled NetworkManager
systemctl is-active NetworkManager

The two commands must answer enabled and active respectively. An enabled without active signals a daemon that will fail at the next reboot: inspect journalctl -u NetworkManager before going further.

Configure a connection with nmcli

Everything that follows rests on three subcommands to tell apart: nmcli device talks about physical cards, nmcli connection about persistent profiles, and nmcli general about the global state. Mixing up device and connection is the first source of mistakes for beginners.

Take stock

Before creating a profile, look at what the daemon sees:

nmcli device status

On an AlmaLinux 10 server with a single card, the output looks like this:

DEVICE  TYPE      STATE                   CONNECTION
enp1s0  ethernet  connected               enp1s0
lo      loopback  connected (externally)  lo

The STATE column is the one that matters. connected marks a driven, active card; disconnected a recognised card with no active profile; unmanaged a card NetworkManager has deliberately left aside, often because another manager claims it. connected (externally) designates an interface configured outside NetworkManager, which it follows without driving it: that is the case of the loopback lo on NetworkManager 1.56, normal and harmless.

Create a DHCP connection

The simplest case lets a DHCP server assign the address. Create the profile, then activate it:

sudo nmcli connection add type ethernet ifname enp1s0 con-name enp1s0-dhcp autoconnect yes
sudo nmcli connection up enp1s0-dhcp

Each keyword has a precise role: type ethernet sets the nature of the link, ifname enp1s0 names the target card, con-name enp1s0-dhcp names the profile (this name is what you will manipulate afterwards), and autoconnect yes asks for its automatic activation at boot. With no explicit IPv4 property, NetworkManager keeps ipv4.method auto, that is DHCP.

Check that the address was obtained:

nmcli -f ipv4.method,ipv4.addresses,ipv4.gateway connection show enp1s0-dhcp
ip addr show enp1s0

Create a connection with a static IP address

This is the reference case on a server, and the one the RHCSA exam expects. Two commands are enough, the first sets the address and the gateway, the second adds the resolvers:

sudo nmcli connection add type ethernet ifname enp1s0 con-name enp1s0-static \
  ip4 192.168.1.50/24 gw4 192.168.1.1
sudo nmcli connection modify enp1s0-static ipv4.dns "192.168.1.10 192.168.1.11"
sudo nmcli connection up enp1s0-static

The ip4 shortcut deserves an explanation, because it does one more thing than it announces: setting ip4 automatically switches ipv4.method to manual. You therefore do not need to add ipv4.method manual by hand, contrary to what you often read. The two DNS servers are passed in a single quoted string, separated by a space.

The check is not a ping, but a reread of the saved profile, because that is what will be replayed at reboot:

nmcli -f ipv4.method,ipv4.addresses,ipv4.gateway,ipv4.dns,connection.autoconnect \
  connection show enp1s0-static

The expected output, measured on AlmaLinux 10, confirms the four settings:

ipv4.method:                            manual
ipv4.addresses:                         192.168.1.50/24
ipv4.gateway:                           192.168.1.1
ipv4.dns:                               192.168.1.10,192.168.1.11
connection.autoconnect:                 yes

The connection.autoconnect: yes line is the most important one of this guide: it is this line, and this line only, that guarantees the configuration comes back after a reboot.

Confirm persistence after a reboot

A profile that is right on paper may never come back up. The only test that counts is a real reboot of the machine, to do on a disposable VM and never on a remote server without console access:

sudo reboot

Once the machine is back, check that the connection reactivated on its own and that the address is set:

nmcli connection show --active
ip addr show enp1s0
ip route

The enp1s0-static connection must appear among the active connections, the address 192.168.1.50/24 on the card, and a default route through 192.168.1.1 in the routing table. If one of the three is missing, the Troubleshooting section below gives you the matching lead.

Change an existing connection

You will fix a profile more often than you create one. nmcli connection modify writes into the configuration, but applies nothing live: the change only takes effect after the profile is reactivated.

sudo nmcli connection modify enp1s0-static ipv4.addresses 192.168.1.51/24
sudo nmcli connection up enp1s0-static

Forgetting connection up is the most frequent trap of troubleshooting: the output of nmcli connection show displays the new value, ip addr still the old one, and the administrator believes in a bug. There is none, the configuration and the current state are simply two distinct things.

Build a bridge for virtualisation

A bridge is a software switch: it lets virtual machines (KVM, Incus, containers) show up directly on the physical network. It is built in three steps, the bridge, the port, then the addressing:

sudo nmcli connection add type bridge ifname br0 con-name br0
sudo nmcli connection add type ethernet ifname enp2s0 con-name br0-port1 controller br0
sudo nmcli connection modify br0 ipv4.method manual \
  ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns "192.168.1.10"
sudo nmcli connection up br0

The controller keyword attaches the physical card to the bridge. It replaces the old master, still accepted as a historical alias by nmcli 1.56 but missing from the online help: on RHEL 9 and 10, write controller. Note also that the IP address is carried by the bridge, never by the physical card attached to it.

Check that the port is attached and that the bridge carries the address:

nmcli -f connection.controller,connection.port-type connection show br0-port1
ip addr show br0

Aggregate two links with a bond

A bond aggregates several cards into a single logical interface, for fault tolerance or for throughput. The active-backup mode is the safest and asks nothing of the switch on the other side:

sudo nmcli connection add type bond ifname bond0 con-name bond0 mode active-backup
sudo nmcli connection add type ethernet ifname enp2s0 con-name bond0-port1 controller bond0
sudo nmcli connection add type ethernet ifname enp3s0 con-name bond0-port2 controller bond0
sudo nmcli connection modify bond0 ipv4.method manual \
  ipv4.addresses 192.168.1.60/24 ipv4.gateway 192.168.1.1 ipv4.dns "192.168.1.10"
sudo nmcli connection up bond0

In active-backup, a single card carries the traffic and the second takes over if the link drops. The other modes (802.3ad for LACP, balance-rr) require a switch-side configuration and are outside the scope of this page.

The check goes through the pseudo-file exposed by the kernel, which gives the active card and the state of each member:

cat /proc/net/bonding/bond0

Connect to a Wi-Fi network

Wi-Fi remains anecdotal in a server room, but it helps in a lab or on a mini-server. nmcli creates the profile and activates it in a single command:

nmcli device wifi list
sudo nmcli device wifi connect "MySSID" password "wifipassword"

The created profile is persistent like the others. Be careful though: the password passed as an argument lands in the shell history. Prefer nmtui, or purge the line concerned, if the machine is shared.

Where NetworkManager stores its connections

Each profile created with nmcli is written to a keyfile under /etc/NetworkManager/system-connections/, the directory where the persistent network configuration of the machine lives. It is this directory you must back up before a migration, and it is the one the daemon rereads at boot.

ls -l /etc/NetworkManager/system-connections/

A keyfile in 0644 is ignored, and the profile disappears at reboot

The 0600 mode of these files is not only a confidentiality good practice, it is a loading condition. NetworkManager refuses any keyfile readable by others:

File permissions (100644) are insecure

nmcli con load prints Could not load file while returning code 0, and the daemon journal carries the exact reason: failure to load ... File permissions (100644) are insecure. The failure mode is particularly baffling: after a reboot, the connection has completely disappeared from nmcli con show while the file is still on disk, with perfectly valid content. The machine behaves as if it did not exist.

sudo chown root:root /etc/NetworkManager/system-connections/*.nmconnection
sudo chmod 600 /etc/NetworkManager/system-connections/*.nmconnection
sudo nmcli con reload

Two other keyfile surprises await the administrator who checks by hand, and each one is measured in a single command.

Two keyfile surprises

A profile that shows up is not necessarily persistent. An address set by hand with ip addr add does not leave "nothing": NetworkManager adopts the interface, which goes to connected (externally), and creates an external connection named after the device, which shows in nmcli con show like an ordinary profile (measured on AlmaLinux 10 with a dummy7 interface). The discriminating field is the FILENAME column: a path under /run/NetworkManager/system-connections/ signals something volatile, only /etc/… is persistent.

nmcli -f NAME,FILENAME con show

An option missing from the file is not a missing option. A keyfile only stores the differences from the default. Setting connection.autoconnect back to yes therefore does not rewrite autoconnect=true: the autoconnect=false line simply disappears. A grep autoconnect with no result is wrongly read as a forgotten setting.

The real output on Rocky 9 shows the important security point, the 0600 permissions, identical on AlmaLinux 10:

-rw------- 1 root root 233 Jul 12 07:37 enp1s0-static.nmconnection

Only root can read these files, which is essential since they contain the secrets (Wi-Fi keys, VPN credentials, 802.1X passwords) in clear text. The content is a simple INI format, here the one of the static profile created above, recorded on AlmaLinux 10:

[connection]
id=enp1s0-static
uuid=ddcafa03-9e46-4748-afdb-3c2538ea61c1
type=ethernet
interface-name=enp1s0
timestamp=1790748775

[ethernet]

[ipv4]
address1=192.168.1.50/24
dns=192.168.1.10;192.168.1.11;
gateway=192.168.1.1
method=manual

[ipv6]
addr-gen-mode=default
method=auto

[proxy]

The two DNS servers passed as one string to nmcli become a list separated by semicolons, and the empty sections ([ethernet], [proxy]) are written even when no option appears in them.

Editing these files by hand remains possible, but it is not the recommended path: the daemon keeps its own view in memory and you risk working in a vacuum. If you touch them anyway, for example to deploy a standardised configuration through Ansible, force the reread:

sudo nmcli connection reload
nmcli connection show

The global file /etc/NetworkManager/NetworkManager.conf remains the place for the daemon behaviour settings, in particular the choice of DNS manager:

[main]
dns=systemd-resolved

This setting tells NetworkManager to delegate resolution to systemd-resolved instead of writing /etc/resolv.conf itself. Any change to this file requires a sudo systemctl reload NetworkManager to be taken into account.

Security and points of attention

The network is the first exposure vector of a server, and NetworkManager is its front door. Three reflexes limit the damage.

First protect the secrets: the .nmconnection files are in 0600 by default, never copy them into a Git repository and never open them to group read. Next, always keep a fallback path before changing the connection that carries your SSH session: a hypervisor console, a cloud console or IPMI access. A mistyped address on connection up throws you out instantly, and no command will bring you back.

Finally, remember that NetworkManager filters nothing: it sets addresses and routes, not firewall rules. On RHEL, Rocky and Alma, filtering remains the job of firewalld, to configure separately. A correctly addressed interface is a reachable interface, including by what you do not want to see coming.

In case of a mistake, the rollback is immediate as long as the old profile still exists: reactivate it and delete the faulty one.

sudo nmcli connection up enp1s0-dhcp
sudo nmcli connection delete enp1s0-static

Troubleshooting

Network outages under NetworkManager almost always come down to a handful of symptoms. The following table gives the associated diagnosis and fix; always follow the same investigation order, from the most concrete to the most abstract: device, then connection, then journal, then configuration.

Symptom	Probable cause	Fix
The interface shows as unmanaged	Another manager (systemd-networkd, Netplan) claims the card, or it is excluded in NetworkManager.conf	Identify the active manager (section above), then choose which one to keep
nmcli connection show displays the right IP, ip addr the old one	Profile changed but never reactivated	sudo nmcli connection up <profile>
The configuration disappears at reboot	connection.autoconnect set to no, or address set with ip addr add (volatile)	sudo nmcli connection modify <profile> connection.autoconnect yes
Active connection but no name resolves	DNS resolvers missing from the profile	sudo nmcli connection modify <profile> ipv4.dns "192.168.1.10" then reactivate
Ping by IP works, nothing else goes out	Default gateway missing	Check ip route, fix with ipv4.gateway
The bond or bridge stays without carrier	Ports created without controller, or port profiles never activated	Check nmcli -f connection.controller connection show <port>

Swipe to see more

When the table is not enough, the daemon journal always holds the exact reason for the refusal, DHCP failure, rejected Wi-Fi key, missing card:

sudo journalctl -u NetworkManager -b --no-pager | tail -50

The -b option limits to the current boot, which avoids digging up errors already solved. To watch an outage live, leave sudo journalctl -u NetworkManager -f running in one terminal while you replay the faulty command in another.

Three commands finally complete the basic diagnosis and deserve to be in your fingers: nmcli general status for the global state of connectivity, ip route for the default route, and resolvectl status (or a simple cat /etc/resolv.conf) for the resolvers actually used.

Put it into practice

The difference between a persistent profile and a volatile address only really sinks in after a reboot. The lab has you set a static IPv4 with nmcli, check connection.autoconnect, then prove at reboot that the address, the gateway and the DNS come back on their own.

Guided lab Practice

Learn how to do it

Configure a persistent static IPv4 with NetworkManager

$ dsoxlab run l4-network-static-persist

Environment: VM·Duration: ~25 min

How it is checked: the state of the system is checked after a reboot, not the command you typed.

First time? What DSOXLab is and how to install it

DSOXLab is the command line that prepares a disposable environment (an isolated shell or a VM), runs the lab scenario, then checks the real state of the system and computes a score. Nothing is installed or broken on your workstation.

It needs Python 3.11 or later, uv or pipx, and git. The installation guide details these prerequisites; on Windows, or on a Mac without Python, use the appliance instead.

This lab starts virtual machines: it also needs ansible-playbook, a hypervisor (KVM or Incus), Terraform and hardware virtualization (/dev/kvm), which inside a VirtualBox VM means nested virtualization. The first time, dsoxlab start l4-network-static-persist checks all of it before creating the machines. Prepare your machine for vm labs.

Install the CLI and add the catalogue, once:

uv tool install dsoxlab   # or: pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training

Before you run the lab, check:

• DSOXLab installed
• catalogue available
• compatible environment (isolated shell or VM)

To check, nothing is probed from this page: run dsoxlab doctor. Read the diagnosis

Run this lab, then validate your work:

dsoxlab run l4-network-static-persist
dsoxlab check l4-network-static-persist

See every lab: dsoxlab list-labs. Track your progress: dsoxlab progress. The full dsoxlab guide covers scoring and the pitfalls.

Key points

• NetworkManager is the standard network manager of RHEL 9 and 10 servers, and of Rocky and Alma: the ifcfg scripts of network-scripts were removed, there is no default alternative.
• Tell the device (nmcli device, the card) from the connection (nmcli connection, the persistent profile): you always configure a profile, never a card.
• An address set with ip addr add is volatile; only a NetworkManager connection with connection.autoconnect yes survives a reboot. That is the point graded at the RHCSA.
• The ip4 shortcut of nmcli connection add already switches ipv4.method to manual: no need to add it.
• nmcli connection modify applies nothing live. As long as you have not run nmcli connection up, the current state stays the old one.
• On RHEL 9 and 10, attach the ports of a bond or a bridge with controller: master is only a historical alias.
• The profiles live in /etc/NetworkManager/system-connections/ with 0600 permissions and contain the secrets in clear text: back up this directory, never version it.
• Never disable the active manager remotely without a fallback console access: you would cut the network of the machine and lose control.

Knowledge check

Check that the essentials of this guide stuck. The questions cover only what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →