Debian 12 Network Diagnostics for VPS Connectivity

What you are fixing on a fresh Debian VPS

This tutorial shows you how to diagnose Debian 12 network diagnostics problems on a VPS when the server is up, but traffic behaves badly. You will check IP addressing, routes, DNS reachability, open ports, IPv4 and IPv6 path issues, and a simple WireGuard VPN test path. The workflow is written for Debian 12 and follows a safe sequence so you do not lock yourself out while fixing the network.

If you are rebuilding a production node, this is the kind of work Hostperl support teams often see after migrations, provider handovers, and firewall changes. If you need a Debian VPS first, Hostperl’s Hostperl VPS hosting is a practical fit for this kind of setup and troubleshooting.

Connect and identify the operating system

On your local computer

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 server. If your provider gave you a default non-root login, connect with that account instead, then elevate with sudo.

Keep this original root session open until the new login and network checks are finished.

On the VPS as root

cat /etc/os-release

This confirms you are on Debian 12 or another Debian-family release. You should see a NAME=Debian GNU/Linux line and a VERSION_ID="12" line on the target system.

Prepare a non-root admin session before changing networking

Do not make firewall or SSH changes from your only session. Create a sudo user first, then test it in a second terminal.

On the VPS as root

adduser deploy

This creates the deploy account. Choose a strong password when prompted.

usermod -aG sudo deploy

This grants sudo access through the Debian sudo group.

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh

This creates the SSH directory with restrictive permissions.

cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys

If your root account already uses key-based login, this copies the same key for the new admin account. If you manage keys differently, paste the public key into the file manually.

chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

These commands protect the key file and set ownership correctly.

On your local computer

ssh deploy@203.0.113.10

Replace the IP with your real server address. Open a second terminal, log in as deploy, and confirm sudo works.

On the VPS as the non-root sudo user

sudo -iu deploy
sudo -v
whoami
pwd

You should remain on the server, whoami should return deploy, and sudo should accept your password. Do not disable root SSH access until this is verified.

Check interfaces, routes, and addresses

Most VPS network problems show up before you touch a firewall rule. Start with the interface table and the route the kernel actually uses.

On the VPS as root

ip addr show

Look for the primary interface, usually eth0, ens3, or something similar, and confirm it has the expected IPv4 and possibly IPv6 address.

ip route show

This shows the default gateway and the connected subnets. If the default route is missing, the VPS will usually respond only to local traffic.

ip -6 route show

This is the IPv6 equivalent. If your provider did not assign IPv6, an empty or minimal table is normal.

Test reachability from the server outward

Before you blame the provider, test the path from the VPS itself. That separates local routing problems from external filtering or DNS issues.

On the VPS as root

ping -c 4 1.1.1.1

This checks raw IPv4 connectivity. Successful replies mean the server can reach the internet at Layer 3.

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

This checks IPv6 reachability. If this fails while IPv4 works, your IPv6 route, prefix, or upstream filter needs attention.

apt update
apt install -y dnsutils iproute2 iputils-ping traceroute tcpdump nftables wireguard-tools

These tools are enough for route, DNS, packet, and WireGuard checks on Debian 12. The install is safe on a fresh system and does not change your network policy by itself.

Verify DNS before changing application ports

Many apparent connectivity failures are really name-resolution problems. Test name lookup directly from the VPS.

On the VPS as root

resolvectl status

If systemd-resolved is active, this shows the configured resolvers and per-link DNS settings.

dig +short example.com A
dig +short example.com AAAA

You should get IPv4 and IPv6 answers if the domain is published that way. If one record type is missing, application traffic that depends on it may fail.

getent ahosts example.com

This confirms the resolver path used by local programs. If dig works but getent does not, your libc or local resolver configuration needs review.

Inspect listening ports and confirm the service is actually up

When users cannot reach a service, the first question is whether anything is listening on the expected port. Use ss instead of guessing.

On the VPS as root

ss -tulpn

Look for your application or SSH on the expected ports. If you expect a web app on 8000, you should see a listener bound to that port.

systemctl --failed

This shows failed services that may have caused a port to disappear after boot or reload.

journalctl -p err -b

This surfaces boot-time errors, including binding failures, interface changes, and route loss.

Use packet captures to separate firewall issues from routing issues

A small capture often saves hours of guesswork. If packets do not arrive, the problem is upstream. If they arrive and leave but no reply comes back, the problem is local routing, firewall policy, or the application itself.

On the VPS as root

tcpdump -ni any port 22

Leave this running while you connect from your local computer. If you see SYN packets arrive but no reply leave, check firewall rules and SSH service health.

tcpdump -ni any host 1.1.1.1

This helps you see whether outbound traffic is leaving the server when you test with ping or curl.

Configure nftables safely on Debian 12

Debian 12 uses nftables cleanly. The goal here is to allow SSH and your application port without opening everything. Add the new rule set before you remove any older firewall state.

On the VPS as root

apt install -y nftables

If nftables is already installed, this is harmless. Next, create a basic policy that allows loopback, established traffic, SSH, and port 8000 for your application test.

cat > /etc/nftables.conf <<'EOF'
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    tcp dport 22 accept
    tcp dport 8000 accept
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
  }

  chain output {
    type filter hook output priority 0; policy accept;
  }
}
EOF

This file keeps inbound traffic tight while preserving SSH, ICMP diagnostics, and a temporary application port for testing.

nft -c -f /etc/nftables.conf

This syntax check must succeed before you load the rules. If there is an error, fix it now while your current SSH session is still open.

