VPN overhead

[nightowl]

Does anyone know how much overhead a VPN connection has on a network link. Is it around 25% or is is more or less than that. I am specifically looking for information on how a VPN connection affects a wireless connection.

 

[Thoreau]

<Not-100%-informed + opinion>

I would think that it would be dependent on the specific VPN protocols used and the level of encryption that is set. The higher the encryption, the higher the security & overhead. Personlly, even at 25% (if that number is accurate.. sounds about right to my feeble mind) overhead, I would gladly run it if I used a wireless network. The security is very much worth it to me, especially since I would be using 802.11g if anything.

</Not-100%-informed + opinion>

 

[Sunner]

In my experience, it's nowhere near 25%.

My connection between work and home is using SHA1/3DES for main mode and MD5/3DES for quick, and Im getting damn near 100% throughput, overhead is small enough not to be noticeable.
10 Mbit line at home and 6 Mbit at work.
No idea about wireless stuff or SOHO routers though.

 

[ScottMac]

The packet size doesn't really vary that much. The overhead tends to be in the line of processing power and, based on processing power and load, the latency overhead of encrypting / decrypting.

Many /most / all of the public encryption schemes do not allow L3 fragmentation. Packets that need to be fragged (and can't be because of the "not not frag" bit being set will be dropped.

FWIW

Scott

 

[cmetz]

nightowl, on an 802.11b wireless connection, real-world throughput is like 2-5Mb/s. For ESP 3DES/HMAC-SHA1, the per-packet byte overhead is not going to be the bottleneck - the crypto speed of the endpoints is. 2Mb/s isn't too much for a PC, but 5Mb/s is starting to get to be a pretty interesting level of performance. Most SOHO VPN routers without crypto accelerator chips can do maybe hundreds of kb/s. SOHO VPN routers with crypto accelerator chips can do a few Mb/s. More than that and you're talking big $$.

ScottMac, I'm a bit confused by your fragmentation statement - it really just doesn't parse. Encryption has nothing at all to do with it, only VPN technology. For IPsec, there are well defined rules for when the inside DF bit gets copied to the outside DF bit and for IPsec security gateways to proxy ICMP too bigs in certain ways to make PMTU discovery work right. That doesn't mean the vendors get it right; IPsec gateway vendors are amazingly underclued for the amount of trust that's placed in their products. For other VPN technologies, I don't know what they do... I assume that most of them ignore DF entirely on the inside and don't set DF on the outside, and thusly create outer fragmentation.

In the case of 802.11 wireless, you can cheat a little - 802.11 if I'm not mistaken supports frame sizes up to somewhere in the neighborhood of 11kb. If your endpoints support it, you could construct a MTU=1500 virtual interface and up the 802.11 physical interface MTU to 2048 or whatever, and work that way. This would be very handy if you're doing the VPN just for over the air and then routing to another Ethernet network, as you can achieve an end-to-end MTU of 1500. (for various reasons, your life will be simpler if your MTU to most of the world is 1500. Not supposed to matter, but it sometimes does).