{{ summary.title }}
{{ summary.primary }}
{{ summary.line }}
{{ badge.label }}
Use the closest profile for the deployed tunnel; choose Custom when you have measured overhead bytes.
Enter the WAN, internet, cloud interconnect, or tunnel shaper rate.
Pick the dominant workload mix so packet efficiency is not based on bulk-transfer packets when the tunnel mostly carries voice or interactive flows.
Use measured per-user payload traffic or a blended estimate for the busy-hour workload.
Use 1.0 for sustained measured peaks, or a higher multiplier when the average comes from quieter samples.
x
Set this to the present busy-hour user count or the target rollout size.
users
Common planning targets are 70% to 85%; use 100% only for a hard mathematical ceiling.
%
Leave at 0 when the WAN link is the only capacity limiter.
Keep this at 1 for a single tunnel; raise it only when traffic can actually balance across active tunnels.
tunnels
Use 1500 for normal Ethernet paths unless the underlay, cloud link, or WAN service advertises another MTU.
bytes
Include outer IP, UDP/NAT-T, ESP/WireGuard/TLS, IV, padding, integrity, and any extra tunnel wrapper bytes you need to model.
bytes
Use packet captures when possible; smaller payloads lower effective tunnel capacity.
bytes
Typical IPv4 TCP is 40 bytes and IPv4 UDP is 28 bytes before VPN encapsulation.
bytes 
{{ jsonText }}
Tags: Networking
Export to PDF Fullscreen
Customize
Advanced
:

VPN tunnel capacity is the usable application traffic that remains after encryption, encapsulation, and planning reserve are taken out of the raw path bandwidth. A one gigabit tunnel does not always carry one gigabit of application payload. Every packet also carries inner IP and transport headers, VPN wrapper bytes, padding, integrity data, and sometimes a UDP wrapper for NAT traversal.

The packet mix matters as much as the headline bandwidth. Large TCP transfers spend a smaller share of each encrypted packet on overhead, while voice, remote-control traffic, and chatty business applications can burn a much larger share on headers. That is why the same WAN circuit can support very different user counts depending on average per-user demand, busy-hour burst factor, selected VPN profile, and packet size.

Diagram of encrypted path budget showing planning target, reserve, payload bytes, headers, and VPN overhead.

Capacity planning is still an estimate. Real tunnels can be limited by gateway CPU, cipher choices, packet loss, traffic shaping, cloud tunnel limits, rekey events, and routing design. A useful calculation makes those assumptions visible, then leaves enough margin so the rollout is not planned at the mathematical ceiling.

Technical Details:

The calculation separates encrypted path capacity from application payload capacity. The raw tunnel line rate is first capped by any gateway crypto limit. The planning target then reserves a percentage of that encrypted ceiling, and packet efficiency converts the remaining encrypted bandwidth into cleartext payload throughput.

Packet efficiency is driven by the selected VPN profile and traffic profile. The built-in VPN profile values are planning estimates: IPsec ESP NAT-T at 96 B, IPsec ESP tunnel at 84 B, IPsec IPv6 conservative at 116 B, WireGuard over UDP at 80 B, and SSL VPN tunnel at 64 B. The custom path uses the entered overhead bytes instead. Traffic profiles pair an average application payload with an inner header allowance: bulk TCP uses 1328 B plus 40 B, mixed web and SaaS uses 850 B plus 40 B, voice RTP over UDP uses 160 B plus 28 B, and interactive TCP uses 64 B plus 40 B.

Formula Core:

The main result is the largest whole concurrent-user count that fits inside the selected planning target after overhead and peak demand are applied.

Beffective = min(Bline,Bgateway×T) E = PP+H+O Bpayload = Beffective×R100×E Users = ⌊BpayloadDavg×F⌋
Symbol Meaning Related output
Bline Tunnel line rate converted to Mbps Tunnel line rate
Bgateway Optional gateway crypto cap per active tunnel Effective encrypted ceiling
T Active tunnels that can actually share traffic Gateway throughput
P Average application payload bytes per packet Average application payload
H Inner IP plus TCP or UDP header bytes Inner packet before VPN
O VPN overhead bytes from the selected profile or custom value VPN overhead bytes
R Planning target percentage Planning target
Davg and F Average user demand and peak factor Peak demand per user

The MTU calculation uses the same overhead value. Safe inner MTU is the parent interface MTU minus VPN overhead. Safe TCP MSS subtracts another 40 B for IPv4 TCP/IP headers, and the UDP payload estimate subtracts 28 B. The MTU state changes to Fragmentation risk when the modeled encrypted packet is larger than the configured parent MTU.

