Sorry, comment typo:
- /* kernel cat return 0.0.0.0/128 host route */
+ /* kernel can return ::/128 host route */
--
Best Regards, Vladislav Grishenko
> -Original Message-
> From: Vladislav Grishenko
> Sent: Tuesday, September 8, 2020 7:54 AM
> To: openvpn-devel@lists.sourceforge.net
>
Netlink route request with NLM_F_DUMP flag set means to return
all entries matching criteria passed in message content -
matching supplied family & dst address in our case.
So, gateway from the first ipv4 route was always used.
On kernels earlier than 2.6.38 default routes are the last ones,
so
Modern TLS libraries might drop Blowfish by default or distributions
might disable Blowfish in OpenSSL/mbed TLS. We still signal OCC
options with BF-CBC compatible strings. To avoid requiring BF-CBC
for this, special case this one usage of BF-CBC enough to avoid a hard
requirement on Blowfish in
This moves from using our own copy of the TLS1 PRF function to using
TLS library provided function where possible. This includes currently
OpenSSL 1.1.0+ and mbed TLS 2.18+.
For the libraries where it is not possible to use the library's own
function, we still use our own implementation. mbed TLS
Without this OpenVPN will later segfault on a FIPS enabled system due
to the algorithm available but not allowed.
Signed-off-by: Arne Schwabe
---
src/openvpn/crypto_openssl.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/openvpn/crypto_openssl.c
OpenVPN will ignore --cipher in lieu of the replacement data-ciphers
for cipher negioation.
Signed-off-by: Arne Schwabe
---
doc/man-sections/protocol-options.rst | 6 --
src/openvpn/options.c | 26 --
2 files changed, 8 insertions(+), 24 deletions(-)
This commit cleans up the logic in the function a bit. It also makes it
more clear the the details printed in the second part of the message are
details about the peer certificate and not the TLS connection as such.
Also print the signature algorithm as this might help to identify
peer certificate
Hi,
On Mon, Sep 07, 2020 at 06:17:34PM +0500, Vladislav Grishenko wrote:
> {
> case AF_INET:
> res.addr_size = sizeof(in_addr_t);
> -req.n.nlmsg_flags |= NLM_F_DUMP;
> +req.r.rtm_dst_len = 32;
> break;
For the record, this actually
Netlink route request with NLM_F_DUMP flag set means to
return all entries matching criteria passed in message
content - matching supplied dst address in our case.
So, gateway from the first returned route was always used
even there were more specific routes present.
By a chance, after route
