Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From infrastructure
Network infrastructure for self-hosted environments: VLANs, firewalls (nftables, OPNsense, pfSense), DNS (Pi-hole, AdGuard Home, split-horizon), reverse proxies (Caddy, Traefik, Nginx Proxy Manager), VPN (WireGuard, Tailscale), TLS/SSL certificate management, DHCP, and security hardening. Invoke when task involves any interaction with network configuration — designing, implementing, debugging, reviewing, or planning network architecture.
npx claudepluginhub xobotyi/cc-foundry --plugin infrastructureHow this skill is triggered — by the user, by Claude, or both
Slash command
/infrastructure:networkingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Security is a non-negotiable default, not an optional add-on. Every network design decision must account for trust
Reviews homelab VLAN segmentation, local DNS filtering, and WireGuard-style remote access before changing router, firewall, DHCP, or VPN configuration.
Provides expert guidance on cloud networking, load balancing, DNS, service discovery, SSL/TLS, and security for AWS, Azure, GCP, multi-cloud, and tools like Nginx, Envoy, Istio.
Configures pfSense firewall rules, NAT policies, VPN tunnels, and traffic shaping to enforce network segmentation, control traffic, and secure zones in enterprise/SMB networks.
Share bugs, ideas, or general feedback.
Security is a non-negotiable default, not an optional add-on. Every network design decision must account for trust boundaries.
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 mitigationfirewall-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 rulesdns-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 DNSreverse-proxy.md — Caddy, Traefik, Nginx Proxy Manager, Cloudflare tunnels: Caddyfile examples, Traefik Docker
labels, decision matrix, snippet patterns, tunnel patterns, auth proxy integrationvpn-tunnels.md — WireGuard, Tailscale, Headscale, site-to-site, HA with OSPF: config examples, topology comparison,
subnet router, hybrid WG+TS, HA failover with BIRD/OSPFtls-certificates.md — Let's Encrypt, ACME, wildcard certs, acme.sh: challenge types, ACME client comparison,
certificate storage patterns, TLS configsecurity-hardening.md — SSH, fail2ban, CrowdSec, IDS/IPS, monitoring, hardening: sshd_config, SSH CA, fail2ban vs
CrowdSec, Suricata IDS, Prometheus stack, monitoring metrics, IPv6 hardeningauth-proxies.md — Authelia, Authentik, forward auth, SSO patterns: Authelia vs Authentik comparison, ForwardAuth
with Traefik/Caddy, SSO/MFA patterns, deployment guidanceSeparate traffic into functional zones based on trust, not device count:
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.
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.
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:
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:
ct state established,related accept early in input/forward chains -- handles bulk of traffic efficientlyct state invalid packets explicitlypolicy drop on input and forward chains (default deny)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.counter on rules during development to verify traffic is hitting themnft list ruleset > /etc/nftables.conf, enable nftables.serviceGUI-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):
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.
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 is essential for IPv6 operation -- blocking all ICMPv6 breaks the network. Apply granular filtering:
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.
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.
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.
CrowdSec: Detection via YAML scenarios with leakspeed/capacity; community-shared threat data; Bouncers for remediation (firewall, Nginx, Traefik); configured via acquis.yaml + Hub collections.
Install CrowdSec collections from the Hub for specific services (SSH, Nginx, Suricata). Configure whitelists immediately to prevent banning your own IPs.
Suricata detects threats via packet inspection and logs to fast.log. CrowdSec parses these logs via acquis.yaml and
makes blocking decisions. This separates detection (Suricata) from remediation (CrowdSec bouncers) -- each tool does
what it does best.
Pi-hole and AdGuard Home are DNS sinkholes that block unwanted domains at the network level. Point DHCP-advertised DNS at the sinkhole.
Deploy redundant pairs on separate hosts for resilience. Sync blocklists between instances. Avoid using firewall-integrated DNS blocking plugins (e.g., pfBlockerNG) -- a core firewall update can silently break the plugin and kill all DNS resolution. Run DNS filtering as a separate service.
Return different DNS answers based on client network. Internal clients resolve to private IPs; external clients resolve to public IPs. Implementation:
*.example.com -> 192.168.1.100) for internal resolution to reverse proxymDNS (.local) is link-local and does not cross routed boundaries. Use Avahi with enable-reflector=yes to bridge mDNS
between specific VLANs (e.g., trusted LAN discovering IoT devices). Restrict interfaces -- never reflect to guest or
WAN.
Always encrypt DNS queries upstream (DNS over TLS or HTTPS) to prevent ISP snooping. Configure the recursive resolver to use encrypted upstream; serve plain DNS internally.
Single entry point for all HTTP/HTTPS services. Terminates TLS, routes by hostname, eliminates per-service port exposure.
| Factor | Caddy | Traefik | Nginx Proxy Manager |
|---|---|---|---|
| Config style | Caddyfile | YAML + Docker labels | Web UI |
| Auto HTTPS | Default behavior | Via cert resolvers | One-click |
| Docker-aware | Plugin | Native | No |
| Learning curve | Low | Medium | Lowest |
| Best for | Simple setups | Docker/K8s stacks | GUI preference |
Client --[HTTPS]--> Reverse Proxy --[HTTP]--> Backend Services
Only the reverse proxy needs TLS certificates. Backend services run plain HTTP on internal networks. One wildcard certificate covers all services.
Use DNS-01 ACME challenge for wildcard certs (*.example.com). Required for internal services not reachable from the
internet. Caddy and Traefik handle this natively with DNS provider plugins.
Both provide SSO and MFA for self-hosted services. Choose based on resource constraints and protocol needs:
Reverse proxies intercept requests and forward headers to the auth server before reaching the backend. Traefik uses
ForwardAuth middleware; Caddy uses similar mechanisms. The auth server validates the session and returns 200 (allow)
or 401 (redirect to login).
Gate user-facing services behind auth proxies. Keep admin panels (router, Proxmox, NAS) on VPN or management VLAN only -- do not expose through public auth proxies. Prefer phishing-resistant MFA (FIDO2/WebAuthn) over TOTP where possible.
Cloudflare Tunnels expose internal services without opening inbound ports. Useful behind CGNAT or when port forwarding
is impossible. The cloudflared daemon initiates outbound connections to Cloudflare's edge.
Internet -> Cloudflare Edge -> cloudflared -> Reverse Proxy -> Backend
Route tunnels into a local reverse proxy (Traefik/Caddy) for SSL termination and routing. Layer Authelia/Authentik or Cloudflare Access for identity gating.
A tunnel makes services accessible, not secure. Weak credentials, missing MFA, or unpatched software remain exploitable regardless of the tunnel.
Kernel-level VPN protocol. ~4,000 lines of code. Fast, simple, no cipher negotiation.
Mesh VPN built on WireGuard. Automatic key management, NAT traversal, DNS.
Hub-and-spoke has a single point of failure: if the hub goes down, the entire VPN is unreachable. Mesh (Tailscale) is resilient -- nodes remain connected to each other even if one fails. Choose topology based on failure tolerance, not just convenience.
Run both: Tailscale for day-to-day remote access (mesh, zero-config), WireGuard as backup VPN gateway for full-tunnel routing or when Tailscale's coordination server is unreachable.
Legacy. Slower, larger attack surface. Choose only when TCP-based tunneling is required to bypass UDP-blocking firewalls. For all new deployments, use WireGuard or Tailscale.
Free, automated certificate issuance. Certificates valid 90 days, renew at 60.
Challenge types:
Let the reverse proxy handle all certificate management. Caddy and Traefik do this automatically. For standalone cert management, use acme.sh (shell-only, no dependencies, many DNS providers).
Strict-Transport-Security: max-age=31536000; includeSubDomainssudoTrustUserCAKeys in sshd_config to
point at the CA public key.Deploy Prometheus + Grafana for network observability:
When designing network architecture: propose segmented designs with explicit trust boundaries. Default to security-first configurations. Present trade-offs between complexity and security.
When implementing configurations: produce production-ready config files, not toy examples. Include comments explaining non-obvious choices. Test connectivity after changes.
When debugging network issues: start at layer 2 (link/VLAN), work up through layer 3 (routing/firewall), then layer 7 (application/proxy). Check firewall deny logs first -- they reveal 80% of connectivity issues. Key tools:
ping / traceroute -- reachability and path verificationdig / nslookup -- DNS resolution from specific resolversss -tlnp / netstat -- listening ports and socket statetcpdump / tshark -- packet captures for traffic flow analysisnft list ruleset -- verify active firewall rules match intentavahi-browse -a -- verify mDNS discovery across VLANscurl -v -- HTTP/HTTPS connectivity with TLS detailsWhen reviewing network configurations: flag missing inter-VLAN firewall rules, default credentials, disabled encryption, overly permissive access, and missing monitoring. State what's wrong and how to fix it.
The containers skill covers Docker/Podman networking (bridge, host, macvlan). This skill covers the network infrastructure those containers sit on. When a task involves both container networking and VLAN/firewall design, both skills apply.
The ansible skill handles automation of network configuration deployment. Use this skill for what to configure, ansible for how to deploy it.
Security is not optional. Every default must be secure. Convenience follows.