Linux Networking Basics for Server Administration

Networking is a core part of Linux server administration. A Linux server can be healthy at both the OS and application levels, but still fail in practice if its network configuration is incorrect.

This article provides an introduction to Linux networking basics for server administration. We cover common Linux network configuration tasks, from inspecting interfaces to verifying Linux IP and DNS configuration. We then look at reading routing tables, managing firewall rules, and troubleshooting common connectivity issues.

#What is Linux Networking?

Linux networking controls how a Linux server sends and receives traffic on local networks and over the Internet. On each server, this starts with the network interfaces and the IP addresses assigned to them. Routing, DNS, and host firewall rules then decide how packets flow and which connections are permitted.

For server administration, Linux networking focuses on maintaining stable and secure network access. Administrators configure IP addresses and DNS settings, verify that the server can reach required systems, and limit exposure to only the ports that need to be accessible.

#Understanding Linux network architecture

Linux network architecture is the structure that links the kernel, network interfaces, IP addresses, routes, DNS, and firewall rules. It defines how traffic moves between applications on the server and the networks they use.

At a high level, Linux networking is built from a few core elements:

• Network interfaces Network interfaces are the points where network traffic enters or leaves a Linux server. They can be physical NICs or virtual devices in VMs and containers, with names like eth0, ens3, enp0s3 for Ethernet and lo for the loopback device. Each interface connects the server to one or more IP networks.

• IP addresses An IP address is the fundamental identifier that allows a Linux server to communicate on a network, similar to a physical mailing address for data packets. The server uses these addresses to distinguish itself on every network it connects to.

• Routing table Linux keeps a routing table for each server. The table lists destination networks and the next step for packets, which may be a local interface or a gateway on another router. When traffic leaves the server, the kernel consults this table and selects a route.

• Name resolution (DNS) DNS handles name resolution on a Linux server. It translates hostnames into IP addresses, allowing applications to know where to direct traffic. When DNS fails, any service that relies on hostnames begins to malfunction, even if interfaces and routes are configured correctly.

• Firewall and filtering Linux uses firewall rules to inspect and filter network traffic. Those rules run in the kernel through frameworks including nftables and iptables, and help restrict access to services that listen on the server.

• Network management layer Most Linux systems rely on a network management service that reads configuration files and brings interfaces up. On Ubuntu, Netplan reads the YAML files and passes the settings to systemd-networkd. Many other distributions use NetworkManager for the same role. At boot, these tools create the interfaces and apply the configured IP addresses, routes, and DNS settings.

#Essential Linux networking commands

Here are some of the essential Linux networking commands.

• ip link

  This lists all network interfaces on the server and shows the link state for each one, alongside their state.

• ip addr

  This displays the IPv4 and IPv6 addresses assigned to each network interface. The output also includes prefix length, scope, and interface flags for each address.

• ip -br addr

  Gives a one-line summary per interface. Easier to skim than ip addr when you just want to check basics.

• ping

  Sends a few packets to a remote host to see if it responds. Useful for confirming basic connectivity.

• traceroute and mtr

  These map the path packets take to a remote host, listing each router hop on the way. The mtr command runs continuously and combines ping with traceroute, so we can watch latency and packet loss per hop and see where problems start.

• curl

  This sends HTTP or HTTPS requests from the terminal. Useful for checking if a web app or API is responding correctly.

• ip route

  This command shows the routing table. It displays the default route and how traffic is handled across all interfaces.

• ip route get

  Shows how the system would route traffic to a specific IP, including the outgoing interface and gateway used.

• dig and host

  These run DNS lookups. You can check which IP address a hostname resolves to, or look up which hostname corresponds to a specific IP address.

• resolvectl status

  On systemd-based systems, this reports the current DNS settings. It shows name servers and search domains in use.

• ss -tulpn

  Lists open TCP and UDP ports and shows which processes own them. It helps spot what services are listening.

• tcpdump

  Captures packets on an interface. You can watch traffic live or write it to a file for later analysis.

#Configuring network settings in Linux

