{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}

Cipher, padding, outer IP family, and vendor framing can change the real byte total.
Use the WAN, cloud interconnect, or tunnel shaper rate available to encrypted traffic.
Use packet-capture averages when the workload does not match a preset.
Use measured payload traffic or a blended busy-hour estimate.
Use 1.0 for a sustained measured peak; increase it when the source average is quieter.
×
Use a whole concurrent-user count from the same busy-hour definition as the demand estimate.
users
A 70% to 85% target is a useful planning range; 100% is only the mathematical ceiling.
%
Zero is neutral. Validate vendor throughput for the actual cipher, packet size, and platform.
Keep 1 for an aggregate device limit, an active/standby pair, or traffic pinned to one tunnel.
tunnels
This is a planning estimate, not a live path-MTU probe.
bytes
Use one observed or documented average for the deployed encapsulation.
bytes
Small payloads spend a larger share of encrypted bandwidth on headers.
bytes
IPv4 without options is commonly 20 B plus 20 B TCP or 8 B UDP.
bytes

Capacity decision

{{ row.label }}
{{ row.value }}

{{ statusLabel }}. {{ decisionLead }}

  • {{ item }}

Formula record

capacity = floor(effective encrypted rate × target × payload efficiency ÷ peak demand per user)
  1. {{ row.label }}:{{ row.value }}{{ row.note }}

The chart renderer is unavailable. The same canonical points remain available in User load ladder.

Load pointUsersEncrypted demandUtilizationStateCopy
{{ row.label }}{{ formatInteger(row.users) }}{{ formatRate(row.encryptedMbps) }}{{ formatPercent(row.utilizationPct) }}{{ row.state }}
Packet itemValuePlanning meaningCopy
{{ row.label }}{{ row.value }}{{ row.note }}
MTU MSS Calculator Calculate a TCP MSS clamp from path MTU and encapsulation overhead, with IPv4 or IPv6 header budgets, floor checks and probe guidance.
IPsec Overhead Calculator Calculate a safe IPsec inner MTU and TCP MSS from the ESP profile and path budget, including NAT-T, padding and optional reserve bytes.
Jumbo Frame Savings Calculator Estimate how jumbo frames reduce packet rate and repeated Ethernet overhead for eligible traffic, with path-risk and optional CPU relief checks.
SNMP Polling Load Calculator Estimate SNMP polling pressure from devices and OIDs with interval and packing effects plus security, MTU and per-poller capacity checks.

An encrypted tunnel rarely delivers its full line rate as application data. The WAN path or gateway may impose the first throughput ceiling, and every packet spends part of that encrypted capacity on inner headers, outer headers, tunnel framing, authentication data, and sometimes padding.

Packet size changes the cost. Adding 80 bytes around a large file-transfer packet is a modest percentage; adding the same amount around a small interactive or voice packet consumes a much larger share. A user count based only on megabits per second can therefore overstate capacity when the real workload contains many small packets.

Planning evidenceWhat it should represent
Sustained encrypted rateThe smaller of usable path bandwidth and the gateway's measured crypto throughput.
Packet mixRepresentative application payload, transport header, and tunnel overhead bytes per packet.
Busy-hour user demandObserved average demand multiplied by a peak factor that covers simultaneous activity.
Planning targetThe share of encrypted capacity deliberately available for the modeled user population.
Underlay MTUThe largest packet that can cross the parent path without fragmentation or another MTU remedy.

Concurrency is not the same as registered users. Capacity planning needs the number simultaneously active during the busy period and the traffic they produce then. A small average from an all-day report can hide short bursts that fill queues, increase latency, or cause packet loss.

The result is a bandwidth and packet-budget estimate, not a VPN security assessment. Cipher choice, hardware acceleration, latency, loss, rekeying, routing, quality of service, licensing, and failover can all reduce usable capacity or determine whether the tunnel is suitable.

How to Use This Tool:

Base the plan on a representative busy-hour capture and the encrypted throughput available to this tunnel path.

  1. Select a VPN profile and enter Tunnel line rate. Use Custom measured overhead when packet captures or vendor documentation give a better byte allowance than a preset.
  2. Choose the Traffic profile, enter average demand per concurrent user, and set the Peak factor. A custom packet mix needs application payload bytes and inner header bytes.
  3. Enter the current concurrent-user count and Planning target. Open Advanced for a gateway crypto cap, active-tunnel count, parent MTU, or custom packet values.
  4. Read Capacity decision with Packet budget. Resolve a negative spare-user count, gateway limit, or fragmentation warning before treating the whole-user estimate as deployable capacity.

