Networking basics
Guides for networking fundamentals: IPs, subnets, ports, firewall, DNS, and troubleshooting connectivity.
- easy 29
- medium 17
Easy
- How to allow a port safely
Allow inbound traffic to a specific port (e.g. 80, 443) without locking yourself out: allow your admin port (SSH) first, then allow the new port, and verify from a second session or after a short test. Use UFW, nftables, or iptables; document the rule so it can be audited. Use this when opening a service to the network.
- Client vs server networking
Clients initiate connections to a server's IP and port; servers listen on a port and accept connections. Learn the roles so you can configure listen addresses, firewall rules, and NAT correctly and debug 'connection refused' vs 'no route to host.' Use this when deploying or troubleshooting any service.
- Common firewall mistakes
Avoid locking yourself out, allowing too much, or misordering rules: allow SSH before enabling or before default deny; do not allow 0.0.0.0/0 to all ports; put allow before deny for the same traffic; allow established/related for outbound. Use this as a checklist so you do not repeat these errors when configuring host or network firewalls.
- DNS checklist
Use this checklist when configuring or troubleshooting DNS on a host: confirm nameservers in resolv.conf or the managing source, ensure resolvers are reachable, test with getent and dig, and allow DNS in the firewall if needed. Ensures resolution works for the system and applications. References DNS concept, test, and fix guides.
- How to check listening ports on Linux
List which ports are listening and which process owns them using ss or netstat. Use this to confirm a service is bound to the expected address and port, to find what is using a port, or to verify before opening a firewall. Use ss -tlnp for TCP and -ulnp for UDP.
- Firewall checklist
Use this checklist when enabling or changing a host firewall: allow SSH (or admin port) first, set default deny inbound, allow only required ports and established/related, verify rule order, test in a second session, and document rules. Avoid lockout and over-permissive rules by following the steps in order. References UFW, allow/deny, verify, and lock-down guides.
- Fix connection refused
Connection refused means the destination host received the connection attempt but no process is listening on that port (or the kernel rejected it). Find what should be listening, start the service or fix the port, and ensure the firewall is not dropping before the listener. Use this when you get 'Connection refused' for SSH, HTTP, or any TCP service.
- How UFW works (conceptual)
UFW (Uncomplicated Firewall) is a front end to iptables or nftables that uses allow/deny rules and a default policy. Learn how rules are ordered, how default deny works, and how to allow a port or subnet so you can use UFW correctly and avoid locking yourself out. Use this before enabling UFW on a server.
- How to inspect the routing table
View the kernel routing table with ip route or route -n so you can verify default route, directly connected networks, and static routes. Use this when debugging 'no route to host,' adding a new network, or confirming what path traffic will take. Interpret the output to see gateway and interface.
- IP addresses and CIDR notation
IPv4 addresses are 32-bit; IPv6 are 128-bit. CIDR (e.g. 192.168.1.0/24) denotes an address and its network prefix length so you can compute the network, broadcast, and host range. Use this when configuring interfaces, routing, or firewall rules that use subnets.
- Latency vs bandwidth vs packet loss
Latency is round-trip or one-way delay; bandwidth is throughput capacity; packet loss is the fraction of packets that do not arrive. Learn how each affects applications and how to measure them so you can diagnose slow or unreliable connections. Use this when tuning or debugging network performance.
- Network troubleshooting checklist
When connectivity fails, work through this order: link and IP, default route, DNS, service listening and firewall, then application. Use ping, ip route, getent/dig, ss and firewall rules to isolate whether the problem is local, path, or remote. References routing, DNS, ports, firewall, and fix guides so you do not guess at the wrong layer.
- Public vs private networks
Public IPs are globally routable on the internet; private IPs (RFC 1918) are for use inside a network and are not routed on the public internet. Learn the private ranges and why NAT is used so you can configure and debug connectivity between internal and external hosts. Use this when planning addressing or fixing 'no route' across the internet.
- Ports explained (1–65535, well-known vs ephemeral)
Ports are 16-bit numbers that identify which service or application gets traffic on a host. Learn well-known (0–1023), registered, and ephemeral (dynamic) ranges so you can open the right port, debug 'connection refused,' and understand listen vs connect. Use this when configuring firewalls or services.
- Routing basics
Routing is how a host or router decides where to send a packet: it consults a routing table (destination prefix and next-hop or interface) and forwards the packet. Learn how default route and longest prefix match work so you can fix 'no route to host' and configure gateways. Use this when a host cannot reach certain networks.
- Server networking checklist before go-live
Before putting a server in production, verify IP and DNS, routing, firewall, and SSH: static or DHCP, resolv.conf or resolved, default route, listening ports, firewall allow SSH and required services only, and a second session test. Use this so you do not ship with wrong IP, open ports, or locked-out SSH. References multiple networking-basics guides.
- Site-to-site vs client VPNs
Site-to-site VPNs connect two networks (e.g. office to cloud); client VPNs connect a single device to a network (e.g. laptop to corporate LAN). Choose site-to-site for always-on network links and client for remote users. Use this when designing or choosing VPN topology. Conceptual only; no vendor config.
- SSH tunnels explained
An SSH tunnel forwards a local or remote port over the SSH connection so you can reach a service as if it were on your machine or expose a local service through the SSH server. Use for one-off secure access to a single port (e.g. DB, admin UI) without a full VPN. Conceptual only; assumes you can SSH to the target host.
- Subnets explained simply
A subnet is a logical subdivision of an IP network defined by a prefix (CIDR). Learn how subnetting splits address space, why you use it for organization and routing, and how to derive the range and size from the prefix. Use this when planning or changing network layout.
- How to test DNS resolution
Verify that hostnames resolve to the expected IPs using getent, dig, or nslookup. Use this when debugging 'can't reach host,' after changing resolvers or DNS records, or to confirm split-horizon or override. Test both the name and the reverse (IP to name) if needed.
- TCP vs UDP and when to use each
TCP is connection-oriented and reliable; UDP is connectionless and low-overhead. Learn the trade-offs so you can choose the right transport, debug timeouts vs packet loss, and configure firewalls and services correctly. Use this when designing or troubleshooting protocols and ports.
- How to verify firewall rules
Confirm that the firewall is active and that rules match your intent: list rules (ufw status, nft list ruleset, iptables -L), test connectivity from a client (nc, curl, telnet), and compare with what should be allowed or denied. Use this after changing rules or before go-live so you do not ship with wrong or missing rules.
- What DNS actually does
DNS maps hostnames to IP addresses and back. Learn how queries and responses work, what resolvers and authoritative servers do, and when DNS is the cause of 'can't reach host' or slow connections. Use this before debugging connectivity or configuring resolvers.
- What a firewall actually does
A firewall filters packets by rules (source, destination, port, protocol) and allows or drops them. It can be on the host (host firewall) or on a network device. Learn how allow and deny work, stateful vs stateless, and where to place rules so you can configure and debug access. Use this before opening or closing ports.
- What a VPN actually is
A VPN is an encrypted tunnel between endpoints so traffic appears to come from the tunnel exit. It provides confidentiality, integrity, and often a different IP or network path. Use when you need private access to a remote network or to carry traffic over untrusted networks; do not rely on it alone for anonymity. This guide is conceptual only; no vendor config.
- When you do NOT need a VPN
A VPN is not always the answer. Skip it when traffic is already encrypted (e.g. HTTPS to a public API), when the problem is DNS or firewall policy, when you only need a single port (SSH tunnel may suffice), or when you are on a trusted network. Use this to avoid over-engineering and to pick the right tool. Conceptual only.
- Network debugging methodology
When connectivity fails, work through layers in order: link and IP, routing, DNS, then service and firewall. Use ping, ip route, getent/dig, and ss/firewall rules to isolate the failure so you fix the right layer instead of guessing. Use this as the standard order for any network troubleshooting.
- DNS debugging methodology
When resolution fails, isolate the problem: check local resolver config, then query a specific server, then check network path to the server. Use dig, getent, and nslookup in a consistent order so you know whether the issue is config, server, or network. Use this when name resolution fails and you need to find the cause quickly.
- traceroute explained (how it works and how to use it)
traceroute shows the path packets take to a destination by using TTL expiry or ICMP/UDP probes. Use it to see where a path fails or which hop adds latency. Use this when debugging connectivity or path issues and when you need to interpret traceroute output.
Medium
- How to deny traffic safely
Deny specific traffic (by port, source, or protocol) without breaking admin access or established connections. Add deny rules after allow rules for required traffic; use default-deny for inbound when possible. Use this when you need to block a port or a hostile source while keeping the host manageable.
- How to change a system IP address
Change the IP address of a Linux host by updating netplan, NetworkManager, or /etc/network/interfaces, then applying the config and optionally restarting networking. Use a temporary change with ip addr to test before making it persistent. Have console access if changing the address you are connected from. Use this when renumbering or moving a host to another subnet.
- How to diagnose no internet access
When a host cannot reach the internet: check default route, DNS resolution, and connectivity to the gateway and a public IP. Use ping, ip route, getent, and traceroute to isolate whether the failure is routing, DNS, or local firewall. Use this before changing config so you fix the right layer.
- How to enable or disable IPv6
Enable or disable IPv6 on Linux via sysctl (net.ipv6.conf.all.disable_ipv6 and per-interface), netplan, or NetworkManager. Use this when you need to turn off IPv6 for compatibility or security, or to turn it back on after it was disabled. Test with ping6 and ip -6 addr.
- How to configure a static IP
Set a static IPv4 address on Linux using netplan, NetworkManager, or /etc/network/interfaces. Include address, prefix length, default gateway, and nameservers so the host has stable addressing and can reach other networks and resolve names. Use this when deploying a server or when DHCP is not desired.
- How to fix broken DNS on Linux
When resolution fails on Linux: fix /etc/resolv.conf or the source that manages it (netplan, NetworkManager, systemd-resolved). Ensure nameservers are reachable and that firewall allows outbound DNS. Use this when getent or dig fails and you need the system to resolve names again.
- Fix no route to host
No route to host means the host has no route to the destination (or the destination is down/unreachable). Check the routing table, default route, and that the destination or gateway is reachable. Use this when you get 'No route to host' or 'Network is unreachable' so you can fix routing or connectivity.
- iptables explained conceptually
iptables is the legacy Linux packet filter: tables (filter, nat), chains (INPUT, OUTPUT, FORWARD), and rules (match criteria and target accept/drop/reject). Learn the model so you can read rules and understand how UFW or other tools map to it. Prefer nftables or UFW for new config. Use this when debugging or migrating from iptables.
- Lock down a server to SSH only
Restrict inbound host firewall access to SSH (and optionally a management port) so no other services are reachable from the network. Use default-deny inbound and allow only TCP 22 (or your SSH port); allow established/related for outbound. Use this as a baseline for minimal exposure before adding other services.
- NAT explained
NAT (Network Address Translation) rewrites source or destination IP and port so many hosts can share one public IP or so internal addresses are hidden. Learn how outbound NAT (SNAT/NAPT) and port forwarding (DNAT) work so you can debug connectivity and configure routers. Use this when traffic from or to a private network fails.
- nftables explained conceptually
nftables is the modern Linux packet filter: tables, chains, and rules in a unified syntax. It replaces iptables and can translate iptables rules. Learn the model (table, chain, rule) and how to read nft list ruleset so you can verify rules and migrate. Use this when configuring or debugging nftables or when moving from iptables.
- How to restart networking safely
Restart networking on Linux without losing SSH by using systemd to restart the networking service or NetworkManager, or by bringing interfaces down and up. Prefer restarting only the affected service; have console or out-of-band access in case the session drops. Use this after changing IP, DNS, or routes so the new config is applied.
- Reverse SSH tunnels explained
A reverse SSH tunnel lets a host behind NAT or a firewall initiate an SSH connection to a reachable server and expose a port on that server that forwards back to the host. Use when the target host cannot accept inbound connections (e.g. no public IP, firewall blocks). Conceptual only; server must allow remote forwards.
- How to troubleshoot SSH connectivity
When SSH connection fails: check that the client can reach the host (ping, port open), that sshd is listening on the expected port, and that authentication succeeds (key or password). Use this to isolate network vs service vs auth failures and to fix 'connection refused,' 'no route to host,' or 'permission denied.'
- WireGuard concepts (no vendor config)
WireGuard is a simple, fast VPN: each peer has a key pair and an allowed-IPs list that acts as both routing and ACL. Tunnels are stateless; crypto is modern. Use this to understand the model (peer, allowed-IPs, no central server required) before deploying. Conceptual only; no step-by-step vendor or distro-specific config.
- MTU and fragmentation explained
MTU is the maximum size of a packet on a link; larger packets may be fragmented or dropped. Use this when you see connectivity that works for small packets but fails for large (e.g. large uploads or specific sites) or when tuning performance and path MTU.
- Packet flow basics (how traffic moves through a host)
Understand how packets are processed: interface, routing, firewall (input/output/forward), and application. Use this when debugging why traffic is dropped or a service is not reachable so you check the right layer.