Wireguard Site-to-Site Performance

General discussion
1

Hi everyone, happy Monday :slight_smile:

I know, this post could also go to a Wireguard/AVM/OpenWRT/… forum, but around here answers are usually most useful. :slight_smile:

Upon being notified by Discomp s.r.o. (discomp.cz) about Turris Academy #4 I decided to evaluate the performance on my site-to-site Wireguard VPN.

What is working?

  • everything
  • I can access resources on the other site, pings work, transfers work

What is not working?

  • Nothing.

Setup:

  • Site A
    • Wireguard runs on Turris Omnia
    • Limited by upload to 15 MBit/s (indicated by red arrow in picture below)
  • Site B
    • The Wireguard VPN endpoints runs on a RaspberryPi 4 behind an AVM FritzBox 7490
    • Limited by upload to 40 MBit/s (indicated by red arrow in picture below)

image
image1407×416 41.9 KB

What is questionable / problem:

  • Performance across the site-to-site Wireguard VPN
  • From Site A to Site B transfers range around 10 MBit/s (only 66% of the line’s capacity) (I would expect approx. 12-14 MBit/s)
  • From Site B to Site A transfers range around 18 MBit/s (only 45% of the line’s capacity) (I would expect approx. 30-35 MBit/s)

Analysis done so far:

  • Both routers (Turris Omnia and AVM Fritz Box) are “bored”. There is no significant CPU usage when performing tests using iperf (running on the Turris Omnia and the RaspberryPi)
  • The RaspberryPi 4 is “bored” also, no significant impact on the CPU either.
  • Speedtests (e.g. Ookla) confirm the lines’ capacity indicated by the green and red arrows.

Key questions:

  1. What my be reasons for the low performance?
  2. What should be evaluated to identify the bottleneck?

Thanks so much!

1 Like
2

After a bit of research and attempts I “kind of” fixed the problem.

What I did was to reduce the MTU on both ends from (the Wireguard default) 1420 bytes to 1412 bytes.

Now I achieve

  • approx. 33-34 MBits/s from site B to site A (~ 83%)
  • approx. 11,5 MBit/s from site A to site B (~ 77%)

Background/Thoughts:

  • Site A is connected by cable (DOCSIS 3.0) which (according to my research) usually has a MTU of 1500
  • Site B is connected by DSL (VDSL2) which (according to my research) usually has a MTU of 1492
  • The minimum of the two, 1492, minus 40 bytes for an IPv6 header, minus 8 bytes for UDP, and minus 32 bytes for Wireguard --> 1412 bytes
  • Note: I used a 40 byte IPv6 header in my calculation even though the connection is IPv4 only as I rather lose 8 bytes per packet (~ 0,5%) than having fragmented packages.

Conclusion, the lower MTU of 1412 works better than 1420 previously.

3 Likes
3

Wow, you did a great research on the MTU!
To anyone who experiences similar issue, I recommend to use some on-line MTU calculator like Visual packet size calculator or Encapsulation overhead calculator

Anyway, during our tests in the lab, we were able to achieve nearly the wire speed.

4

This topic was automatically closed after 60 days. New replies are no longer allowed.