Initial Situation
The goal was to restore connectivity to a Wazuh SIEM server running in a virtualized lab environment after all connection attempts from the analyst workstation failed. The server at 172.22.3.49 was completely unreachable - ping, SSH, and browser access all returned errors.
Every connection method failed from the Windows analyst PC (172.22.2.119):
The objective was not simply to restore access, but to identify the root cause through methodical investigation. The failure could stem from any layer: the VM power state, network interface configuration, IP assignment, routing, firewall policy, or a failed service. Each possibility had to be systematically ruled in or out before applying a fix.
Initial Hypotheses
Before taking any action, several possible causes were considered:
- VM is powered off or in a suspended state
- VM is running but has no IP address assigned to its network interface
- Incorrect network interface configuration or missing routing table
- VLAN or subnet separation between the analyst workstation and the server
- VM attached to the wrong virtual network in the hypervisor
- Firewall policy blocking inbound connections
- Required service not running on the server
Rather than applying fixes at random, the investigation followed a structured layer-by-layer approach: power and VM state first, then network interface, then routing, then service availability. Each layer was confirmed before moving to the next.
Step-by-Step Investigation
Step 1 - Verify connectivity from the analyst PC:
Step 2 - Check the virtualization platform: Logged into Xen Orchestra (XOA), the hypervisor management interface. Located the server VM in the VM list.
Discovery: The VM was powered off. Started the VM through Xen Orchestra.
After the VM powered on, connection attempts still failed. "VM powered on" ≠ "network reachable."
Step 3 - Access the VM console: Opened the guest OS console directly in Xen Orchestra - bypassing the network entirely. Logged in as user shamar on Rocky Linux.
Step 4 - Check network interface:
This confirmed the problem: the network interface existed and was recognized, but had no IP address.
Step 5 - Check routing table:
Step 6 - Check NetworkManager:
This was the key discovery. The network configuration was correct - the static IP, gateway, and DNS were all properly set. The profile simply wasn't active.
Root Cause
This is a common scenario in virtualized environments: a VM is cloned or restored from snapshot, or reboots and the connection profile doesn't automatically activate. The interface exists, the config exists, but nothing connects them.
The Fix
After activating the profile, the server was immediately reachable from the Windows analyst PC. The dashboard became accessible at https://172.22.3.49.
Making the Fix Persistent
After verifying the fix worked, the server was rebooted to confirm the network would remain active. It didn't - the same problem reappeared after reboot. The connection profile was not set to autoconnect.
With connection.autoconnect yes set, the NetworkManager profile activates automatically at boot. The server remained reachable after subsequent reboots.