Mastering Ubuntu 24.04 Networking: Configuration and Troubleshooting Tips

Whether you are a student experimenting on a personal laptop or a systems engineer managing bare-metal servers in a remote data center, mastering network configuration and troubleshooting is a non-negotiable skill. When a server drops off the network—and eventually, one always does—you need to know exactly which commands to run to prove where the fault lies.

In this guide, we will walk through the essential network configuration and troubleshooting workflows specifically tailored for Ubuntu 24.04 LTS (Noble Numbat).

01. Interface IP Configuration

To function within a local network, a device needs an IP address. If it needs to access the internet or communicate with devices on different subnets, it also requires a default gateway. When configuring these IP settings, don't be surprised if your configurations suddenly disappear after a system reboot! This happens because Ubuntu utilizes two distinct types of network configuration: Live (Temporary) and Persistent.

01.1. Live (Temporary) Configuration

Live configurations are saved directly in RAM and will vanish as soon as the PC or server is rebooted. They are typically used for quick, on-the-fly modifications or for troubleshooting an active issue without committing long-term changes to the system.

Setup An IP Address

To temporarily add an IP address and subnet mask to a specific network interface, use the following syntax:

sudo ip addr add { IP_Address }/{ CIDR } dev { Interface_Name } 

For example, to assign the IP address 192.168.1.50 with a /24 subnet mask to the eth0 interface, you would run:

sudo ip addr add 192.168.1.50/24 dev eth0

Setup Default Gateway

To temporarily add a default gateway to a network interface so your machine can route traffic to the internet or other subnets, use the following syntax:

sudo ip route add default via { IP_Address } dev { Interface_Name }

For example, to route all outbound traffic through your local router at 192.168.1.1 via the eth0 interface, you would run:

sudo ip route add default via 192.168.1.1 dev eth0

01.2. Persistent Configuration

To perform permanent configurations that will survive a system reboot, modern Ubuntu relies entirely on a utility called Netplan. We can configure persistent IPs and gateways either by using the netplan set command in the terminal or by directly editing a Netplan YAML configuration file.

Method 01: Using netplan set Command

This is the fastest way to push persistent changes without having to manually write YAML syntax.

Setup An IP Address 

To permanently add an IP address and subnet mask to a specific network interface, use the following syntax:

sudo netplan set ethernets.{Interface_Name}.addresses=[{IP_Address}/{CIDR}]

For example, to assign the IP address 192.168.1.50 with a /24 subnet mask to the eth0 interface, you would run:

sudo netplan set ethernets.eth0.addresses=[192.168.1.50/24]

Setup Default Gateway

To permanently add a default gateway to a network interface so your machine can route traffic to the internet or other subnets, use the following syntax:

sudo netplan set ethernets.{Interface_Name}.routes=[{to: default, via: Gateway_IP}]

For example, to route all outbound traffic through your local router at 192.168.1.1 via the eth0 interface, you would run:

sudo netplan set ethernets.eth0.routes=[{to: default, via: 192.168.1.1}]

Method 02: Directly Editing the YAML File

Alternatively, you can manually edit the Netplan configuration files, which are typically located in the /etc/netplan/ directory (e.g., /etc/netplan/50-cloud-init.yaml or /etc/netplan/01-netcfg.yaml).

Open the file with your preferred text editor (like nano):

sudo nano /etc/netplan/50-cloud-init.yaml

A standard static IP configuration will look like this(replace the values with your actual values):

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 192.168.1.50/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]

Applying Configuration

Whether you used the netplan set command or edited the YAML file manually, you must apply the changes for them to take effect. Instead of applying them blindly, use

sudo netplan try

The command will prompt you to press Enter to confirm the changes, and if you aren't able to do it, it will revert to the old configuration. This command allows you to verify your configuration and roll back if you have made a mistake while editing the YAML file.

01.3. Verifying Configuration

Once you have configured the interface IP and default gateway, you must make sure that the configurations have been applied as intended. 

To view the current IP addresses assigned to all network interfaces, use:

ip a

Check the output under your specific interface (like eth0 or ens33) to ensure the inet line matches the IP you configured.

Even if your IP is correct, your server cannot reach the internet without a default gateway. To check the kernel's active routing table, run:

ip route show

Look for a line that starts with default via {Gateway_IP}. If that line is missing, your server does not know how to route traffic outside of its local subnet.

Then you can perform a ping test to make sure you have connectivity to whatever resource required.

ping -c 4 8.8.8.8

Note: Pinging 1.1.1.1 (Cloudflare's public DNS) or 8.8.8.8 (Google's public DNS) is an industry-standard way to test internet connectivity because it bypasses your local DNS resolver. If this works but you still can't browse the web, you have a DNS issue, not a routing issue!

02. Verifying Open Ports

