openvpn-devel Mailing List for OpenVPN

From: Selva Nair <sel...@gm...> Also make sure --dhcp-pre-release results in not just dhcp_release() in open_tun() but a subsequent dhcp_renew() as well. Else dhcp transaction gets aborted as this call to release() happens after the adapter status is changed to connected. Alternatively, the undocumented --dhcp-pre-release may be removed. Fixes Trac #807 (but can't say the same for Trac #665 without knowing how to reproduce it) Signed-off-by: Selva Nair <sel...@gm...> --- src/openvpn/tun.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index f812844..31fcd67 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -6056,6 +6056,7 @@ open_tun(const char *dev, const char *dev_type, const char *dev_node, struct tun if (tt->options.dhcp_pre_release) { dhcp_release(tt); + dhcp_renew(tt); } if (tt->options.dhcp_renew) { @@ -6224,10 +6225,7 @@ close_tun(struct tuntap *tt) } #endif - if (tt->options.dhcp_release) - { - dhcp_release(tt); - } + dhcp_release(tt); if (tt->hand != NULL) { -- 2.1.4 

Hi, On Fri, Dec 30, 2016 at 10:58 AM, Selva Nair <sel...@gm...> wrote: > > Based on Trac #807, it seems removing ipv6 address on tun close is more > than just good behaviour. Hmm.. this patch was about deleting ipv6 routes not address, so not really related to Trac 807, nor as important as I thought. Sorry for the confusion. Selva 

Hi, Based on Trac #807, it seems removing ipv6 address on tun close is more than just good behaviour. A review of this patch would help. Thanks, Selva On Fri, Nov 25, 2016 at 12:21 AM, Selva Nair <sel...@gm...> wrote: > This was missing on Windows when interactive service is in use. > > - Added route_ipv6_clear_host_bits(r6) to delete_route_ipv6: this is > required for Windows IP-helper API. Won't hurt other platforms (?) > > v2: Be const correct: route in delete_route_ipv6() made non-const. > None of the exisitng calls are affected. > > Signed-off-by: Selva Nair <sel...@gm...> > --- > src/openvpn/route.c | 4 +++- > src/openvpn/route.h | 2 +- > src/openvpn/tun.c | 3 +++ > 3 files changed, 7 insertions(+), 2 deletions(-) > > diff --git a/src/openvpn/route.c b/src/openvpn/route.c > index fec12c1..34b1196 100644 > --- a/src/openvpn/route.c > +++ b/src/openvpn/route.c > @@ -2102,7 +2102,7 @@ delete_route (struct route_ipv4 *r, > } > > void > -delete_route_ipv6 (const struct route_ipv6 *r6, const struct tuntap *tt, > unsigned int flags, const struct env_set *es) > +delete_route_ipv6 (struct route_ipv6 *r6, const struct tuntap *tt, > unsigned int flags, const struct env_set *es) > { > struct gc_arena gc; > struct argv argv = argv_new (); > @@ -2124,6 +2124,8 @@ delete_route_ipv6 (const struct route_ipv6 *r6, > const struct tuntap *tt, unsigne > > gc_init (&gc); > > + route_ipv6_clear_host_bits (r6); > + > network = print_in6_addr( r6->network, 0, &gc); > gateway = print_in6_addr( r6->gateway, 0, &gc); > > diff --git a/src/openvpn/route.h b/src/openvpn/route.h > index c358681..70aeb65 100644 > --- a/src/openvpn/route.h > +++ b/src/openvpn/route.h > @@ -252,7 +252,7 @@ void copy_route_ipv6_option_list (struct > route_ipv6_option_list *dest, > struct gc_arena *a); > > void add_route_ipv6 (struct route_ipv6 *r, const struct tuntap *tt, > unsigned int flags, const struct env_set *es); > -void delete_route_ipv6 (const struct route_ipv6 *r, const struct tuntap > *tt, unsigned int flags, const struct env_set *es); > +void delete_route_ipv6 (struct route_ipv6 *r, const struct tuntap *tt, > unsigned int flags, const struct env_set *es); > > void add_route (struct route_ipv4 *r, > const struct tuntap *tt, > diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c > index 560b1a8..40ce202 100644 > --- a/src/openvpn/tun.c > +++ b/src/openvpn/tun.c > @@ -5663,6 +5663,9 @@ close_tun (struct tuntap *tt) > { > if (tt->options.msg_channel) > { > + /* remove route pointing to interface */ > + delete_route_connected_v6_net(tt, NULL); > + > do_address_service (false, AF_INET6, tt); > if (tt->options.dns6_len > 0) > do_dns6_service (false, tt); > -- > 2.1.4 > > 

