Skip to content

Extended sequence numbers arriving on the XGS 3300's engine. Measured, 2026-10-20

Yes. With this driver an association with extended sequence numbers that arrives is decrypted by the XGS 3300's engine and holds: 20.7 million frames on one association at the link's rate, through the sequence that killed it on 2026-10-12, through three minutes of 1,500-byte frames, and through a rekey in the middle of a download - and no drop or authentication counter of the coprocessor moved. So the driver takes it by default now, as the XGS 136's does, and both directions of an ESN tunnel run on the engine.

On 2026-10-12 it did not hold (under ESN, what arrives stays with the kernel): modules c92ca5dd and a4c1091e, a peer that was another firewall, and the coprocessor decrypted a million frames or so and then refused every one with CRYPTO_DROP_AUTH until a rekey, three runs in four. That cause was not found then and is not found now; it is not there with this driver.

What the driver does now

octep_ipsec.c takes an arriving association marked SADB_X_SAFLAGS_ESN and sends it with ext_seq (bit 18 of SA_ADD's control word), as it always did for one that leaves. dev.octep.0.ipsec.esn_decrypt (tunable hw.octep.ipsec_esn_decrypt) at 0 leaves it to the kernel as before, counted in esn_refused; it is read when an association is installed, because the kernel offers one only then. OPNsense's IPsec pages have no ESN field: strongSwan takes it through the ESP proposal (aes256gcm16-esn), set in swanctl.conf by hand at both ends.

How it was measured

The lab tunnel between the second XGS 3300 and the XGS 136 behind its Port8, AES-GCM-16-256, the PC's 10G port on the 3300's side - so the PC sending to the 136 is the 3300 encrypting, and the 136 sending to the PC is the 3300 decrypting. images/deploy/lab-3300-esn.sh (not in this repository) makes both ends' swanctl.conf again from the GUI's configuration, puts the proposal and the 3300's replay window in, ends the whole IKE association and has the child made again; then the 2026-10-12 sequence - four streams up 16 s, four down 16 s, one down 12 s - with iperf3, and the 3300's engine counters.

First, a rebooted peer. The evening's first runs did die: after the child had been made again about a dozen times, nothing the XGS 136 sent through the tunnel arrived at all - with the plain proposal too, and with the 3300's kernel decrypting instead of its engine - and a reboot of the 136 cured it (644). Every measurement below was made from a rebooted 136, and the photographed one from both appliances rebooted.

Measured

On module d4fb3b12 (the switch at 1 by hand), one association, a 32-packet window, the 136 rebooted:
the 2026-10-12 sequence, five times up 984 to 985 Mbit/s, four down 983 to 985, one down 959 to 985 - every run
three minutes down, four streams, jumbo frames (the link is at MTU 9,000) 984 Mbit/s every minute, 20.6 GB
three minutes down, four streams, 1,500-byte frames (the 136's Port8 held at 1,500 for it) 905 to 907 Mbit/s, 19.0 GB, 15,188,960 frames decrypted by the engine
on that association in all 20.7 million frames decrypted; the coprocessor's counters: FROM_WIRE_TO_IPSEC_DECR moving with them, no CRYPTO_DROP and no AUTH counter at all
a rekey 20 s into a 50 s four-stream download 985, 976, 985, 982, 985 Mbit/s in its ten-second steps; the new arriving association on the engine

A 4,096-packet window was tried too, before the peer was rebooted, and died as the 32 did then - which, with the 136 in the state above, says nothing either way about the window.

Then the default, f7eede10: both appliances rebooted, no tunable set, esn_decrypt reading 1:

The second XGS 3300 on module f7eede10, nothing set: an ESN association arriving on its engine through the 2026-10-12 sequence at 983 to 985 Mbit/s, then three minutes of 1,500-byte frames at 905 Mbit/s, 15,169,983 frames decrypted, no drop or authentication counter moved

The "initiate failed" in it is the 3300's own request crossing the 136's, which made the child first; the table under it shows the pair on the engine, the arriving one with its 32-packet window, and flags=0x00000400, the kernel's ESN mark.

Scripts: images/deploy/lab-3300-esn.sh, and lab-3300-esn-proof.sh for the photograph.

What it does not mean

  • The 2026-10-12 failure is not explained, only not reproduced: a different peer, a different module, and a driver much changed since (the replay window and its head, the second acknowledge, the slot for both directions). If it came from the coprocessor's firmware under a condition this bench does not make, it could come back; esn_decrypt at 0 puts the kernel back.
  • One peer, one appliance. The second XGS 3300 and the XGS 136; the first XGS 3300 not tried.
  • A gigabit. The tunnel runs over the 136's gigabit Port8; the 3300's engine at 10 Gbit/s with ESN is not measured.

Discussion

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.