532 lines
17 KiB
Markdown
532 lines
17 KiB
Markdown
---
|
||
pageType: source
|
||
id: source.pi-hole-blocker-project
|
||
title: Pi-hole-Blocker-Project
|
||
sourceType: local-file
|
||
sourcePath: /home/topher/.openclaw/workspace-crash-bot/projects/pihole-blocker.md
|
||
ingestedAt: 2026-05-02T21:01:38.021Z
|
||
updatedAt: 2026-05-02T21:01:38.021Z
|
||
status: active
|
||
---
|
||
|
||
# Pi-hole-Blocker-Project
|
||
|
||
## Source
|
||
- Type: `local-file`
|
||
- Path: `/home/topher/.openclaw/workspace-crash-bot/projects/pihole-blocker.md`
|
||
- Bytes: 16974
|
||
- Updated: 2026-05-02T21:01:38.021Z
|
||
|
||
## 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
|
||
<!-- openclaw:human:start -->
|
||
<!-- openclaw:human:end -->
|
||
|
||
## Related
|
||
<!-- openclaw:wiki:related:start -->
|
||
- No related pages yet.
|
||
<!-- openclaw:wiki:related:end -->
|