iperf3 testing 500/40 connection: 33mpbs
-
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
-
@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 msThis is a ping outside the tunnel from my friend's UniFi USG 200/200 fibre to my SG-1100 500/40 cable.
-
@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 ;)
-
@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 -
@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?
ThanksSure 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_LinuxHere 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.
-
@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 -
@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..
-
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
-
@johnpoz @stephenw10 : If I put up a VPN connection on two SG-1100 units, one at each node, I can probably max out that hardware.
I just had an insight: replacing the hardware at only one end node (e.g. swapping one of the SG-1100's for a beefy SG-6100) will probably make zero difference as the other end will be the bottleneck. Correct?
Thanks,
Pete -
Probably, though there is a difference between encode and decode loading you may find it helps in one direction.
Steve
-
This post is deleted! -
@stephenw10 The key assumption is that the firewall CPU is the bottleneck, correct? So you are suggesting there might be an asynchronous CPU load for server side vs client side? That sounds interesting.
The next question then is: at which end would I place the most powerful device?No wait - I should be able to figure this out myself by testing the same connection again and then watch the CPU load at both ends and look for differences. Would this be a good approach?
-
Yes, I would do that. It's not a huge difference but if you're only upgrading one side you might as well do it to the side seeing the heaviest load.
Steve
-
@stephenw10 Just one more question to make this effort more than just academic: How would I create multiple simultaneous VPN connections? If I'd create several VPN server instances in the OpenVPN settings, I can only assume I'd have to choose a different tunnel subnet for each, and how would they together constitute one "wide" connection with permissions to the same VLAN(s)? How would the system balance routing packets through the individual tunnels? Or am I seeing this all the wrong way?
Thanks, Pete
-
It's possible to do that. You have to use policy routing with a load-balanced gateway group setup with both remote side IPs as gateways.
However that only works for multiple connections between the sites. For a single file transfer for example it will only use one tunnel.
Steve
