# Production firewall policy

iptables (not nftables) — deliberately, to stay consistent with the Provisioner's own dynamic
per-Lab egress rules, which already manipulate the `DOCKER-USER` chain via iptables
(`platform/provisioner/src/firewall.js`, Phase 1). Mixing the nft and legacy iptables backends
on the same host is a known source of silent rule-ordering bugs; the host-level policy below
uses the same backend the app already depends on.

Each `.rules` file is `iptables-restore` format — deployed by the matching Ansible role
(`firewall` for the VMs; the Proxmox host ruleset is applied manually per
`docs/PRODUCTION_DEPLOYMENT.md` §2, since Proxmox host firewalling is out of Ansible's blast
radius by design — a mistake there can lock out the only way in).

| File | Applies to | Deployed by |
|---|---|---|
| `proxmox-host.rules` | The Proxmox hypervisor itself | manual, `docs/PRODUCTION_DEPLOYMENT.md` §2 |
| `rn-platform-01.rules` | Platform VM | `infra/ansible/roles/firewall/` |
| `rn-lab-host-01.rules` | Lab Host VM | `infra/ansible/roles/firewall/` |

All three encode the same policy table from `docs/PRODUCTION_NETWORK_SECURITY.md` §6 — this
README doesn't restate it, that doc is the source of truth for *why*; these files are the
*what*, in a form the host can actually load.

**IP addresses/subnets are Ansible template variables** (`{{ platform_ip }}`,
`{{ lab_host_ip }}`, `{{ management_cidr }}`, etc.) — see `infra/ansible/group_vars/production.yml`.
Nothing here hardcodes a real production IP, per the explicit Phase 4 instruction not to guess
those before the real host exists.

`infra/firewall/validate-firewall.sh` renders each ruleset with dummy IPs and runs it through
`iptables-restore --test` (syntax/semantic validation only — proves the rules are well-formed
iptables, not that the real network topology is correct, which needs the real hardware).