Cue Rule Meaning
Inside plan Encrypted utilization is less than or equal to the planning target. The load point fits the selected reserve policy.
Uses reserve Encrypted utilization is above the planning target and less than or equal to 100%. The tunnel has not crossed the hard ceiling, but growth and burst margin are being consumed.
Oversubscribed Encrypted utilization is above 100%. Modeled demand exceeds the effective encrypted ceiling.
Capacity buffer is thin Current utilization is above 85% of the planning target. The current load still fits, but small changes can push it into reserve.
MTU profile needs review Average encrypted packet bytes exceed the parent MTU. MSS, payload size, or parent MTU should be reviewed before relying on the capacity number.

All numeric inputs are clamped or rejected by fixed ranges before results are shown. Line rate and average user demand must be greater than zero, peak factor must stay from 1.0 to 20.0, planning target from 1% to 100%, active tunnels from 1 to 64, parent MTU from 576 to 9000 B, custom overhead from 0 to 400 B, custom payload from 1 to 8900 B, and custom inner header from 0 to 200 B.

Everyday Use & Decision Guide:

Start with the tunnel's busy-hour reality, not the contract speed alone. Choose the closest VPN profile, enter the encrypted-path Tunnel line rate, pick a Traffic profile, and set Average user demand from monitoring data when you have it. If demand came from a quiet sample, raise Peak factor so the model reflects bursts rather than calm periods.

The default planning target range on the page hints at a useful operating style: 70% to 85% is a common planning band, while 100% is only a mathematical ceiling. A tunnel that appears acceptable at 100% can still struggle during rekeys, traffic spikes, packet loss, or gateway CPU pressure.

  • Use Gateway crypto cap when an appliance datasheet, cloud VPN limit, or measured encryption ceiling is lower than the WAN rate.
  • Increase Active tunnels only when traffic can balance across them. Parallel tunnels that sit idle do not multiply useful capacity.
  • Use Custom overhead and Custom packet mix when packet captures or vendor details are better than the built-in estimates.
  • Check Payload efficiency before trusting a high user count. Small packets can make a fast tunnel behave like a smaller path.
  • Read MTU state with Safe TCP MSS estimate. A capacity plan that ignores fragmentation risk can look better than the tunnel will feel.

Capacity Snapshot gives the main number, Overhead Packet Budget explains where bandwidth is lost, User Load Ladder shows how utilization changes as users are added, and Planning Brief turns the current run into short action notes. Use Tunnel Load Curve when you need to show the gap between encrypted demand, planning target, and encrypted ceiling across several user counts.

Do not read Estimated user capacity as a promise that every application will be responsive. Validate the plan with encrypted interface Mbps, packet size histograms, drops, CPU, and rekey behavior, especially when the result says Current load uses reserve, Tunnel is over plan, or MTU profile needs review.

Step-by-Step Guide:

  1. Set VPN profile first. If none of the built-in profiles matches the tunnel, choose Custom overhead bytes and enter the measured wrapper, crypto, padding, and integrity allowance in Custom overhead.
  2. Enter Tunnel line rate and its unit. If the summary changes to Check inputs with Tunnel line rate must be greater than 0., fix that field before reading the result tables.
  3. Choose Traffic profile, then enter Average user demand and Peak factor. For custom packet mixes, fill Custom payload bytes and Custom inner header so Overhead Packet Budget can show the encrypted packet size.
  4. Set Current concurrent users and Planning target. The summary should show a user capacity, spare users or users short, peak demand per user, and the selected encrypted-path target.
  5. Open Advanced if gateway throughput or MTU is part of the decision. Enter Gateway crypto cap, Active tunnels, and Parent interface MTU, then confirm whether Effective encrypted ceiling is limited by the tunnel line rate or the gateway crypto cap.
  6. Review Capacity Snapshot and Planning Brief. If Spare users at current load is negative, reduce users or add encrypted capacity before treating the rollout as inside plan.
  7. Open Tunnel Load Curve or User Load Ladder when you need to explain growth. The curve and ladder should show current users, modeled capacity, encrypted demand, planning target, and encrypted ceiling in the same run.

Interpreting Results:

The first reading should combine Estimated user capacity, Spare users at current load, Current encrypted utilization, and the summary status. A positive spare-user count means the current inputs fit the selected planning target. A negative count means the busy-hour demand already exceeds the modeled plan, even if the physical line rate sounds large.

