Restoring an Unreachable Linux Server

The situation

The goal was to restore connectivity to a Wazuh SIEM server running in a virtualized lab after every connection attempt from the analyst workstation failed.

The server at 172.22.3.49 was completely unreachable. Every connection method failed from the Windows analyst PC (172.22.2.119):

ping 172.22.3.49
Destination host unreachable.

ssh shamar@172.22.3.49
ssh: connect to host 172.22.3.49 port 22: Connection refused

# Browser access to https://172.22.3.49 also failed

The objective wasn’t just to restore access, but to identify the root cause through methodical investigation. The failure could have come from any layer: the VM power state, network interface configuration, IP assignment, routing, firewall policy, or a failed service. Each possibility had to be ruled in or out before applying a fix.

Hypotheses

Before taking any action, I listed the possible causes. Here they are with how each one played out:

1. H1VM is powered off or suspendedFound powered off in Xen Orchestra. Starting it alone didn’t fix connectivity.Contributing
2. H2VM is running but has no IP address on its interfaceConfirmed: eth0 had no IPv4 because its connection profile was inactive.Root cause
3. H3Incorrect interface configuration or missing routesRoutes were missing, but only as a symptom. The saved configuration itself was correct.Symptom
4. H4VLAN or subnet separation between workstation and serverRuled out: both sit inside 172.22.0.0/22.Ruled out
5. H5VM attached to the wrong virtual networkRuled out: the server was reachable once the profile was activated.Ruled out
6. H6Firewall policy blocking inbound connectionsRuled out: ping, SSH, and HTTPS all worked after the fix.Ruled out
7. H7Required service not running on the serverRuled out: the Wazuh dashboard loaded as soon as the network was up.Ruled out

Rather than applying fixes at random, the investigation followed a structured order: power and VM state first, then the network interface, then routing, then service availability. Each layer was confirmed before moving to the next.

Step-by-step investigation

1. 1

   Verify connectivity from the analyst PC

   Windows: ARP and routing checks Copy

   arp -a
   # Cached MAC-to-IP mappings: has this PC seen any 172.22.3.x devices?
   
   route print
   # PC is on 172.22.2.x, server on 172.22.3.x. Same /22 mask, so it should be reachable

2. 2

   Check the virtualization platform

   I logged in to Xen Orchestra (XOA), the hypervisor management interface, and located the server VM. Discovery: the VM was powered off. I started it through Xen Orchestra.

   Connection attempts still failed after it powered on. A VM being powered on is not the same as being reachable on the network.

3. 3

   Get into the guest through the console

   I opened the guest OS console directly in Xen Orchestra, bypassing the network entirely, and logged in to Rocky Linux.

   Rocky Linux (wazuh1) console Copy

   whoami
   shamar
   
   hostname
   wazuh1
   
   sudo -l
   User shamar may run the following commands on wazuh1: (ALL) ALL

4. 4

   Inspect the network interface

   ip addr: interface inspection Copy

   ip addr
   1: lo: <LOOPBACK,UP> mtu 65536 ...
       inet 127.0.0.1/8 scope host lo
   2: eth0: <BROADCAST,MULTICAST> mtu 1500 ...
       # No inet line: no IPv4 address assigned to eth0

   That confirmed the problem: the interface existed and was recognized, but had no IP address.

5. 5

   Check the routing table

   ip route Copy

   ip route
   # No output: the routing table was completely empty

6. 6

   Check NetworkManager

   NetworkManager status Copy

   nmcli device status
   DEVICE  TYPE      STATE         CONNECTION
   eth0    ethernet  disconnected  --
   lo      loopback  unmanaged     --
   
   nmcli connection show
   NAME   UUID   TYPE      DEVICE
   eth0   ...    ethernet  --
   # The profile exists, but DEVICE shows "--" (not attached)
   
   sudo nmcli connection show eth0 | grep ipv4
   ipv4.method:    manual
   ipv4.addresses: 172.22.3.49/22
   ipv4.gateway:   172.22.0.1
   ipv4.dns:       172.22.0.1,1.1.1.1

   This was the key discovery. The static IP, gateway, and DNS were all correctly set. The profile simply wasn’t active.

Root cause

This is a common scenario in virtualized environments: a VM is cloned or restored from a snapshot, or it reboots, and the connection profile doesn’t activate automatically. The interface exists and the config exists, but nothing connects them.

The fix

sudo nmcli connection up eth0
Connection successfully activated (D-Bus active path: ...)

# Verify the IP assignment
ip addr show eth0
    inet 172.22.3.49/22 brd 172.22.3.255 scope global eth0

# Verify the routing table is back
ip route
default via 172.22.0.1 dev eth0 proto static metric 100
172.22.0.0/22 dev eth0 proto kernel scope link src 172.22.3.49

After activating the profile, the server was immediately reachable from the analyst PC, and the dashboard loaded at https://172.22.3.49.

Making the fix persistent

After verifying the fix, I rebooted the server to confirm the network would stay up. It didn’t. The same problem reappeared, because the connection profile wasn’t set to autoconnect.

sudo nmcli connection modify eth0 connection.autoconnect yes
sudo nmcli connection up eth0

# Verify
nmcli device status
eth0    ethernet    connected    eth0

With connection.autoconnect yes, the profile activates automatically at boot, and the server stayed reachable after subsequent reboots.

Skills demonstrated

This recovery was the first phase of a larger build: AI-Powered SOC Alert Triage.