iperf3 testing 500/40 connection: 33mpbs

stephenw10

Add a specific rule to allow only that ping from the remote public IP.

Patch

@cabledude said in iperf3 testing 500/40 connection: 33mpbs:

Actually I did test all individual components

What about the hardware at the other end? Running a vpn tunnel is reasonalbly processor intensive.

Cabledude

@stephenw10 said in iperf3 testing 500/40 connection: 33mpbs:

Add a specific rule to allow only that ping from the remote public IP.

Something of this sort?
Schermafbeelding 2021-12-19 om 00.51.00.jpg

Cabledude

@patch said in iperf3 testing 500/40 connection: 33mpbs:

What about the hardware at the other end? Running a vpn tunnel is reasonalbly processor intensive.

this is my end (speedtest is over WiFi but FTR VPN test was wired):
Schermafbeelding 2021-12-18 om 23.47.59.jpg

My friend's firewall is a USG 3P but the VPN wasn't S2S but remote access so I think his firewall isn't doing any encryption is it?
This is his line:
Schermafbeelding 2021-12-18 om 23.48.59.jpg

stephenw10

@cabledude said in iperf3 testing 500/40 connection: 33mpbs:

Something of this sort?

I would set the protocol to ICMP and the destination to WAN address. But since that's a single source IP and one you trust the risk is minimal.

Steve

johnpoz

Just taking his 18ms I see there as lowest one..

With only a 64k window your looking at 29.13 Mbit/sec due to the BDP..

Also lets not forget the overhead, are you trying to send 1500, those will get fragmented, again also lowering the performance. What is the box on his end doing the vpn connection? His router, what router is that - if some soho type of router, while it might be able to do a 200mbps connection, what can it push through a openvpn connection?

You prob want to adjust your txqueuelen and your tcp-queue-limit as well if your trying to see what is the max you could achieve for performance.

Cabledude

@johnpoz said in iperf3 testing 500/40 connection: 33mpbs:

Just taking his 18ms I see there as lowest one..

With only a 64k window your looking at 29.13 Mbit/sec due to the BDP..

That sounds about right! Could you share your calculation, I am very interested in that.

His router is a UniFi USG 3P. Not the fastest box but he can do about 80 mbps with his VPNs.

johnpoz

@cabledude

https://www.cisco.com/c/en/us/support/docs/ip/transmission-control-protocol-tcp/200943-Why-Your-Application-only-Uses-10Mbps-Ev.html#anc3

There are few calculators around.. Here is one I use
https://www.switch.ch/network/tools/tcp_throughput/

Cabledude

@johnpoz Hi John, thank you, good read.
I was just thinking what protocol am I using for the pfSense OpenVPN setup and it is UDP. Is this relevant for the BDP? If i read the article correctly it assumes TCP.

Thank you for helping out! I am learning every day :)

Pete

johnpoz

@cabledude what your tunnel is doesn't really matter. Your testing with TCP from your iperf outputs.

Cabledude

@johnpoz Ah okay I see, thank you.

So apparently building a VPN tunnel for high speed backups isn't as easy as simply connecting two gigabit nodes.

In order to troubleshoot further, would it be of any use to repeat the iperf3 test using UDP? Or using any other flags?

My friend is not available for further testing today but I might get a chance next week. He is willing to ping to my network tonight (UTC +1) though.

Pete

johnpoz

@cabledude said in iperf3 testing 500/40 connection: 33mpbs:

would it be of any use to repeat the iperf3 test using UDP?

Depends on what your wanting accomplish - if just to see if a difference sure, but does your backup actually leverage udp ;)

stephenw10

Testing using UDP eliminates the TCP windowing/ack packets issue so can be useful as long as you interpret the result correctly.

You should definitely use UDP for the VPN tunnel itself. You should only ever use TCP there if you are forced to, like is UDP is blocked. A TCP connection inside a TCP tunnel can produce horrible results.

Steve

Cabledude

@stephenw10 said in iperf3 testing 500/40 connection: 33mpbs:

Not really, you'd have to ping between the public IPs directly outside the VPN.

18 packets transmitted, 18 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 15.493/18.116/24.227/2.289 ms

This is a ping outside the tunnel from my friend's UniFi USG 200/200 fibre to my SG-1100 500/40 cable.

johnpoz

@cabledude said in iperf3 testing 500/40 connection: 33mpbs:

15.493/18.116/24.227