Result cue What to do with it
Payload efficiency below 70% Recheck the packet mix. Small-packet traffic is using a large share of encrypted bandwidth for headers and VPN overhead.
Gateway crypto cap is the limiter Treat the appliance or cloud tunnel throughput as the bottleneck, even when the WAN rate is higher.
Current load uses reserve The load is below the hard encrypted ceiling but above the selected planning target. Growth and burst margin are already thin.
Tunnel is over plan Modeled demand exceeds the planning capacity. Reduce demand, add encrypted capacity, or revisit packet and peak assumptions.
MTU profile needs review The modeled encrypted packet is larger than the parent MTU. Check Safe TCP MSS estimate before relying on the user count.

A green status does not prove vendor throughput, end-user latency, or application quality. It only says the entered values fit the calculator's capacity math. Before changing production limits, compare the result with measured encrypted Mbps, packet size distribution, drops, retransmits, gateway CPU, and tunnel rekey timing.

Worked Examples:

Default mixed web tunnel

With IPsec ESP NAT-T / cloud default, a 1 Gbps tunnel line rate, Mixed web and SaaS, 850 Kbps average user demand, a 1.6x peak factor, 420 current users, and a 75% planning target, the modeled capacity is 475 users. Spare users at current load is +55 users, Payload efficiency is 86.2%, and Current encrypted utilization is 66.3%. The status is Capacity buffer is thin because the current load is close enough to the target to deserve monitoring.

Voice traffic on a smaller tunnel

A 200 Mbps IPsec NAT-T tunnel carrying Voice RTP / UDP at 80 Kbps per user with a 1.4x peak factor and a 70% planning target models 704 users. If Current concurrent users is 900, the result shows 196 users short and Tunnel is over plan. The important clue is Payload efficiency at 56.3%, because small voice packets spend much more of the encrypted path on overhead.

Gateway cap below the WAN rate

A WireGuard run with a 1 Gbps line rate, Bulk TCP packets, 2 Mbps average user demand, a 1.2x peak factor, and a 300 Mbps gateway crypto cap has an Effective encrypted ceiling of only 300 Mbps. With 180 current users, the model returns 91 users, 89 users short, and Gateway crypto cap as the limiter. Raising the WAN rate alone would not fix that run.

Custom MTU review

A custom profile with 180 B overhead, 1100 B custom payload, 40 B custom inner header, and a 1200 B parent MTU creates a 1320 B encrypted packet. The capacity still models 83 users with 33 spare users in the sample run, but the summary changes to MTU profile needs review. Safe TCP MSS estimate is 980 B, so the MTU issue should be fixed before the spare-user count is treated as acceptable.

FAQ:

Why can small packets reduce user capacity so much?

The VPN overhead is added to every packet. When the application payload is small, the overhead takes a larger share of the encrypted packet, so Payload efficiency falls and fewer users fit inside the same planning target.

Should I enter WAN speed or VPN gateway throughput?

Enter the path bandwidth in Tunnel line rate. Use Gateway crypto cap when the appliance, cloud tunnel, or measured encryption throughput is lower. The result uses the smaller effective encrypted ceiling.

What does the safe TCP MSS estimate mean?

Safe TCP MSS estimate is the parent MTU minus the selected VPN overhead and a 40 B IPv4 TCP/IP allowance. It is a planning value for avoiding fragmentation, not a replacement for testing the actual path.

Why did the summary say Check inputs?

One or more values failed a range check. Common causes are a zero tunnel line rate, zero average user demand, peak factor outside 1.0 to 20.0, planning target outside 1% to 100%, or a parent MTU outside 576 to 9000 B.

Does the calculation send tunnel details to a server?

The capacity math runs in the browser and there is no tool-specific server calculation endpoint. The current input values can be reflected in the page address for sharing, so avoid sharing a URL that contains sensitive capacity numbers.

Glossary:

Payload efficiency
The percentage of encrypted-path bandwidth that carries application payload after headers and VPN overhead are counted.
Encrypted ceiling
The effective encrypted bandwidth after the tunnel line rate is compared with any gateway crypto cap.
Planning target
The percentage of the encrypted ceiling reserved for planned load instead of the hard maximum.
Gateway crypto cap
An optional throughput limit from a VPN appliance, cloud tunnel, or measured encryption ceiling.
Safe TCP MSS
The estimated TCP segment payload size that fits after subtracting VPN overhead and IPv4 TCP/IP headers from parent MTU.
Fragmentation risk
A warning state where the modeled encrypted packet is larger than the configured parent MTU.

References: