Networking: Configuration, Troubleshooting, and Optimization

Configure, troubleshoot, and optimize Linux networking infrastructure. Covers DNS, reverse proxies, VPNs, firewalls (nftables), VLANs, subnetting, high availability, dynamic routing, and network performance tuning.

Target versions (May 2026):

When to use

• Configuring DNS servers (Unbound, CoreDNS, dnsmasq, BIND9, Pi-hole, AdGuard Home)
• Setting up or troubleshooting reverse proxies and load balancers
• VPN configuration (WireGuard, OpenVPN, IPsec) and overlay networks
• Linux firewall rules (nftables, legacy iptables)
• VLAN configuration, subnetting, network segmentation
• High availability with keepalived/VRRP, floating IPs
• Network diagnostics (tcpdump, mtr, ss, dig, iperf3, Wireshark/tshark)
• TCP/network performance tuning (MTU, buffers, congestion control, bufferbloat)
• Dynamic routing with FRRouting (BGP, OSPF)
• TLS/certificate management for network services
• Split-horizon DNS, DNS-over-HTTPS/TLS, DNSSEC

When NOT to use

• OPNsense/pfSense firewall appliance management (use firewall-appliance)
• Web browsing, scraping, or headless page interaction - use browse
• Kubernetes networking: NetworkPolicy, Gateway API, service mesh, CNI (use kubernetes)
• Broad Kubernetes cluster health checks, node status, and post-maintenance diagnostics (use cluster-health)
• Docker/container networking: bridge, overlay, Compose networks (use docker)
• Cloud VPCs, security groups, managed load balancers (use terraform)
• Network config management at scale via playbooks (use ansible)
• Offensive pentesting, exploitation, lateral movement (use lockpick)
• Application-level security review, SSRF, header injection (use security-audit)
• CI/CD-automated network configuration management at pipeline scale (use ci-cd)

AI Self-Check

Before returning any generated network configuration, verify:

• No hardcoded secrets: passwords, PSKs, API keys use placeholders or env vars
• Correct interface names: didn't assume eth0 - modern Linux uses predictable names (enp0s3, ens18, etc.). Ask or check ip link output
• MTU considered: VPN tunnels need reduced MTU (WireGuard: 1420, OpenVPN: ~1400, VXLAN: 1450). Mismatched MTU causes silent packet drops
• DNS resolver order: systemd-resolved vs /etc/resolv.conf vs NetworkManager - check which DNS manager is active before modifying
• Firewall persistence: nftables rules need nft list ruleset > /etc/nftables.conf or a service to persist across reboots. Raw nft add commands are ephemeral
• Port conflicts checked: reverse proxy ports (80, 443) may conflict with existing services. Verify with ss -tlnp
• TLS versions: minimum TLS 1.2 for all services. TLS 1.3 preferred where supported
• Private IP ranges correct: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (not /24)
• Subnet overlap: VPN address ranges must not overlap with LAN or other VPN ranges
• IPv6 considered: dual-stack config or explicit disable. Half-configured IPv6 leaks traffic around IPv4-only VPNs
• Backup before modifying: save current config before changes (nft list ruleset > backup.nft, cp nginx.conf nginx.conf.bak). Network misconfigs can lock out remote access
• Service reload vs restart: prefer graceful reload (nginx -s reload, systemctl reload) over restart to avoid dropping active connections
• IP forwarding enabled: any config involving routing, VPN, or inter-VLAN traffic needs net.ipv4.ip_forward = 1 (and net.ipv6.conf.all.forwarding = 1 for dual-stack). Without it, the kernel silently drops forwarded packets
• systemd-resolved conflict: if deploying a local DNS server (Unbound, CoreDNS, dnsmasq), check whether systemd-resolved is binding port 53. Disable its stub listener (DNSStubListener=no) or bind your server to a different port
• Current source checked: dated versions, CLI flags, API names, and support windows are verified against primary docs before repeating them
• Hidden state identified: local config, credentials, caches, contexts, branches, cluster targets, or previous runs are made explicit before acting
• Verification is real: final checks exercise the actual runtime, parser, service, or integration point instead of only linting prose or happy paths
• Routing overlap checked: overlapping skills, trigger terms, and "When NOT to use" boundaries are checked before returning guidance
• Spec claims verified: claims about tool behavior, output contracts, or repo conventions are checked against current docs, scripts, or skill files
• Topology verified: interface names, routes, DNS resolvers, namespaces, VPN state, and firewall backend are observed before changes
• Rollback path preserved: remote network changes include timed rollback, console access, or an alternate path

Performance

• Measure path, DNS, TLS, and application latency separately before tuning.
• Use packet captures with narrow filters and time windows to avoid huge captures and privacy spill.
• Prefer persistent nftables sets, DNS caches, and proxy connection reuse where appropriate.

Best Practices

• Diagnose before changing: capture current routes, rules, addresses, and resolver state.
• Change one layer at a time: DNS, routing, firewall, proxy, VPN, or application.
• Keep emergency access open when editing firewall, VPN, or default-route configuration remotely.

Workflow

Step 1: Identify the task type

Step 2: Gather context

Before writing config or running commands:

1. What distro and init system? (systemd vs OpenRC - affects service management)
2. What's the current network state? (ip addr, ip route, ss -tlnp, resolvectl status)
3. Is there an existing firewall? (nft list ruleset, iptables-save)
4. Who manages DNS? (resolvectl status or cat /etc/resolv.conf - check for systemd-resolved stub)
5. Any existing VPN/overlay? (wg show, tailscale status, ip link for tun/wg/vxlan devices)
6. Is this behind NAT? (affects VPN, reverse proxy, and HA design)

Step 3: Implement

Read the appropriate reference file for detailed patterns