systemctl enable nftables
systemctl restart nftables
systemctl status nftables --no-pager

After restart, check that the service is active and the rules are loaded.

nft list ruleset

You should see the table and chain definitions you created.

If you are moving from a previous firewall tool, test the new policy before removing the old one. A safe rule change should never be the first and only copy of access.

Test SSH and port access from a client

Now verify the server from the outside. Keep the original root session open in case you need to reverse the firewall change.

On your local computer

ssh deploy@203.0.113.10

Replace the IP address with your actual server IP. If this fails, but local packet captures showed no SYN packets, the issue is upstream or DNS. If SYN packets arrived but no response came back, the firewall or SSH daemon is the likely culprit.

For a service on port 8000, check HTTP reachability from your local machine:

curl -I http://203.0.113.10:8000

A valid HTTP response proves the port is reachable end to end. If you see a timeout, check the firewall and the application listener.

Set up a small WireGuard test tunnel

WireGuard is useful when you need a private path for administration, database access, or migration work. This section creates a minimal tunnel between the VPS and your client. It is separate from your public SSH path and should be added, not substituted, for normal access.

On the VPS as root

umask 077
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub
wg genkey | tee /etc/wireguard/client.key | wg pubkey > /etc/wireguard/client.pub

This generates private and public keys for a simple two-peer test. The files are created with restrictive permissions because they contain secrets.

SERVER_PRIV=$(cat /etc/wireguard/server.key)
CLIENT_PUB=$(cat /etc/wireguard/client.pub)
cat > /etc/wireguard/wg0.conf <<EOF
[Interface]
Address = 10.44.0.1/24
ListenPort = 51820
PrivateKey = ${SERVER_PRIV}

[Peer]
PublicKey = ${CLIENT_PUB}
AllowedIPs = 10.44.0.2/32
EOF

This creates the server side of the tunnel. Replace nothing in the file if you paste it exactly as shown; the shell variables fill in the generated keys.

nft add rule inet filter input udp dport 51820 accept
wg-quick up wg0
systemctl enable wg-quick@wg0
wg show

Open UDP 51820 before starting the interface. wg show should list the interface and local keys. If the client has not been configured yet, the handshake will remain empty for now.

On your local computer

wg genkey | tee client.key | wg pubkey > client.pub

Use the client public key in the server config if you regenerate the keys. The matching client configuration should look like this:

[Interface]
PrivateKey = <contents of client.key>
Address = 10.44.0.2/24

[Peer]
PublicKey = <contents of /etc/wireguard/server.pub>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.44.0.0/24
PersistentKeepalive = 25

Replace the placeholders with your real key contents. After you import that profile, test the tunnel with:

ping -c 3 10.44.0.1

A successful reply confirms the private path is live.

Common failure patterns and exact diagnostics

These are the most likely issues on a Debian VPS after a network change.

• No SSH after firewall reload: check the current rules with nft list ruleset. If port 22 is missing, restore it with nft add rule inet filter input tcp dport 22 accept from the still-open root session.
• IPv4 works, IPv6 fails: run ip -6 route show and ping -6 -c 4 2606:4700:4700::1111. If there is no default route, the provider side may need a routed prefix or gateway correction.
• DNS works in dig but apps fail: compare getent ahosts example.com with resolvectl status. Local resolver settings or application-level DNS caching may be stale.
• Port is listening but unreachable remotely: use tcpdump -ni any port 8000 while testing from the client. If no packets arrive, the issue is upstream. If packets arrive and no response leaves, check nftables and the application binding address.

Rollback and recovery

If your new nftables policy causes trouble, restore access from the original root session first. Do not reboot and hope it fixes itself.

On the VPS as root

cp /etc/nftables.conf /etc/nftables.conf.bak
cat > /etc/nftables.conf <<'EOF'
flush ruleset
EOF
nft -c -f /etc/nftables.conf
systemctl restart nftables

This temporary recovery policy clears custom rules so you can regain access. Once you are back in control, reapply the safer rule set in smaller steps.

If WireGuard is the problem, stop it cleanly without touching SSH:

wg-quick down wg0
systemctl disable wg-quick@wg0

This removes the tunnel from boot and drops the interface.

Final verification from server and client

Finish by proving persistence. A network change is only complete when it survives a reboot and still accepts the expected traffic.

On the VPS as root

systemctl is-enabled nftables
systemctl is-enabled wg-quick@wg0
ss -tulpn | grep -E ':(22|8000|51820)\b'
reboot

After the reboot, reconnect and confirm the services are still enabled and the listeners are present. If you changed the firewall to support a permanent application, repeat the HTTP check from outside.

On your local computer

ssh deploy@203.0.113.10
curl -I http://203.0.113.10:8000
ping -c 3 10.44.0.1

If these return the expected responses, your Debian 12 network path is stable.

FAQ

Why does SSH still work locally but not from my laptop?
That usually means a firewall, routing, or upstream filtering issue. Compare tcpdump output on the VPS with your client connection attempt.

Should I open port 8000 permanently?
Only if the service truly listens there in production. Otherwise, put the app behind a reverse proxy and close the temporary test port once validation is complete.

How do I know if the IPv6 problem is mine or the provider’s?
Check ip -6 route show on the server and run an external IPv6 ping from the client side. Missing routes point to server config; missing replies with correct routes often point to the provider or an upstream ACL.

Can I use UFW instead of nftables on Debian 12?
You can, but Debian 12 works well with nftables natively. Pick one firewall system and keep the policy consistent.