Thank you for taking your time to reply again! Unfortunately I think did not make myself clear, I am not a native speaker nor a network professional so I am probably misusing some terms; I will try to rephrase my questions:
Regarding geo distance, yes, less hops. For example, if I live in San Francisco and connect to a server in LA, I will get better speed compared to connecting to a server in Hong Kong. This is the Latency metric you see on speed test sites. So, when you see someone posting awesome VPN speed, you also need to consider geo distance to the server they are connected to. If they were to connect to a server half way across the globe, the speeds will be lower.
When you say "speed" I feel like you mean bandwidth, which again, I couldn't care less about. I understand this is the most important metric for most people, but personally I can live with couple megabits (for this particular connection). I also understand that communicating with any server far away (using any protocol) has to be slower (as in latency) than communicating with a server that is close by, simply because we are bound by the speed of light (but also because we are jumping through more hops).
What I am trying to clarify is if the process of renegotiating the key itself is going to taker longer with a server that is far away (and if so, why?). So in my scenario (with bogus numbers):
- I connect to a server that is 1000 km away. The connection can do 100mbits and has 50 ms latency. On my slow device the renegotiating of the key takes 1000ms.
- I connect to a server that is 5000km away. The connection can do 50mbits and has 250 ms latency. Will the renegotiating of the key take more than 1000ms (using the same device) and if so, why?
The only answer I can think of is the key reneg process is basically a full handshake (and not just symmetrically encrypted UDP data flow) and so while the client has to wait for the server to answer (and vice versa) before proceeding the latency will accumulate? Is this correct?
My understanding is acceleration has to do with the CPU.
It surely is the case with AES-NI, but things like hardware crypto acceleration cards exist and openssl can take an advantage of those too; what I am trying to understand is what makes it impossible for somebody to code an emulated crypto card that's multi threaded and use that for encrypting/decrypting. I will try to explain it better below:
One limitation is the architecture of OpenVPN. It is single core threaded. So, if you have a multi core CPU, it will only use one core.
I accept that OpenVPN itself is a single threaded program, I don't mean to mess with this situation at all. What I am saying is the program that OpenVPN is offloading it's crypto operations does NOT need to be single threaded as well, unless I am misunderstanding how things work to a comical degree. Let me expose my ignorance with some pseudo "code":
[..... we have an established connection and we get some data to send from the client ...]
in OpenVPN client (all happening in the same thread):
encryptData(data, cipher, key)
{
return libOpenSSL(data, cipher, key)
[... CPU jumps into OpenSSL library ...]
{
cryptEngine = pickEncryptionEngine(cipher);
//openSSL tries to pick the fastest way to handle the encryption
[here is the interesting part; if we are using no acceleration (or a built in one like AES-NI) the CPU just jumps to the appropriate library and does the calculations; if we are using a HW card it will make a call to the driver; either way we are still staying in the same thread as far as OpenVPN is concerned, it will just wait/sleep till something returns data]
[the only difference from the program's perspective is how fast the data gets returned]
return cryptEngine->encrypt(data, cipher, key);
}
}
So what I thought could be done is writing a purely software encryption engine, either as part of OpenSSL or if that proves to be impossible/impractical, as an emulated system device (e.g. a pure software module for
http://cryptodev-linux.org/) that can execute instructions independent of OpenVPN's state. I am not saying this would be fast enough, but it should be much faster than what is available now.
Please bear in mind that this is a purely theoretical discussion for me at this point. I have been known to be dumb, but I ain't nearly dumb enough to write my own crypto :') I just want to understand why it hasn't been done before, as it seems like an obvious solution without implementation and in my experience when I encounter those it's usually because I misunderstood a concept at its core. If this is a wrong forum to discuss ideas like this please let me know.
But the RT-Ac87U is end of life and it sounds like you have tried to max it out with firmware choices and settings with little improvement.
That is true, however, the limitations seem to be purely software based. There is one more core that's idling, so the resources are there. There are other devices on the market that have 4 cores and no hardware acceleration, that's 3/4th of the resources idling. Feels very wasteful to me to just give up on them. Personally I *will* just get a better router with HW acceleration because I am a lazy person, but I disagree about those devices reaching their maximum potential.
The pfSense looks really neat, I have been playing with it since yesterday in VMs. Overkill for my needs, but I am going to learn it anyway just for the sake of it.
Are you marrried to your VPN provider?
May be time to break up with them. There are many other providers available. Many have a seven day trial period. Try one or two and compare. It may also allow you to validate that the issue is really the renegotiate setting and not something else.
My subscription with them runs out in 2 months or so and I do not mind switching. I picked them partially because of their focus on privacy and commitment to open source solutions. but the most important reason (I have used them for a while so maybe things changed), however, they were the best I was able to find when it comes to low jitter - I get sub 1ms jitter when connecting to the servers close to me and only 2-3 ms with servers further away (this is under minimal loads of course). If you know other VPN services like that please feel free to recommend some! Most recommendations that I was able to find (that were not pure advertisements/referral spam) focus on irrelevant (to me) stuff like ease of setup or bandwidth or geolocators bypass etc.
However, even if I did find another good VPN provider, how does that solve the problem of my core maxing out? The key renegotiation process is there to ensure Perfect Forward Secrecy, if I understand correctly. I would be worried that a provider that does not enforce privacy measures doesn't really care about the privacy at all.
Once again thanks for taking the time out of your day to read this/reply!
