IPsec throughput lower than expected? Check the active SA first
A long transform list is not the session protecting your transfer. Record the negotiated SA, payload size and delivered rate before blaming encryption.
The configuration offers eight transforms, someone reads the strongest one, and the throughput figure gets pinned on it. The tunnel probably did not choose that transform, and it did not run the workload anyone imagined either. What it negotiated is one entry from that list, carrying one packet size, in one direction, on one build. Measure that and the argument about algorithms usually ends before it starts.
The symptom: a number below what the configuration promises
A long transform list describes possibilities, and each possibility gets scored on paper instead of on this hardware. The negotiated result is a single combination that both peers accepted, and it can be the weakest one either side still permits for compatibility. What that combination achieves depends on offload state, packet size and queue behaviour, so two devices with an identical policy file can land far apart. The list is a menu; the association is the order that came back.
Reading the list tells you what might have been chosen. Reading the association tells you what is carrying the transfer, and that is the only thing a throughput number describes. Every tuning step that starts from the list is a guess with extra paperwork.
Record the association that is carrying this transfer
On an ASA, show crypto ipsec sa lists the live associations with their transforms and per-direction counters, and the Cisco command reference documents that output. Pick the peer and the direction that matter, and note that a rekey replaces the association and resets its counters, which quietly invalidates a baseline you were still trusting. Store the output next to the test notes so the next run has something to diff. An association identifier that drifts between runs makes every later comparison meaningless.
| What to record | Where to read it | What it rules out |
|---|---|---|
| Negotiated transform and SA identifiers | show crypto ipsec sa for that peer and direction | "the configuration picked the wrong algorithm" |
| Offload or accelerator state for that build | platform show commands and interface statistics | "the crypto engine is the ceiling" |
| Payload size and offered rate | the test tool's own settings and summary | "packets per second versus bytes per second" |
| Delivered rate and loss at the receiver | the receiving endpoint, not the sender's counters | "the sender transmitted, so it arrived" |
| Access-link load and drops | underlay interface counters along the path | "the bottleneck lives inside the tunnel" |
Five rows are enough to make a measurement reproducible, and each one rules out a specific explanation when it is missing. None of them is a proposal-list entry, because the list cannot say what is protecting your bytes right now. Fill the table once and the next incident starts from data instead of from a fresh argument about algorithms.
The access-link row is the one people skip, and it is the one that most often explains a gap that looks cryptographic. A saturated underlay or a policer along the path produces the same symptom shape as a slow engine.
Measure one direction with a controlled load
Drive the test from a LAN endpoint that represents the application rather than from the gateway itself, because a gateway-generated probe can follow a different local policy. Measure one direction before adding a second stream, and record both the offered rate and what the receiver actually received. A rate-limited UDP run separates offered load from TCP's congestion response, while an unlimited UDP sender is not a neutral diagnostic. Log the payload length too, since a larger datagram changes both packet rate and encapsulation overhead.
show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30Run the same test twice with the same payload length and duration, because one run cannot separate a ceiling from a bad minute. If the receiver reports fewer packets than the sender emitted, the loss is your finding, and the crypto engine is only one of several candidates for it.
Explain the gap before you tune anything
Check forwarding policy, queue drops, interface errors and resource limits alongside the encryption path, since a rate deficit on its own never identifies a CPU. Keep the accounting layers explicit as well: outer tunnel bytes include encapsulation, and retransmissions move the relationship between inner and outer counts. Comparing unrelated counters byte for byte manufactures a discrepancy that was never there.
Packet size deserves its own controlled comparison rather than a number copied from an old example. TCP MSS adjusts TCP and has no effect on arbitrary UDP datagrams, so a fixed 1350 carried over from a legacy document measures nothing at all. Change the payload length on purpose and watch what the receiver reports.
Change one variable and keep the workload
Once the baseline repeats inside a narrow band, change one supported variable and rerun the original application task. That step is what turns a number into a cause, and it is the only one that justifies touching the configuration. Repeat the same workload rather than a friendlier one.
Do not retire proposals, weaken authentication or switch off protection to make a synthetic figure larger. Those moves change the security posture and then measure the result of that change, not the capacity of the tunnel.