Yeah with those ping results, without updating your window size your seeing what would be prob normal for a 64k window size..

I recently got pulled into an issue in real life work ;) Where a customer was complaining they were seeing terrible speeds in an app from their location into the DC, well its like 30ms between the locations.

Their local firewall (palo) was preventing the window size from scaling - because they were using syn cookies..

You would be surprised how many time issues with bandwidth comes down to window size ;) We have a gig pipe and only seeing fraction of that - well yeah your X ms apart and using window size Y.. So yeah your not going to be able to come anywhere close to filling the pipe ;)

Cabledude

@johnpoz said in iperf3 testing 500/40 connection: 33mpbs:

Yeah with those ping results, without updating your window size your seeing what would be prob normal for a 64k window size..

You would be surprised how many time issues with bandwidth comes down to window size ;) We have a gig pipe and only seeing fraction of that - well yeah your X ms apart and using window size Y.. So yeah your not going to be able to come anywhere close to filling the pipe ;)

@johnpoz
Dear John,
Thank you for laying that out. As from tomorrow I will be having a second WAN to play with, a fiber gig line.

I had a good look at the BDP calculator you linked to. Looking at the variables, the only factor that is within our control is the window size. Thus, there is no other way to benefit from the gigabit potential than to increase the window size. I may do some testing using varying numbers here:

Ultimately, after reading VPN scaling,I may need to revert to IPsec instead of OpenVPN.

Question 1
Do you have any advice for me there? This connection is for a handful of users only (my family and me) and only I will be stressing it for speed.

Also (Question 2), after doing the math above, getting a much more powerful negate appliance such as the 3100 or even 6100 won't speed up the OpenVPN connection if the window size is too small. Is openVPN even a viable solution at all if I would like to achieve several 100 mbps throughput?

Thanks
Pete

johnpoz

@cabledude said in iperf3 testing 500/40 connection: 33mpbs:

Is openVPN even a viable solution at all if I would like to achieve several 100 mbps throughput?
Thanks

Sure it is.. Keep in mind that the outside tunnel is normally UDP, where there is not acks, etc. so the tcp traffic inside window size can be adjusted.

There is also the MTU of the tunnel that can be adjust, etc.

the only factor that is within our control is the window size

This is true when your talking about BDP sure..

only I will be stressing it for speed.

Not sure exactly what that means - what speed are you trying to achive, and why?

Is openVPN even a viable solution at all if I would like to achieve several 100 mbps throughput?

Yeah it is.. This is becoming dated but you might want to look at
https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux

Here is is really a pretty much stock openvpn connection running on a very low cost VPS I have out in LV.. Look at the latency.. And still can achieve almost 200mbps through it.. My upload is limited to 50, and looking I currently have 2 clients streaming off my plex server.. So

here is plex running

Which could put a real stress on my upload. So I wouldn't look to much at that, I only have 50 up max.. And this time of night its rare to see that..

I wasn't try to push you away from openvpn, was just trying to point out when doing such tests that quite often there can be variables at play that typical users might not be aware of that can effect results, etc.

Cabledude

@johnpoz Thank you, that helps somewhat. And I mean that in a very positive way as I consider myself a newbie here. Only a year ago I was quite unaware of networking, except that I knew how to set up a router in bridge mode and configure my own firewall (started with UniFi USG, now SG-1100).
I am really struggling with this VPN stuff as I feel I need to learn so much in order to be able to do even some simple tricks. It took me quite some hours of learning how to set up OpenVPN on pfSense (with FreeRADIUS to authenticate) and connect to my network from my Macbook while off site. I managed to do this, with mostly default settings. It's like learning how to sail: one can be up and going in a few days but learning the fine details can take years.

Anyway sorry for the long post this has become.

I absolutely don't understand how you manage 200mbps with 70ms latency:

So you would need a massive window size to accomplish this. Or am I seeing this the wrong way? Could you shed some light or share your secret?

Thanks,
Pete

johnpoz

@cabledude keep in mind doing multiple streams - the other option to doing large window sizes ;) for overcoming latency..

Game is on - so don't have a chance currently... But I will repeat the test in morning and check the window size being used.

Just wanted to show that openvpn can quite easy handle over 100mbps..

stephenw10

As a side note I enable fastIO and set send/recv buffers to 512K on pretty much any server I configure these days. Unless it's a TCP tunnel but if you're doing that speed will be low anyway.

Steve