What are “Expected” IKEv2 Mobile VPN speeds with Firebox T40?

We have recently upgraded some aspects of our internet service, and I am experiencing VPN speeds (connecting from home to office) that I think are slower than they should. But before trying to solve any problems, I was wanting confirmation that there actually is a problem.

Office specs:

  • ISP connection is nominally a 1 Gbps download / 1 Gbps upload
  • We have a Watchguard Firebox T40 (see specs below)
  • If using Ookla speedtest (in MS Edge browser – see note below on why) I get:

Home Internet specs:

  • ISP connection is nominally a 180 Mbps download / 10 Mbps upload
  • If using Ookla speedtest (in MS Edge browser) I get:
    • Download speeds: 120 Mbps
    • Upload speeds: 10 Mbps
    • Ping (idle/download/upload): 20/40/25 ms
    • These values are repeatable within ~20% when tested across different days, time of days, etc.

Firebox T40 specs:

IKEv2 Mobile VPN Speed tests:
Note: I was previously using SSL, which was slower than IKEv2 for all measures .

  • Iperf3 (client at home, server at office):

    • 9.5 Mbps send
    • 9.5 Mbps receive.
  • Mean speed to transfer a 40 MB file:

    • 8 Mbps (office to home)
    • 8 Mbps (home to office)
  • Note: for both tests these values are repeatable within ~20% when tested across different days, time of days, etc.

  • Note: colleagues of mine get similar results for iperf3 (10-16 Mbps) when testing from their home to their office PC (i.e. completely different computers at both ends from my tests and different home ISP)

The values I observe going from home to office are what I would expect, because of my home ISP’s upload speed limit of 10 Mbps.
The values I observe going from office to home are about 10% of what I would expect (i.e. I was expecting ~ 80-100 Mbps, not 8-10 Mbps). Again, I think that my home ISP should be the limiting factor.

Are my expectations incorrect? If so, why?


  • What is the latency of your connection between your home & the office?

    Review the calcs here:

    How to Calculate TCP throughput for long distance WAN links http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/

    although I may have a 1GE link between these Data Centers I should not expect any more than 17Mbps when transferring a file between two servers, given the TCP window size and latency.

  • Specific to the T20 and T40 series there was an issue with performance if on a 12.8.x firmware which was fixed in 12.8.2U1 (https://portal.watchguard.com/wgknowledgebase?type=Known Issues&SFDCID=kA16S0000007lO7SAI&lang=en_US)

    If you haven't already upgraded the T40's firmware I would do this first as I had a client setup with a T40-W that had this exact issue and the upgrade did resolve the speed issue with a 400Mbps link.

    At that point you can then retest and see if the issue is somewhere else.

  • Thanks! That link provides a nice, clear explanation of basic throughput.

    My RTT latency (using ping) was ~40 ms. So using that link, that gives ~13.1 Mbps, which is getting close to what I observe.

    However... I then ran some additional tests using iperf3, which apparently allows me to set the TCP Window size. The following is what I observed:
    o -w 8k: ~1.7 Mbps
    o -w 16k: ~3.4 Mbps
    o -w 32k: ~6.6 Mbps
    o -w 64k: ~9.2 Mbps
    o -w 128k: ~9.2 Mbps

    Those results make sense for TCP Window size from 8 - 32k (i.e. throughput increases linearly with Window size, and given my 40 ms latency those values are almost exactly as expected), but then the 64k window does not result in a doubling of Window size, and 128k windows have identical performance to 64k windows. I am not sure how to interpret these results? Does that mean that something else is limiting/fixing the TCP Window size (i.e. over-riding iperf3)? Or is does this reflect something else limiting the throughput?

  • Sorry, no idea.
    I found that article in 2019 to help someone else understand this type of issue.
    TCP Windows size possibilities & limitiations are beyond my knowledge.

    Could it be a TCP Window size setting on the other end??

  • Thanks @PhilT_VIT. We are on a slightly order firmware version, so we will update at some point in the next few weeks and I can test that out to see if that fixes my problem(s).

Sign In to comment.