networking

What this skill does

# Networking

Security is a non-negotiable default, not an optional add-on. Every network design decision must account for trust
boundaries.

## References

Extended configuration examples, comparison tables, and detailed patterns for the rules below live in
`${CLAUDE_SKILL_DIR}/references/`.

- `vlan-segmentation.md` — VLAN design, trunk/access ports, inter-VLAN policy, Layer 2 security: segment table, firewall
  rule matrix, hardware requirements, DHCP snooping, DAI, port security, L2 attack mitigation
- `firewall-rules.md` — nftables syntax, OPNsense/pfSense hardening, IPv6 firewall rules: chain types/hooks/priorities,
  connection tracking, NAT, rate limiting, sets/maps, ICMPv6 policy, dual-stack rules
- `dns-architecture.md` — Pi-hole, AdGuard Home, split-horizon, mDNS, Unbound, DoH/DoT: tool comparison, deployment
  patterns, Avahi reflector config, recursive vs authoritative, encrypted DNS, IPv6 DNS
- `reverse-proxy.md` — Caddy, Traefik, Nginx Proxy Manager, Cloudflare tunnels: Caddyfile examples, Traefik Docker
  labels, decision matrix, snippet patterns, tunnel patterns, auth proxy integration
- `vpn-tunnels.md` — WireGuard, Tailscale, Headscale, site-to-site, HA with OSPF: config examples, topology comparison,
  subnet router, hybrid WG+TS, HA failover with BIRD/OSPF
- `tls-certificates.md` — Let's Encrypt, ACME, wildcard certs, acme.sh: challenge types, ACME client comparison,
  certificate storage patterns, TLS config
- `security-hardening.md` — SSH, fail2ban, CrowdSec, IDS/IPS, monitoring, hardening: sshd_config, SSH CA, fail2ban vs
  CrowdSec, Suricata IDS, Prometheus stack, monitoring metrics, IPv6 hardening
- `auth-proxies.md` — Authelia, Authentik, forward auth, SSO patterns: Authelia vs Authentik comparison, ForwardAuth
  with Traefik/Caddy, SSO/MFA patterns, deployment guidance

## VLAN Segmentation

### Segment by Trust Level

Separate traffic into functional zones based on trust, not device count:

- **Management** (VLAN 10): Hypervisors, switches, routers, IPMI/iLO -- highest trust
- **Trusted/Lab** (VLAN 20): VMs, containers, workstation -- high trust
- **IoT** (VLAN 30): Smart devices, cameras, sensors -- low trust, restricted
- **Guest** (VLAN 40): Visitor devices -- zero trust, internet only
- **Storage** (VLAN 50): NAS, iSCSI, backup targets -- high trust, limited access
- **DMZ** (VLAN 99): Publicly exposed services -- medium trust, no inward access

Start with 3-4 VLANs. Add more only with a clear security or performance reason. Over-segmentation adds complexity
without proportional benefit. Separate production self-hosted services from experimental lab services -- prevent
experimentation from causing downtime for household-facing apps.

### Inter-VLAN Policy

VLANs without firewall rules provide zero security benefit. Every VLAN boundary needs explicit allow/deny policy.
Default deny between all VLANs, then explicitly allow required flows. Always permit established/related return traffic.

### Infrastructure Requirements

- Managed (VLAN-aware) switches with 802.1Q support
- Router/firewall capable of VLAN termination and inter-VLAN routing
- Access points with per-SSID VLAN tagging
- Set native VLAN on trunks to an unused VLAN (not VLAN 1)

## Firewalls

### nftables

Modern Linux firewall replacing iptables. Use `inet` family for dual-stack rules.

Core structure: **tables** contain **chains**, chains contain **rules**. Base chains attach to Netfilter hooks (`input`,
`forward`, `output`, `prerouting`, `postrouting`).

Minimal host firewall:

