VPN Tunnel Capacity Calculator

VPN profile:

Use the closest profile for the deployed tunnel; choose Custom when you have measured overhead bytes.

Tunnel line rate:

Enter the WAN, internet, cloud interconnect, or tunnel shaper rate.

Traffic profile:

Pick the dominant workload mix so packet efficiency is not based on bulk-transfer packets when the tunnel mostly carries voice or interactive flows.

Average user demand:

Use measured per-user payload traffic or a blended estimate for the busy-hour workload.

Peak factor:

Use 1.0 for sustained measured peaks, or a higher multiplier when the average comes from quieter samples.

Burst multiplier slider {{ peakFactorRangeLabel }}

Current concurrent users:

Set this to the present busy-hour user count or the target rollout size.

users

Load comparison slider {{ currentUsersRangeLabel }}

Planning target:

Common planning targets are 70% to 85%; use 100% only for a hard mathematical ceiling.

Reserve target slider {{ planningTargetRangeLabel }}

Gateway crypto cap:

Leave at 0 when the WAN link is the only capacity limiter.

Active tunnels:

Keep this at 1 for a single tunnel; raise it only when traffic can actually balance across active tunnels.

tunnels

Parent interface MTU:

Use 1500 for normal Ethernet paths unless the underlay, cloud link, or WAN service advertises another MTU.

bytes

Underlay MTU slider {{ parentMtuRangeLabel }}

Custom overhead:

Include outer IP, UDP/NAT-T, ESP/WireGuard/TLS, IV, padding, integrity, and any extra tunnel wrapper bytes you need to model.

bytes

Overhead byte slider {{ customOverheadRangeLabel }}

Custom payload bytes:

Use packet captures when possible; smaller payloads lower effective tunnel capacity.

bytes

Custom inner header:

Typical IPv4 TCP is 40 bytes and IPv4 UDP is 28 bytes before VPN encapsulation.

bytes

{{ header }}	Copy
{{ cell }}
No rows available.

