10. From ports to offload¶
Front ports as interfaces made the appliances firewalls again - with every packet crossing the host. But a coprocessor is more than a port controller. It has a fast path that forwards on its own, and a crypto engine - the very thing the eight months of looking set out to understand. The next stage was to hand both of them the firewall's own decisions.
pf decides, the coprocessor forwards. A connection the firewall has passed goes into the coprocessor's flow table, and comes back out the moment pf lets go of it.
On the XGS 3300¶
| date | step |
|---|---|
| 2026-10-03 | Offload was never switched on, which is why there were no flows - the first finding was that the feature had never been enabled |
| 2026-10-06 | a flow table and a sweep that fills it from pf's states; the whole table discarded when the ruleset is replaced |
| 2026-10-07 | the kernel drives the coprocessor: IPsec associations that strongSwan installs through OPNsense land on the crypto engine, in both directions, under FreeBSD's own offload contract |
| 2026-10-08 | the flow carries the association: tunnel connections in the flow table |
| 2026-10-18 | IPv6 connections in the flow table, and the table sized by what the board itself states: 2,000,000 |
The run that closed the IPv6 work, photographed as it finished - 9.24 Gbit/s one way and 9.27 back, all eighteen directions in hardware:
On the XGS 136¶
The ARMADA came second to offload and went quickly, because the XGS 3300 had already drawn the map:
| date | step |
|---|---|
| 2026-10-14 | the chain measured - the entry, then the gate, then the flow table - and the driver accelerates its first flow |
| 2026-10-14 | the crypto engine accepts an association; IPsec in hardware both ways; fragmentation before the envelope; NAT traversal and AES-CBC with an HMAC; the replay window - all in one day |
| 2026-10-17 | IPsec offload on by its own setting; frames and ESP envelopes above 4,096 bytes |
| 2026-10-18 | the flow table at the size the board states, 1,500,000, its commands answered in 138 microseconds instead of ten milliseconds; IPv6 connections |
What the two share, and what they do not¶
The same rows for both, side by side, are on docs/families/parity.md. It also says plainly what the XGS 136 still lacks: receive driven by the coprocessor's interrupts instead of a poll, posted flow writes, connections handed back and revived, tunnel connections in the flow table, and IPsec over IPv6.
Every figure behind these rows is on Measurements, with the photograph of its run.
Previous: 9. The XGS 3300 and the last hop · Next: 11. An appliance again
The discussion of this page is held in the project's GitHub Discussions. Showing it here loads giscus from giscus.app and GitHub, and writing in it needs a GitHub account - what that means.