What's the fastest speeds you've experienced?

[Terry Stanford 11]

I am choosing a new ISP contract. They are trying to sell me a 500mbps contract, when I just remembered VPN's don't run at native ISP speeds! To help me decide, I wondered if people could chip in here with the very FASTEST speeds they have ever experienced with AirVPN? (download speeds) Anyone ever seen 100mbps? 200?!...

[Staff 9764]

Hello!

You may like to start from here:
https://airvpn.org/forums/topic/48234-speedtest-comparison/?do=findComment&comment=130191

Kind regards
 

[Terry Stanford 11]

Holy Smokes!!!!!!!!

[Terry Stanford 11]

Ha, didn't think to say, I meant without Wireguard. Am I right in thinking Wireguard speeds are faster?

[OpenSourcerer 1361]

I am capable of maxing out my line, 250/40 Mbit/s, if I really need it, with carefully selected servers, which for me are currently Kitalpha and Mesarthim, using OpenVPN. In the near future, a Gbit fiber line will be at my disposal, so some more tests and optimizations will be done. I'll try to remember posting about it here afterwards.

[Terry Stanford 11]

Can I ask, do you not use Wireguard? If not, why not?
I don't, I had reservations about privacy for years so never used it. But people are saying it's fine to use now, would be interested in your thoughts.

[OpenSourcerer 1361]

1 hour ago, Terry Stanford said:

Can I ask, do you not use Wireguard? If not, why not?

wg-quick doesn't work for me. I mean, it brings up a connection, alright, but there is practically no traffic. It does work when imported with nmcli as described in a thread, then used with NetworkManager. But this way all traffic is routed through the VPN, including local. It's not as flexible as defining a few --route directives if you need them, then reconnect and you're golden.
Besides, I can max out my line with OpenVPN. There is no need to rethink the infrastructure if the purpose of using a VPN gets fulfilled. And it's not like OpenVPN is an obsolete thing and in the process of being phased out, so there really is no pressure to switch.

Privately, though, I do use Wireguard to connect to my home network, and soon for the interconnection of all home networks in my family. I used IPsec for both in the past and upgrading from that is really a step-up.

As for the privacy argument… I never even remotely considered which of the two is "more private". My use case does not warrant getting crazy over such a thing.

[Terry Stanford 11]

Thanks. nobody is 'getting crazy', I assume most people's choice to use a VPN is to enhance their privacy online at least a little. So when both OpenVPN and WG work, and WG is faster, I naturally wonder if there is a trade off and was told there was a big trade off in privacy, but that was a few years ago (at least) so it's probably not an issue any more
I am trying it and I don't like the official Wireguard app, not very functionally useful for me, so will go back to Eddie i think

[oassQ9w4cbl4AySZhhth%p36x 2]

On 5/15/2023 at 4:57 PM, OpenSourcerer said:

wg-quick doesn't work for me. I mean, it brings up a connection, alright, but there is practically no traffic. It does work when imported with nmcli as described in a thread, then used with NetworkManager. But this way all traffic is routed through the VPN, including local. It's not as flexible as defining a few --route directives if you need them, then reconnect and you're golden.
Besides, I can max out my line with OpenVPN. There is no need to rethink the infrastructure if the purpose of using a VPN gets fulfilled. And it's not like OpenVPN is an obsolete thing and in the process of being phased out, so there really is no pressure to switch.

Privately, though, I do use Wireguard to connect to my home network, and soon for the interconnection of all home networks in my family. I used IPsec for both in the past and upgrading from that is really a step-up.

As for the privacy argument… I never even remotely considered which of the two is "more private". My use case does not warrant getting crazy over such a thing.

as someone who migrated recently to wireguard, one nice thing about it is that its method of doing replay attack prevention is better. with openvpn you get latency and its time based upon whether it drops packets or not. With wireguard it uses an incremental counter to keep track of it, so you almost never drop traffic. 

 

[Staff 9764]

5 hours ago, oassQ9w4cbl4AySZhhth%p36x said:

as someone who migrated recently to wireguard, one nice thing about it is that its method of doing replay attack prevention is better. with openvpn you get latency and its time based upon whether it drops packets or not. With wireguard it uses an incremental counter to keep track of it, so you almost never drop traffic.

