Network appliance evaluation

This guide creates a two-interface Debian image for a WireGuard, DNS, and routing lab. Production use requires an exact interface map, reviewed firewall policy, real key custody, hardware-driver testing, and a recovery path.

Prompt


Create a Debian Trixie headless network-appliance evaluation image with two
NICs, SSH, firewall, WireGuard, dnsmasq, nftables, and IP forwarding. Keep
WireGuard private keys and site addresses out of the recipe. Create a locked
operator account and require key-only SSH only after its public key path is
verified. Add a client VM scenario that proves DHCP/DNS behavior, routed
traffic, allowed management access, and denied traffic.

Recipe shape


{
  "name": "branch-network-appliance-evaluation",
  "base_image": "debian-trixie",
  "hardware": {
    "platform": "pc",
    "architecture": "x86_64",
    "min_cpu_cores": 2,
    "min_memory_gb": 2,
    "min_storage_gb": 16,
    "nic_count": 2
  },
  "os": {
    "features": ["headless", "ssh", "firewall", "vpn-wireguard"],
    "packages": ["dnsmasq", "nftables"],
    "users": [
      {
        "username": "operator",
        "groups": ["sudo"],
        "shell": "/bin/bash"
      }
    ],
    "services": [
      {
        "name": "ssh",
        "enabled": true,
        "config": {
          "port": 2222,
          "allow_root": false,
          "disable_password_auth": true
        }
      }
    ],
    "startup_scripts": [
      {
        "name": "enable-ip-forwarding",
        "description": "Persist the reviewed IPv4 forwarding setting.",
        "command": "set -Eeuo pipefail\nprintf '%s\\n' 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openfactory-forwarding.conf\nsysctl --system >/dev/null",
        "packages": [],
        "run_as": "root",
        "after": "network.target"
      }
    ]
  }
}

Changing the SSH port reduces scanning noise but is not an authentication control. Key-only SSH is valuable only after a working key is installed and tested.

Test the data path, not just packages

A single VM can show that wg, dnsmasq, and nftables exist and that forwarding is enabled. It cannot prove client behavior. Build a topology with at least:

the appliance with WAN and LAN interfaces;
a LAN client with no alternate default route; and
a bounded upstream service or probe.

Verify DHCP lease assignment, DNS forwarding, intended routes, NAT if required, WireGuard handshake with test-only keys, allowed management access, and denied unsolicited traffic. Include negative tests so a permissive firewall cannot pass.

Deployment boundary

At deployment time, separately review:

mapping of VM interface order to physical NIC names and MAC addresses;
private-key generation, storage, rotation, and revocation;
approved subnets, routes, forwarding, NAT, and DNS policy;
IPv6 behavior rather than silently disabling it;
updates without severing management access;
configuration backup and offline recovery; and
fail-open/fail-closed behavior after link, DNS, clock, and power failures.

Validate the exact appliance hardware before production use.