FireBrick IPsec Throughput

Back up to the FireBrick IPsec Tunnels Category Page
From AAISP Support Site
Revision as of 23:59, 14 March 2017 by Reedy (talk | contribs) (clean up, typos fixed: 15Mb/s → 15Mbit/s (4), eg → e.g. (2))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


On a FB 2700, throughput should be around 10 - 15Mbit/s.

Here is a speedtest from a Road Warrior on a good internet connection connected to a FB2700 on a single 60Mbit/s down and 20Mbit/s up FTTC, using HMAC-SHA1

Speedtest over a FB2700 IPsec tunnel
Another speedtest over a FB2700 IPsec tunnel
Download over a FB2700 IPsec tunnel

A FB6000 can do nearer 50Mbit/s, whilst newer generation of FireBrick hardware should be even better.


Other notes on throughput

If an IPsec connection is slow, it is useful check a few other things. Latency can have large impact on e.g. a TCP connection so it's good to:

  • Try a ping with a large payload (e.g. 1400 bytes)
  • The window buffer size needs to be larger the larger the latency, as it needs to be able to support holding data for the whole round-trip-time. see below


Window Buffer Size

Increasing the window size may help with throughput.

The window buffer size needs to be larger the larger the latency, as it needs to be able to support holding data for the whole round-trip-time. The way TCP works is that the sender is not allowed to send more data than would fit in the receiver's incoming TCP window (which the sender knows the size of). The sender only gets to know how much room is left in the receiver's buffer after each ACK comes back, which is the round-trip time since the data was sent Which means there can never be more data in flow than would fit in the receiver's buffer. This used to be a problem with older MS-windows machines which had small TCP windows - but is less of a problem now.