--- pageType: source id: source.pihole-blocker title: pihole-blocker sourceType: local-file sourcePath: /home/topher/.openclaw/workspace-crash-bot/projects/pihole-blocker.md ingestedAt: 2026-05-02T21:18:27.608Z updatedAt: 2026-05-02T21:18:27.608Z status: active growth: sprout --- # pihole-blocker ## Source - Type: `local-file` - Path: `/home/topher/.openclaw/workspace-crash-bot/projects/pihole-blocker.md` - Bytes: 16974 - Updated: 2026-05-02T21:18:27.608Z ## Content ````text # Pi-hole Blocker Project **Status:** Planning / Not started **Thread:** #pihole **Hardware:** Seeed Studio Dual-GbE Carrier Board with 4GB RAM + 32GB eMMC (CM4) **URL:** https://www.seeedstudio.com/Dual-GbE-Carrier-Board-with-4GB-RAM-32GB-eMMC-RPi-CM4-Case-p-5029.html --- ## ⚠️ Project Scope Expanded (2026-04-17) This project has evolved from a simple Pi-hole DNS ad-blocker into a **full DIY router/firewall** for the home network. The FCC's March 2026 ban on new foreign-made consumer routers and concerns about closed-source router firmware (eeros) drove the decision to make the CM4 the network brain. **New target architecture:** ``` Modem → CM4 (router/firewall/DNS/VPN/DHCP) → Switch → eeros (bridge mode, WiFi only) → Devices ``` The eeros become dumb WiFi access points. The CM4 handles everything else. --- ## Decision Log ### 2026-04-17 — Architecture Revision (Full Router Mode) **Changed from:** Option 1 (DNS redirect only, eeros as router) **Changed to:** Option 3 (CM4 as full router/firewall, eeros in bridge mode) **Drivers:** - FCC foreign router ban (March 2026) makes closed-source router future uncertain - Desire for router-level VPN (protect all devices without client software) - eeros as black-box devices on network — want to contain their visibility - Full control over DHCP, firewall, DNS — architectural self-defense **Software stack confirmed:** Raspberry Pi OS Lite (NOT OpenWrt) - Pi-hole needs full Linux (systemd, dnsmasq) — won't run on OpenWrt - Pi OS gives Time Machine support (OpenWrt can't do this easily) - Manual iptables/nftables for firewall (learning value > GUI) - WireGuard VPN restored (router-level VPN is a different use case than Tailscale per-device) **pfSense/OPNsense rejected for CM4:** Both are amd64/x86-64 only. No ARM builds exist. Intel N100 firewall boxes ($150-200) are the hardware swap option if x86 is needed later. **OpenWrt considered but rejected:** Its built-in `adblock` package works functionally but lacks Pi-hole's web UI, query logs, and per-client breakdown. Pi OS + Pi-hole = better for a learning/demo environment. ### 2026-04-04 — Initial Research **Hardware selected:** CM4 with dual GbE + eMMC (no SD card!) **Chosen approach:** Raspberry Pi OS Lite + Pi-hole (manual install) - Full control - Well-documented - eMMC more reliable than SD - Dual GbE enables passthrough or bridge mode **Rejected:** - Pre-built images (outdated, inflexible) - DietPi (good but less common for troubleshooting) - Docker (overkill for dedicated hardware) --- ## TODO (When Ready) - [ ] Flash Raspberry Pi OS Lite (64-bit) to eMMC - [ ] Enable SSH, set hostname before first boot - [ ] First boot + network config - [ ] Install Pi-hole: `curl -sSL https://install.pi-hole.net | bash` - [ ] Configure upstream DNS (Cloudflare/Google/Quad9) - [ ] Decide network mode: passthrough vs bridge vs VLAN - [ ] Point router DNS to Pi-hole IP - [ ] Test + document --- ## Network Config Notes (Dual GbE) **Goal:** Transparent filtering for entire network ### Option 1: Single Port + Router DNS Redirect (Recommended) ⭐ ``` Modem → Existing Router → Pi-hole (eth0 only) → All devices ↳ Time Machine (same port) ``` **How:** Router forces all port 53 traffic to Pi-hole IP **Pros:** - Simplest setup - Existing router handles DHCP/NAT (less to break) - Time Machine works on same network - Dual GbE not needed, but harmless **Cons:** - Devices can bypass with hardcoded DNS (8.8.8.8) - Router must support DNS redirect/forced DNS **Best for:** Most home setups, transparent operation --- ### Option 2: Bridge Mode (Dual GbE Active) ``` Router → eth0 ─┬─ Pi-hole (bridged) ─┬─ eth1 → Switch/House └─ Time Machine share ─┘ ``` **How:** Both ports bridged at OS level, Pi acts as Layer 2 device **Pros:** - All traffic passes through (harder to bypass) - Time Machine visible to all devices - Existing router still handles DHCP/NAT **Cons:** - More complex network config (bridge interfaces) - Pi becomes network dependency (if it dies, network dies) **Best for:** Maximum coverage, willing to troubleshoot bridging --- ### Option 3: Full Inline Router (Dual GbE) ``` Modem → eth0 (WAN) → Pi-hole routes/NAT → eth1 (LAN) → House ↳ Time Machine on LAN side ``` **How:** Pi replaces your router entirely **Pros:** - Complete control, can't bypass - Full firewall/NAT control - True network segmentation possible **Cons:** - Most complex (DHCP, NAT, firewall rules) - Single point of failure - Time Machine only visible to LAN side - Need to reconfigure entire network **Best for:** Advanced users, want full network control --- ## Decision Log ### 2026-04-04 — Final Decisions **Network Mode:** REVISED — Option 3 (Full Inline Router) ⭐ - CM4 replaces eeros as router/firewall - eeros go into bridge mode (WiFi access points only) - Phased rollout (see Phased Implementation Plan below) - Original Option 1 (DNS redirect) is Phase 1 only **Add-ons Confirmed:** - ✅ Pi-hole (DNS ad-blocking) - ✅ Unbound (recursive DNS, privacy) - ✅ Time Machine (Mac backups via Samba + Avahi) - ✅ Wireshark/tcpdump lab (packet capture for learning) - ✅ WireGuard VPN — RESTORED (router-level VPN for all devices, see VPN section) - ✅ iptables/nftables firewall (NAT, port forwarding, kill switch) - ✅ DHCP server (dnsmasq or isc-dhcp-server) - ✅ VLAN support (isolate WiFi/IoT from trusted wired devices) **Location:** HOME (separate from brewery setup) **Dual GbE Verdict:** NOT overkill — enables bridge mode for packet capture learning lab 🎓 **Rejected:** - Pre-built Pi-hole images (outdated, inflexible) - DietPi (less common for troubleshooting) - Docker (overkill for dedicated hardware) - OpenWrt as OS (Pi-hole can't run on OpenWrt natively; Pi OS + manual firewall gives more flexibility) - pfSense/OPNsense (amd64 only — no ARM support, won't run on CM4) - Intel N100 firewall box (considered as hardware swap, decided to stick with CM4) **Software stack:** Raspberry Pi OS Lite (not OpenWrt) — gives full Pi-hole, Time Machine, Linux CLI for lab, and manual firewall/routing via iptables --- ## Phased Implementation Plan (2026-04-17) ### Phase 1: Pi-hole + Time Machine (alongside existing eeros) - Flash Pi OS Lite to eMMC - Install Pi-hole, Unbound - Set up Time Machine (Samba + Avahi) - eeros stay as router, DNS redirect to Pi-hole - **Goal:** Get the box running, learn the hardware ### Phase 2: Router Mode (weekend test) - Enable IP forwarding on CM4 - Set up iptables NAT + firewall rules on CM4 - Configure DHCP server on CM4 - Put eeros into bridge mode - **CM4 eth0 = WAN (modem), CM4 eth1 = LAN (switch → eeros)** - Test thoroughly — keep rollback plan ready ### Phase 3: VPN + Hardening - Install WireGuard, configure full/split tunnel VPN - Add kill switch (iptables rule to block non-VPN outbound) - Set up DNS hijacking (DNAT port 53 → Pi-hole) - Monitor eero traffic with tcpdump - **Goal:** Privacy layer + containment of eeros as black-box devices ### Phase 4: VLAN Isolation (optional, advanced) - 802.1Q VLANs on CM4 - VLAN 1: Trusted (wired devices, Time Machine) - VLAN 2: WiFi/IoT (all eero-connected devices) - Firewall rules between VLANs - **Goal:** Even if eero firmware is compromised, it can't see trusted LAN traffic --- ## Router-Level VPN (2026-04-17) **Why:** All traffic from every device on the network gets VPN protection without installing VPN clients on individual devices. ISP/eeros only see encrypted packets going to a VPN endpoint. **Architecture:** ``` Devices → eeros (WiFi) → CM4 (Pi-hole DNS first, then VPN tunnel) → Internet ``` Pi-hole resolves DNS locally (ad blocking), then clean requests go through WireGuard tunnel. ### VPN Provider Options | Option | Cost | Protocol | Notes | |--------|------|----------|-------| | **Mullvad** ⭐ | €5/mo | WireGuard | Gold standard. No account/email needed. Audited no-logs. | | **ProtonVPN Free** | Free | WireGuard | No data cap, 5 countries. Good for testing. | | **ProtonVPN Plus** | $10/mo | WireGuard | More servers, Secure Core routing. | | **Self-hosted VPS** | $3-6/mo | WireGuard | Full control, you're the admin. | | **Windscribe Free** | Free (10GB/mo) | WireGuard | Budget test option. | **Recommendation:** Start with ProtonVPN Free to test, move to Mullvad for production. ### Setup Commands ```bash # Install WireGuard sudo apt install wireguard # Drop in VPN config sudo nano /etc/wireguard/wg0.conf # NAT for VPN tunnel sudo iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE sudo iptables -A FORWARD -i eth1 -o wg0 -j ACCEPT sudo iptables -A FORWARD -i wg0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT # Bring up sudo wg-quick up wg0 sudo systemctl enable wg-quick@wg0 ``` ### Kill Switch (prevent leaks if VPN drops) ```bash sudo iptables -A FORWARD -i eth1 ! -o wg0 -j DROP ``` ### Split vs Full Tunnel | Mode | VPN'd | Not VPN'd | Use | |------|-------|-----------|-----| | **Split** | Web browsing | Local/Time Machine | Start here. Less latency. | | **Full** | Everything | Nothing | Max privacy. More latency. | --- ## eero Bridge Mode — Security Considerations (2026-04-17) ### What eeros CAN see in bridge mode - Broadcast/multicast traffic (ARP, mDNS, DHCP requests) - MAC addresses of all devices - Unencrypted (HTTP) traffic — rare now - Frame-level metadata (who talks to who) ### What eeros CAN'T see in bridge mode - DNS queries (handled by Pi-hole on CM4) - HTTPS content (encrypted end-to-end) - VPN traffic (double-encrypted) - Routing decisions (CM4 handles) ### Threat Model | Threat | Severity | Mitigation | |--------|----------|------------| | Firmware eavesdropping | Medium | Monitor eero traffic via tcpdump on CM4 | | Remote management backdoor | Medium | Firewall eero management traffic, block firmware update IPs | | DNS exfiltration | Low | DNAT port 53 redirect to Pi-hole | | Full compromise | High | VLAN isolation (Phase 4) | ### Best Mitigation: VLAN Architecture ``` CM4 eth1 → VLAN 1 (Trusted - wired devices) → VLAN 2 (WiFi/IoT - eeros only) ``` Even a fully compromised eero can only see VLAN 2 traffic. Trusted wired devices are invisible. --- ## FCC Router Ban — Strategic Context (2026-04-17) **March 2026:** FCC added all foreign-made consumer routers to its Covered List. No new foreign-made router models can receive FCC authorization for sale in the US. - Existing routers: Still legal to own and use - Firmware updates: Waivered until March 1, 2027 (uncertain after that) - New models: Banned unless manufactured domestically - US-branded routers (eero, Netgear, Ubiquiti): Also affected — they're all made in Asia **Why this matters for this project:** - eeros may stop receiving firmware updates after March 2027 - Building your own router on open hardware sidesteps the entire regulatory issue - CM4 carrier board is a development board, not a consumer router — different FCC category - You control the software pipeline, not dependent on any manufacturer - This ban may be less about security and more about forcing onshore manufacturing where US legal jurisdiction (CALEA, FISA, NSLs) applies **Conclusion:** Rolling your own router isn't just a fun project — it's architectural self-defense against a future where consumer routers are increasingly subject to government access frameworks. --- ## Learning/Lab Use Cases (Dual GbE Bonus!) ### Packet Capture & Analysis (Wireshark/tcpdump) **Bridge mode = perfect learning lab:** ``` Router → eth0 → Pi (bridged) → eth1 → House ↓ Full packet capture ``` **What you can learn:** - Wireshark filters and display rules - Protocol analysis (DNS, HTTP, SMB, etc.) - Network troubleshooting - Security analysis (spot suspicious traffic) - IoT device behavior (what's my Roomba actually doing?) **Tools to install:** - `wireshark` (GUI, needs X11/VNC) or `tshark` (CLI) - `tcpdump` (lightweight CLI capture) - `nethogs` (bandwidth by process) - `iftop` / `ntopng` (real-time traffic visualization) **Example commands:** ```bash # Capture all traffic on eth0 sudo tcpdump -i eth0 -w capture.pcap # Live DNS query monitoring sudo tshark -i eth0 -Y "dns" -T fields -e dns.qry.name # Real-time bandwidth by host sudo nethogs -t -c 5 eth0 ``` **Privacy note:** You'll see EVERYTHING on your network — passwords in plaintext (HTTP), browsing history, device fingerprints. Great for learning, serious responsibility. --- ### Other Lab Scenarios | Scenario | Setup | Learning Value | |----------|-------|----------------| | **Network segmentation** | VLANs on dual NIC | Enterprise networking | | **Firewall rules** | iptables/nftables | Security hardening | | **QoS testing** | Traffic shaping | Bandwidth management | | **MITM analysis** | ARP spoofing detection | Security awareness | | **Service monitoring** | Port scanning, service discovery | Network mapping | --- **Verdict:** Dual GbE is NOT overkill if you want a learning lab. Bridge mode + packet capture = home network university. 🎓 --- ## Add-on Modules (Optional) ### Confirmed Interest (2026-04-04) | Add-on | Purpose | Notes | |--------|---------|-------| | **Time Machine Target** | Network backup for Macs | Samba + Avahi, ~50MB RAM | | **Grafana + TILT Data** | Fermentation visualization | Pipe TILT data → InfluxDB → Grafana | | **Fire Stick Display** | Brew house monitoring screen | Display Grafana dashboard on Fire Stick | ### Architecture Clarification (2026-04-04) **Location split:** - **Pi-hole CM4:** HOME (with dual GbE) - **TILT Bridge:** BREWERY (ESP32) - **Home Assistant:** BREWERY (separate instance) - **Fire Stick:** BREWERY (display) **Implication:** TILT data already lives at brewery HA. Fire Stick should just display brewery HA directly! ### Simplified Brew House Display ``` TILT → ESP32 Bridge → Brewery HA → Fire Stick (kiosk browser) ``` **No need to pipe to home!** Fire Stick points at `http://brewery-ha:8123/lovelace/fermentation-dashboard` ### Home Pi-hole Box Add-ons (Final) | Add-on | Purpose | Priority | |--------|---------|----------| | Pi-hole | DNS ad-blocking | Core | | Unbound | Recursive DNS (privacy) | High | | Time Machine | Mac backups | High | | Wireshark/tcpdump | Packet capture lab | Medium (learning) | | Grafana (home metrics) | Network monitoring | Low (optional) | --- ## Time Machine Backup — Detailed Specs ### Requirements | Item | Details | |------|---------| | **OS** | Raspberry Pi OS Lite (any version) | | **Services** | Samba (SMB), Avahi (mDNS/Bonjour) | | **Storage** | USB drive (SSD recommended) or network share | | **RAM** | ~50MB overhead | | **CPU** | Minimal (compression is client-side) | ### How It Works ``` Mac → Bonjour discovery (Avahi) → Samba share → USB drive on Pi ``` 1. Avahi advertises `_adisk._tcp` service (Mac sees it as Time Machine destination) 2. Samba provides SMB share with Time Machine extensions 3. Mac backs up over network automatically --- ### Limitations | Limitation | Impact | Workaround | |------------|--------|------------| | **Network speed** | First backup slow (hours), subsequent faster | Use Ethernet, not WiFi | | **USB drive speed** | HDD = slow, SSD = fast | Use SSD for better experience | | **Single user** | One Mac per sparsebundle (by default) | Can configure multi-user but tricky | | **Backup size** | Limited by USB drive capacity | Use large drive (1TB+ recommended) | | **No encryption** | Backups unencrypted on disk | Enable FileVault on Mac instead | | **Pi must be on** | No backup if Pi is off | Set static IP, ensure uptime | --- ### Nice-to-Haves | Feature | Why | How | |---------|-----|-----| | **SSD storage** | 10-20× faster than HDD | USB 3.0 SSD enclosure | | **Dedicated partition** | Isolate backups from OS | Separate USB drive or partition | | **Backup quotas** | Prevent one Mac from filling drive | `tmutil` setquota per Mac | | **Auto-mount** | Survive reboots | `/etc/fstab` entry | | **Monitoring** | Alert if backup fails | HA integration or cron check | | **Multiple destinations** | Redundancy | Rotate between 2 USB drives | --- ### Setup Commands (Reference) ```bash # Install Samba + Avahi sudo apt install samba avahi-daemon # Create backup share sudo mkdir -p /srv/timemachine sudo chown nobody:nogroup /srv/timemachine sudo chmod 2777 /srv/timemachine # Configure Samba (/etc/samba/smb.conf) # Configure Avahi (/etc/avahi/services/timemachine.service) # Restart services sudo systemctl restart smbd avahi-daemon ``` --- ### Estimated Setup Time - **Fresh install:** ~30 minutes - **First Mac backup:** 2-8 hours (depends on data size) - **Subsequent backups:** 10-30 minutes (incremental) --- *Created: 2026-04-04* *Updated: 2026-04-17 — Full router architecture, VPN, eero bridge mode, FCC context* ```` ## Notes ## Related ### Referenced By - [brewery-pid-replacement](sources/brewery-pid-replacement.md) - [README](sources/readme.md)