```nft
table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    ct state invalid drop
    iifname "lo" accept
    icmp type echo-request accept
    icmpv6 type { echo-request, nd-neighbor-solicit, nd-router-advert } accept
    tcp dport { ssh } accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
  }
  chain output {
    type filter hook output priority filter; policy accept;
  }
}
```

Key rules:

- Place `ct state established,related accept` early in input/forward chains -- handles bulk of traffic efficiently
- Drop `ct state invalid` packets explicitly
- Use `policy drop` on input and forward chains (default deny)
- Use `policy accept` on output chains (restrict outbound only when needed)
- `accept` is not final across chains -- later chains at the same hook still evaluate. `drop` is always final.
- Use `counter` on rules during development to verify traffic is hitting them
- Persist rules: `nft list ruleset > /etc/nftables.conf`, enable `nftables.service`

### OPNsense / pfSense

GUI-managed firewalls. Rules evaluate top-to-bottom, first match wins. Place more specific rules (e.g., block-LAN) above
general rules (e.g., allow-internet) -- rule ordering mistakes are the most common cause of VLAN isolation failures.

Post-install hardening (first 30 minutes):

1. Change default admin password
2. Enable 2FA (OPNsense: built-in; pfSense: package)
3. Disable web UI access from WAN
4. Configure DNS over TLS upstream
5. Enable automatic config backups
6. Restrict RFC1918 on WAN interface
7. Restrict DNS resolver to internal interfaces only (default allows queries from all interfaces -- open resolvers get
   abuse complaints)

OPNsense has faster security patches and built-in 2FA. pfSense has a larger community knowledge base. Security posture
depends more on configuration than platform choice.

Throughput problems after install: disable hardware offloading (CRC, TSO, LRO) first -- this is the most common culprit
in virtualized environments. If still slow, check IDS rulesets -- too many active rules kill performance. Start with 2-3
rulesets, add more only as needed.

## IPv6

### Dual-Stack Configuration

Run IPv4 and IPv6 concurrently. Dual-stack doubles the attack surface -- maintain identical security policies for both
protocols. Use `inet` family in nftables for rules that apply to both stacks; use `ip6` only for IPv6-specific rules
(ICMPv6, neighbor discovery).

### ICMPv6 Firewall Policy

ICMPv6 is essential for IPv6 operation -- blocking all ICMPv6 breaks the network. Apply granular filtering:

- **Must allow transit**: Destination Unreachable (Type 1), Packet Too Big (Type 2), Time Exceeded (Type 3) -- required
  for PMTU discovery and communication
- **Link-local only**: Router/Neighbor Solicitation and Advertisement (Types 133-136) -- critical for local discovery,
  must never cross network boundaries
- **Drop invalid**: Drop ICMPv6 from unexpected sources or with malformed headers

### Address Assignment

- **SLAAC**: Stateless, no server needed. Devices auto-configure from router advertisements. Simple but less control.
- **DHCPv6**: Stateful, centralized address management. Provides DNS server addresses. Use for servers requiring fixed
  addresses.
- **Privacy extensions**: Randomize interface identifiers to prevent tracking. Enable for external communications,
  disable internally (rotating addresses break logging and service correlation).

### DNS and IPv6

Add AAAA records only after IPv6 connectivity is verified and working. Premature AAAA records cause timeouts when IPv6
is not properly configured. In dual-stack environments, test both A and AAAA resolution paths.

## IDS/IPS

### Suricata

Network threat detection engine. Performs deep packet inspection and generates alerts based on rulesets. OPNsense
includes Suricata built-in; pfSense requires a package.

Performance impact: enabling 3 rulesets causes ~27% throughput drop. Start with 2-3 essential rulesets, add more only as
needed. Disable hardware offloading (CRC, TSO, LRO) first if throughput is poor -- offloading conflicts with packet
inspection.

### CrowdSec

Collaborative security engine that replaces or augments fail2ban. Key differences from fail2ban:

**fail2ban:** Detection via regex on local logs; local-only intelligence; iptables/nftables ban remediation; configured
via jail.conf.

**Crow