On a Linux server, network settings decide which interfaces start, which IP addresses they use, and where outbound traffic goes. In this section, we use Ubuntu Server 24.04 with Netplan for the examples.

#Step 1: Check the current IP, routes, and DNS

We start by checking which IP addresses are active and how the system sends traffic out to other networks.

To list the interfaces and their assigned addresses, run:

ip -br addr

Example output:

Outputlo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             46.166.165.88/24 fe80::ec4:7aff:fe32:c540/64
eno2             DOWN
eno1.3545@eno1   UP             10.172.74.47/24 fe80::ec4:7aff:fe32:c540/64

We can see that eno1 is up with the public IP 46.166.165.88, while eno2 is down. The loopback interface lo appears as expected. The VLAN interface eno1.3545 is also active with an address in the 10.172.74.0/24 private subnet.

For a more detailed view, use the full ip addr command. It shows every address on each interface, along with extra flags and metadata:

ip addr

On NetworkManager-based systems, the following command shows IP details for each device:

nmcli dev show

This displays the IPv4 and IPv6 addresses, DNS information, and other link settings for every network interface.

#Confirm routes and default gateway

Next, we inspect the routing table:

ip route

Example output:

Outputdefault via 46.166.165.1 dev eno1 proto static
10.172.74.0/24 dev eno1.3545 proto kernel scope link src 10.172.74.47
46.166.165.0/24 dev eno1 proto kernel scope link src 46.166.165.88

The output shows the default gateway (46.166.165.1 on eno1), the VLAN subnet on eno1.3545, and the directly connected network on eno1.

#Check DNS configuration

The resolvectl status command displays the server’s current DNS configuration, including the active DNS servers and resolver settings:

resolvectl status

Example output (shortened):

OutputGlobal
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (eno1)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS
…

For eno1, DNS queries go to 46.166.166.46 and 5.199.160.160, and the search domain is localdomain.

Applications read `/etc/resolv.conf`, so we also check that file:

cat /etc/resolv.conf

Output:

Outputnameserver 127.0.0.53
options edns0 trust-ad
search localdomain

In this setup, applications send DNS queries to the local stub resolver at 127.0.0.53, and systemd-resolved forwards them to the upstream servers shown by resolvectl status.

#Step 2: Locate and understand the Netplan configuration

Persistent network configuration on this server is stored in Netplan YAML files located in the /etc/netplan/ directory. We first find the files, then identify which one controls eno1.

List the files in that directory:

ls /etc/netplan

Example output:

Output50-cloud-init.yaml  60-10.172.74.47.yaml

On this server:

• 50-cloud-init.yaml defines the base configuration for the physical interface eno1.
• 60-10.172.74.47.yaml defines a VLAN interface that runs on the eno1 interface.

Next, search all Netplan files for eno1:

grep -n 'eno1' /etc/netplan/*.yaml

Output:

Output/etc/netplan/50-cloud-init.yaml:4:    eno1:
/etc/netplan/50-cloud-init.yaml:14:      set-name: "eno1"
/etc/netplan/60-10.172.74.47.yaml:4:        eno1.3545:
/etc/netplan/60-10.172.74.47.yaml:8:            link: eno1

From this, we know that 50-cloud-init.yaml holds the main eno1 definition, and 60-10.172.74.47.yaml defines the VLAN interface eno1.3545 that rides on eno1.

Open the file that defines eno1:

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

You should see a similar output:

network:
    version: 2
    ethernets:
        eno1:
            match:
                macaddress: "0c:c4:7a:32:c5:40"
            addresses:
                - "46.166.165.88/24"
            nameservers:
                addresses:
                    - 46.166.166.46
                    - 5.199.160.160
            gateway4: 46.166.165.1
            set-name: "eno1"
            mtu: 1500
        eno2:
            match:
                macaddress: "0c:c4:7a:32:c5:41"
            optional: true
            set-name: "eno2"
            mtu: 1500

Here:

• addresses shows the IPv4 address on eno1.
• gateway4 sets the default route.
• nameservers.addresses lists the DNS servers in use.

#Step 3: Clean up and update the Netplan configuration

Create a backup so we can roll back if needed:

sudo cp /etc/netplan/50-cloud-init.yaml /etc/netplan/50-cloud-init.yaml.backup

To restore it later, run:

sudo cp /etc/netplan/50-cloud-init.yaml.backup /etc/netplan/50-cloud-init.yaml

#Update the configuration file

Edit the eno1 section to match the structure below, using your own addresses:

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

Example configuration:

network:
    version: 2
    ethernets:
        eno1:
            match:
                macaddress: "0c:c4:7a:32:c5:40"
            addresses:
                - "46.166.165.88/24"
            nameservers:
                addresses:
                    - 1.1.1.1
                    - 8.8.8.8
            routes:
                - to: default
                  via: 46.166.165.1
            mtu: 1500
        eno2:
            match:
                macaddress: "0c:c4:7a:32:c5:41"
            optional: true
            mtu: 1500

In this version:

• The routes block carries the default route using to: default and via: 46.166.165.1, which replaces the earlier gateway4 directive.
• The nameservers.addresses list uses public resolvers as an example. In practice, we swap in the real DNS servers for this environment.

YAML is strict about indentation, so use spaces only and keep the structure aligned exactly as shown.

#What if this server uses DHCP?

If the server receives its IP settings from DHCP instead of using a static address, the eno1 section looks simpler:

network:
    version: 2
    ethernets:
        eno1:
            match:
                macaddress: "0c:c4:7a:32:c5:40"
            dhcp4: true
            mtu: 1500

Here, the DHCP server provides the IP address, default gateway, and usually DNS servers. Netplan still turns this into backend configuration, but we do not specify addresses or routes manually.

#Step 4: Safely validate, apply, and verify the configuration

Now that the Netplan YAML is updated, we validate it and apply the changes safely.

#Validate the configuration

First, validate the configuration and generate backend files:

sudo netplan --debug generate

On a valid config, the output ends with a message similar to:

Output** (generate:17694): DEBUG: 08:07:34.531: eno2: setting default backend to 1
** (generate:17694): DEBUG: 08:07:34.531: Configuration is valid

This confirms that Netplan parsed the YAML successfully and generated the backend configuration. No live settings have changed yet.

#Test with automatic rollback

Next, test the new configuration with Netplan’s safety timeout:

sudo netplan try

Netplan applies the new settings temporarily and shows a prompt:

OutputDo you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in 120 seconds

If we press ENTER in time, the configuration is saved. If we do nothing, Netplan restores the previous settings.

#Verify connectivity while testing

While netplan try is waiting, use another terminal or SSH session to confirm that networking still works.

Check the IP address on the main interface:

ip -br addr show eno1

Confirm that the default gateway is reachable:

ping -c 2 46.166.165.1

Verify DNS resolution:

ping -c 2 google.com

Check that the new DNS servers are active on eno1:

resolvectl status eno1

We should now see 1.1.1.1 and 8.8.8.8 (or the chosen resolvers) listed as DNS servers. If these checks pass, we return to the netplan try prompt and confirm the configuration.

If these checks pass, return to the netplan try prompt and confirm the configuration.

#Apply permanently

After testing, apply the configuration permanently:

sudo netplan apply

Next, run a quick check:

Outputip -br addr
resolvectl status eno1
ping -c 2 46.166.165.1
ping -c 2 google.com

This confirms that the IP address, default route, and DNS work under the new configuration and persist across reboots.

#Linux routing basics

Routing determines how packets leave a server and reach other systems. The kernel maintains a routing table that maps destinations to outgoing interfaces and gateways.

#The Linux routing table

Inspect the routing table with:

ip route

Output:

Outputdefault via 192.168.1.1 dev eth0 proto static metric 100
10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.5
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

The first line is the default route traffic with no more specific match goes through 192.168.1.1 on eth0. The remaining lines cover directly attached subnets.

When multiple routes match, the kernel picks the one with the longest prefix. A route to 192.168.1.0/24 beats a route to 192.168.0.0/16 for traffic headed to 192.168.1.50.

#Testing routing decisions

To see which route a destination would use without sending real traffic, run:

ip route get 8.8.8.8

This shows the outgoing interface, gateway, and source IP.

#Adding temporary static routes

For quick tests, add routes directly:

sudo ip route add 10.20.0.0/16 via 10.172.74.1 dev eno1.3545

You can remove it with:

sudo ip route del 10.20.0.0/16 via 10.172.74.1 dev eno1.3545

These changes are not persistent. They disappear after a reboot.

#Making routes persistent on Ubuntu with Netplan

On Ubuntu Server, persistent routes belong in Netplan YAML files. This example adds a static route alongside the default:

network:
    version: 2
    ethernets:
        eno1:
            match:
                macaddress: "0c:c4:7a:32:c5:40"
            addresses:
                - "46.166.165.88/24"
            routes:
                - to: default
                  via: 46.166.165.1
                - to: 10.20.0.0/16
                  via: 10.172.74.1
            nameservers:
                addresses:
                    - 1.1.1.1
                    - 8.8.8.8

After saving the file, apply it:

sudo netplan apply

#Firewall configuration

A firewall limits which traffic can reach or leave a server. On Ubuntu, UFW provides a simple interface to the underlying nftables system.

#Check the current state

sudo ufw status verbose

This shows whether the firewall is active, the default policies, and any existing rules.

#Set default policies

A common baseline for most servers:

sudo ufw default deny incoming
sudo ufw default allow outgoing

These commands deny all new inbound connections by default and allow outbound traffic, without opening any ports yet.

#Allow essential services

Next, we explicitly allow the services that the server needs to expose.

Open SSH (port 22):

sudo ufw allow 22/tcp

To restrict SSH to a specific IP:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

Open HTTP and HTTPS:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Enable the firewall:

sudo ufw enable

Output:

OutputCommand may disrupt existing ssh connections. Proceed with operation (y|n)?

Confirm that SSH access is allowed before proceeding to avoid locking yourself out.

Check the final state:

sudo ufw status verbose

Example output:

OutputStatus: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
22/tcp                     ALLOW IN    203.0.113.10
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
22/tcp (v6)                ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)

This confirms that the firewall is active, the default policy denies incoming connections, and allows outgoing connections.

#How to remove or adjust rules

Firewall rules change as services are added or removed.

To make deletion easier, list rules with line numbers:

sudo ufw status numbered

Expected output:

OutputStatus: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 22/tcp                     ALLOW IN    203.0.113.10
[ 3] 80/tcp                     ALLOW IN    Anywhere
[ 4] 443/tcp                    ALLOW IN    Anywhere
[ 5] 22/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 6] 80/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 7] 443/tcp (v6)               ALLOW IN    Anywhere (v6)

Delete a rule by number. For example, to delete the first rule:

sudo ufw delete 1

Or delete a rule using its specification:

sudo ufw delete allow 80/tcp

#Network services & daemons

Network services run as background processes (daemons) that listen on ports. SSH, web servers, and DNS resolvers all work this way.

A simple way to see which network services are active is to list all listening sockets:

sudo ss -tuln

Example output:

OutputNetid State  Local Address:Port  Peer Address:Port
tcp   LISTEN 0.0.0.0:22         0.0.0.0:*
tcp   LISTEN 0.0.0.0:80         0.0.0.0:*

Port 22 typically indicates SSH, while port 80 indicates a web server, for example, Nginx or Apache.

To see which process owns each socket:

sudo ss -tulpen

#Managing services with systemctl

Start with the SSH service check, since remote access is critical on almost every server:

sudo systemctl status ssh

In the output, we focus on the Active line. For a healthy service, we expect something like:

OutputActive: active (running)

Restart, start, or stop a service:

sudo systemctl restart ssh
sudo systemctl start nginx
sudo systemctl stop nginx

Next, enable or disable a service at boot:

sudo systemctl enable nginx
sudo systemctl disable nginx

#Troubleshooting Linux network issues

Most problems fall into a few categories: wrong IP settings, missing routes, DNS failures, services not running, or firewall rules blocking traffic. Work through them in order.

1. Check local configuration

   Confirm the default route exists:

   Command Line

   ip route show default
   

   If missing or incorrect, fix it in the Netplan configuration before continuing.

2. Test basic reachability with ping

   Ping the gateway:

   Command Line

   ping -c 2 46.166.165.1
   

   Example success output:

   OutputPING 46.166.165.1 (46.166.165.1) 56(84) bytes of data.
   
   64 bytes from 46.166.165.1: icmp_seq=1 ttl=255 time=0.45 ms
   64 bytes from 46.166.165.1: icmp_seq=2 ttl=255 time=0.40 ms
   
   --- 46.166.165.1 ping statistics ---
   2 packets transmitted, 2 received, 0% packet loss, time 1002ms
   

   If this fails with "Network is unreachable," the route or IP configuration is wrong. Then ping an external IP:

   Command Line

   ping -c 2 8.8.8.8
   

3. Check DNS resolution

   After IP connectivity is confirmed, check DNS. Many network problems are caused by DNS rather than routing.

   Compare ping by IP and by hostname:

   Command Line

   ping -c 2 8.8.8.8
   ping -c 2 google.com
   

   If the IP works but the hostname fails, the issue is name resolution (DNS). Check the current DNS settings:

   Command Line

   resolvectl status
   

4. Check services and listening ports

   If IP and DNS are working, confirm that the service itself is running and listening on the correct port.

   Confirm the service is running:

   Command Line

   sudo systemctl status ssh
   

   If inactive or failed, restart it:

   Command Line

   sudo systemctl restart ssh
   

   Then confirm that it is listening on the expected port:

   Command Line

   sudo ss -tuln
   

   Example output:

   Outputtcp   LISTEN 0.0.0.0:22    0.0.0.0:*
   tcp   LISTEN 0.0.0.0:80    0.0.0.0:*
   

   A service bound only to 127.0.0.1 will not accept remote connections.

5. Check firewall rules Review the firewall if a service is running and listening on the correct port, but clients are unable to connect.

   Check the current rules:

   Command Line

   sudo ufw status verbose
   

   Example output:

   OutputStatus: active
   Logging: on (low)
   Default: deny (incoming), allow (outgoing), disabled (routed)
   New profiles: skip
   
   To                         Action      From
   --                         ------      ----
   22/tcp                     ALLOW IN    Anywhere
   80/tcp                     ALLOW IN    Anywhere
   22/tcp (v6)                ALLOW IN    Anywhere (v6)
   80/tcp (v6)                ALLOW IN    Anywhere (v6)
   

   Confirm that the port used by the service is listed with an ALLOW IN action, and that any source restrictions match the client IP you are testing from.

   When a required port is missing, add an allow rule:

   Command Line

   sudo ufw allow 80/tcp
   

#Best practices for network security

Linux networking is not only about making services reachable, but ensuring their safety as well.

#Limited exposed services

Every open port adds risk, so keep only what is necessary. The ss -tuln command shows which ports are listening, and anything that is not needed can be stopped or removed.

#Harden SSH access

SSH is usually the main way we manage a server, so it needs extra care. A good baseline is to use SSH keys instead of passwords. It also helps to disable direct root login and use a normal user with sudo.

#Keep systems updated and use the firewall consistently

Security patches matter as much as initial configuration. We apply regular updates to the kernel, OpenSSH, web servers, and other network daemons, and treat the firewall as a clear expression of policy rather than a temporary fix.

#Document and review regularly

Network security is easier to manage when it is documented. Note which services should be reachable and on which ports. Review open ports and firewall rules from time to time to confirm they still match the intended design.

#Conclusion

This article covered the core Linux networking tasks for server administration: checking interfaces and IP addresses, verifying routes and DNS, managing firewall rules, and troubleshooting connectivity issues.

These fundamentals provide a starting point for keeping servers connected and accessible. As you work with more complex network setups, you will build on these basics.