Networking on Fedora: NetworkManager and nmcli in practice

You do not configure networking on Fedora by editing /etc/network/interfaces (that is Debian) or by hand-writing ifcfg-* (old RHEL). NetworkManager is the way, and configuration lands in keyfiles. Below is the measured state on F45.

First look: devices and connections are different things

nmcli dev status
nmcli con show

DEVICE  TYPE      STATE                   CONNECTION
ens19   ethernet  connected               Wired connection 1
eth0    ethernet  connected               cloud-init eth0
lo      loopback  connected (externally)  lo

NAME                UUID                                  TYPE      DEVICE
Wired connection 1  cf212e00-8e4d-3de6-8857-6c482a96bf14  ethernet  ens19
cloud-init eth0     1dd9a779-d327-56e1-8454-c65e2556c12c  ethernet  eth0
lo                  0bbf4b30-87a7-4515-846a-350b23d9eda8  loopback  lo

A device is hardware; a connection is configuration. One device can carry different connections, and an unconfigured NIC shows as disconnected in dev status while not appearing in con show at all.

Where the configuration actually lives:

ls /etc/NetworkManager/system-connections/

cloud-init-eth0.nmconnection

Note

F45 uses the keyfile format (.nmconnection), not the ifcfg-eth0 files older tutorials describe. Finding nothing under /etc/sysconfig/network-scripts/ is normal.

Addresses and routes

ip -br addr
ip route

lo      UNKNOWN  127.0.0.1/8 ::1/128
eth0    UP       192.168.2.247/24 fe80::be24:11ff:fe92:6176/64
ens19   UP       192.168.50.21/24 fe80::be24:11ff:fe5b:3961/64

default via 192.168.50.1 dev ens19 proto dhcp src 192.168.50.21 metric 100
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.247 metric 101

With more than one default route, the smaller metric wins. Dual-NIC machines that “cannot reach the internet” often have the wrong NIC holding the default route.

Switching to a static address

sudo nmcli con mod "Wired connection 1" \
  ipv4.method manual \
  ipv4.addresses 192.168.2.60/24 \
  ipv4.gateway 192.168.2.1 \
  ipv4.dns "223.5.5.5 192.168.2.1" \
  ipv4.may-fail no
sudo nmcli con up "Wired connection 1"

Back to DHCP:

sudo nmcli con mod "Wired connection 1" ipv4.method auto
sudo nmcli con up "Wired connection 1"

Caution

nmcli con mod only edits configuration — it does not apply it. You must run con up (or nmcli dev reapply). Editing without activating is the most common “I changed it and nothing happened”.

Common changes at a glance

Goal	Command
device state	nmcli dev status
connection config	nmcli con show
switch to static	nmcli con mod "<name>" ipv4.method manual ipv4.addresses …
back to DHCP	nmcli con mod "<name>" ipv4.method auto
change DNS	nmcli con mod "<name>" ipv4.dns "223.5.5.5"
apply the change	nmcli con up "<name>" or nmcli dev reapply <device>
add a connection	nmcli con add type ethernet ifname <device> con-name <name>
delete a connection	nmcli con delete "<name>"
resolution only	getent hosts <name>

Caution

The row most often forgotten is “apply the change”. nmcli con mod followed by con up — both steps or it is not done.

Who owns DNS

cat /etc/resolv.conf
resolvectl status | head -8

nameserver 127.0.0.53
options edns0 trust-ad
search hicyou.de

127.0.0.53 is the systemd-resolved local stub — the real upstream servers are managed by resolved. The chain is: NetworkManager reads DNS from the connection, hands it to resolved, and resolved answers on 127.0.0.53.

So editing /etc/resolv.conf by hand usually does nothing: it is the managed target. Change DNS on the connection instead:

sudo nmcli con mod "Wired connection 1" ipv4.dns "223.5.5.5"
sudo nmcli con up "Wired connection 1"

Test resolution only, not connectivity:

getent hosts fedoraproject.org

The order to check when it will not connect

ip -br link                     # 1) is the NIC up
ip -br addr                     # 2) does it have an address
ip route                        # 3) where does the default route point
ping -c1 <gateway-ip>           # 4) is layer 2 working
ping -c1 223.5.5.5              # 5) can it leave the network (IP, not name)
getent hosts fedoraproject.org  # 6) does resolution work
ss -tlnp                        # 7) what is listening locally

The dividing line is between steps 5 and 6: IPs work but names do not means a DNS problem, not “the network is down”. That single distinction removes most of the work.

Tip

For the exact error text see unknown connection, Device not found and Could not resolve hostname in error lookup.

Related pages

• Error lookup — networking messages and fixes
• firewalld — port openings and zones
• SELinux — port types and booleans (needed when a service binds a new port)
• Storage and filesystems — disks and mounts
• Cheat sheet — networking commands
• Official: Configuring IP networking with nmcli