Hi, On Thu, Dec 29, 2016 at 10:30:58AM +0500, ???????? ?????????????? wrote: > I would split !read || !write into 2 separate calls with separate debug log > messages... NAK on this. This code can basically not fail unless the interactive service dies - and then, it does not really matter which one failed (because both will fail). So unless you see *this* error message ("TUN: could not talk to service:") and wonder whether read or write is causing is, there is no benefit in making this part of the code more lines. > and move FlushIpNet error closer to FlushIpNet call. > > right ? No. The error check is *right* under the line where it is set. No need to have duplicate code in both if/else clauses before that. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Hi, On Thu, Dec 29, 2016 at 09:56:44AM +0500, ???????? ?????????????? wrote: > I seem to see several times issues like described in #665 It came up on openvpn-users yesterday as well, and that's a bit weird as our test set covers the case in question ("connect to different remotes on the same tap device") and I never saw this. Must be timing related. > what seems to be strange is couple of things: > > 1) "OR" clause. why not "AND" ? > https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/tun.c#L6012-L6013 Because both are "not". So "if not write() or not read() -> error". The code is correct, otherwise you'd end up with this error message ("TUN: could not talk to service") which is not there in the logs. > 2) error message seems to be irrelevant > https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/tun.c#L6034 > > it might be an error from earlier function calls, not only FlushIpNetTable > itself. How? status is either set in line 6019 or in 6023. There is no way 6034 can be reached without calling either the iservice-based flushing or directly calling FlushIpNetTable() - so status is always relevant. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Hi, On 29-12-16 20:06, Selva Nair wrote: > > On Thu, Dec 29, 2016 at 5:53 AM, Samuli Seppänen <sa...@op... > <mailto:sa...@op...>> wrote: > -------- Messaggio Inoltrato -------- > Oggetto: Re: [Openvpn-announce] OpenVPN 2.4.0 released > Data: Tue, 27 Dec 2016 22:04:23 -0600 > Mittente: Michael French <Mi...@mp... > <mailto:Mi...@mp...>> > A: Samuli Seppänen <sa...@op... <mailto:sa...@op...>> > > I installed 2.4 on a couple Windows 7x64 computers and all seems well. > I even got tls-crypt to work using the old ta.key file on both client > and server. As a general rule of thumb: if you change your cryptographic primitives (here, exchange --tls-auth for --tls-crypt), also change your keys. So it would be best to generate a fresh tc.key, to replace your ta.key. (In this case, reusing ta.key will *probably* not break the crypto, but better be safe than sorry.) > However, I noticed in the documentation for 2.4 that the parameter > tls-version-min is supposed to work with the 'or-highest' option, but it > does not. Please specify what you mean when you say 'it does not'. Do you get connection errors? Is a different-then-expected version negotiated? Please elaborate. > I wish that it did work because I always want to run with the most > secure version of TLS and the 'or-highest' option would save me the > trouble of manually editing the TLS number every time it changes. > > I too find this option somewhat counter-intuitive. I think you can > effectively get it set to the highest available version by specifying an > insanely large number as the first parameter. For example, > > --tls-version-min 5.0 or-highest > > As 5.0 is larger than any available versions, the minimum will get set > to the highest available (say Since 1.2). > > However, that will also make it impossible to connect to a server that > doesn't support the said version. Exactly this. To clarify a bit more, there are two mechanisms to enforce that the most secure version is used: 1) TLS version negotiation will automatically used the newest TLS version *that both peers support*. So if e.g. the server supports upto 1.2, and the client upto 1.1, TLS will negotiate 1.1. OpenVPN does not do any browser-like 'version fallback'. 2) To prevent any attacks on problems in the above mechanisms, or enforce a specific version to be used, you can use OpenVPN's --tls-version-min. Using or-highest as Selva suggests will ensure that the highest version support *by the local OpenVPN version* is required. So if you peer does not support that version, the connection will fail. Summarizing, only use --tls-version-min if you are sure that *all* peers in you network support that version. And if you do not use --tls-version-min, TLS will automatically negotiate the highest version that *is* possible to negotiate. -Steffan 

