On 26/03/2021 01:09, tincanteksup wrote:
Hi,
On 25/03/2021 23:26, Antonio Quartulli wrote:
Hi,
On 30/10/2018 13:53, Lev Stipakov wrote:
From: Lev Stipakov
+
+ msg(D_LOW, "Recursive routing detected, drop packet %s. Fix
your routing or consider using --allow-recursive-routing optio
Gửi từ điện thoại thông minh Samsung Galaxy của tôi. Tin nhắn gốc
Từ: Antonio Quartulli Ngày: 26/03/2021 06:40
(GMT+07:00) Đến: Rolf Fokkens ,
openvpn-devel@lists.sourceforge.net, open...@sf.lists.topphemmelig.net Cc:
Valentin Bajrami , Jasper Siero
Chủ đề: Re: [Openvpn
Hi,
On 25/03/2021 23:26, Antonio Quartulli wrote:
Hi,
On 30/10/2018 13:53, Lev Stipakov wrote:
From: Lev Stipakov
+
+msg(D_LOW, "Recursive routing detected, drop packet %s. Fix your routing or
consider using --allow-recursive-routing option.", BSTR(&addrs_buf));
I would add "if yo
Hi,
On 25/03/2021 23:15, Antonio Quartulli wrote:
Hi,
On 25/03/2021 18:44, Arne Schwabe wrote:
These have been troublesome in the past and also today's CVE-2021-3449
DOS is only exploitable if renegotiation is enabled.
Signed-off-by: Arne Schwabe
What is the practical effect of this change
Hi Rolf,
I know this is oldbut...
Is this something you'd consider resending based on current master?
Would you also have any chance of testing it again after rebase?
Cheers,
On 17/08/2019 14:12, Rolf Fokkens via Openvpn-devel wrote:
> On Fri, 2019-08-16 at 13:45 +0200, David Sommerseth wro
Hi,
On 14/07/2019 11:45, Steffan Karger wrote:
> Hi,
>
> On 06-12-18 18:10, Gert Doering wrote:
>> Creation of new instances (= new incoming reset packets with different
>> source IP addresses / source ports) can be rate-limited in the current
>> code by use of the "--connect-freq" option.
>>
>>
Hi,
On 30/10/2018 13:53, Lev Stipakov wrote:
> From: Lev Stipakov
>
> This patch provides additional information, such as
> source address/port and destination address/port, to a
> "recursive routing" warning message. It also mentiones
> possible workaround.
>
> Trac #843
>
> Signed-off-by: Le
Hi,
On 25/03/2021 18:44, Arne Schwabe wrote:
> These have been troublesome in the past and also today's CVE-2021-3449
> DOS is only exploitable if renegotiation is enabled.
>
> Signed-off-by: Arne Schwabe
What is the practical effect of this change?
With the current code (before this patch) whe
Hi,
On 25/03/2021 01:01, Arne Schwabe wrote:
> This option has been deprecated in OpenVPN 2.4 and the ciphers that allow
> using this option fall all into the SWEET32 category of ciphers with
> 64 bit block size.
>
> Signed-off-by: Arne Schwabe
> ---
> config-msvc.h| 1 -
> con
Hi,
On 25/03/2021 01:01, Arne Schwabe wrote:
> The non-TLS mode is a relict from OpenVPN 1.x or 2.0. When tls mode was
> introduce the advantages of TLS over non-tls were small but tls mode
> evolved to include a lot more features. (NCP, multipeer, AEAD ciphers to name
> a few).
>
> Today VPN tha
Hi,
On 17/03/2021 14:03, Arne Schwabe wrote:
> This structures the code a bit nicer and also prepares for deferred
> scripts that needs their own set of files.
>
> Signed-off-by: Arne Schwabe
For me this is an ACK, but unfortunately I have no test rig for deferred
auth and therefore I cannot re
Hi,
On 05/03/2021 00:06, Arne Schwabe wrote:
> 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 algo
Hi,
On 15/12/2020 17:42, Arne Schwabe wrote:
> For --nobind clients OpenVPN reuses the context and tls_multi structs
> of the previous clients and does not rerun the connect scripts on
> connect. But since it is a new client connection, the key_id is 0 and
> we postpone the key generation but it w
Hi,
On 15/12/2020 17:42, Arne Schwabe wrote:
> Some code currently is doing weird workarounds to figure out that side
> as side effect from other variables in tls_multi.
>
Arne can you rephrase what this patch is trying to address?
I think I understand the implementation, but I fail to see what
Hi,
On 25/03/2021 22:37, Antonio Quartulli wrote:
> Anybody can see why we need that for port-share?
> I'd rather try to understand the above and ditch this member entirely,
> if the answer is "we don't need it".
After more tests I indeed recovered the reason why this is needed with
port-share.
Hi,
On 26/10/2020 10:49, Arne Schwabe wrote:
> Am 24.10.20 um 21:43 schrieb Gert Doering:
>> Hi,
>>
>> On Fri, Oct 23, 2020 at 01:34:28PM +0200, Arne Schwabe wrote:
>>> Make options.c only set xmit_hold when port_share is active to least
>>> document this dependency. I have not actually tested if
Hi,
On 07/12/2018 21:28, Gert Doering wrote:
> If an attacker sends lots of RESET packets from different source
> ports (but the same source address), every packet will create a
> new multi_instance, leading to resource waste on the server, and
> to lots of reply packets while OpenVPN tries to est
Hi,
On 24/03/2021 23:08, Arne Schwabe wrote:
> This option allow migration to a non compression server config while
> still retraining compatibility with client that have a compression
> setting in their config.
>
> For existing setups that used to have comp-lzo no or another
> compression settin
Am 25.03.21 um 20:57 schrieb Antonio Quartulli:
> Hi,
>
> On 25/03/2021 20:29, Matthias Andree wrote:
>> I find the reasons you present to withdraw the symmetric non-TLS mode
>> too weak to justify its deprecation or removal. Yes, TLS-based
>> configurations may be more feature-rich, but those are
Hi,
On 25/03/2021 20:29, Matthias Andree wrote:
> I find the reasons you present to withdraw the symmetric non-TLS mode
> too weak to justify its deprecation or removal. Yes, TLS-based
> configurations may be more feature-rich, but those are not mandatory and
> we should not paternalize the users
Am 25.03.21 um 01:01 schrieb Arne Schwabe:
> The non-TLS mode is a relict from OpenVPN 1.x or 2.0. When tls mode was
> introduce the advantages of TLS over non-tls were small but tls mode
> evolved to include a lot more features. (NCP, multipeer, AEAD ciphers to name
> a few).
>
> Today VPN that us
These have been troublesome in the past and also today's CVE-2021-3449
DOS is only exploitable if renegotiation is enabled.
Signed-off-by: Arne Schwabe
---
src/openvpn/ssl_mbedtls.c | 3 +++
src/openvpn/ssl_openssl.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/openvpn/ssl_mbedtls
Hi,
On 25/03/2021 16:46, tincanteksup wrote:
> Hi,
>
> On 25/03/2021 07:59, Antonio Quartulli wrote:
>> Hi,
>>
>> On 25/03/2021 08:49, Antonio Quartulli wrote:
>>> That change (that was *Actually* made in 2.4) was exactly to remove this
>>> ambiguity.
>>
>> Forgive my hasty reply. This combinatio
Hi,
On 25/03/2021 07:59, Antonio Quartulli wrote:
Hi,
On 25/03/2021 08:49, Antonio Quartulli wrote:
That change (that was *Actually* made in 2.4) was exactly to remove this
ambiguity.
Forgive my hasty reply. This combination of option is actually
not-supported since 2.5 (in 2.4 we probably o
Acked-by: Gert Doering
"Because it makes sense". The DWORD changes for the loop variables
confused me a bit, because these are not "passed to a windows API" - but
they are *compared* to "i < rt->dwNumEntries", and since *that* is a
DWORD, I can see why it might warn.
Again, compile tested on M
Acked-by: Gert Doering
On non-windows, socket_descriptor_t is typedef'ed to "int", so this is
no "generated code change", just ensuring consistency in our types. On
Windows, this is a "SOCKET", which might or might not fit into an int,
but is certainly not interchangeable. So, makes sense.
Com
Hi,
On Wed, Mar 24, 2021 at 11:23:28PM +0100, Arne Schwabe wrote:
> diff --git a/src/openvpn/dhcp.c b/src/openvpn/dhcp.c
> index c19370eb..1e79ccc4 100644
> --- a/src/openvpn/dhcp.c
> +++ b/src/openvpn/dhcp.c
> @@ -113,7 +113,7 @@ do_extract(struct dhcp *dhcp, int optlen)
>
Acked-by: Gert Doering
Read through the code changes, seem to all make sense. Verified the
fread() change according to FreeBSD man page. The only hunk that
slightly confuses me is that the patch removes a "const" which seems
to be "correctly before the change" - but not sure this is relevant
a
Hi,
On 25/03/2021 08:49, Antonio Quartulli wrote:
> That change (that was *Actually* made in 2.4) was exactly to remove this
> ambiguity.
Forgive my hasty reply. This combination of option is actually
not-supported since 2.5 (in 2.4 we probably only introduced the
deprecation warning).
Regards,
Hi,
On 25/03/2021 01:47, tincanteksup wrote:
> I made this change to the wiki:
> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions?action=diff&version=45
I had this discussion with "Pippin_" in #openvpn-meeting:
The change you made is wrong. That part of the wikipage talks about
movin
30 matches
Mail list logo
