Hi, On Fri, Jun 30, 2017 at 06:20:29PM +0200, open...@keemail.me wrote: > Now, in some cases, when the client connects with different ciphers, the > server appears to wrongly choose the peer cipher or data channel enc/dec > cipher. > > In the server logs this is can be observed as: > > <DATETIME> us=416063 <CLIENT-NAME>/<CLIENT-IP:PORT> WARNING: 'link-mtu' is > used inconsistently, local='link-mtu 1602', remote='link-mtu 1550' > <DATETIME> us=416125 <CLIENT-NAME>/<CLIENT-IP:PORT> WARNING: 'cipher' is used > inconsistently, local='cipher AES-256-CBC', remote='cipher AES-128-GCM' > <DATETIME> us=416182 <CLIENT-NAME>/<CLIENT-IP:PORT> WARNING: 'auth' is used > inconsistently, local='auth SHA512', remote='auth [null-digest]' > <DATETIME> us=416317 <CLIENT-NAME>/<CLIENT-IP:PORT> WARNING: 'keysize' is > used inconsistently, local='keysize 256', remote='keysize 128' > <DATETIME> us=416538 <CLIENT-NAME>/<CLIENT-IP:PORT> Data Channel Encrypt: > Cipher 'AES-256-CBC' initialized with 256 bit key > <DATETIME> us=416614 <CLIENT-NAME>/<CLIENT-IP:PORT> Data Channel Encrypt: > Using 512 bit message hash 'SHA512' for HMAC authentication > <DATETIME> us=416672 <CLIENT-NAME>/<CLIENT-IP:PORT> Data Channel Decrypt: > Cipher 'AES-256-CBC' initialized with 256 bit key > <DATETIME> us=416730 <CLIENT-NAME>/<CLIENT-IP:PORT> Data Channel Decrypt: > Using 512 bit message hash 'SHA512' for HMAC authentication > <DATETIME> us=416803 <CLIENT-NAME>/<CLIENT-IP:PORT> TLS: move_session: > dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1 > <DATETIME> us=417059 <CLIENT-NAME>/<CLIENT-IP:PORT> TLS: tls_multi_process: > untrusted session promoted to semi-trusted
If you look closely, you can see that there is no "Connection established"
here, because the server does not see this as a *new* connection, but
thinks it's a TLS renegotiation.
Unless there is a specific reason, always use --nobind on the client, which
ensures that a client restart will use a different port, avoiding this
issue.
> WR<DATETIME> us=417997 <CLIENT-NAME>/<CLIENT-IP:PORT> Control Channel:
> TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4069 bit RSA
> R<DATETIME> us=551112 <CLIENT-NAME>/<CLIENT-IP:PORT> PUSH: Received control
> message: 'PUSH_REQUEST'
> WR<DATETIME> us=690323 <CLIENT-NAME>/<CLIENT-IP:PORT> PUSH: Received control
> message: 'PUSH_REQUEST'
> WR<DATETIME> us=956749 <CLIENT-NAME>/<CLIENT-IP:PORT> PUSH: Received control
> message: 'PUSH_REQUEST'
> WR<DATETIME> us=474589 <CLIENT-NAME>/<CLIENT-IP:PORT> PUSH: Received control
> message: 'PUSH_REQUEST'
> WR<DATETIME> us=993878 <CLIENT-NAME>/<CLIENT-IP:PORT> PUSH: Received control
> message: 'PUSH_REQUEST'
Something is funky here anyway, as we shouldn't be receving multiple
PUSH_REQUESTS in short order, but since you mangled the timestamps and
client ports, it's not easy to see what really happened.
> <DATETIME> us=993980 <CLIENT-NAME>/<CLIENT-IP:PORT> Using peer cipher
> 'AES-128-GCM'
... why is the client not using NCP anyway? "using peer cipher" is just
a fallback option for 2.3 clients that cannot be properly upgraded...
[..]
> Why does this occur and how can I fix this issue?
- use --nobind on the client
- use 2.4.3 everywhere
- do not use --ncp-disable and varying --cipher settings unless there is
a very specific situation that you need this for
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
