Branch Office Reconnect Storm: strongSwan Admission Limits

Watch a branch office come back after a link failure and the gateway sees something that never appears during a normal day: dozens of laptops arriving from a single public address at once. Each one is a legitimate device and each one starts an IKE exchange that has not finished yet. Whether that burst succeeds depends on limits that have nothing to do with how many employees the server can carry. The burst is short, and it is precisely the workload the admission path was built to survive.

Follow One Laptop Back Onto the Network

The client sends an initial request and waits, and until the exchange completes the gateway holds admission state for that attempt. Other devices behind the same address arrive while the first one is still waiting, and they queue behind a limit that counts addresses rather than users. From the outside the symptom is a handful of users who connect and a larger group who time out.

Nothing in that sequence is a fault. It is the admission path doing what it was configured to do.

Count Half-Open Work as Its Own Resource

strongSwan separates two populations: associations that are fully established, and attempts that are still connecting or waiting to be processed. The block threshold applies to half-open associations attributed to one peer address, and the cookie thresholds apply globally and per address. Those counters protect the daemon from being consumed by unauthenticated work, which is exactly the shape of a reconnect storm. None of that state appears in a list of established tunnels.

Reading them as a cap on employee sessions is the mistake that leads to raising everything at once. A server that carries four hundred established tunnels is not automatically able to absorb four hundred simultaneous first packets, because the two costs land in different places.

Authentication latency decides how long each attempt stays in the half-open count. A backend that answers slowly turns a short burst into a long queue even when the arrival rate is modest.

swanctl --stats
swanctl --list-sas | grep -c ESTABLISHED

Read the Admission Settings Before Changing Them

Find the values the running daemon actually loaded before forming an opinion about them. Configuration is often split across a main file and a directory of per-plugin snippets, so a value you set in one place can be overridden in another. The search below shows every file that mentions the settings.

Then decide which number is too small. If one address legitimately represents a whole office, the per-address block threshold is the value that has to accommodate that concentration. A global cookie threshold protects the daemon against a wider flood and should not be relaxed because one site reconnects. Compare that per-address value against the largest site you actually have.

Keep the cookie mechanism enabled. Cookies make a client prove it can receive at its claimed address before the daemon spends real work on the exchange, and disabling them is not a neutral capacity upgrade. Raise a threshold only with a measured arrival rate and a stated authentication budget behind it.

grep -rn -E 'block_threshold|cookie_threshold' /etc/strongswan.conf /etc/strongswan.d/
swanctl --stats | grep -i half

Plan for the Return, Not Only the Steady State

An availability target that counts only established sessions describes a quiet afternoon, not a recovery. Ask instead how the intended population returns after a shared network event, and whether the admission path can absorb that shape.

Staggering reconnection across a managed fleet is often cheaper than enlarging limits, because it removes the artificial burst rather than paying for it permanently. Monitor half-open state and admission events next to successful establishments, and treat a rising half-open count with flat successes as an early warning rather than a curiosity.

The vendor reference for these settings is the strongswan.conf documentation, which names the counters and the release that introduced the per-address cookie threshold. Read the section for your installed version rather than the newest page, because defaults move between releases.