Misconfigured Files: Web Labs, SSH Server, ping, traceroute, and Web Apps Not Working on Main VM (SSH via Browser Works)

When web labs, SSH servers, and ping fail on an Ubuntu VM while browser-based SSH succeeds, the issue typically stems from local service misconfigurations or network isolation settings rather than host connectivity. Verifying that services like sshd are listening on the correct interfaces and checking firewall rules in ufw or iptables resolves most of these discrepancies by ensuring internal traffic is permitted while external access remains controlled.

Understanding the Network Discrepancy

The fact that SSH via a browser works is a critical diagnostic clue. This method usually relies on a proxy or a specific port forwarding rule set up by your virtualization platform (such as VirtualBox, VMware, or KVM) to map a host port to the guest’s SSH port. When standard tools like ping, traceroute, or direct SSH clients fail, it indicates that the guest operating system is not responding to standard ICMP echo requests or TCP connections on the expected ports from within the same logical network segment, or the services themselves are bound incorrectly. This scenario often occurs when the virtual machine is configured in "NAT" mode but the internal networking stack is restricted, or when the firewall is active but misconfigured. In NAT mode, the host acts as a gateway. If the guest’s firewall blocks incoming traffic on non-whitelisted ports, or if the SSH daemon is configured to only listen on 127.0.0.1 (localhost), external connections will fail even if the hypervisor forwards traffic for the browser-based client. You must distinguish between connectivity issues at the network layer and configuration errors at the application layer.

Checking Service Binding and Listeners

First, verify that the SSH server is actually listening for connections. Run the following command to check active listeners:

sudo netstat -tlnp | grep sshd
# OR
sudo ss -tlnp | grep sshd

Look for lines indicating :22 or your custom SSH port. If you see 127.0.0.1:22, the service is only accepting local connections. To fix this, edit the SSH configuration file:

sudo nano /etc/ssh/sshd_config

Find the line starting with #ListenAddress. Remove the hash symbol and change the address to 0.0.0.0 to allow connections from all network interfaces:

ListenAddress 0.0.0.0

After saving the file, restart the SSH service:

sudo systemctl restart sshd

If the service was already bound to 0.0.0.0 or ::, the issue likely lies elsewhere, such as the firewall or routing tables. For more insights on headless setup, see Installing Linux OS with SSH on a Headless Computer.

Firewall Configuration Analysis

Ubuntu systems frequently use ufw (Uncomplicated Firewall) by default. If ufw is enabled, it may be blocking incoming traffic on ports other than those explicitly allowed. Check the status with:

sudo ufw status

If the status is active, ensure that SSH (port 22) is listed as ALLOW IN. If it is missing, add it using:

sudo ufw allow ssh

However, since browser-based SSH works, the hypervisor might be bypassing ufw for that specific forwarded port, or the browser client uses a different protocol/path. Web labs and other web apps rely on HTTP/HTTPS ports (80, 443, or custom ports). Ensure these are also open:

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

If you are using iptables directly instead of ufw, check for restrictive rules:

sudo iptables -L -n -v

Look for DROP or REJECT rules in the INPUT chain that might be affecting your specific subnet. Misconfigured firewall rules are a common cause for ping failures, as ICMP is often blocked by default security policies.

Network Interface and Routing

Verify that the network interface has an IP address assigned. Use:

ip addr show

Ensure the interface (e.g., eth0 or ens33) has a valid IP in the expected range. If the IP is 169.254.x.x, the VM failed to obtain an address via DHCP. Restart the networking service or check the hypervisor’s DHCP server settings. Additionally, check the default gateway:

ip route show

A missing default gateway will prevent outbound connectivity and can affect traceroute results. If the gateway is incorrect, update it in your network configuration files, typically located in /etc/netplan/ for modern Ubuntu versions. Apply changes with:

sudo netplan apply

For further details on connecting via Ethernet, refer to Connecting to Ubuntu using ssh over Ethernet.

Web Lab and Application Specifics

Web labs often require specific software stacks (Apache, Nginx, Node.js) to be running. Check their status:

sudo systemctl status apache2
sudo systemctl status nginx

If they are inactive, start them:

sudo systemctl start apache2

Ensure they are enabled to start on boot:

sudo systemctl enable apache2

Misconfigured files in the web root (e.g., /var/www/html) can also cause applications to appear broken. Check permissions:

sudo chown -R www-data:www-data /var/www/html
sudo chmod -R 755 /var/www/html

Incorrect permissions can prevent the web server from reading necessary files, leading to blank pages or 403 Forbidden errors.

Diagnostic Steps for Ping and Traceroute

If ping fails but SSH works, ICMP might be blocked. Test with TCP instead:

nc -zv localhost 22

If this succeeds, the network path is functional, but ICMP is filtered. For traceroute, ensure it is installed:

sudo apt install traceroute

Run it against the loopback address first to verify basic functionality:

traceroute 127.0.0.1

If this works, try tracing to the gateway. Failure here suggests a routing issue.

Virtual Machine Network Mode

Check your hypervisor settings. "Bridged" mode connects the VM directly to the physical network, requiring proper IP assignment. "NAT" mode shares the host’s IP. If you switched modes recently, reconfigure the network adapter in the VM settings and restart the guest. Ensure that the virtual switch is not isolating the VM from other guests or the host LAN.

Conclusion

Resolving these issues requires a layered approach: confirm service binding, adjust firewall rules, validate network configuration, and check application permissions. By systematically verifying each component, you can isolate whether the problem lies in the OS configuration or the virtualization environment.

Frequently Asked Questions

Why does SSH work via browser but not from my terminal?

Browser-based SSH often uses a WebSocket proxy or a specific port forwarding rule configured in the hypervisor that bypasses standard firewall restrictions. Terminal SSH attempts direct TCP connections which may be blocked by ufw or iptables if not explicitly allowed.

How do I enable ICMP for ping if it is blocked?

You can allow ICMP by modifying your firewall rules. For ufw, use sudo ufw allow icmp. If using iptables, add a rule to accept ICMP echo requests in the INPUT chain. Note that some cloud providers block ICMP by default for security reasons.

What should I do if my web lab shows a 403 Forbidden error?

A 403 error typically indicates insufficient file permissions. Ensure the web server user (e.g., www-data) owns the web directory and has read/execute permissions. Use chown and chmod to correct ownership and permission bits on the relevant files.

Can NAT mode cause ping failures?

Yes, NAT mode routes traffic through the host. If the host’s firewall drops ICMP packets destined for the guest, ping will fail even though TCP traffic (like SSH) might be forwarded successfully. Bridged mode avoids this by placing the VM on the same subnet as the host.

How do I check if my network interface is down?

Use the command ip link show. Look for the state of your interface (e.g., UP or DOWN). If it is down, bring it up with sudo ip link set eth0 up (replace eth0 with your interface name).