Hi, On Fri, Apr 09, 2021 at 11:24:01AM +0200, Jan Just Keijser wrote: > 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 ;)
--data-ciphers is the option to tell the client what to announce as acceptable
ciphers to the server, and what to accept if pushed (in case a server is
not well-behaved).
This is part of NCP, and if you turn off NCP, it is no longer active.
And because this confuses people, the idea is, for 2.6, to remove that
knob with changes the flow "config -> operational session" in ways that
most people are not aware.
[..]
> 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).
The MTU/frame overhead calculation, depending on configured and negotiated
ciphers, is a big source of pain (just grep the source for "frame") - and
yes, we are aware of it, but it's actually close to impossible to fix
without really ripping it all out and doing it anew.
Arne is currently busy with ripping out all the renegotiation / half-
authenticated keys / session stuff, and I understand that MTU is not
far down his list.
My server test rig has a few cases where "large ping" fails due to exactly
this, MTU miscalculations. Which is good, because it reminds me every
day that this needs fixing.
> 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.
Just set --tun-mtu 1448, done.
The "automatic" way is "take link-mtu, default 1500, and calculate tun-mtu
from it depending on cipher/auth overhead". Which fails more often than
not, but --tun-mtu can also be set directly.
> 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?
No. My test bed talks happily to 2.2 and 2.3 clients, some instances
with --ncp-disable, most with NCP enabled (= as if there were no option
to disable NCP).
You don't need that option today to make them talk, so they won't stop
talking if you take the option away.
> 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.
ncp/cipher/data-cipher is fine, and well-documented.
frame/mtu is where the pain is.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
