Networking: addresses, DNS and firewalls

Interfaces and routes, DNS resolution, the tools that prove where a connection dies, and firewall rules that do not lock you out.

Interfaces, routes and DNS

ip -br a                       # one line per interface: up/down plus address
ip a show eth0
ip -4 a
ip r                           # routing table; look for the default gateway
ip neigh                       # ARP/neighbour cache

nmcli device status
nmcli con show eth0
resolvectl status              # what systemd-resolved actually uses
cat /etc/resolv.conf           # often a stub pointing at 127.0.0.53
cat /etc/hosts                 # checked before DNS

Command	Answers
`ip -br a`	Which interfaces exist and what addresses they hold
`ip r get 1.1.1.1`	Which interface and source address a route would take
`ss -tulpn`	Which sockets are listening and which process owns them
`dig +short example.com`	Resolution result only, no commentary
`dig @1.1.1.1 example.com`	Query a specific resolver to separate DNS from network faults

dig example.com A +short
dig example.com MX
dig -x 203.0.113.10            # reverse lookup

getent hosts example.com       # the same path the application library uses
# getent honours /etc/hosts and NSS; dig does not - compare the two when they disagree

⚠️

On a remote server, add your firewall rule before enabling the firewall, and never flush the rule set over SSH. ufw allow OpenSSH (or firewall-cmd --add-service=ssh) first, then enable — otherwise your own session is the first thing the new policy blocks, and only out-of-band console access can undo it.

Proving where a connection dies

ping -c 3 1.1.1.1            # is there a path at all?
mtr -rwzc 20 example.com     # per-hop loss, better than a single traceroute
traceroute -T -p 443 example.com

curl -v https://example.com              # DNS, TCP, TLS and HTTP in one trace
curl -sS -o /dev/null -w '%{http_code} %{time_connect}s %{time_total}s\n' https://example.com
curl --resolve example.com:443:203.0.113.10 https://example.com   # test before DNS changes

sudo ss -tnp state established        # who is connected right now
sudo tcpdump -i any -nn port 443 -c 20

Connection refused means the packet arrived and nothing was listening; a firewall usually drops, which looks like a timeout instead.
A timeout can equally be the firewall, a dead service behind a load balancer, or a bad route. Test from the target host outward, then compare.
Check the application's own resolution path with getent hosts — caching layers and /etc/hosts frequently explain 'it works with dig but not with the app'.

Firewalls

# ufw (Debian/Ubuntu)
sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw allow from 10.0.0.0/8 to any port 5432 proto tcp
sudo ufw enable
sudo ufw status verbose
sudo ufw delete allow 443/tcp

# firewalld (RHEL family): permanent rules need a reload
sudo firewall-cmd --add-service=https
sudo firewall-cmd --add-service=https --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

# nftables, the modern back end under both front ends
sudo nft list ruleset
sudo nft add rule inet filter input tcp dport 443 accept

Layer	What it can see	Where the rule belongs
Cloud security group	Instance, before the OS	The provider console or Terraform
nftables / iptables	Packets, ports, interfaces, source addresses	The host itself
Application	User identity and request content	The service configuration
Container network	Container ports, not host ports	The compose or run flags

Docker and Podman insert their own chains. Rules you add for a published container port may sit in the wrong place — publish on 127.0.0.1 and let a reverse proxy own the public port.
Default-deny inbound with a short allow list is far easier to reason about than a long list of denies.
ufw status shows the effective policy; nft list ruleset shows what is really installed.

FAQ

The service is up locally but unreachable from outside. Where do I start?

In this order: is it listening on the right address (ss -tulpn — 127.0.0.1 is not reachable remotely), is the host firewall allowing it, is the cloud security group allowing it, and does the route to the host exist.

ping fails but the web application works?

ICMP is often blocked deliberately. Test the actual service port with curl or nc -vz host 443. Never use ping alone as evidence that a host is down.

systemd units and reading logs Performance triage and troubleshooting

Last refreshed 2026-09-18.

Networking: addresses, DNS and firewalls

Interfaces, routes and DNS

Proving where a connection dies

Firewalls

FAQ

Related