Hi Arne, Antonio,
On 09/04/21 11:53, Arne Schwabe wrote:
Am 09.04.21 um 11:24 schrieb Jan Just Keijser:
On 08/04/21 17:52, Gert Doering wrote:
On Thu, Apr 08, 2021 at 05:30:52PM +0200, Jan Just Keijser wrote:
I don't have any evidence with 2.5 right now but this is just a matter
of use/principle to me: I can very well see that I would like to have a
setup *without* NCP as I simply do not need it (e.g. my cipher is
hardwired to aes-256-gcm) and in that case I don't *want* NCP to ensure
my setup is 100% predictable.
By setting "--data-ciphers AES-256-GCM" on the client side, you achieve
a 100% predictable outcome. No other cipher will be offered or accepted.
Ah a new 2.5 option - I assume the same thing is true for adding this on
the server side?
And I see that --data-ciphers works only in combination with NCP, that
is, if you do
--data-ciphers aes-256-gcm --ncp-disable
then --data-ciphers is effectively ignored. Nice ;)
Yes data-ciphers (and data-ciphers-fallback) are meant to replace all
other cipher related options eventually.
and I was hoping that this would be resolved before removing something
like --ncp-disable. Having said that, I now see that with openvpn 2.5,
the server mtu is still 1379 in my setup, regardless of whether I use
--ncp-disable or not - seems to me that is still too low.
Yes DATA_V2 adds 3 bytes compared to DATA_V1.
I understand the 3 bytes (--peerid and such) but is there any way to NOT
have such a low server-side MTU?
Also note that having a different server-side MTU versus client-side MTU
makes it even harder to tune the performance
On the client side I now see even more confusing fun:
Server has --ncp-disable set:
- with --cipher aes-256-cbc the client side MTU is 1428
- with --cipher aes-256-gcm the client side MTU is 1376 <--- huh?
Server does not have --ncp-disable set:
- with --cipher aes-256-cbc the client side MTU is 1428
- with --cipher aes-256-gcm the client side MTU is 1448
(ok I understand the latter).
What I'd really like to see is a way to get the server-side MTU to also
be 1428/1448 using the right magic options - any idea if that's possible?
The lower the MTU on either side, the lower the maximum bandwidth -
which will hurt especially over low-bandwidth links.
Also, when this option is dropped, does that mean that a 2.4/2.5 client
with the option set can no longer connect to a 2.6 server?
I am not sure how you came to that conclusion. I have written a fairly
comprehensible documentation how NCP in 2.5 works for our manpage:
https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negotiation.rst
That should also answer your question.
Conclusion: a further overhaul of the ncp/cipher/data-ciphers logic
might be in order...
Which is one of my gut reasons for saying : don't remove --ncp-disable
until this mess is thoroughly sorted out.
Please don't mix two things here. Yes the MTU calculation and MTU in
general is broken but shouldn't pollute this discussion here.
And yes we will look into MTU related issues before 2.6 is released but
having a non NCP and a NCP code path for MTU is not helping to reduce
the complexity.
thanks for all the clarifications - esp the cipher-negotiation.rst was
very helpful.
And I understand the argument about "polluting the discussion" but to me
the *order* in which things are done is important. That is, for the 2.6
release all MTU issues should be resolved , so that noone will ever have
a need to debug MTU issues by dis- or enabling NCP.
So I guess if things were done in the order
1) fix the MTU issues on both client and server side
2) drop --ncp-disable
then you would not have heard any complaints from me.
cheers,
JJK
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
