openSUSE Leap Network Troubleshooting for VPS Reachability

When a VPS is up but still unreachable

If your server boots but SSH still times out, the problem is usually not “the internet.” It is almost always one of four things: address assignment, routing, firewall policy, or service binding. This tutorial walks you through openSUSE Leap network troubleshooting on a fresh VPS, then shows you how to restore reachability without locking yourself out.

We will work on openSUSE Leap because the stack differs a little from Ubuntu or RHEL-family systems. You will use zypper, firewalld, and AppArmor-aware checks, and you will confirm network state with systemd tools before changing anything. If you are moving a customer server, finishing a migration, or recovering access after a firewall change, this is the safest order to follow. For larger deployments, Hostperl VPS hosting at Hostperl VPS gives you room to test these changes without pushing production traffic onto a fragile setup.

What you will fix

By the end, you will be able to:

• Confirm the server’s IP, route, and DNS state.
• Test ICMP, SSH, and service ports from inside and outside the VPS.
• Repair common firewalld mistakes on openSUSE Leap.
• Check whether SSH or an app is listening on the right interface.
• Verify IPv4 and IPv6 reachability separately.
• Roll back a bad change safely if you break connectivity.

This guide focuses on a real support scenario: the VPS responds in the provider panel, but clients cannot connect. If you are also hardening SSH access, keep SSH hardening without lockouts open in another tab, because the order of operations matters.

1) Connect and identify the operating system

On your local computer, open your terminal and connect as root first. Keep the original session open until you have tested a second login.

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation address. Replace it with the real public IP assigned to your VPS.

If your provider gives you a default non-root account, use that first, then elevate with sudo after verification:

ssh deploy@203.0.113.10

On the VPS as root, confirm the operating system before making any changes:

cat /etc/os-release

You should see openSUSE Leap details such as the NAME and VERSION fields. If you do not, stop here and follow the correct OS guide for that system.

2) Refresh packages and inspect the current network state

openSUSE Leap uses zypper. Refresh metadata first so you are not troubleshooting with stale packages or tools.

zypper refresh

zypper update -y

Now inspect interfaces, addresses, and routes. These commands show whether the VPS has the expected public IP and a default gateway.

ip addr show

ip route show

ip -6 addr show

ip -6 route show

Look for three clues: the expected IPv4 address on the main interface, a default route, and any IPv6 address that should actually be reachable. If the address is missing, this is usually a provider-side assignment issue or a bad netconfig profile.

3) Test basic connectivity from the VPS itself

Before you blame the outside world, check whether the server can reach its own gateway and a public resolver. That separates local routing problems from upstream packet filtering.

ping -c 4 203.0.113.1

ping -c 4 1.1.1.1

ping -c 4 8.8.8.8

Replace 203.0.113.1 with your actual gateway if your provider documents one. If gateway ping fails but public ping works, your route table may still be wrong. If public ping fails too, check the interface state and the provider network.

For name resolution, test DNS separately. Broken DNS often looks like “the internet is down” when it is really just lookup failure.

resolvectl status

getent hosts hostperl.com

If getent returns an IP, DNS resolution is working. If it hangs or returns nothing, fix resolver settings before touching the firewall.

4) Check listening services and interface binding

Many reachability failures are not network failures at all. The service is simply listening on 127.0.0.1 instead of the public interface, or it is not running.

ss -tulpn

Look for SSH on port 22 and any application port you expect to expose, such as 8000. A healthy SSH daemon usually shows 0.0.0.0:22, [::]:22, or both. If you only see 127.0.0.1:22, SSH is bound to localhost and remote access will fail.

Check service status next:

systemctl status sshd --no-pager

On openSUSE Leap, the SSH service is usually sshd. If the unit is inactive or failed, read the journal:

journalctl -u sshd -b --no-pager

If you are publishing an app on port 8000, verify the process is listening on all required interfaces. For a local-only test service, 127.0.0.1 is fine. For public access, it is not.

5) Confirm firewalld is not blocking the port

