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

# 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

  • No related pages yet.