To access any application or service across a network, traffic must travel through a dedicated communication channel known as a port. Because of this, verifying open ports is an indispensable step in network troubleshooting.

First, it allows you to confirm that a service (such as an Nginx web server or an SSH daemon) is actively running and sitting in a listening state. Second, it helps you diagnose port conflicts—a common and frustrating issue where a service completely refuses to start up because another background application is already running and occupying that exact same port number.

To view the ports your server is actively listening on and identify the exact service using each one, run the following command:

sudo ss -tulpn

To understand exactly what this command is doing, here is a breakdown of the specific flags used:

• -t: Show TCP ports
• -u: Show UDP ports
• -l: Show only listening sockets
• -p: Show the process using the socket (requires sudo)
• -n: Show numerical addresses and ports instead of trying to resolve names (makes the command run much faster)
  

03. Configuration & Verification of DNS

Even if you can successfully ping a local or remote device using an IP address, you cannot access services using a domain name or a subdomain if your DNS is not functioning correctly. Without working name resolution, critical automated tasks like running sudo apt update, downloading packages from GitHub, or pulling down dependencies will instantly fail.

The quickest way to test this is to try pinging a domain name to see if it successfully resolves into an IP address:

ping -c 4 domain_name.com

If the terminal prints ping: domain_name.com: Name or service not known, you have a DNS issue, not a routing issue.

03.1. Check Active Nameservers

To see exactly which upstream DNS servers your system is actively utilizing right now, run:

resolvectl status

Scroll down to your active interface section (e.g., Link 2 (ens33)). Look closely for the "DNS Servers" and "Current DNS Server" fields. If this list is blank or contains an old, unreachable IP address, your system cannot translate domain names.

03.2. Permanent Nameserver / DNS Server Configuration

Historically, administrators manually typed out nameservers into the file  /etc/resolv.conf. But this file is dynamically generated by the system. Therefore manually editing it is strictly temporary—any changes you make there will be completely overwritten upon the next reboot or network restart. 

You can view the contents in it using the command, you will likely notice a line stating nameserver 127.0.0.53:

cat /etc/resolv.conf

This is the Ubuntu's local stub resolver. It simply means the operating system is catching local DNS queries and securely forwarding them to the upstream servers you verified using resolvectl status.

To change your DNS servers permanently so they survive reboots and network updates, we can use the netplan command. Since Netplan handles your persistent network settings, you can append nameservers directly from the terminal using this syntax:

sudo netplan set ethernets.{Interface_Name}.nameservers.addresses=[{IP_ADD_01},{IP_ADD_02}]

For example, if you are setting the permanent DNS servers for the interface eth0 to Google (8.8.8.8) and Cloudflare (1.1.1.1), the command would look like this:

sudo netplan set ethernets.eth0.nameservers.addresses=[8.8.8.8,1.1.1.1]

Then apply the configuration using the command:

sudo netplan try

04. Verifying Firewalls

You have verified your IP settings, confirmed your services are listening on the correct ports, and proven that DNS is resolving perfectly. Yet, external clients still receive a "Connection Timed Out" or "Connection Refused" error when trying to reach your server. Conversely, you might face the exact opposite issue: a connection that is supposed to be strictly blocked is somehow gaining access to the device. When network traffic is either failing to reach its destination or slipping past your security perimeters, it is time to check the local system firewalls..

In Ubuntu 24.04, traffic can be blocked either at the user-friendly application level or directly inside the Linux kernel framework

04.1. The Uncomplicated Firewall (UFW)

UFW is the default firewall management tool developed for Ubuntu. It acts as a simplified frontend configuration wrapper for the underlying kernel firewall rules.

To check whether UFW is actively running and see what security policies are currently implemented, execute:

sudo ufw status verbose

Analyze the output against your specific troubleshooting scenario:

• Status: inactive — UFW is turned off entirely. If traffic is still being blocked, the issue lies elsewhere (like an external network firewall or cloud security groups). If traffic is slipping through unsecured, this is your culprit!

You can enable UFW using the following command:

sudo ufw enable

WARNING: Before running the enable command on a remote server, ensure you have already explicitly allowed SSH traffic. Do not close your current SSH session until you have successfully opened a second, completely separate terminal window and verified you can log back in. Keeping your original session open—or ensuring you have direct out-of-band console access is your only safety net against permanently locking yourself out of your own server.

• Status: active — UFW is armed. Check the rules listed below the line Default: deny (incoming), allow (outgoing), deny (routed). If your application port (e.g., 22/tcp for SSH) is not explicitly set to ALLOW, UFW is actively dropping that incoming traffic.

04.1.1. Allowing Traffic Globally by Port or Service Name

If your status check reveals that UFW is blocking a legitimate service—or failing to block an unauthorized one—you can modify the firewall policies instantly.