openSUSE Leap commonly uses firewalld. That is good, but it also means you need to check zone rules before blaming routing. Start by confirming the service is running.

systemctl status firewalld --no-pager

List the active zone and its allowed services or ports:

firewall-cmd --get-active-zones

firewall-cmd --zone=public --list-all

If SSH is missing from the active zone, add it before closing any other access method. Do not remove the current session or change SSH settings yet.

firewall-cmd --permanent --zone=public --add-service=ssh

firewall-cmd --reload

If your application uses port 8000, open it explicitly:

firewall-cmd --permanent --zone=public --add-port=8000/tcp

firewall-cmd --reload

Check the result immediately:

firewall-cmd --zone=public --list-ports

firewall-cmd --zone=public --list-services

If you use a custom zone, replace public with that zone name. The rule must match the interface’s actual zone assignment, or the port will stay blocked.

6) Add a non-root admin safely

If you are still working as root, create the non-root admin now. This is the right moment because network access is already stable and you can test a second login before changing anything else.

On the VPS as root, create the account, add it to wheel, and prepare SSH access:

useradd -m -G wheel -s /bin/bash deploy

passwd deploy

mkdir -p /home/deploy/.ssh

chmod 700 /home/deploy/.ssh

Copy your public key into the account. Replace the example key with your own:

cat > /home/deploy/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEexampleKeyHereReplaceMe user@example.com
EOF

chmod 600 /home/deploy/.ssh/authorized_keys

chown -R deploy:deploy /home/deploy/.ssh

Now open a second terminal on your local computer and test the account before touching root access:

ssh deploy@203.0.113.10

After logging in, confirm sudo works:

sudo -v

If sudo asks for your password and then succeeds, your admin path is ready. Leave the root session open until this works.

7) Repair SSH only after firewall access is confirmed

If SSH is still unreachable from outside, inspect its configuration. On openSUSE Leap, the file is usually /etc/ssh/sshd_config. Use a safe edit and keep a rollback copy.

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

grep -E '^(Port|ListenAddress|PermitRootLogin|PasswordAuthentication)' /etc/ssh/sshd_config

If you need SSH on the default port with key-based access only, make the following minimal changes with vi or your preferred editor:

vi /etc/ssh/sshd_config

Use these settings if they are missing or commented out:

Port 22
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes

Save and exit the editor, then validate syntax before restart:

sshd -t

No output means the config syntax is valid. Then reload safely:

systemctl reload sshd

Test the new session from your local computer before ending the original root connection:

ssh deploy@203.0.113.10

For lockout prevention, do not disable password authentication or root login until this second connection succeeds.

8) Diagnose IPv6 separately from IPv4

IPv6 failures are common because the address exists, but the route or firewall does not. Treat IPv6 as its own path.

ping -6 -c 4 google.com

ping -6 -c 4 2606:4700:4700::1111

ss -tulpn | grep -E ':22|:8000'

If IPv4 works and IPv6 fails, verify the default route and the firewall zone again. Some providers deliver IPv6 only when you add a routed prefix or enable the correct virtual NIC settings in the control panel. That is a provider-side configuration issue, not an OS bug.

For DNS on dual-stack hosts, check both A and AAAA records from your workstation:

dig A server.example.com +short

dig AAAA server.example.com +short

Replace server.example.com with your hostname. A missing AAAA record can make IPv6-only clients fail even when the server is otherwise healthy.

9) NetworkManager and persistent interface issues

If the server reboots and loses the IP, the problem may be in the persistent profile rather than the live interface. openSUSE Leap uses NetworkManager on many installs, so inspect its active connection.

nmcli device status

nmcli connection show

nmcli connection show --active

Find the connection profile tied to your main NIC, then inspect it:

nmcli connection show "Wired connection 1"

If the profile is wrong, modify the connection rather than editing random files. For example, to set static IPv4 on the main profile:

nmcli connection modify "Wired connection 1" ipv4.addresses 203.0.113.10/24 ipv4.gateway 203.0.113.1 ipv4.method manual