Yep, looks to be OK now (with definitions updated today). Thanks! ... Russell -----Original Message----- From: Magnus Kroken [mailto:mk...@gm...] Sent: Thursday, December 29, 2016 12:34 PM To: Morris, Russell <rm...@rk...> Cc: ope...@li...; Samuli Seppänen <sa...@op...> Subject: Re: [Openvpn-devel] OpenVPN Service Flagged as Trojan Hi On 29.12.2016 19.07, Morris, Russell wrote: > That's good - thanks! Not sure how to fix Windows flagging this though - I'm assuming others will have the same issue. > > ... Russell Most likely a definition update will fix this very soon, or already has. I just ran it through Virustotal [1], all scanners report it as harmless, including Microsoft with todays definitions. Also, Defender reports openvpnserv2 as clean on my computer, with definitions created today at 10:44 AM (CET or UTC, I'm not sure which). [1] https://www.virustotal.com/en/file/c3970ec979ccbdb03d38c1df606fc3437a85cea2f3b56a2f03c32fde4dfe9046/analysis/1483035462/ /Magnus 

Hi, On Thu, Dec 29, 2016 at 07:57:26PM +0100, Christian Hesse wrote: > From: Christian Hesse <ma...@ew...> > > We have voices that do not want to "litter ENABLE_SYSTEMD all over the > code". So move the systemd specific bits to platform_notify() in > platform.c. While this is better, it's still far from a proper abstraction that could be used for cross-platform notification - like Selva said, we might want to add windows event logging eventually (quite likely a larger user base than Linux)... So, for a start, passing arguments to platform_notify() that do not make sense to anything that is not sd_notify() is a non-starter. Then, please investigate using the existing status file / management interface code to add this, instead of adding new calls in init.c (I mentioned this yesterday). If our existing status file / management code is not up to more fine-grained notification, I'd rather see that one improved, and then call out to systemd / windows events / ... than new code in parallel to the existing notification code. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Hi, On Wed, Dec 28, 2016 at 11:49:24PM +0100, David Sommerseth wrote: > On 28/12/16 22:03, Gert Doering wrote: > > nothing else but a subset of Linux distributions use systemd today, > > If including the "millions" of various Linux distributions on > DistroWatch, you might very well be right. > > But a far better measuring point would be which Linux distributions the > majority of Linux users do use. And in my experience, the list which is > gathered on wikipedia [1] covers what the vast majority of Linux users > installs. At least the majority of users I have met on various > conferences over the last few years. > > [1] <https://en.wikipedia.org/wiki/Systemd#Adoption_and_reception> My point was not whether it's "many" or "few" Linux distributions, but it's "a (large) subset of Linux-only". Even if it reaches 99% one day, it's still "Linux", which makes it a more of a platform-dependent thing for me, and not a "feature", when regarding "where do we want to have these #ifdef". gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

On Thu, Dec 29, 2016 at 5:53 AM, Samuli Seppänen <sa...@op...> wrote: > Hi, > > Any comments about the forwarded email? Is our documentation regarding > "or-highest" correct? > > Samuli > > > -------- Messaggio Inoltrato -------- > Oggetto: Re: [Openvpn-announce] OpenVPN 2.4.0 released > Data: Tue, 27 Dec 2016 22:04:23 -0600 > Mittente: Michael French <Mi...@mp...> > A: Samuli Seppänen <sa...@op...> > > > > Hi Samuli, > I installed 2.4 on a couple Windows 7x64 computers and all seems well. > I even got tls-crypt to work using the old ta.key file on both client > and server. > > However, I noticed in the documentation for 2.4 that the parameter > tls-version-min is supposed to work with the 'or-highest' option, but it > does not. > > I wish that it did work because I always want to run with the most > secure version of TLS and the 'or-highest' option would save me the > trouble of manually editing the TLS number every time it changes. > I too find this option somewhat counter-intuitive. I think you can effectively get it set to the highest available version by specifying an insanely large number as the first parameter. For example, --tls-version-min 5.0 or-highest As 5.0 is larger than any available versions, the minimum will get set to the highest available (say 1.2). However, that will also make it impossible to connect to a server that doesn't support the said version. Selva 

From: Christian Hesse <ma...@ew...> We have voices that do not want to "litter ENABLE_SYSTEMD all over the code". So move the systemd specific bits to platform_notify() in platform.c. Signed-off-by: Christian Hesse <ma...@ew...> --- src/openvpn/init.c | 23 +++++------------------ src/openvpn/platform.c | 13 +++++++++++++ src/openvpn/platform.h | 2 ++ 3 files changed, 20 insertions(+), 18 deletions(-) diff --git a/src/openvpn/init.c b/src/openvpn/init.c index 9a3e29d..46df8ca 100644 --- a/src/openvpn/init.c +++ b/src/openvpn/init.c @@ -30,10 +30,6 @@ #include "syshead.h" -#ifdef ENABLE_SYSTEMD -#include <systemd/sd-daemon.h> -#endif - #include "win32.h" #include "init.h" #include "sig.h" @@ -983,13 +979,11 @@ possibly_become_daemon(const struct options *options) { bool ret = false; -#ifdef ENABLE_SYSTEMD /* return without forking if we are running from systemd */ - if (sd_notify(0, "READY=0") > 0) + if (platform_notify("READY=0", "STATUS=Possibly become daemon") > 0) { return ret; } -#endif if (options->daemon) { @@ -1026,7 +1020,6 @@ do_uid_gid_chroot(struct context *c, bool no_delay) { if (no_delay) { -#ifdef ENABLE_SYSTEMD /* If OpenVPN is started by systemd, the OpenVPN process needs * to provide a preliminary status report to systemd. This is * needed as $NOTIFY_SOCKET will not be available inside the @@ -1040,10 +1033,8 @@ do_uid_gid_chroot(struct context *c, bool no_delay) * have a sane way to know if OpenVPN will chroot or not and to * which subdirectory it will chroot into. */ - sd_notifyf(0, "READY=1\n" - "STATUS=Entering chroot, most of the init completed successfully\n" - "MAINPID=%lu", (unsigned long) getpid()); -#endif + platform_notify("READY=1", + "STATUS=Entering chroot, most of the init completed successfully"); platform_chroot(c->options.chroot_dir); } else if (c->first_time) @@ -1384,17 +1375,13 @@ initialization_sequence_completed(struct context *c, const unsigned int flags) show_adapters(M_INFO|M_NOPREFIX); msg(M_INFO, "%s With Errors ( see http://openvpn.net/faq.html#dhcpclientserv )", message); #else -#ifdef ENABLE_SYSTEMD - sd_notifyf(0, "STATUS=Failed to start up: %s With Errors\nERRNO=1", message); -#endif /* HAVE_SYSTEMD_SD_DAEMON_H */ + platform_notify("READY=0", "STATUS=Failed to start up"); msg(M_INFO, "%s With Errors", message); #endif } else { -#ifdef ENABLE_SYSTEMD - sd_notifyf(0, "READY=1\nSTATUS=%s\nMAINPID=%lu", message, (unsigned long) getpid()); -#endif + platform_notify("READY=1", "STATUS=Initialization Sequence Completed"); msg(M_INFO, "%s", message); } diff --git a/src/openvpn/platform.c b/src/openvpn/platform.c index 952d633..55a25b0 100644 --- a/src/openvpn/platform.c +++ b/src/openvpn/platform.c @@ -30,6 +30,10 @@ #include "syshead.h" +#ifdef ENABLE_SYSTEMD +#include <systemd/sd-daemon.h> +#endif + #include "buffer.h" #include "error.h" #include "win32.h" @@ -336,3 +340,12 @@ platform_stat(const char *path, platform_stat_t *buf) #endif } +int +platform_notify(const char *status, const char *message) +{ +#ifdef ENABLE_SYSTEMD + return sd_notifyf(0, "%s\n%s", status, message); +#endif + + return 0; +} diff --git a/src/openvpn/platform.h b/src/openvpn/platform.h index 62396a9..94c92e4 100644 --- a/src/openvpn/platform.h +++ b/src/openvpn/platform.h @@ -144,4 +144,6 @@ typedef struct stat platform_stat_t; #endif int platform_stat(const char *path, platform_stat_t *buf); +int platform_notify(const char *status, const char *message); + #endif /* ifndef PLATFORM_H */ -- 2.11.0 

From: Christian Hesse <ma...@ew...> In non-TLS configuration we wait for the remote peer to connect before issuing "Initialization Sequence Completed". So prevent to time out by telling systemd service manager we are ready for now. Status will be "Non-TLS mode, ready for now. Waiting for peer..." and changes once the remote peer connects. This fixes #801 (static key tunnels impossible to start via systemd) v2: Rebase on "move systemd specific code to platform.c" (commit 46e647933030da848774656029c4c4a1f204e2f1). Tested-by: Mantas Mikulėnas <gr...@gm...> Signed-off-by: Christian Hesse <ma...@ew...> --- src/openvpn/openvpn.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/openvpn/openvpn.c b/src/openvpn/openvpn.c index 888acda..ddcb9ed 100644 --- a/src/openvpn/openvpn.c +++ b/src/openvpn/openvpn.c @@ -73,6 +73,18 @@ tunnel_point_to_point(struct context *c) return; } + /* In non-TLS configuration we wait for the remote peer to connect + * before issuing "Initialization Sequence Completed". So prevent to + * time out by telling systemd service manager we are ready for now. + * Status will be "Non-TLS mode, ready for now. Waiting for peer..." + * and changes once the remote peer connects. */ + if (c->options.tls_client == false + && c->options.tls_server == false) + { + platform_notify("READY=1", + "STATUS=Non-TLS mode, ready for now. Waiting for peer..."); + } + /* main event loop */ while (true) { -- 2.11.0 

Hi On 29.12.2016 19.07, Morris, Russell wrote: > That's good - thanks! Not sure how to fix Windows flagging this though - I'm assuming others will have the same issue. > > ... Russell Most likely a definition update will fix this very soon, or already has. I just ran it through Virustotal [1], all scanners report it as harmless, including Microsoft with todays definitions. Also, Defender reports openvpnserv2 as clean on my computer, with definitions created today at 10:44 AM (CET or UTC, I'm not sure which). [1] https://www.virustotal.com/en/file/c3970ec979ccbdb03d38c1df606fc3437a85cea2f3b56a2f03c32fde4dfe9046/analysis/1483035462/ /Magnus 

Hi, Sure you bet! Had to restore it from Quarantine (was removed by Window Defender). Here are the checksums - do they look right? SHA-1: 12A92A1314394994E5493DEEDECCE1B885E88497 MD5: 4628C852B721472918C0F07C954AD11D CRC32: BC4B4D67 Thanks, ... Russell -----Original Message----- From: Samuli Seppänen [mailto:sa...@op...] Sent: Thursday, December 29, 2016 3:44 AM To: Morris, Russell <rm...@rk...>; ope...@li... Subject: Re: [Openvpn-devel] OpenVPN Service Flagged as Trojan Hi Russell, Interesting. Can you send me the sha1sum or md5sum of your openvpnserv2.exe? We've typically had false positives related to the OpenVPN installers, but never with the bundled executables afaik. Samuli Il 29/12/2016 05:45, Morris, Russell ha scritto: > Something you may want to know about - at least on my Windows 10 > machine, when I try to run openvpnserv2.exe . Windows Defender > identifies it as a Trojan - quarantines and removes it . L. > > > > Thanks, > > . Russell > > > > > > > > ---------------------------------------------------------------------- > -------- Check out the vibrant tech community on one of the world's > most engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > 

That's good - thanks! Not sure how to fix Windows flagging this though - I'm assuming others will have the same issue. ... Russell -----Original Message----- From: Samuli Seppänen [mailto:sa...@op...] Sent: Thursday, December 29, 2016 12:03 PM To: Morris, Russell <rm...@rk...>; ope...@li... Subject: Re: [Openvpn-devel] OpenVPN Service Flagged as Trojan Your sha1sum matches that of "openvpnserv2-1.3.0.0.exe" on the download server, which is correct. So there is nothing suspicious about your copy of openvpnserv2.exe. Samuli Il 29/12/2016 18:40, Morris, Russell ha scritto: > Hi, > > Sure you bet! Had to restore it from Quarantine (was removed by Window Defender). Here are the checksums - do they look right? > > SHA-1: 12A92A1314394994E5493DEEDECCE1B885E88497 > MD5: 4628C852B721472918C0F07C954AD11D > CRC32: BC4B4D67 > > Thanks, > ... Russell > > > -----Original Message----- > From: Samuli Seppänen [mailto:sa...@op...] > Sent: Thursday, December 29, 2016 3:44 AM > To: Morris, Russell <rm...@rk...>; > ope...@li... > Subject: Re: [Openvpn-devel] OpenVPN Service Flagged as Trojan > > Hi Russell, > > Interesting. Can you send me the sha1sum or md5sum of your openvpnserv2.exe? > > We've typically had false positives related to the OpenVPN installers, but never with the bundled executables afaik. > > Samuli > > Il 29/12/2016 05:45, Morris, Russell ha scritto: >> Something you may want to know about - at least on my Windows 10 >> machine, when I try to run openvpnserv2.exe . Windows Defender >> identifies it as a Trojan - quarantines and removes it . L. >> >> >> >> Thanks, >> >> . Russell >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> - >> -------- Check out the vibrant tech community on one of the world's >> most engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> >> >> >> _______________________________________________ >> Openvpn-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openvpn-devel >> > > 

Your sha1sum matches that of "openvpnserv2-1.3.0.0.exe" on the download server, which is correct. So there is nothing suspicious about your copy of openvpnserv2.exe. Samuli Il 29/12/2016 18:40, Morris, Russell ha scritto: > Hi, > > Sure you bet! Had to restore it from Quarantine (was removed by Window Defender). Here are the checksums - do they look right? > > SHA-1: 12A92A1314394994E5493DEEDECCE1B885E88497 > MD5: 4628C852B721472918C0F07C954AD11D > CRC32: BC4B4D67 > > Thanks, > ... Russell > > > -----Original Message----- > From: Samuli Seppänen [mailto:sa...@op...] > Sent: Thursday, December 29, 2016 3:44 AM > To: Morris, Russell <rm...@rk...>; ope...@li... > Subject: Re: [Openvpn-devel] OpenVPN Service Flagged as Trojan > > Hi Russell, > > Interesting. Can you send me the sha1sum or md5sum of your openvpnserv2.exe? > > We've typically had false positives related to the OpenVPN installers, but never with the bundled executables afaik. > > Samuli > > Il 29/12/2016 05:45, Morris, Russell ha scritto: >> Something you may want to know about - at least on my Windows 10 >> machine, when I try to run openvpnserv2.exe . Windows Defender >> identifies it as a Trojan - quarantines and removes it . L. >> >> >> >> Thanks, >> >> . Russell >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >> -------- Check out the vibrant tech community on one of the world's >> most engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> >> >> >> _______________________________________________ >> Openvpn-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openvpn-devel >> > > 

Am 29.12.16 um 10:53 schrieb Samuli Seppänen: > Hi, > > Any comments about the forwarded email? Is our documentation regarding > "or-highest" correct? > Yes should be correct. Speciyfing a not yet supported tls version, e.g. "1.3" will also give an error. Also this directive is not for being always bumped to the next version but (as tls-version-max) but to exclude certain version, i.e. 1.0. Arne 

Hi, Any comments about the forwarded email? Is our documentation regarding "or-highest" correct? Samuli -------- Messaggio Inoltrato -------- Oggetto:	Re: [Openvpn-announce] OpenVPN 2.4.0 released Data:	Tue, 27 Dec 2016 22:04:23 -0600 Mittente:	Michael French <Mi...@mp...> A:	Samuli Seppänen <sa...@op...> Hi Samuli, I installed 2.4 on a couple Windows 7x64 computers and all seems well. I even got tls-crypt to work using the old ta.key file on both client and server. However, I noticed in the documentation for 2.4 that the parameter tls-version-min is supposed to work with the 'or-highest' option, but it does not. I wish that it did work because I always want to run with the most secure version of TLS and the 'or-highest' option would save me the trouble of manually editing the TLS number every time it changes. Thanks and keep up the good work! Regards, Mike 

Hi Russell, Interesting. Can you send me the sha1sum or md5sum of your openvpnserv2.exe? We've typically had false positives related to the OpenVPN installers, but never with the bundled executables afaik. Samuli Il 29/12/2016 05:45, Morris, Russell ha scritto: > Something you may want to know about – at least on my Windows 10 > machine, when I try to run openvpnserv2.exe … Windows Defender > identifies it as a Trojan – quarantines and removes it … L. > > > > Thanks, > > … Russell > > > > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > 

Copying with the attached logs forwarded to the devel list for more expert opinion Hi, Thanks for the logs. The repeated .. Route: Waiting for TUN/TAP interface to come up... in the logs is the same as what I wrote about previously -- I think setting the tunnel IP by dhcp fails but openvpn tags this as a not-fatal route setting error, the GUI only sees the final "CONNECTED, SUCCESS..." message and wrongly reports as if all is well... That said I do not know why the the adapter fails to set the IP the second time -- possibly some misbehaviour in the tap-driver when the IP is changed in a quick succession? Just guessing. Selva ---------- Forwarded message ---------- From: Dmitry Melekhov <dm...@be...> Date: Thu, Dec 29, 2016 at 12:02 AM Subject: Fwd: Re: [Openvpn-users] 2.4, windows tap driver problem To: sel...@gm... Hello! Message to mail list was blocked before moderator approval, so forwarding to you directly. Thank you! -------- Перенаправленное сообщение -------- Тема: Re: [Openvpn-users] 2.4, windows tap driver problem Дата: Thu, 29 Dec 2016 09:00:53 +0400 От: Dmitry Melekhov <dm...@be...> <dm...@be...> Кому: ope...@li... 29.12.2016 07:30, Selva Nair пишет: On Wed, Dec 28, 2016 at 10:07 PM, Dmitry Melekhov < <dm...@be...> dm...@be...> wrote: > On Wed, Dec 28, 2016 at 1:43 AM, Dmitry Melekhov < <dm...@be...> > dm...@be...> wrote: > >> Just installed 2.4 on windows 7. >> >> Connecting to on server, tun is set to, let's say to 10.1.10.6, >> >> everything is fine. >> >> Disconnect. >> >> Change remote in config, connect to another server, >> tun address should be 192.168.31.6, gui says so, >> >> but real address on tun is 10.1.10.6. >> >> >> Reboot solves problem, but on next connection sequence it is reproduced. >> > > > I tried to reproduce this but fortunately no luck :) > > As Gert said, logs please. Also please include an output of ipconfig /all > showing the settings on tun adapters with each connection up. > > I sent logs to Gert already...connection > > but, afair, only failed connection.. This rings a bell. I've seen connection failures in the past when the same tap adapter is used with different remotes in a succession. The connection fails with something like repeated "TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down" which indicates setting IP by dhcp didn't succeed. Without logs, not sure that's what you are seeing, though. Never seen it lately as I now use explicitly named dev nodes (--dev-node name option) so that each connection uses a fixed adapter node. And no idea why it happens. Could be tap-driver related so someone else may have a clue. OK, here are 1. ipconfig before first connection: C:\>ipconfig /all Настройка протокола IP для Windows Имя компьютера . . . . . . . . . : JNK-W7 Основной DNS-суффикс . . . . . . : ad.belkam.com Тип узла. . . . . . . . . . . . . : Гибридный IP-маршрутизация включена . . . . : Нет WINS-прокси включен . . . . . . . : Нет Порядок просмотра суффиксов DNS . : ad.belkam.com p98.belkam.com Ethernet adapter Подключение по локальной сети 2: Состояние среды. . . . . . . . : Среда передачи недоступна. DNS-суффикс подключения . . . . . : Описание. . . . . . . . . . . . . : TAP-Windows Adapter V9 Физический адрес. . . . . . . . . : 00-FF-BE-79-4D-53 DHCP включен. . . . . . . . . . . : Да Автонастройка включена. . . . . . : Да Ethernet adapter Подключение по локальной сети: DNS-суффикс подключения . . . . . : p98.belkam.com Описание. . . . . . . . . . . . . : Адаптер рабочего стола Intel(R) PRO/1000 MT Физический адрес. . . . . . . . . : 08-00-27-6D-1B-5A DHCP включен. . . . . . . . . . . : Да Автонастройка включена. . . . . . : Да Локальный IPv6-адрес канала . . . : fe80::fdd4:7bac:502c:dacd%10(Основной) IPv4-адрес. . . . . . . . . . . . : 192.168.22.44(Основной) Маска подсети . . . . . . . . . . : 255.255.255.0 Аренда получена. . . . . . . . . . : 29 декабря 2016 г. 8:35:07 Срок аренды истекает. . . . . . . . . . : 29 декабря 2016 г. 14:35:07 Основной шлюз. . . . . . . . . : 192.168.22.221 DHCP-сервер. . . . . . . . . . . : 192.168.22.222 IAID DHCPv6 . . . . . . . . . . . : 235405351 DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-13-1E-AD-C1-08-00-27-6D-1B-5A DNS-серверы. . . . . . . . . . . : 192.168.22.222 192.168.22.99 Основной WINS-сервер. . . . . . . : 192.168.22.91 NetBios через TCP/IP. . . . . . . . : Включен Туннельный адаптер isatap.p98.belkam.com: Состояние среды. . . . . . . . : Среда передачи недоступна. DNS-суффикс подключения . . . . . : p98.belkam.com Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP включен. . . . . . . . . . . : Нет Автонастройка включена. . . . . . : Да Туннельный адаптер Подключение по локальной сети*: Состояние среды. . . . . . . . : Среда передачи недоступна. DNS-суффикс подключения . . . . . : Описание. . . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP включен. . . . . . . . . . . : Нет Автонастройка включена. . . . . . : Да Туннельный адаптер isatap.{BE794D53-798C-40DC-8B64-4CE37589133F}: Состояние среды. . . . . . . . : Среда передачи недоступна. DNS-суффикс подключения . . . . . : Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP #2 Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP включен. . . . . . . . . . . : Нет Автонастройка включена. . . . . . : Да 2. ipconfig before second connection C:\>ipconfig /all Настройка протокола IP для Windows Имя компьютера . . . . . . . . . : JNK-W7 Основной DNS-суффикс . . . . . . : ad.belkam.com Тип узла. . . . . . . . . . . . . : Гибридный IP-маршрутизация включена . . . . : Нет WINS-прокси включен . . . . . . . : Нет Порядок просмотра суффиксов DNS . : ad.belkam.com p98.belkam.com Ethernet adapter Подключение по локальной сети 2: DNS-суффикс подключения . . . . . : Описание. . . . . . . . . . . . . : TAP-Windows Adapter V9 Физический адрес. . . . . . . . . : 00-FF-BE-79-4D-53 DHCP включен. . . . . . . . . . . : Да Автонастройка включена. . . . . . : Да IPv4-адрес. . . . . . . . . . . . : 10.1.10.6(Основной) Маска подсети . . . . . . . . . . : 255.255.255.0 Аренда получена. . . . . . . . . . : 29 декабря 2016 г. 8:48:39 Срок аренды истекает. . . . . . . . . . : 29 декабря 2017 г. 8:48:39 Основной шлюз. . . . . . . . . : DHCP-сервер. . . . . . . . . . . : 10.1.10.254 DNS-серверы. . . . . . . . . . . : 10.1.1.1 Основной WINS-сервер. . . . . . . : 192.168.22.220 NetBios через TCP/IP. . . . . . . . : Включен Ethernet adapter Подключение по локальной сети: DNS-суффикс подключения . . . . . : p98.belkam.com Описание. . . . . . . . . . . . . : Адаптер рабочего стола Intel(R) PRO/1000 MT Физический адрес. . . . . . . . . : 08-00-27-6D-1B-5A DHCP включен. . . . . . . . . . . : Да Автонастройка включена. . . . . . : Да Локальный IPv6-адрес канала . . . : fe80::fdd4:7bac:502c:dacd%10(Основной) IPv4-адрес. . . . . . . . . . . . : 192.168.22.44(Основной) Маска подсети . . . . . . . . . . : 255.255.255.0 Аренда получена. . . . . . . . . . : 29 декабря 2016 г. 8:35:07 Срок аренды истекает. . . . . . . . . . : 29 декабря 2016 г. 14:35:08 Основной шлюз. . . . . . . . . : 192.168.22.221 DHCP-сервер. . . . . . . . . . . : 192.168.22.222 IAID DHCPv6 . . . . . . . . . . . : 235405351 DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-13-1E-AD-C1-08-00-27-6D-1B-5A DNS-серверы. . . . . . . . . . . : 192.168.22.222 192.168.22.99 Основной WINS-сервер. . . . . . . : 192.168.22.91 NetBios через TCP/IP. . . . . . . . : Включен Туннельный адаптер isatap.p98.belkam.com: Состояние среды. . . . . . . . : Среда передачи недоступна. DNS-суффикс подключения . . . . . : p98.belkam.com Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP включен. . . . . . . . . . . : Нет Автонастройка включена. . . . . . : Да Туннельный адаптер Подключение по локальной сети*: Состояние среды. . . . . . . . : Среда передачи недоступна. DNS-суффикс подключения . . . . . : Описание. . . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP включен. . . . . . . . . . . : Нет Автонастройка включена. . . . . . : Да Туннельный адаптер isatap.{BE794D53-798C-40DC-8B64-4CE37589133F}: Состояние среды. . . . . . . . : Среда передачи недоступна. DNS-суффикс подключения . . . . . : Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP #2 Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP включен. . . . . . . . . . . : Нет Автонастройка включена. . . . . . : Да Logs are attached. Thank you! 

2016-12-29 10:23 GMT+05:00 Selva Nair <sel...@gm...>: > Hi, > > On Wed, Dec 28, 2016 at 11:56 PM, Илья Шипицин <chi...@gm...> > wrote: > >> >> I seem to see several times issues like described in #665 >> > > I have seen this in the past but, iirc, without the FlushipNetTable error, > though not 100% sure of that. > > However, > > >> >> what seems to be strange is couple of things: >> >> 1) "OR" clause. why not "AND" ? https://github.com/OpenVPN/ope >> nvpn/blob/master/src/openvpn/tun.c#L6012-L6013 >> > > OR is correct as either case (error in WriteFile or error in ReadFile) is > a failure. > > >> >> >> 2) error message seems to be irrelevant https://github.com/OpenVPN/ope >> nvpn/blob/master/src/openvpn/tun.c#L6034 >> > > I think this results from failure to set the IP using DHCP and always > thought it to be some misbehavior in the tap driver. But the failure to > flush may be related... > > Have you found a way to reproduce it consistently? > I only seen that on Win10 (as described in trac ticket). So, I'll make win10 virtual appliance and will try to consistently reproduce it myself. > > Selva > > 

2016-12-29 10:23 GMT+05:00 Selva Nair <sel...@gm...>: > Hi, > > On Wed, Dec 28, 2016 at 11:56 PM, Илья Шипицин <chi...@gm...> > wrote: > >> >> I seem to see several times issues like described in #665 >> > > I have seen this in the past but, iirc, without the FlushipNetTable error, > though not 100% sure of that. > > However, > > >> >> what seems to be strange is couple of things: >> >> 1) "OR" clause. why not "AND" ? https://github.com/OpenVPN/ope >> nvpn/blob/master/src/openvpn/tun.c#L6012-L6013 >> > > OR is correct as either case (error in WriteFile or error in ReadFile) is > a failure. > > >> >> >> 2) error message seems to be irrelevant https://github.com/OpenVPN/ope >> nvpn/blob/master/src/openvpn/tun.c#L6034 >> > > I think this results from failure to set the IP using DHCP and always > thought it to be some misbehavior in the tap driver. But the failure to > flush may be related... > > Have you found a way to reproduce it consistently? > not yet. so ... should we at least improve debug here ? I would split !read || !write into 2 separate calls with separate debug log messages... and move FlushIpNet error closer to FlushIpNet call. right ? > > Selva > > 

Hi, On Wed, Dec 28, 2016 at 11:56 PM, Илья Шипицин <chi...@gm...> wrote: > > I seem to see several times issues like described in #665 > I have seen this in the past but, iirc, without the FlushipNetTable error, though not 100% sure of that. However, > > what seems to be strange is couple of things: > > 1) "OR" clause. why not "AND" ? https://github.com/OpenVPN/ > openvpn/blob/master/src/openvpn/tun.c#L6012-L6013 > OR is correct as either case (error in WriteFile or error in ReadFile) is a failure. > > > 2) error message seems to be irrelevant https://github.com/OpenVPN/ > openvpn/blob/master/src/openvpn/tun.c#L6034 > I think this results from failure to set the IP using DHCP and always thought it to be some misbehavior in the tap driver. But the failure to flush may be related... Have you found a way to reproduce it consistently? Selva 

2016-12-29 9:56 GMT+05:00 Илья Шипицин <chi...@gm...>: > Hello, > > I seem to see several times issues like described in #665 > > what seems to be strange is couple of things: > > 1) "OR" clause. why not "AND" ? https://github.com/OpenVPN/ > openvpn/blob/master/src/openvpn/tun.c#L6012-L6013 > I will answer myself. !read || !write - is proper use of "OR" > > > 2) error message seems to be irrelevant https://github.com/OpenVPN/ > openvpn/blob/master/src/openvpn/tun.c#L6034 > > it might be an error from earlier function calls, not only FlushIpNetTable > itself. > > > any ideas ? > > > Cheers, > Ilya Shipitsin > 

Hello, I seem to see several times issues like described in #665 what seems to be strange is couple of things: 1) "OR" clause. why not "AND" ? https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/tun.c#L6012-L6013 2) error message seems to be irrelevant https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/tun.c#L6034 it might be an error from earlier function calls, not only FlushIpNetTable itself. any ideas ? Cheers, Ilya Shipitsin