Did my firewall just get AI?
Please explain this a little more - I would love to embed ai into my OPNsense firewall.
Short answer: not really — and that's intentional.
What this LoRA does is map normalised "CAP v1" packets from a coordinator to the right OPNsense tool call. It's the OPNsense specialist in a 3-agent SOC where the actual reasoning happens upstream (a Qwen 2.5 7B pilot decomposes intent → plan → CAP packets → specialists). The firewall stays a firewall; the LLMs stay on a sidecar VM.
The model was trained on 13 701 examples mixing free-form NL → tool_call and CAP v1 → tool_call (~60/40), then verified on the production format (verify_opnsense_v2.py): 102 / 102 OPNsense functions match correctly end-to-end.
Full picture in the README — see Team play — part of an agentic SOC for the architecture diagram and the v3→v7 verification table, and Deployment topology for why you don't run this inside OPNsense.
Update — a reference implementation is now public:
👉 https://github.com/patlegu/opnsense-ai-firewall
An experimental "OPNsense with an embedded LLM" — llama-server
(FreeBSD-native, b9000) + this Phi-3 mini LoRA running inside the
OPNsense VM itself. A local Python agent maps natural-language admin
intents to OpenAI-style tool_calls, then dispatches them on the
local OPNsense REST API (127.0.0.1:4443).
What works (validated May 2026, cx33 Hetzner VM):
oaf-agent ask "Show system information"→ JSON returned from OPNsenseoaf-agent ask "Block IP 1.2.3.4 on WAN" --confirm→ realpfrule
created, OPNsense returns a UUID- Latency ~10 s/intent on 4 vCPU shared, CPU-only inference
What it isn't: a production design. The repo doubles as a
why-not-in-prod analysis — CPU contention with pf, attack surface
on a firewall, llama.cpp vs OPNsense lifecycle drift, audit gaps.
Details in docs/why-not-in-prod.md.
Most LoRA consumers will want the sidecar pattern instead. This repo
exists to measure what "AI in firewall" actually costs.