{{ jsonText }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A VPN tunnel can run out of useful capacity before the carrier link looks full. The encrypted path carries application payload, inner IP and transport headers, tunnel wrapper bytes, integrity data, padding, and sometimes UDP encapsulation for NAT traversal. Only part of the advertised bandwidth is available for the traffic users actually care about.

Capacity planning therefore has two separate questions. The first is the encrypted ceiling: the smaller of the line rate and any gateway crypto limit that applies to the active tunnels. The second is payload efficiency: the share of each encrypted packet that remains after headers and tunnel overhead are counted. A large file transfer and a voice stream can cross the same 1 Gbps tunnel and still produce very different user counts because their packet sizes are different.

VPN capacity planning factors
Planning factor	Why it changes the answer	Common mistake
Packet mix	Small packets pay the fixed tunnel overhead more often than large packets.	Using file-transfer efficiency for voice, terminal, or control traffic.
Planning reserve	A 70% to 85% target leaves room for bursts, rekeys, retransmits, and growth.	Treating the mathematical ceiling as a rollout target.
Gateway throughput	Appliance, virtual gateway, or cloud encryption limits can be lower than the WAN rate.	Assuming a WAN upgrade fixes a crypto-bound tunnel.
MTU and MSS	Encapsulation reduces the safe inner packet size before fragmentation risk appears.	Ignoring MSS clamping until users report stalls or retransmits.

Diagram of a VPN capacity budget showing planned encrypted load, reserve, payload, inner headers, VPN overhead, and the MTU edge.

Several neighboring limits still sit outside a simple capacity estimate. Latency and jitter decide whether voice or remote-control traffic feels usable. Packet loss and retransmits raise real demand above the clean byte model. Route asymmetry, cipher choice, rekey behavior, and gateway CPU can also move the bottleneck away from the line-rate number.

The safest use of a VPN capacity number is as a planning boundary. It can show whether a proposed user count is clearly inside the target, consuming reserve, or beyond the modeled ceiling. It cannot prove application experience without measurements from the same busy-hour workload and the same tunnel path.

How to Use This Tool:

Model the encrypted path first, then refine the estimate with the traffic mix, per-user demand, reserve target, and MTU assumptions. The default run starts with a 1 Gbps IPsec NAT-T tunnel carrying mixed web and SaaS traffic.

Select the VPN profile. Choose Custom overhead bytes when packet captures, vendor documentation, or lab measurements give a better overhead value.
Enter the Tunnel line rate. Add a Gateway crypto cap when a VPN appliance, virtual gateway, or cloud tunnel encrypts less traffic than the underlay link can carry.
Choose the Traffic profile. Bulk TCP, mixed web and SaaS, voice UDP, and interactive TCP have different payload and inner-header sizes, so the payload efficiency changes.
Set Average user demand and Peak factor from monitoring, packet captures, or rollout assumptions. The peak demand per user shown in the summary should match a busy-hour design value, not a quiet average.
Enter Current concurrent users and the Planning target. If the summary reports reserve use or over-plan capacity, reduce the rollout count, raise capacity, or lower the target workload before relying on the result.
Use Parent interface MTU, Custom payload bytes, and Custom inner header bytes when fragmentation or MSS sizing is part of the decision. Clear any MTU warning before treating the plan as production-ready.
Check Capacity Snapshot, Overhead Packet Budget, User Load Ladder, and Tunnel Load Curve. A result is ready to share when the warnings match known design tradeoffs and the current user count sits where the planning team expects.

Interpreting Results:

The headline capacity is the largest whole concurrent-user count that fits inside the selected planning target after packet efficiency and peak per-user demand are applied. Spare users compare that modeled capacity with the current user count. A negative spare value means the current load is already beyond the chosen planning target, even if the hard encrypted ceiling has not been reached.

VPN tunnel result cues and responses
Result cue	Meaning	What to verify
Tunnel capacity ready	Current encrypted demand is at or below the selected planning target.	Confirm the per-user demand and packet mix with busy-hour data.
Capacity buffer is thin	Current utilization is close to the selected planning target.	Check growth plans, retransmits, rekeys, and burst behavior before adding users.
Current load uses reserve	Demand is below the hard ceiling but above the planning target.	Expect less room for spikes and measurement error.
Tunnel is over plan	The current user count exceeds the modeled planning capacity.	Add real encrypted capacity, reduce busy-hour demand, or split traffic only across tunnels that can actually share load.
MTU profile needs review	The modeled encrypted packet is larger than the parent MTU.	Review payload size, overhead bytes, underlay MTU, and TCP MSS clamping.

Payload efficiency is often the surprising number. A tunnel carrying small voice or interactive packets may spend a large share of encrypted bandwidth on headers and tunnel bytes, while bulk TCP can keep most of the encrypted path available for payload. The Overhead Packet Budget is the best place to check the byte assumptions behind the user count.

Do not treat a clean result as proof that users will have good experience. Compare the estimate with encrypted interface throughput, packet-size histograms, drop counters, retransmits, gateway CPU, and application response time from the same path and time window.

Technical Details:

VPN capacity math starts with an encrypted bandwidth budget and then converts it into a payload budget. The encrypted budget is the line rate unless a gateway crypto cap is entered and that cap, multiplied by active tunnels, is lower. The planning target reserves part of the encrypted ceiling before packet efficiency is applied.

Packet efficiency is based on average packet bytes. Payload bytes, inner IP/TCP or IP/UDP header bytes, and VPN overhead bytes are added into one encrypted packet estimate. Smaller payloads lower efficiency because the same fixed overhead is paid for less useful data.

Formula Core:

\begin{array}{lll} B_{effective} & = & \min (B_{line}, B_{gateway} \times N_{tunnels}) \\ E_{payload} & = & \frac{P}{P + H + O} \\ B_{payload-plan} & = & B_{effective} \times R_{plan} \times E_{payload} \\ D_{peak} & = & D_{avg} \times F_{peak} \\ Capacity & = & ⌊ \frac{B_{payload-plan}}{D_{peak}} ⌋ \end{array}

VPN tunnel formula variables
Symbol	Meaning	Unit or source
`Bline`	Tunnel line rate after unit conversion.	Mbps
`Bgateway`	Optional crypto cap per active tunnel. When no cap is entered, the line rate remains the ceiling.	Mbps
`Ntunnels`	Active tunnels that can actually share traffic.	Whole number from 1 to 64
`P`	Average application payload bytes in the packet mix.	Traffic profile or custom payload
`H`	Inner IP plus TCP or UDP header bytes.	Traffic profile or custom header
`O`	VPN overhead bytes added around the inner packet.	VPN profile or custom overhead
`Rplan`	Planning target as a decimal, so 75% becomes 0.75.	Planning target
`Davg`	Average cleartext demand per concurrent user after unit conversion.	Mbps
`Fpeak`	Multiplier applied to average user demand.	1.0 to 20.0

For the default run, a 1 Gbps tunnel and a 75% planning target give 750 Mbps of planned encrypted capacity. Mixed web and SaaS packets use 850 payload bytes, 40 inner-header bytes, and 96 VPN overhead bytes, so payload efficiency is 850 divided by 986, or about 86.2%. The payload planning ceiling is about 646.6 Mbps. With 850 Kbps average user demand and a 1.6 peak factor, peak demand is 1.36 Mbps per user, so the modeled capacity is 475 users.

Built-in VPN and packet planning assumptions
Assumption	Built-in values	Boundary
VPN overhead	IPsec ESP NAT-T/cloud default 96 B, IPsec ESP tunnel 84 B, IPsec IPv6 conservative 116 B, WireGuard over UDP 80 B, SSL VPN tunnel 64 B.	Custom overhead accepts 0 to 400 B when measured values are available.
Traffic packet mix	Bulk TCP 1328 B payload plus 40 B header, mixed web/SaaS 850 B plus 40 B, voice UDP 160 B plus 28 B, interactive TCP 64 B plus 40 B.	Custom payload accepts 1 to 8900 B, and custom inner header accepts 0 to 200 B.
MTU estimates	Safe inner MTU = parent MTU - VPN overhead. Safe TCP MSS = safe inner MTU - 40 B. Safe UDP payload = safe inner MTU - 28 B.	Parent interface MTU is constrained to 576 to 9000 B.
Utilization bands	At or below the planning target is inside plan. Above target but at or below 100% uses reserve. Above 100% is oversubscribed.	Thin-buffer status appears when current utilization exceeds 85% of the planning target.

Current utilization is computed by multiplying current users by peak per-user demand, dividing by payload efficiency to return to encrypted demand, and comparing that demand with the effective encrypted ceiling. Rounding uses whole users for capacity and displayed rounded rates for readability, so one-user edge cases should be checked against the detailed rows when the plan is tight.

Limitations, Privacy, and Accuracy Notes:

The estimate depends on the values entered. It does not measure a live tunnel, discover real gateway throughput, inspect routing, test path MTU, or model every cipher, padding choice, vendor frame, and rekey event. Replace built-in overhead and packet assumptions with measurements when the result drives a production change.

The calculation runs locally in your browser, and downloaded or copied results are generated from the current page values. Shared URLs can include input values, so avoid sending links that expose sensitive tunnel rates, gateway limits, user counts, or rollout plans.

Multi-tunnel estimates assume traffic can balance across the active tunnels and that the entered gateway cap is per tunnel. If a vendor publishes one aggregate crypto limit, enter that aggregate limit and keep active tunnels set to 1.

Advanced Tips:

Use packet-capture averages for Custom packet mix when the workload is voice-heavy, terminal-heavy, or dominated by small application messages.
Keep Planning target below 100% for user rollout decisions. Use 100% only to find the mathematical ceiling for comparison.
Enter the lower VPN appliance, virtual gateway, or cloud tunnel encryption number as Gateway crypto cap before assuming the WAN link is the bottleneck.
Use User Load Ladder to explain reserve consumption to stakeholders because it shows demand and headroom at selected user counts.
Compare Tunnel Load Curve after changing packet mix or peak factor. A curve that steepens quickly means small changes in users or demand can consume reserve.
Pair the safe TCP MSS estimate with device configuration checks; the number is a planning clue, not proof that every path segment uses that MTU.

Worked Examples:

Mixed SaaS rollout

With IPsec ESP NAT-T, a 1 Gbps line rate, mixed web and SaaS traffic, 850 Kbps average user demand, a 1.6 peak factor, 420 current users, and a 75% planning target, the modeled capacity is about 475 users. That leaves roughly 55 spare users, with payload efficiency near 86.2% and current encrypted utilization near 66.3%.

Voice packets on a smaller tunnel

A 200 Mbps IPsec NAT-T tunnel carrying voice RTP/UDP at 80 Kbps average demand per user, a 1.4 peak factor, and a 70% planning target fits about 704 users. If the current user count is 900, the result moves over plan because voice-sized packets spend a much larger share of the encrypted path on overhead.

Gateway-bound WireGuard path

A WireGuard plan with a 1 Gbps line rate, bulk TCP packets, 2 Mbps average demand, a 1.2 peak factor, and a 300 Mbps gateway crypto cap is limited by the gateway. The WAN link is not the active ceiling, so adding internet bandwidth alone would not improve the modeled tunnel capacity.

MTU warning from custom overhead

A custom packet profile with 180 B of VPN overhead, 1100 B of payload, 40 B of inner header, and a 1200 B parent MTU creates a 1320 B encrypted packet. The user count may still look acceptable, but the MTU warning should be fixed before relying on the plan.

FAQ:

Why not divide tunnel speed by average user demand?

That shortcut ignores VPN overhead, packet size, peak factor, planning reserve, and gateway crypto limits. It usually overstates capacity, especially for small-packet traffic.

Which traffic profile should I choose?

Use packet captures when possible. Without captures, choose the closest dominant workload: bulk TCP for large transfers, mixed web and SaaS for ordinary browser traffic, voice UDP for RTP-like traffic, or interactive TCP for small control packets.

What planning target is reasonable?

A 70% to 85% target is a common planning range because it leaves capacity for bursts, variance, rekeys, retransmits, and growth. Use 100% only when comparing against the hard mathematical ceiling.

Does safe TCP MSS guarantee no fragmentation?

No. It is an estimate from parent MTU and modeled overhead. Real paths can include lower MTU segments, TCP options, different headers, or devices that handle fragmentation differently.

Can several active tunnels be added together?

Yes, but only when traffic can actually balance across them. Standby tunnels, policy routes that pin traffic to one path, or aggregate vendor limits should not be modeled as independent extra capacity.

Glossary:

VPN overhead: Bytes added by outer IP, UDP or NAT traversal, ESP, WireGuard, TLS, integrity data, padding, or another tunnel wrapper.
Payload efficiency: The percentage of encrypted packet bytes that carry application payload.
Effective encrypted ceiling: The encrypted bandwidth limit after the line rate is compared with any gateway crypto cap.
Peak factor: A multiplier that turns average per-user demand into a busier planning demand.
Safe TCP MSS: The estimated TCP segment size that should fit after VPN overhead and IPv4 TCP/IP headers are subtracted from the parent MTU.
User Load Ladder: A result table showing selected user counts, encrypted demand, utilization, and headroom against modeled capacity.

References:

RFC 4303: IP Encapsulating Security Payload (ESP), RFC Editor.
RFC 3948: UDP Encapsulation of IPsec ESP Packets, RFC Editor.
WireGuard Protocol & Cryptography, WireGuard.
RFC 9293: Transmission Control Protocol (TCP), RFC Editor.
RFC 768: User Datagram Protocol (UDP), RFC Editor.
RFC 1191: Path MTU Discovery, RFC Editor.