Hardening the Gateway: Firewalla Security Architecture, Custom DNS & Automated Post-Boot Scripts

Consumer wireless routers bundle routing, firewalling, and Wi-Fi into a single unmaintained firmware image, while virtualized software routers (like OPNsense or pfSense in a VM) create a critical single point of failure that brings down your entire household network whenever the hypervisor reboots.

A dedicated hardware security appliance like Firewalla provides an enterprise-grade boundary defense for homelabs. Running an Ubuntu-based Linux core with active Intrusion Detection/Prevention (IDS/IPS), Firewalla handles line-rate DPI, IoT device isolation, and local DNS. By leveraging Firewalla’s native hook architecture, you can execute custom automated scripts on every boot that survive firmware upgrades.

⚡ Quick Runbook: 60-Second Implementation

TL;DR: Deploy an automated post-boot script on Firewalla using the native post_main.d hook:

# SSH into Firewalla: ssh [email protected]
sudo mkdir -p /home/pi/.firewalla/config/post_main.d

# Create persistent post-boot execution script
sudo tee /home/pi/.firewalla/config/post_main.d/01-custom-services.sh << 'EOF'
#!/bin/bash
# Executed automatically after Firewalla core daemons initialize on reboot

# 1. Start custom Docker daemon and containerized stacks
if command -v systemctl >/dev/null 2>&1; then
    sudo systemctl start docker
fi

# 2. Start containerized Tailscale subnet router (if deployed)
if [ -f /home/pi/.firewalla/run/docker/tailscale/docker-compose.yml ]; then
    sudo docker compose -f /home/pi/.firewalla/run/docker/tailscale/docker-compose.yml up -d
fi

# 3. Notify Uptime Kuma of successful reboot
curl -fsS -m 10 --retry 3 https://uptime.example.com/api/push/GATEWAY_KEY?status=up&msg=Firewalla+Rebooted >/dev/null 2>&1

exit 0
EOF

# Make script executable
sudo chmod +x /home/pi/.firewalla/config/post_main.d/01-custom-services.sh

1. Firewalla Operating Architecture

Unlike proprietary router appliances that hide their internals behind crippled web interfaces, Firewalla runs a standard, auditable Linux userland. Key architectural attributes include:

Dedicated Appliance vs Hypervisor VM: Placing routing on dedicated hardware prevents network outages when storage servers or hypervisors undergo kernel upgrades or hardware maintenance.
Suricata-Powered Deep Packet Inspection (DPI): Analyzes network packet headers and payloads at line rate, detecting signature-based malware callbacks, port scans, and unusual egress traffic.
Local Docker Engine: Firewalla includes a lightweight native Docker runtime, allowing administrators to run network utility containers (e.g. Tailscale subnet routers, AdGuard Home, or custom telemetry collectors) directly on the edge gateway.

2. Network Hardening & IoT Segmentation

The primary security responsibility of an edge gateway is preventing lateral movement. Smart home devices (security cameras, robotic vacuums, smart TVs, and IoT bulbs) represent unpatched attack vectors that must never share a broadcast domain with your NAS, workstations, or servers.

Dedicated IoT Network: Place all smart devices on a distinct VLAN or dedicated subnet (e.g., 10.1.10.0/24).
Block Local Traffic Rule: Create a rule in Firewalla blocking traffic from the IoT network to all local subnets (Traffic from IoT > Block > Target: Local Networks).
Egress Restrictions: Restrict IP cameras to outbound RTSP/WebRTC streams or internal NVR ingest only, denying outbound WAN internet access entirely.

3. Split-Horizon Custom DNS Rules

When running local reverse proxies (such as Caddy on your internal server 10.1.0.50), navigating to app.example.com from inside your home should resolve directly to the local LAN IP rather than hairpining out to the public internet and back.

In the Firewalla app, navigate to DNS Service > Custom DNS Rules and add entries pointing internal hostnames directly to your server:

# Example Custom DNS Table in Firewalla
DOMAIN                      ADDRESS
nas.home.example.com        10.1.0.50
vault.example.com           10.1.0.50
immich.example.com          10.1.0.50
paperless.example.com       10.1.0.50

4. NextDNS Integration via Control-D CLI (ctrld)

While Firewalla includes native ad-blocking and DoH, power users often prefer NextDNS for detailed analytics, cloud blocklist management, and granular per-device query logging.

The Control-D CLI (ctrld) features a specialized “NextDNS Mode” that forwards encrypted DNS traffic while attributing queries to individual client IP addresses on Firewalla:

# 1. Disable conflicting native features in the Firewalla app:
# Disable: "DNS over HTTPS", "Unbound", "Ad Block", and "Family Mode"

# 2. Download and install ctrld CLI on Firewalla:
sudo sh -c 'sh -c "$(curl -sL https://api.controld.com/dl)"'

# 3. Start ctrld in NextDNS mode (replace 'abcdef' with your NextDNS Profile ID):
sudo ctrld start --nextdns abcdef

5. Automated Scripts on Reboot (post_main.d)

Firewalla features an automated post-boot hook directory: /home/pi/.firewalla/config/post_main.d/. Any executable shell script placed here is guaranteed to execute at the end of the boot process after network interfaces and core firewalls are online.

Example: Persistent Tailscale Subnet Router & Exit Node

To run Tailscale directly on Firewalla without risking Docker socket degradation during OS updates, configure a persistent Docker Compose stack:

# /home/pi/.firewalla/run/docker/tailscale/docker-compose.yml
services:
  tailscale:
    container_name: tailscale
    image: tailscale/tailscale:stable
    restart: unless-stopped
    network_mode: host
    cap_add:
      - net_admin
      - sys_module
      - net_raw
    volumes:
      - /data/tailscale:/var/lib/tailscale
      - /dev/net/tun:/dev/net/tun
    environment:
      - TS_AUTH_KEY=tskey-auth-xxxxxx
      - TS_ROUTES=10.1.0.0/20
      - TS_EXTRA_ARGS=--advertise-exit-node
      - TS_USERSPACE=false

By registering this in /home/pi/.firewalla/config/post_main.d/start-tailscale.sh, your edge gateway always re-establishes its remote mesh VPN bridge immediately upon reboot.