RHEL Network Diagnostics on a VPS: Route and Port Checks

What this tutorial fixes on a fresh RHEL VPS

RHEL network diagnostics is the quickest way to tell a hosting issue from an application issue. If a VPS can ping out but cannot reach a package mirror, accepts SSH on one port but not another, or starts timing out on IPv6 after a migration, you need to check routes, ports, and firewall rules in a careful order.

This guide uses RHEL, Oracle Linux, and Fedora Server because they share the tools that matter here: dnf, ip, ss, firewalld, and SELinux. For Hostperl customers moving workloads between VPS plans or onto a dedicated server, that common toolset makes troubleshooting much easier. A clean diagnosis saves reboots and keeps you from blaming the app when the network edge is the real problem. If you are still choosing infrastructure, compare a Hostperl VPS with your expected traffic and remote-access needs before you migrate.

We will create a non-root admin, inspect routes, test ports, open only the rules you need, and verify the server still comes back after a reboot. You will also see when to check logs and when to stop changing settings. For context on operational logging, the guide Nginx access logs that actually help troubleshoot apps is a useful companion when the network looks fine but the app still fails.

Scenario and outcome

You have a new RHEL-compatible VPS at Hostperl, and one of three things is happening:

• SSH works from one network but times out from another.
• An app on port 8000 is reachable locally but not from your laptop.
• IPv4 works, but IPv6 or a routed VPN subnet does not.

By the end, you will have a documented network baseline, a tested SSH admin login, a firewall that allows only the required ports, and a rollback path if you lock yourself out.

First login and platform detection

On your local computer:

ssh root@203.0.113.10

Use 203.0.113.10 only as documentation. Replace it with the public IP assigned to your server. If your provider gave you a default non-root account, use that account name with the same IP.

After you connect, confirm the operating system before doing anything else.

On the VPS as root:

cat /etc/os-release

You should see rhel, ol, or fedora in the release data. The commands below are written for this family only.

Create a non-root admin before changing access rules

Keep the root session open. Open a second terminal later and test the new login before you touch SSH restrictions.

RHEL, Oracle Linux, and Fedora Server

On the VPS as root:

useradd -m -G wheel -s /bin/bash deploy
passwd deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

This creates the deploy account, adds it to the sudo-capable wheel group, and copies your SSH key so you can test login safely. If you do not already use keys, add your public key first from your local machine with ssh-copy-id.

On your local computer, in a second terminal:

ssh deploy@203.0.113.10

Then confirm sudo works:

sudo -v
whoami
id

You should see deploy as the user and wheel in the group list. Do not disable root login until this works.

For a broader operating-system setup pattern, Hostperl customers often pair this with the account-hardening flow in How to add a new sudo user on Linux VPS servers.

Record the current network state

These commands show whether the problem is related to addressing, routing, ports, or DNS.

On the VPS as the non-root sudo user:

sudo ip addr show
sudo ip route show
sudo ss -tulpn
sudo ping -c 3 1.1.1.1
sudo ping -c 3 example.com

Expected results:

• ip addr shows the server's IPv4 and, if assigned, IPv6 addresses.
• ip route shows a default route via your provider gateway.
• ss lists listening services and their ports.
• ping 1.1.1.1 proves raw outbound IP connectivity.
• ping example.com proves DNS resolution too.

If DNS fails but IP ping works, the issue is resolver configuration, not routing.

Set up firewalld for SSH and one application port

RHEL-compatible systems usually ship with firewalld enabled or ready to enable. Open the new port before removing any old access path. Here we allow SSH and a sample app on port 8000.

On the VPS as the non-root sudo user:

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-port=8000/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

You should see ssh and 8000/tcp in the active zone. If your app uses a different port, replace 8000 with the real service port.

For Linux hosting buyers comparing traffic patterns and upgrade paths, a Hostperl VPS is usually the right starting point when you need control over ports without moving to a dedicated server too early.

Test the listening service locally and from the client

Before you blame the firewall, prove the service is listening on the server.

On the VPS as the non-root sudo user:

sudo ss -tulpn | grep ':8000'
curl -I http://127.0.0.1:8000

If nothing appears in ss, the application is not bound to the port. If local curl works but remote access fails, the firewall or upstream filtering is the next place to look.

On your local computer:

curl -I http://203.0.113.10:8000

Success means you can reach the application from outside the server. If the request hangs, check the firewall, provider security rules, and any reverse proxy in front of the app.

Check IPv6 and routing separately

IPv6 failures often look like general network trouble, but they usually come from a missing default route, broken DNS AAAA records, or firewall rules that never allowed v6 traffic.

On the VPS as the non-root sudo user:

sudo ip -6 addr show
sudo ip -6 route show
sudo ping -6 -c 3 2606:4700:4700::1111

