[Openvpn-devel] [S] Change in openvpn[master]: mbedtls: Allow TLS 1.3 if available
Attention is currently required from: MaxF, flichtenheld. plaisthos has posted comments on this change. ( http://gerrit.openvpn.net/c/openvpn/+/1042?usp=email ) Change subject: mbedtls: Allow TLS 1.3 if available .. Patch Set 2: (1 comment) Patchset: PS2: Same comment as on the previous patch applies about using the internal mbed TLS define -- To view, visit http://gerrit.openvpn.net/c/openvpn/+/1042?usp=email To unsubscribe, or for help writing mail filters, visit http://gerrit.openvpn.net/settings Gerrit-Project: openvpn Gerrit-Branch: master Gerrit-Change-Id: If5e832866b312a2f8a1ce6b4e00d40e3dcf63681 Gerrit-Change-Number: 1042 Gerrit-PatchSet: 2 Gerrit-Owner: MaxF Gerrit-Reviewer: flichtenheld Gerrit-Reviewer: plaisthos Gerrit-CC: openvpn-devel Gerrit-Attention: flichtenheld Gerrit-Attention: MaxF Gerrit-Comment-Date: Thu, 22 May 2025 13:31:05 + Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [M] Change in openvpn[master]: Use mbedtls_ssl_export_keying_material()
Attention is currently required from: flichtenheld, plaisthos. MaxF has posted comments on this change. ( http://gerrit.openvpn.net/c/openvpn/+/1041?usp=email ) Change subject: Use mbedtls_ssl_export_keying_material() .. Patch Set 2: (1 comment) File CMakeLists.txt: http://gerrit.openvpn.net/c/openvpn/+/1041/comment/48dc00df_b6879caa : PS2, Line 305: check_symbol_exists(mbedtls_ssl_export_keying_material mbedtls/ssl.h HAVE_MBEDTLS_SSL_EXPORT_KEYING_MATERIAL) > shouldn't we rather rely on the mbed TLS configuration define > MBEDTLS_SSL_KEYING_MATERIAL_EXPORT to […] In configure.ac, we need to check if one of the key exporting callbacks exists, or if mbedtls_ssl_export_keying_material() exists, to determine if we should set HAVE_EXPORT_KEYING_MATERIAL. Is it possible to check that a define exists in autoconf? Alternatively, we could just refuse to compile if there's no way to export keying material, but I think I would rather do that in a different commit. -- To view, visit http://gerrit.openvpn.net/c/openvpn/+/1041?usp=email To unsubscribe, or for help writing mail filters, visit http://gerrit.openvpn.net/settings Gerrit-Project: openvpn Gerrit-Branch: master Gerrit-Change-Id: I1204bc2ff85952160a86f0b9d1caae90e5065bc4 Gerrit-Change-Number: 1041 Gerrit-PatchSet: 2 Gerrit-Owner: MaxF Gerrit-Reviewer: flichtenheld Gerrit-Reviewer: plaisthos Gerrit-CC: openvpn-devel Gerrit-Attention: plaisthos Gerrit-Attention: flichtenheld Gerrit-Comment-Date: Thu, 22 May 2025 13:35:11 + Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: plaisthos Gerrit-MessageType: comment ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] multi.c: Allow floating to a new IP right after connection setup
> The thing is that I do not really understand your scenario and how it > exactly breaks for you to the extend that I cannot reproduce the issue. I thought I explained things sufficiently in: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg31502.html Apparently not. Please let me know what is unclear about that explanation. > You are saying that the client switches the IP address after connect. But > that is just a regular float from the perspective of the VPN server. I > still do not understand where the other connection that is already on that > IP/port is coming from. It is also not an older connection as it is not a > fully established connection either. Well, as far as I can tell, it _is_ just a regular float... that stopped working after the mentioned commit. It is indeed that recent connection. From what I gather from the earlier workings, we should not end up in that piece of code (where I added the fix), but for some reason we _do_ now. > In summary I am not able to either reproduce or understand what is > happning in your scenario. And I do not want to apply a patch that I don't > understand. Totally fair that you don't want to apply a patch that you don't understand. I on the other hand do not see why you're unable to reproduce. The scenario is not at all complicated: - Two vpn servers; - first vpn server pushes a default gateway; - second vpn server pushes its external IP as net_gateway (*); - second vpn server immediately sees the client float from one IP to another. If you're unable to reproduce that, then: - Either you're using a vastly different version and it has been fixed since then (but not something that landed in debian/bookworm or ubuntu/noble, and I _think_ I did try latest 2.6 as well); - or you're using different settings (udp; auth/tls-auth; dev-tun; subnet-topology); - or there is some unknown factor involved that neither of us can think or right now. I will create a reproducer config so you can see the exact settings (apart from the IP addresses). In the mean time, can you confirm that you understand the scenario or ask for additional clarification? Thank you! Walter (*) Why? Because if it didn't, traffic from the client to VPN-two goes through VPN-one as well. And that incurs overhead: additional latency and cpu load, possible MTU issues. ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [M] Change in openvpn[master]: Use mbedtls_ssl_export_keying_material()
Attention is currently required from: MaxF, flichtenheld. plaisthos has posted comments on this change. ( http://gerrit.openvpn.net/c/openvpn/+/1041?usp=email ) Change subject: Use mbedtls_ssl_export_keying_material() .. Patch Set 2: Code-Review-1 (2 comments) Patchset: PS2: the cmake detection didn't work properly for me but we should also not use that (see other comment) So I tested with replacing !HAVE_MBEDTLS_SSL_EXPORT_KEYING_MATERIAL defined(MBEDTLS_SSL_KEYING_MATERIAL_EXPORT) in the source code to test this. I can confirm that the patch otherwise works. File CMakeLists.txt: http://gerrit.openvpn.net/c/openvpn/+/1041/comment/93bf1992_f65e7263 : PS2, Line 305: check_symbol_exists(mbedtls_ssl_export_keying_material mbedtls/ssl.h HAVE_MBEDTLS_SSL_EXPORT_KEYING_MATERIAL) shouldn't we rather rely on the mbed TLS configuration define MBEDTLS_SSL_KEYING_MATERIAL_EXPORT to detect this? We have to do this cmake/configure.ac dance for the old apis since mbed TLS doesn't have a proper define but to detect if the API is available using MBEDTLS_SSL_KEYING_MATERIAL_EXPORT should work unless I am overlooking something. -- To view, visit http://gerrit.openvpn.net/c/openvpn/+/1041?usp=email To unsubscribe, or for help writing mail filters, visit http://gerrit.openvpn.net/settings Gerrit-Project: openvpn Gerrit-Branch: master Gerrit-Change-Id: I1204bc2ff85952160a86f0b9d1caae90e5065bc4 Gerrit-Change-Number: 1041 Gerrit-PatchSet: 2 Gerrit-Owner: MaxF Gerrit-Reviewer: flichtenheld Gerrit-Reviewer: plaisthos Gerrit-CC: openvpn-devel Gerrit-Attention: flichtenheld Gerrit-Attention: MaxF Gerrit-Comment-Date: Thu, 22 May 2025 13:08:05 + Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Gerrit-MessageType: comment ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [M] Change in openvpn[master]: Remove HAVE_EXPORT_KEYING_MATERIAL macro
Attention is currently required from: flichtenheld, plaisthos.
Hello plaisthos, flichtenheld,
I'd like you to do a code review.
Please visit
http://gerrit.openvpn.net/c/openvpn/+/1043?usp=email
to review the following change.
Change subject: Remove HAVE_EXPORT_KEYING_MATERIAL macro
..
Remove HAVE_EXPORT_KEYING_MATERIAL macro
This was always defined in all supported versions of OpenSSL and
WolfSSL. EKM should be available in supported mbed TLS versions, too.
This commit includes some style changes required by uncrustify.
Change-Id: Icbfffae877f8eca8d94721a4d54e140c50d4a550
---
M config.h.cmake.in
M configure.ac
M src/openvpn/init.c
M src/openvpn/multi.c
M src/openvpn/options.c
M src/openvpn/options.h
M src/openvpn/ssl.c
M src/openvpn/ssl_mbedtls.c
M src/openvpn/ssl_mbedtls.h
M src/openvpn/ssl_ncp.c
10 files changed, 10 insertions(+), 67 deletions(-)
git pull ssh://gerrit.openvpn.net:29418/openvpn refs/changes/43/1043/1
diff --git a/config.h.cmake.in b/config.h.cmake.in
index 5164ce3..5df0ac8 100644
--- a/config.h.cmake.in
+++ b/config.h.cmake.in
@@ -120,9 +120,6 @@
/* Define to 1 if you have the header file. */
#cmakedefine HAVE_ERR_H
-/* Crypto library supports keying material exporter */
-#define HAVE_EXPORT_KEYING_MATERIAL 1
-
/* Define to 1 if you have the header file. */
#cmakedefine HAVE_FCNTL_H
diff --git a/configure.ac b/configure.ac
index 75367e8..1b908e6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -988,10 +988,6 @@
[AC_MSG_ERROR([OpenSSL check for AES-256-GCM support failed])]
)
- # All supported OpenSSL versions (>= 1.1.0)
- # have this feature
- have_export_keying_material="yes"
-
CFLAGS="${saved_CFLAGS}"
LIBS="${saved_LIBS}"
@@ -1064,7 +1060,6 @@
[AC_DEFINE([HAVE_MBEDTLS_SSL_TLS_PRF], [0], [no])]
)
- have_export_keying_material="yes"
AC_CHECK_FUNC(
[mbedtls_ssl_conf_export_keys_ext_cb],
[AC_DEFINE([HAVE_MBEDTLS_SSL_CONF_EXPORT_KEYS_EXT_CB], [1],
[yes])],
@@ -1077,7 +1072,7 @@
[AC_DEFINE([HAVE_MBEDTLS_SSL_SET_EXPORT_KEYS_CB], [0],
[no])]
)
if test "x$ac_cv_func_mbedtls_ssl_set_export_keys_cb" != xyes;
then
- have_export_keying_material="no"
+ AC_MSG_ERROR(This version of mbed TLS has no support
for exporting key material.)
fi
fi
@@ -1132,17 +1127,12 @@
)
AC_CHECK_HEADER([wolfssl/options.h],,[AC_MSG_ERROR([wolfSSL header
wolfssl/options.h not found!])])
- # wolfSSL signal EKM support
- have_export_keying_material="yes"
-
if test "${enable_wolfssl_options_h}" = "yes"; then
AC_DEFINE([EXTERNAL_OPTS_OPENVPN], [1], [Include options.h from
wolfSSL library])
else
AC_DEFINE([WOLFSSL_USER_SETTINGS], [1], [Use custom
user_settings.h file for wolfSSL library])
fi
- have_export_keying_material="yes"
-
CFLAGS="${saved_CFLAGS}"
LIBS="${saved_LIBS}"
@@ -1346,12 +1336,6 @@
test "${enable_dns_updown_by_default}" = "yes" &&
AC_DEFINE([ENABLE_DNS_UPDOWN_BY_DEFAULT], [1], [Enable dns-updown hook by
default])
test "${enable_ntlm}" = "yes" && AC_DEFINE([ENABLE_NTLM], [1], [Enable NTLMv2
proxy support])
test "${enable_crypto_ofb_cfb}" = "yes" && AC_DEFINE([ENABLE_OFB_CFB_MODE],
[1], [Enable OFB and CFB cipher modes])
-if test "${have_export_keying_material}" = "yes"; then
- AC_DEFINE(
- [HAVE_EXPORT_KEYING_MATERIAL], [1],
- [Crypto library supports keying material exporter]
- )
-fi
OPTIONAL_CRYPTO_CFLAGS="${OPTIONAL_CRYPTO_CFLAGS} ${CRYPTO_CFLAGS}"
OPTIONAL_CRYPTO_LIBS="${OPTIONAL_CRYPTO_LIBS} ${CRYPTO_LIBS}"
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index e0ba255..15eacab 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -3483,7 +3483,6 @@
to.comp_options = options->comp;
#endif
-#ifdef HAVE_EXPORT_KEYING_MATERIAL
if (options->keying_material_exporter_label)
{
to.ekm_size = options->keying_material_exporter_length;
@@ -3499,7 +3498,6 @@
{
to.ekm_size = 0;
}
-#endif /* HAVE_EXPORT_KEYING_MATERIAL */
/* TLS handshake authentication (--tls-auth) */
if (options->ce.tls_auth_file)
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 80dd0c0..a5eee01 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1837,7 +1837,6 @@
c->c2.push_request_received = true;
}
-#ifdef HAVE_EXPORT_KEYING_MATERIAL
if (proto & IV_PROTO_TLS_KEY_EXPORT)
{
o->imported_protocol_flags |= CO_USE_TLS_KEY_MATERIAL_EXPORT;
@@ -1856,7 +1855,6 @@
{
o->imported_protocol_flags |= CO_USE_DYNAMIC_TLS_CRYPT;
}
-#endif
if (proto & IV_PROTO_CC_EXIT_NOTIFY)
{
diff --git a/src/openvpn/options.c b/
[Openvpn-devel] [XS] Change in openvpn[master]: dco_linux: avoid bogus text when netlink message is not parsed
Attention is currently required from: cron2, flichtenheld, ordex, plaisthos.
Hello cron2, flichtenheld, plaisthos,
I'd like you to reexamine a change. Please visit
http://gerrit.openvpn.net/c/openvpn/+/1027?usp=email
to look at the new patch set (#2).
The following approvals got outdated and were removed:
Code-Review-1 by cron2
Change subject: dco_linux: avoid bogus text when netlink message is not parsed
..
dco_linux: avoid bogus text when netlink message is not parsed
We may bail out parsing an incoming DCO message because it may
concern a different interface.
In that case we print the following debug messages:
dco_do_read
ovpn-dco: ignoring message (type=5) for foreign ifindex 313
process_incoming_dco: received message of type 0 - ignoring
However, the last message is confusing, because there is no message
of type 0 being received, but the message_type was simply not
initialized.
Bail out parsing earlier and avoid printing any bogus text.
Change-Id: I568faa12a5960e8b69de23c2df413b70b231592c
Signed-off-by: Antonio Quartulli
---
M src/openvpn/forward.c
1 file changed, 6 insertions(+), 0 deletions(-)
git pull ssh://gerrit.openvpn.net:29418/openvpn refs/changes/27/1027/2
diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index ed4cdb4..b90a88c 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -1251,6 +1251,12 @@
dco_do_read(dco);
+/* no message was parsed - bail out */
+if (dco->dco_message_type == 0)
+{
+return;
+}
+
/* FreeBSD currently sends us removal notifcation with the old peer-id in
* p2p mode with the ping timeout reason, so ignore that one to not shoot
* ourselves in the foot and removing the just established session */
--
To view, visit http://gerrit.openvpn.net/c/openvpn/+/1027?usp=email
To unsubscribe, or for help writing mail filters, visit
http://gerrit.openvpn.net/settings
Gerrit-Project: openvpn
Gerrit-Branch: master
Gerrit-Change-Id: I568faa12a5960e8b69de23c2df413b70b231592c
Gerrit-Change-Number: 1027
Gerrit-PatchSet: 2
Gerrit-Owner: ordex
Gerrit-Reviewer: cron2
Gerrit-Reviewer: flichtenheld
Gerrit-Reviewer: plaisthos
Gerrit-CC: openvpn-devel
Gerrit-Attention: plaisthos
Gerrit-Attention: cron2
Gerrit-Attention: flichtenheld
Gerrit-Attention: ordex
Gerrit-MessageType: newpatchset
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] multi.c: Allow floating to a new IP right after connection setup
Dear mailing list and Arne,
I saw in the IRC meeting notes that 2.7 is about to be branched.
I don't mean to push, but I personally think this bug is important enough
to get looked at and fixed, preferably before 2.7.0 is made.
Is this new patch good enough? Should I put it in Gerrit? Are there any
questions about the functionality?
I realise that I did not explain _why_ b364711486 breaks things. I'm also
curious, but I think the author of that patch, or someone else more
intimate with the codebase, can more easily explain. Regardless there is a
bug in 2.6.x right now, and I'd would like it if a fix is upstreamed; be
it my fix, or someone elses.
Thanks!
Walter
> From: Walter Doekes
>
> When you're connected to a VPN which is used as the default gateway, a
> connection to a second VPN will cause a tunnel-in-tunnel traffic. If the
> administrator of the second VPN wants to avoid that, by pushing its IP
> as net_gateway, this means that the client's source IP switches right
> after connect:
>
> the client source IP switches, from
> - the first-VPN-exit-IP, to the
> - regular-ISP-exit-IP
>
> In openvpn 2.5 and below, this worked fine. Since openvpn 2.6,
> specifially b364711486, this triggers the "Disallow float to an address
> taken by another client" code. Since that change, the traffic from the
> second source IP creates a second connection, which now needs special
> handling in the check-floating-IP code.
>
> This change allows one to switch to the new IP, if it is still in an
> unconnected state. That makes the use-case mentioned above work again.
>
> Github: closes OpenVPN/openvpn#704
> Signed-off-by: Walter Doekes
> ---
> src/openvpn/multi.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
> index a2d3fd10..51a00b71 100644
> --- a/src/openvpn/multi.c
> +++ b/src/openvpn/multi.c
> @@ -3236,8 +3236,21 @@ multi_process_float(struct multi_context *m, struct
> multi_instance *mi,
> struct tls_multi *m1 = mi->context.c2.tls_multi;
> struct tls_multi *m2 = ex_mi->context.c2.tls_multi;
>
> +/* if the new connection is fresh and the old one is already
> connected, this
> + * might be a legitimate move to a new IP by the original client;
> + * for example when the server IP is pushed as net_gateway to
> escape from
> + * a double VPN. */
> +if (m1->multi_state == CAS_CONNECT_DONE
> +&& m2->multi_state == CAS_NOT_CONNECTED
> +&& m1->locked_cert_hash_set
> +&& !m2->locked_cert_hash_set
> +&& session_id_equal(&m1->session[TM_ACTIVE].session_id,
> + &m2->session[TM_ACTIVE].session_id))
> +{
> +/* allow this case */
> +}
> /* do not float if target address is taken by client with another
> cert */
> -if (!cert_hash_compare(m1->locked_cert_hash_set,
> m2->locked_cert_hash_set))
> +else if (!cert_hash_compare(m1->locked_cert_hash_set,
> m2->locked_cert_hash_set))
> {
> msg(D_MULTI_LOW, "Disallow float to an address taken by
> another client %s",
> multi_instance_string(ex_mi, false, &gc));
> --
> 2.34.1
>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] multi.c: Allow floating to a new IP right after connection setup
Am 22.05.2025 um 09:09 schrieb Walter Doekes: Dear mailing list and Arne, I saw in the IRC meeting notes that 2.7 is about to be branched. I don't mean to push, but I personally think this bug is important enough to get looked at and fixed, preferably before 2.7.0 is made. Is this new patch good enough? Should I put it in Gerrit? Are there any questions about the functionality? I realise that I did not explain _why_ b364711486 breaks things. I'm also curious, but I think the author of that patch, or someone else more intimate with the codebase, can more easily explain. Regardless there is a bug in 2.6.x right now, and I'd would like it if a fix is upstreamed; be it my fix, or someone elses. The thing is that I do not really understand your scenario and how it exactly breaks for you to the extend that I cannot reproduce the issue. You are saying that the client switches the IP address after connect. But that is just a regular float from the perspective of the VPN server. I still do not understand where the other connection that is already on that IP/port is coming from. It is also not an older connection as it is not a fully established connection either. In summary I am not able to either reproduce or understand what is happning in your scenario. And I do not want to apply a patch that I don't understand. Arne ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [XS] Change in openvpn[master]: dco_linux: avoid bogus text when netlink message is not parsed
Attention is currently required from: flichtenheld, ordex, plaisthos. cron2 has posted comments on this change. ( http://gerrit.openvpn.net/c/openvpn/+/1027?usp=email ) Change subject: dco_linux: avoid bogus text when netlink message is not parsed .. Patch Set 2: (1 comment) File src/openvpn/forward.c: http://gerrit.openvpn.net/c/openvpn/+/1027/comment/641ebff7_a3997926 : PS2, Line 1254: /* no message was parsed - bail out */ I would change this to ``` /* no message for us to handle - platform specific code has logged details */ ``` because we do not really "bail out", we just do nothing because nothing is to be done. -- To view, visit http://gerrit.openvpn.net/c/openvpn/+/1027?usp=email To unsubscribe, or for help writing mail filters, visit http://gerrit.openvpn.net/settings Gerrit-Project: openvpn Gerrit-Branch: master Gerrit-Change-Id: I568faa12a5960e8b69de23c2df413b70b231592c Gerrit-Change-Number: 1027 Gerrit-PatchSet: 2 Gerrit-Owner: ordex Gerrit-Reviewer: cron2 Gerrit-Reviewer: flichtenheld Gerrit-Reviewer: plaisthos Gerrit-CC: openvpn-devel Gerrit-Attention: plaisthos Gerrit-Attention: flichtenheld Gerrit-Attention: ordex Gerrit-Comment-Date: Fri, 23 May 2025 06:09:55 + Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [L] Change in openvpn[master]: dns: deal with --dhcp-options when --dns is active
Attention is currently required from: d12fk, flichtenheld, plaisthos, stipa. cron2 has posted comments on this change. ( http://gerrit.openvpn.net/c/openvpn/+/904?usp=email ) Change subject: dns: deal with --dhcp-options when --dns is active .. Patch Set 21: (1 comment) File src/openvpn/options.c: http://gerrit.openvpn.net/c/openvpn/+/904/comment/aaf0a34c_938d33d0 : PS15, Line 4299: tuntap_options_postprocess_dns(o); > The reason why is that both had DNS before and they were using the DNS > related elements in `struct t […] I have thought about this a while now, and would suggest to do the following - *if and only if* we are using the tap driver with ip-win32 dhcp, keep DNS things "as they are in 2.6" -> fill in DHCP options, do not set DNS via iservice - if DCO is used or a non-DHCP mode -> use iservice this will effectively make us use iservice most of the time, but if someone really wants old behaviour and relies on DHCP, they can have that (... and, alas, we see users that use a) tap, b) dhcp, and c) no iservice... - which is strongly not recommended, but...) -- To view, visit http://gerrit.openvpn.net/c/openvpn/+/904?usp=email To unsubscribe, or for help writing mail filters, visit http://gerrit.openvpn.net/settings Gerrit-Project: openvpn Gerrit-Branch: master Gerrit-Change-Id: I635c4018fb43b5976a39b6a90cb2e9cb2570cd6a Gerrit-Change-Number: 904 Gerrit-PatchSet: 21 Gerrit-Owner: d12fk Gerrit-Reviewer: flichtenheld Gerrit-Reviewer: plaisthos Gerrit-Reviewer: stipa Gerrit-CC: cron2 Gerrit-CC: openvpn-devel Gerrit-Attention: plaisthos Gerrit-Attention: flichtenheld Gerrit-Attention: d12fk Gerrit-Attention: stipa Gerrit-Comment-Date: Fri, 23 May 2025 06:14:05 + Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: d12fk Comment-In-Reply-To: stipa Gerrit-MessageType: comment ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] multi.c: Allow floating to a new IP right after connection setup
Totally fair that you don't want to apply a patch that you don't understand. I on the other hand do not see why you're unable to reproduce. The scenario is not at all complicated: - Two vpn servers; - first vpn server pushes a default gateway; - second vpn server pushes its external IP as net_gateway (*); - second vpn server immediately sees the client float from one IP to another. What I understand so far: - so you connect to vpn 1 first and that is a normal VPN with a default gateway and you get VPN1 IP - Then via that VPN, you connect a 2nd VPN and you have as source the VPN IP, so the 2nd VPN server only see the VPN1 IP. - after connection is established, you do the host route directly to the server. - 2nd VPN server sees a float from VPN1 IP to extern IP (EXTIP) of client - Server refuses the float since there is already a not fully established connection on EXTIP What I don't understand where the this not fully established connection should be coming from. That would mean that the server would have need to have received a valid connection attempt from EXTIP that was never established. And I do not understand from you explaination where that happens. If you're unable to reproduce that, then: - Either you're using a vastly different version and it has been fixed since then (but not something that landed in debian/bookworm or ubuntu/noble, and I _think_ I did try latest 2.6 as well); - or you're using different settings (udp; auth/tls-auth; dev-tun; subnet-topology); - or there is some unknown factor involved that neither of us can think or right now. I will create a reproducer config so you can see the exact settings (apart from the IP addresses). In the mean time, can you confirm that you understand the scenario or ask for additional clarification? I wrote again down what you basically told me and there is still this mystery connection that blocks you. And there is no explaination why this connection exist in the first place. You are fixing the sympton of this ghost connection that blocks your float but from my perspective we have not really established why it exists in the first place. Arne ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