Hello!
Well, If a packet fails the authentication it must be dropped. WireGuard will drop forged packets (the contrary would trivially mean that it's highly insecure, which is not the case).

OpenVPN replay protection is time based and size based. Additionally OpenVPN can work over TCP.

OpenVPN is highly configurable, in UDP you can modify the replay protection sliding-window size and time through the proper directives, so you can make it identical to WireGuard to perform consistent tests. OpenVPN default sliding window size is 64 (identical to IPsec) with 15 seconds time. This is a very robust setup but at the same time you can modify it according to the type of network you are in (while you can't do it with WireGuard, unfortunately) . If you want to test consistently to make a comparison with WireGuard you can replicate WireGuard settings in OpenVPN (while you can't do the same in WireGuard). By comparison, check the settings and hard coded implementation in WireGuard https://www.wireguard.com/protocol/#nonce-reuse-replay-attacks
 

Quote

A 64bit counter is used, and cannot be wound backward. UDP, however, sometimes delivers messages out of order. For that reason we use a sliding window, in which we keep track of the greatest counter received and a window of roughly 2000 prior values, checked after verifying the authentication tag. This avoids replay attacks while ensuring nonces are never reused and that UDP can maintain out-of-order delivery performance.

with those in OpenVPN, test accordingly and then draw your own conclusions.
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/
 

Quote   --replay-window args   Modify the replay protection sliding-window size and time window. Valid syntaxes: replay-window n replay-window n t Use a replay protection sliding-window of size n and a time window of t seconds. By default n is 64 (the IPSec default) and t is 15 seconds. This option is only relevant in UDP mode, i.e. when either --proto udp is specified, or no --proto option is specified. When OpenVPN tunnels IP packets over UDP, there is the possibility that packets might be dropped or delivered out of order. Because OpenVPN, like IPSec, is emulating the physical network layer, it will accept an out-of-order packet sequence, and will deliver such packets in the same order they were received to the TCP/IP protocol stack, provided they satisfy several constraints. The packet cannot be a replay (unless --no-replay is specified, which disables replay protection altogether). If a packet arrives out of order, it will only be accepted if the difference between its sequence number and the highest sequence number received so far is less than n. If a packet arrives out of order, it will only be accepted if it arrives no later than t seconds after any packet containing a higher sequence number. If you are using a network link with a large pipeline (meaning that the product of bandwidth and latency is high), you may want to use a larger value for n. Satellite links in particular often require this. If you run OpenVPN at --verb 4, you will see the message "PID_ERR replay-window backtrack occurred [x]" every time the maximum sequence number backtrack seen thus far increases. This can be used to calibrate n. There is some controversy on the appropriate method of handling packet reordering at the security layer. Namely, to what extent should the security layer protect the encapsulated protocol from attacks which masquerade as the kinds of normal packet loss and reordering that occur over IP networks? The IPSec and OpenVPN approach is to allow packet reordering within a certain fixed sequence number window. OpenVPN adds to the IPSec model by limiting the window size in time as well as sequence space. OpenVPN also adds TCP transport as an option (not offered by IPSec) in which case OpenVPN can adopt a very strict attitude towards message deletion and reordering: Don't allow it. Since TCP guarantees reliability, any packet loss or reordering event can be assumed to be an attack. In this sense, it could be argued that TCP tunnel transport is preferred when tunneling non-IP or UDP application protocols which might be vulnerable to a message deletion or reordering attack which falls within the normal operational parameters of IP networks. So I would make the statement that one should never tunnel a non-IP protocol or UDP application protocol over UDP, if the protocol might be vulnerable to a message deletion or reordering attack that falls within the normal operating parameters of what is to be expected from the physical IP layer. The problem is easily fixed by simply using TCP as the VPN transport layer.

M

Kind regards
 

[OpenSourcerer 1361]

On 5/16/2023 at 1:22 PM, Terry Stanford said:

So when both OpenVPN and WG work, and WG is faster, I naturally wonder if there is a trade off and was told there was a big trade off in privacy, but that was a few years ago (at least) so it's probably not an issue any more

There still is, though, see the FAQ.

---

I think we should somehow pool together all the info and metrics for different connection setups and create optimized settings for OpenVPN and Wireguard for all to use. I'm envisioning a small helper program to generate the settings. The user selects:

• Connection technology: wireless, ethernet, etc.
• Type of internet: GSM, DSL, DOCSIS, fiber, tethering (wireless, Bluetooth or USB), etc.
• Latency and throughput, maybe even automatically tested
• Protocol: OpenVPN or Wireguard, for OpenVPN also TCP, UDP, SSL, SSH or Tor
• OS and architecture
• …

The tool will then print the settings one can put into the respective config: Special directives on OpenVPN like --fast-io for *nix, --link-mtu, --tun-mtu, --fragment, --mssfix, --replay-window and other values optimized for the respective connection path, choice of cipher between AES and ChaCha20 based on the CPU flags, etcetc.

[oassQ9w4cbl4AySZhhth%p36x 2]

2 hours ago, Staff said:

Hello!
Well, If a packet fails the authentication it must be dropped. WireGuard will drop forged packets (the contrary would trivially mean that it's highly insecure, which is not the case).

OpenVPN replay protection is time based and size based. Additionally OpenVPN can work over TCP.

OpenVPN is highly configurable, in UDP you can modify the replay protection sliding-window size and time through the proper directives, so you can make it identical to WireGuard to perform consistent tests. OpenVPN default sliding window size is 64 (identical to IPsec) with 15 seconds time. This is a very robust setup but at the same time you can modify it according to the type of network you are in (while you can't do it with WireGuard, unfortunately) . If you want to test consistently to make a comparison with WireGuard you can replicate WireGuard settings in OpenVPN (while you can't do the same in WireGuard). By comparison, check the settings and hard coded implementation in WireGuard https://www.wireguard.com/protocol/#nonce-reuse-replay-attacks
 
with those in OpenVPN, test accordingly and then draw your own conclusions.
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/
 

	M

Kind regards
 

hi yep i know of those settings and tried numerous variables to try and get it under control but it still wasn't possible and it makes sense that it wasn't. When the end point can do say on average 300 mbps and you are attempting to push 500 mbps or more through it, its normal that the latency goes through the roof. 

In my network I also implement FQ_CODEL so thats an additional form of packet loss too once the latency gateways get high. I've not seen a compelling case for time based replay attack prevention being better just an incremental counter - i guess in theory if its counting up / down then someone could interject packets and try calculate the next counter but its hard to imagine such a thing occurring. 

I could also just be observing the nature of the server being able to process packets at the speed sufficient for my connection