If there is no IPv6 address or no default route, the server will not speak IPv6 even if the hostname has AAAA records. In that case, remove the AAAA record at the DNS provider or fix the provider-side addressing first. For DNS and host mapping decisions, Hostperl customers often review public IP planning with IP and DNS resources when they need stable routing for mail, panels, or VPNs.

Enable remote administration safely with SSH hardening

Only do this after the deploy login works. If you plan to move SSH to a custom port, add that rule first and do not remove port 22 until the new port works. In this tutorial, we keep port 22 and reduce risk by disabling password login.

On the VPS as root:

sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sshd -t

sshd -t must return no output. That means the SSH config syntax is valid.

On the VPS as root:

sudo systemctl reload sshd

Open a third terminal and confirm you can still log in as deploy with your key. Leave the original root session open until that test succeeds.

Use SELinux clues instead of turning it off

On RHEL-family systems, SELinux often explains why a port works locally but fails through a proxy or after a policy change.

On the VPS as the non-root sudo user:

sudo getenforce
sudo ausearch -m AVC -ts recent | tail -n 20

If getenforce returns Enforcing and ausearch shows AVC denials, the policy is blocking access. Do not disable SELinux as a first move. Instead, inspect the exact denial, then adjust the service context or port labeling. For a web stack, the error often appears after an Nginx or Apache reverse-proxy change.

Use the existing Hostperl Nginx troubleshooting guide if the server is healthy but your proxy logs show repeated 502s: Nginx access logs that actually help troubleshoot apps.

Add a basic connectivity monitor and persistence check

A one-time fix is not enough. You want proof the server comes back with the same access rules after a reboot.

On the VPS as the non-root sudo user:

sudo systemctl is-enabled firewalld
sudo systemctl is-enabled sshd
sudo reboot

After the reboot, reconnect from your local computer with the same SSH command. Then confirm the services and port state again:

On the VPS as the non-root sudo user:

sudo firewall-cmd --list-all
sudo ss -tulpn
sudo systemctl status firewalld --no-pager
sudo systemctl status sshd --no-pager

You should see the firewall active, SSH listening, and your allowed port still open.

Rollback if you lock yourself out

If SSH fails after a change, use the provider console or rescue access. Once you are back in, restore the previous SSH settings first. Keep a copy of the old config before editing next time.

On the VPS as root or via rescue console:

cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sed -i 's/^PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
sed -i 's/^PermitRootLogin no/PermitRootLogin yes/' /etc/ssh/sshd_config
sshd -t && systemctl reload sshd

If the service still refuses to start, inspect the journal:

journalctl -u sshd -b --no-pager | tail -n 50
journalctl -u firewalld -b --no-pager | tail -n 50

The clues usually point to a syntax error, a denied SELinux context, or a port conflict.

Most likely failures and how to diagnose them

Remote SSH times out

Diagnostic command:

sudo firewall-cmd --list-all
sudo ss -tulpn | grep ':22'

Clue: SSH is not listening, or port 22 is not allowed in the active zone.

Fix: Ensure sshd is running and re-add the SSH service with firewall-cmd --permanent --add-service=ssh, then reload firewalld.

Local curl works, remote curl fails

Diagnostic command:

sudo ss -tulpn | grep ':8000'
sudo firewall-cmd --list-ports

Clue: The app is listening only on 127.0.0.1, or the firewall does not allow the port.

Fix: Bind the app to 0.0.0.0 or the server IP, then open the port with firewalld.

IPv6 times out but IPv4 works

Diagnostic command:

sudo ip -6 addr show
sudo ip -6 route show
sudo ping -6 -c 3 2606:4700:4700::1111

Clue: No IPv6 address or no default route.

Fix: Confirm the VPS plan includes IPv6 and correct DNS AAAA records before advertising IPv6 service.

Final verification from both sides

On the VPS as the non-root sudo user:

whoami
sudo firewall-cmd --list-all
sudo ss -tulpn
curl -I http://127.0.0.1:8000

On your local computer:

ssh deploy@203.0.113.10
curl -I http://203.0.113.10:8000

If both logins and both HTTP checks succeed, the server is ready for production traffic. You now have a repeatable baseline for route checks, port exposure, and safe admin access on a Hostperl VPS.

FAQ

Should I disable root login immediately?

No. Verify the new deploy account can log in with SSH keys and sudo first. Then disable root login and password authentication.

Why does ping work but my app port does not?

Ping only proves ICMP reachability. Your app port still needs the process to listen on the correct address and the firewall to allow the port.

Do I need both IPv4 and IPv6?

Not always. Use both only if your DNS, provider network, and application stack are ready. Partial IPv6 support creates confusing support tickets.

What if firewalld is running but the port is still closed?

Check whether the service is bound to 127.0.0.1, whether SELinux is denying access, or whether the wrong zone is active for your interface.

Can I use this on a fedora server after a migration?

Yes. Fedora Server uses the same family of tools, but upgrade and lifecycle timing move faster than RHEL or Oracle Linux, so confirm package versions before changing network policy.