To open a port up to all incoming connections, specify the port number and its transport protocol (tcp or udp) using the following syntax:

sudo ufw allow {Port_or_Service}

For example, to open TCP port 80 to allow incoming web traffic, the following command can be used:

sudo ufw allow 80/tcp

Instead of numbers, you can also use the common service profiles built right into Ubuntu's default application registry, for example to allow SSH you can use the following command:

sudo ufw allow ssh

04.1.2. Restricting Access to a Single Trusted IP Address

Leaving critical management ports wide open to the public internet can expose your server to relentless brute-force attacks. You can add a targeted rule that strictly permits traffic from a trusted machine:

sudo ufw allow from {Trusted_IP} to any port {Port_Number} proto {tcp/udp}

If your server has multiple network interfaces or secondary IP addresses and you want to pin the rule to a specific interface, use this advanced syntax:

sudo ufw allow from {Trusted_IP} to {Dest_IP} port {Port_Number} proto {tcp/udp}

For example, if you want your administrative workstation at 192.168.1.150 to access SSH (Port 22) only through your management interface IP 10.0.0.5, you would run:

sudo ufw allow from 192.168.1.150 to 10.0.0.5 port 22 proto tcp

04.1.3. Explicitly Dropping Malicious Traffic (Deny Rules)

If you observe an unauthorized external device hitting your open ports, you can drop their packets immediately by switching allow to deny:

sudo ufw deny from {Source_IP}

04.1.4. Removing Rules

If you make a mistake while typing out a rule or accidentally open the wrong gateway, removing the rule is simple. The safest way to handle this without messing up existing chains is by referencing the firewall's index numbers.

First, list out all active rules along with their current system index numbers:

sudo ufw status numbered

Then, identify the number corresponding to the unwanted rule and delete it directly:

sudo ufw delete {Rule_Number}

04.2. Kernel Rules (iptables / nftables)

Sometimes, checking UFW isn't enough. Modern applications like Docker manipulate network routing by injecting rules directly into the Linux kernel's Netfilter subsystem, completely bypassing UFW's user-facing status screen.

To see the absolute, raw truth of what the Linux kernel is doing with network packets, bypass the firewall helpers and query the Netfilter tables directly:

sudo iptables -L -n -v

or

sudo nft list ruleset

But as you might have noticed running a raw dump of iptables or nftables can be incredibly overwhelming because the kernel tracks everything—including dozens of internal routing chains created by Docker, container bridges, and system loops. It's like trying to find a specific entry in a phonebook by reading it from cover to cover.

Therefore, the trick to keeping your sanity is to use search filters to cut through the noise.

Group by "Chains" (Target the Traffic Direction)

Netfilter organizes its rules into distinct paths called Chains. Instead of looking at the entire universe of rules, you can isolate just the direction of traffic you care about such:

• INPUT: Traffic coming into your host from the outside world.
• FORWARD: Traffic passing through your host
• OUTPUT: Traffic going out from your host to the outside world

To view just one specific chain, append its name to your command:

sudo iptables -L {CHAIN} -n --line-numbers

Note: The --line-numbers flag adds a handy index column to the left, which is perfect if you want to delete a specific rule later

Filter With grep

If you suspect a specific port or application is causing issues, don't read the table manually. Pipe the massive output into grep to pull out only the lines that match your exact query.

sudo iptables -L -n | grep :{PORT_NUMBER}

Using iptables-save Compact View

The standard iptables -L command tries to format the output into human-readable text columns, which actually makes it take up more vertical space on your screen.

If you want a highly condensed, ultra-compact blueprint of every active rule in the kernel, use iptables-save instead. It outputs the rules in the exact, raw format the kernel uses to load them:

sudo iptables-save

The Troubleshooting Checklist

When a system loses network connectivity, running commands at random can lead to confusion or unintended changes. By adopting a structured troubleshooting approach, you can narrow down the issue efficiently:

• Layer 3 (IP & Routing): Run ip a and ip route show. Validate that the interface has an assigned IP address and that a default gateway is present. Test local network paths by pinging your local gateway
• Layer 4 (Services & Ports): Use sudo ss -tulpn to verify whether the target application is active and listening on the designated port. Check for any port conflicts.
• Application Layer (DNS Name Resolution): Test resolution using ping domain_name.com or resolvectl status. If resolution fails but direct IP communication works, update your upstream servers permanently via Netplan.
• Security Filter (Firewalls): Audit policies with sudo ufw status verbose and check netfilter tables using sudo iptables -L -n -v to ensure security rules are not dropping valid traffic or permitting unauthorized sessions.

Keeping this checklist and these core Ubuntu 24.04 networking utilities in mind will help you diagnose network issues efficiently and keep your systems properly connected.