Calling "openvpn --inetd" from the CLI (= no socket on stdin) will
lead to endless looping in the accept(4) loop.
Instead of cluttering that function further, detect failure to call
getsockame() in phase2_inetd() already, and trigger a M_FATAL abort
on "errno == ENOTSOCK" ("The argument s is a
Am 08.09.20 um 12:51 schrieb Gert Doering:
> Calling "openvpn --inetd" from the CLI (= no socket on stdin) will
> lead to endless looping in the accept(4) loop.
>
> Instead of cluttering that function further, detect failure to call
> getsockame() in phase2_inetd() already, and trigger a M_FATAL
On 08/09/2020 14:36, Vladislav Grishenko wrote:
> On kernels earlier than 2.6.38 default routes are the last ones,
> so arbitrary host/net route w/o gateway is likely be returned as
> first, causing gateway to be invalid or empty.
> After refactoring in 2.6.38 kernel default routes are on top, so
It's a long-standing and well-known problem that --push-reset removes
"critical" options from the push list (like "topology subnet") which
will then lead to non-working client configs. This can not be
reasonably fixed, because the list of "critical" options depends on
overall server config.
So
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
Am 08.09.20 um 13:15 schrieb Gert Doering:
> It's a long-standing and well-known problem that --push-reset removes
> "critical" options from the push list (like "topology subnet") which
> will then lead to non-working client configs. This can not be
> reasonably fixed, because the list of
This options allows to pin a certificate or a number of certificate.
It also prepares for doing TLS authentication without a CA and just
self-signed certificates.
Signed-off-by: Arne Schwabe
---
Changes.rst | 7 ++
doc/man-sections/inline-files.rst | 4 ++--
From: "Jason A. Donenfeld"
OpenVPN traditionally works around CAs. However many TLS-based protocols also
allow an alternative simpler mode in which rather than verify certificates
against CAs, the certificate itself is hashed and compared against a
pre-known set of acceptable hashes. This is
On 08/09/2020 13:15, Gert Doering wrote:
> It's a long-standing and well-known problem that --push-reset removes
> "critical" options from the push list (like "topology subnet") which
> will then lead to non-working client configs. This can not be
> reasonably fixed, because the list of
Hi,
On 08/09/2020 15:08, David Sommerseth wrote:
> On 08/09/2020 14:36, Vladislav Grishenko wrote:
>> On kernels earlier than 2.6.38 default routes are the last ones,
>> so arbitrary host/net route w/o gateway is likely be returned as
>> first, causing gateway to be invalid or empty.
>> After
Also remove the static key setup example as it is less secure and we
want to avoid it for new setups as we want to slowly deprecate these.
Signed-off-by: Arne Schwabe
---
Changes.rst | 5
doc/man-sections/examples.rst| 46
Setting up a CA even with the help of easy-tls and similar tools is
difficult/tiresome. For small setups self-signed certificates are
sufficient enough and restarting the server to add another client is
generally not a big problem (when you need that capability a CA is
better suited).
This patch
For a new syntax introduced now it does not make much sense to support
deprecated and old hashes, so support only SHA-256.
Also give a warning about SHA1 hash being deprecated to verify certificates
as it is now "industry standard".
Signed-off-by: Arne Schwabe
---
> One of the nice features of Jason's patch was that also for big(ger)
> deployments you could get rid of the CA if you have another channel to
> establish trust between client and server.
I really wonder which large deployment want to do that instead of a CA.
I really understand the need for
On 03/09/2020 13:44, Vladislav Grishenko wrote:
> According client-options.rst additional argumets ``port`` and ``proto``
> are both optional and it's allowed to have port absent and protocol set:
> --remote args
> Examples:
> remote server.example.net tcp
>
> But when protocol
Hi David,
> -Original Message-
> From: David Sommerseth
> Sent: Tuesday, September 8, 2020 6:23 PM
> To: Vladislav Grishenko ; openvpn-
> de...@lists.sourceforge.net
> Subject: Re: [Openvpn-devel] [PATCH] Fix --remote protocol can't be set
> without
> port argument
>
> On 03/09/2020
Hi,
On Tue, Sep 08, 2020 at 03:11:40PM +0200, David Sommerseth wrote:
> It would be good if --push-reset would actually not remove certain critical
> options, but this is anyhow a good heads-up for our users.
Well, that ticket sat there 10 years (!!) waiting for someone to go
and implement it...
Am 08.09.20 um 18:35 schrieb Gert Doering:
> Hi,
>
> On Tue, Sep 08, 2020 at 03:11:40PM +0200, David Sommerseth wrote:
>> It would be good if --push-reset would actually not remove certain critical
>> options, but this is anyhow a good heads-up for our users.
>
> Well, that ticket sat there 10
Hi,
My vote would be to deprecate --push-reset
(same for --route-nopull)
André
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Tuesday 8 September 2020 18:41, Arne Schwabe wrote:
> Am 08.09.20 um 18:35 schrieb Gert Doering:
>
> > Hi,
> > On Tue, Sep 08, 2020 at
On 9/8/20 5:41 PM, Arne Schwabe wrote:
The main difference of this patch set to Jason's V1 version is that it does
not rely on an external script on the server side and instead relys on an a
inlined section. The downside is that this requires a
server restart on adding a client but the upside
Am 08.09.20 um 19:04 schrieb André:
> Hi,
>
> My vote would be to deprecate --push-reset
> (same for --route-nopull)
>
Route-nopull is still a very useful option that has no good replacement.
I regularly use it when the server should not mess up my routing table.
Arne
signature.asc
21 matches
Mail list logo