Interpreting Results:

Estimated capacity is floored to a whole concurrent-user count after the encrypted ceiling, planning target, and packet efficiency are applied. Spare users compares that count with the current load; a negative value is a modeled shortage.

  • Payload efficiency is the share of encrypted packet bytes that carry application payload. Small packets usually lower it.
  • Inside plan means current utilization is at or below the planning target. Uses reserve is above the target but no more than 100%; Oversubscribed is above 100%.
  • Fragment risk means the modeled encrypted packet is larger than the parent MTU. Confirm path MTU and packet captures before applying the displayed TCP or UDP size guidance.

Technical Details:

Capacity is derived in two stages. Packet accounting converts encrypted bandwidth into application-payload bandwidth. Busy-hour demand then converts that payload budget into a whole-user ceiling. Rates are normalized to Mbps before either stage.

Transformation Core:

The packet path is application payload plus the inner network and transport header, followed by the VPN allowance. Presets are conservative planning values rather than exact wire sizes for every cipher, padding length, address family, or vendor.

VPN profileOverhead allowancePlanning scope
IPsec ESP with NAT-T96 BConservative IPv4 outer IP, UDP, ESP, padding, and integrity allowance
IPsec ESP tunnel84 BCommon site-to-site allowance without NAT-T
IPsec IPv6116 BConservative larger outer-header and crypto-framing allowance
WireGuard over UDP80 BOuter IP, UDP, transport data framing, authentication tag, and padding estimate
SSL VPN tunnel64 BApproximate tunnel-mode allowance; vendor framing can differ
Traffic profilePayloadInner header
Bulk TCP1,328 B40 B
Web and SaaS850 B40 B
Voice RTP over UDP160 B28 B
Interactive TCP64 B40 B

Formula Core:

Let L be the line rate, G the aggregate gateway crypto cap when one is set, T the planning target as a fraction, p payload bytes, h inner-header bytes, and o VPN overhead bytes.

E=min(L,G) when a gateway cap is set; otherwise L η=pp+h+o Bpayload=E×T×η Rpeak=Raverage×k Ncapacity=⌊BpayloadRpeak⌋ Ucurrent=Ncurrent×Rpeakη×E×100

The aggregate gateway cap is the entered per-tunnel cap multiplied by Active tunnels. That multiplication is valid only when traffic can balance across those tunnels. A zero gateway cap leaves the line rate as the sole encrypted-throughput ceiling. Capacity is floored once after all rate and efficiency calculations retain full precision.

Rule Core:

MTU checks use the same packet assumptions as the capacity path. The safe inner MTU is parent MTU minus VPN overhead; the IPv4 TCP maximum segment estimate subtracts another 40 bytes, and the IPv4 UDP payload estimate subtracts 28 bytes. Fragment risk is true only when payload plus inner header plus VPN overhead is greater than the parent MTU; equality fits.

A gateway is marked as the limiter only when its positive aggregate cap is below the line rate. Current load is inside plan at or below the planning target, uses reserve above the target through 100%, and is oversubscribed above 100%.

Limitations and Security Notes:

Preset byte counts and traffic mixes are estimates. Real overhead changes with address family, cipher suite, authentication tag, padding, extensions, vendor framing, and packet-size distribution. Hardware acceleration, latency, packet loss, rekeying, quality of service, and other traffic on the path are not modeled.

Use measured encrypted throughput and representative packet captures for a production plan. Separately verify cryptographic configuration, authentication, routing, firewall policy, failover behavior, and vendor tunnel or session limits.

Worked Examples:

WireGuard path limited by gateway throughput

A 1 Gbps path with a 300 Mbps gateway cap uses 300 Mbps as its encrypted ceiling. At a 75% planning target, the planned encrypted rate is 225 Mbps. A 1,328-byte bulk payload with 40 inner-header bytes and 80 bytes of WireGuard allowance is 91.71% payload-efficient, leaving about 206.35 Mbps for application data. With 2 Mbps average demand and a 1.2 peak factor, whole-user capacity is floor(206.35 ÷ 2.4) = 85 users.

References: