Overview
Modern Linux networking tooling replaced the older ifconfig/netstat pair with ip and ss from the iproute2 suite, ip address/ip route manage interfaces and routing, while ss inspects sockets directly from kernel data structures with far more TCP state detail than netstat ever exposed. Understanding TCP socket states (LISTEN for a server waiting on a port, ESTABLISHED for an active two-way connection, TIME-WAIT during teardown) is usually the fastest way to diagnose "is this service actually up and bound where I expect." Firewalling has moved the same direction: nftables consolidates what used to be separate iptables/ip6tables/arptables tools into one framework, organizing rules into tables and chains, with a chain only doing anything once it's attached to a kernel hook like input, output, or forward.
Quick Reference
| Tool | Replaces | Purpose |
|---|---|---|
ip address / ip route | ifconfig, route | Manage interfaces, addresses, routing |
ss | netstat | Inspect sockets and connection states |
nft (nftables) | iptables, ip6tables, arptables | Unified packet filtering across address families |
| TCP state | Meaning |
|---|---|
LISTEN | Bound to a port, waiting to accept connections |
ESTABLISHED | Active, two-way connection to a specific peer |
TIME-WAIT | Connection closed, waiting to ensure delayed packets don't arrive |
Syntax
ip address show dev eth0 # show an interface's addresses
ss -tulpn # listening TCP/UDP sockets, with process namesExamples
# nftables - a table containing a chain hooked to "input", with
# one rule allowing established/related connections back in.
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; }
nft add rule inet filter input ct state established,related acceptA missing LISTEN socket is the fastest first diagnostic
If a service isn't reachable, check ss -tulpn for its expected port before anything else. No LISTEN entry means the process isn't running, crashed, or bound to a different address/port than expected, no firewall or routing investigation is relevant until that's confirmed.
Visual Diagram
Common Mistakes
- Reaching for
netstatout of habit whenssis the actively maintained tool with materially more socket detail available. - Assuming a connectivity problem is a firewall issue before checking whether the service even has a
LISTENsocket on the expected port. - Writing an nftables chain without attaching it to a hook, then being confused when its rules never seem to apply to any traffic.
- Duplicating similar rules across separate
ip/ip6address families out of oldiptables/ip6tableshabit, when a singleinetfamily table in nftables covers both.
Performance
ssreads kernel socket tables directly and is considerably faster on systems with a large number of open connections than parsing/procthe waynetstattraditionally did.- nftables' rule evaluation is generally more efficient than equivalent
iptablesrulesets at scale, since related rules can be organized into sets and maps the kernel can match more efficiently than a long linear rule chain.
Best Practices
- Default to
ipandssoverifconfig/netstat; they're the actively maintained tools and expose meaningfully more detail. - Check socket state (
ss -tulpn) before firewall rules when diagnosing "can't connect," it's the faster and more direct signal. - Organize nftables rulesets by address family (
inetfor both IPv4 and IPv6) instead of duplicating rules the old per-protocol way. - Always verify a new chain is attached to the correct hook and priority; a chain with no hook silently does nothing.