nmcli connection modify "Wired connection 1" ipv4.dns "1.1.1.1 8.8.8.8"

nmcli connection up "Wired connection 1"

Replace the example address, prefix, and gateway with the values supplied for your VPS. Then recheck the route and test connectivity again.

10) WireGuard reachability check for private tunnels

If your server is supposed to be reachable over a WireGuard tunnel, the failure may sit in the tunnel rather than the public interface. Confirm the tunnel state and the peer handshake.

systemctl status wg-quick@wg0 --no-pager

wg show

ip addr show wg0

A healthy tunnel shows a recent handshake and an address on wg0. If the handshake is stale, check firewall rules for UDP port 51820 and verify the peer’s endpoint IP and allowed IPs. If you need a dedicated address for a tunnel-facing service, Hostperl’s IP resources at Hostperl IP address rental can help with routed public addressing on the service side.

11) Roll back safely if you break access

When a change causes a lockout, revert in the least risky order. First, keep an active session open if you still have one. Second, restore the last known-good firewall or SSH config. Third, reboot only if the network stack is wedged and the provider panel shows a console.

To restore the SSH backup:

cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config

sshd -t

systemctl restart sshd

To remove a temporary firewall port you no longer need:

firewall-cmd --permanent --zone=public --remove-port=8000/tcp

firewall-cmd --reload

If the interface profile is wrong, return it to DHCP or the previous static settings with nmcli, then reconnect. Avoid random file edits under /etc/sysconfig/network/ unless you know which profile is in use.

Verification from server and client

On the VPS, confirm that the services are active and the sockets are listening:

systemctl is-active sshd

systemctl is-active firewalld

ss -tulpn | grep -E ':22|:8000'

journalctl -u sshd -b --no-pager | tail -n 20

On your local computer, test both SSH and the public port from outside:

ssh deploy@203.0.113.10

curl -I http://203.0.113.10:8000

If the SSH login works and the HTTP check returns a valid response, the server is reachable again. If the service is not HTTP, substitute the correct protocol-specific client test, such as nc -vz 203.0.113.10 25 for SMTP or nc -vz 203.0.113.10 5432 for PostgreSQL.

Troubleshooting the most likely failures

• Symptom: SSH times out, but the panel console works. Check: firewall-cmd --zone=public --list-all. Fix: add ssh to the active zone and reload.
• Symptom: The service starts only on localhost. Check: ss -tulpn. Fix: change the app or SSH to bind to 0.0.0.0 or the public IP.
• Symptom: IPv4 works, IPv6 does not. Check: ip -6 route show and firewall-cmd --list-all. Fix: add the routed prefix and allow the needed IPv6 port.
• Symptom: Reachability fails after reboot. Check: nmcli connection show --active. Fix: correct the persistent NetworkManager profile.

Why this matters for production hosting

Reachability issues consume support time fast. A server that is “up” but unreachable still misses customer traffic, mail, or API calls. On a production VPS or migration project, a clean network checklist saves you from guessing and shortens downtime.

If you are planning a new deployment rather than repairing one, Hostperl VPS hosting gives you a practical place to stage the network design before cutover. For larger or traffic-sensitive environments, compare that with dedicated server hosting when you need more control over NIC layout, routing, and performance isolation.

FAQ

Why can I ping the server but not SSH into it?

ICMP and SSH use different paths. The firewall may allow ping but block port 22, or SSH may be listening only on localhost.

Should I disable root login immediately?

No. First verify that your non-root sudo account works from a second terminal. Only then reduce root access.

How do I know if the problem is DNS or routing?

Test both. Use getent hosts or dig for DNS, then ping or traceroute for routing.

Can I use this process for a web app on port 8000?

Yes. Replace the SSH-specific checks with your app’s port and service name, then confirm the app binds to the correct interface and the firewall allows that port.

What if firewalld is not installed?

Then your image may use a different firewall path, but on openSUSE Leap it is common. Check systemctl status firewalld first before assuming another tool is active.