openvpn-devel Mailing List for OpenVPN

On 04/30/2014 02:15 PM, Samuli Seppänen wrote: > >> On 04/29/2014 10:02 PM, Samuli Sepp?nen wrote: >>> Hi all, >>> >>> I built OpenVPN 2.3.3 installers that contain tap-windows6 (NDIS 6) drivers: >>> >>> <http://build.openvpn.net/downloads/temp/ndis6> >>> >>> Note the build number, "605", where the first digit ("6") means "comes >>> with an NDIS 6 driver". >>> >>> I tested the 64-bit version on Win7 64-bit and it seemed to work ok, but >>> my testing was anything but extensive. So, if [some of] you happen to >>> have a non-critical Windows box(es) lying around it'd be great if you >>> could test whether the new driver works ok in your environment. I >>> suggest removing any previous OpenVPN installations, installing the new >>> package and then verifying the driver version using the Device Manager; >>> the NDIS 5 driver version is 9.9.2, whereas this new driver is 9.21.0 >>> >>> Note that as tap-windows6 is still an unproven driver it can BSOD. We >>> haven't experienced any problems with it, but it's best too keep that >>> possibility in mind. >>> >>> We will soon start offering the OpenVPN installer with NDIS 6-driver as >>> an option and hopefully soon afterwards make them the default option for >>> Windows Vista and above. >>> >> Hello, >> >> I've just done some testing on Win7 64-bit (german localization) and >> didn't notice any problems. However, driver assembly version is >> indicated as "9.0.0.21", not "9.21.0". (?) >> >> Regards, >>	Christian >> > Thanks for testing, Christian! > > I believe that odd version number is to be expected, and really boils > down to formatting differences. Similarly the old tap-windows (NDIS 5) > driver will report 9.0.0.9 as it's version - in our parlance that > translates to 9.9.x. > Hello Samuli, thanks for clarification. I've now tested successfully on Win 8.1 64-bit (german localization). Version numbers are the same as on Win 7. Regards,	Christian -- Dr. Christian Rank Rechenzentrum Universität Passau Bereich Netzwerk und Telekommunikation IT-Sicherheitsbeauftragter der Universität Innstr. 33 D-94032 Passau GERMANY Tel.: 0851/509-1838 Fax: 0851/509-1802 

On 04/29/2014 10:02 PM, Samuli Sepp?nen wrote: > Hi all, > > I built OpenVPN 2.3.3 installers that contain tap-windows6 (NDIS 6) drivers: > > <http://build.openvpn.net/downloads/temp/ndis6> > > Note the build number, "605", where the first digit ("6") means "comes > with an NDIS 6 driver". > > I tested the 64-bit version on Win7 64-bit and it seemed to work ok, but > my testing was anything but extensive. So, if [some of] you happen to > have a non-critical Windows box(es) lying around it'd be great if you > could test whether the new driver works ok in your environment. I > suggest removing any previous OpenVPN installations, installing the new > package and then verifying the driver version using the Device Manager; > the NDIS 5 driver version is 9.9.2, whereas this new driver is 9.21.0 > > Note that as tap-windows6 is still an unproven driver it can BSOD. We > haven't experienced any problems with it, but it's best too keep that > possibility in mind. > > We will soon start offering the OpenVPN installer with NDIS 6-driver as > an option and hopefully soon afterwards make them the default option for > Windows Vista and above. > Hello, I've just done some testing on Win7 64-bit (german localization) and didn't notice any problems. However, driver assembly version is indicated as "9.0.0.21", not "9.21.0". (?) Regards,	Christian -- Dr. Christian Rank Rechenzentrum Universität Passau Bereich Netzwerk und Telekommunikation IT-Sicherheitsbeauftragter der Universität Innstr. 33 D-94032 Passau GERMANY Tel.: 0851/509-1838 Fax: 0851/509-1802 

 > On 04/29/2014 10:02 PM, Samuli Sepp?nen wrote: >> Hi all, >> >> I built OpenVPN 2.3.3 installers that contain tap-windows6 (NDIS 6) drivers: >> >> <http://build.openvpn.net/downloads/temp/ndis6> >> >> Note the build number, "605", where the first digit ("6") means "comes >> with an NDIS 6 driver". >> >> I tested the 64-bit version on Win7 64-bit and it seemed to work ok, but >> my testing was anything but extensive. So, if [some of] you happen to >> have a non-critical Windows box(es) lying around it'd be great if you >> could test whether the new driver works ok in your environment. I >> suggest removing any previous OpenVPN installations, installing the new >> package and then verifying the driver version using the Device Manager; >> the NDIS 5 driver version is 9.9.2, whereas this new driver is 9.21.0 >> >> Note that as tap-windows6 is still an unproven driver it can BSOD. We >> haven't experienced any problems with it, but it's best too keep that >> possibility in mind. >> >> We will soon start offering the OpenVPN installer with NDIS 6-driver as >> an option and hopefully soon afterwards make them the default option for >> Windows Vista and above. >> > Hello, > > I've just done some testing on Win7 64-bit (german localization) and > didn't notice any problems. However, driver assembly version is > indicated as "9.0.0.21", not "9.21.0". (?) > > Regards, >	Christian > Thanks for testing, Christian! I believe that odd version number is to be expected, and really boils down to formatting differences. Similarly the old tap-windows (NDIS 5) driver will report 9.0.0.9 as it's version - in our parlance that translates to 9.9.x. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

ACK. Patch is slightly bigger than f80a52b09eed8e5e0cad ("the same thing for master") as it also backports the renaming of x509_get_serial() to backend_x509_get_serial() - which is purely cosmetic, but now the code is better aligned. Your patch has been applied to the release/2.3 branch. commit 142d4dd2e98317a03ca9827f03fc4643fe922834 (release/2.3) Author: Steffan Karger Date: Mon Apr 28 21:50:22 2014 +0200 Make serial env exporting consistent amongst OpenSSL and PolarSSL builds. Signed-off-by: Steffan Karger <st...@ka...> Acked-by: Gert Doering <ge...@gr...> Message-Id: <535...@ka...> URL: http://article.gmane.org/gmane.network.openvpn.devel/8664 Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

Latest iteration of this patch has been applied to the release/2.3 branch, thanks to all who helped. commit a291825f7145679e6d1806029290402d0430b465 (release/2.3) Author: James Yonan Date: Mon Apr 28 22:52:11 2014 +0200 When tls-version-min is unspecified, revert to original versioning approach. Signed-off-by: James Yonan <ja...@op...> Signed-off-by: Gert Doering <ge...@gr...> Signed-off-by: Steffan Karger <st...@ka...> Acked-by: James Yonan <ja...@op...> Message-Id: <535...@ka...> URL: http://article.gmane.org/gmane.network.openvpn.devel/8665 Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

On 28/04/2014 15:19, Steffan Karger wrote: > Hi, > > On 27-04-14 22:10, Steffan Karger wrote: >> On 27-04-14 19:53, Gert Doering wrote: >>> On Mon, Apr 21, 2014 at 01:10:04AM -0600, James Yonan wrote: The >>> attached patch is what I intend to commit to release/2.3 *only*, >>> not to master - as agreed at the IRC meeting. "Please ACK" :-) >> >> Sorry, but NAK. > > On a more constructive note: attached a new proposal for this patch. > >> The OpenSSL bits look fine > > On a closer look, the wrapping "if (tls_version_min > TLS_VER_UNSPEC)" > in tls_ctx_set_options() seems redundant, because TLS_VER_UNSPEC < > TLS_VER_1_0 < TLS_VER_1_1 < TLS_VER_1_2 and the ifs are checking for > "tls_version_min > TLS_VER_1_x". I've removed these changes in the > attached patch proposal. > >> the PolarSSL bits >> would also allow for SSL_MINOR_VERSION_0, which is SSLv3 and thus a >> reduction in security (and actually increases the handshake complexity). > > To elaborate a bit: The naming is a bit confusing, but > SSL_MAJOR_VERSION_3 + SSL_MINOR_VERSION_O means SSLv3, ... + > SSL_MINOR_VERSION_1 means TLSv1.0, ... + SSL_MINOR_VERSION_2 means > TLSv1.1, etc. If none are given (what would happen in the previous > version of the patch), PolarSSL defaults the minimum version to SSLv3 > and maximum to TLSv1.2. The attached patch thus removes the wrapping "if > (tls_version_min > TLS_VER_UNSPEC)" and sets the default to TLSv1.0 to > TLSv1.2 again. That is equal to the behaviour prior to the TLS > versioning patch. > > -Steffan This is fine. I can ACK this. Thanks, James 

Patch has been applied to the master and release/2.3 branches. commit c29e08a2f33234fb705a8323c0d9e1e07b0773fd (master) commit d08a6a94e14a73b62603500b9a1a89cb9ec5cb2f (release/2.3) Author: Gert Doering Date: Tue Apr 29 23:09:39 2014 +0200 Conditionalize calls to print_default_gateway on !ENABLE_SMALL Signed-off-by: Gert Doering <ge...@gr...> Acked-by: Steffan Karger <ste...@fo...> Message-Id: <139...@gr...> URL: http://article.gmane.org/gmane.network.openvpn.devel/8670 -- kind regards, Gert Doering 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ACK. - -Steffan On 29-04-14 23:09, Gert Doering wrote: > Calls to print_default_gateway() depended on #ifdef ENABLE_DEBUG, > but the actual function wasn't compiled in #ifdef ENABLE_SMALL, so > the combination "configure --enable-small --enable-debug" didn't > work. Fix. > > Fix trac #397 > > Signed-off-by: Gert Doering <ge...@gr...> --- > src/openvpn/options.c | 2 +- src/openvpn/route.c | 2 +- 2 files > changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/openvpn/options.c b/src/openvpn/options.c index > 40210e6..fe9b99d 100644 --- a/src/openvpn/options.c +++ > b/src/openvpn/options.c @@ -4144,7 +4144,7 @@ add_option (struct > options *options, > > read_config_file (options, p[1], level, file, line, msglevel, > permission_mask, option_types_found, es); } -#ifdef ENABLE_DEBUG > +#if defined(ENABLE_DEBUG) && !defined(ENABLE_SMALL) else if (streq > (p[0], "show-gateway")) { struct route_gateway_info rgi; diff --git > a/src/openvpn/route.c b/src/openvpn/route.c index 1d9da42..12f5b62 > 100644 --- a/src/openvpn/route.c +++ b/src/openvpn/route.c @@ > -579,7 +579,7 @@ init_route_list (struct route_list *rl, if > (rl->rgi.flags & RGI_ADDR_DEFINED) { setenv_route_addr (es, > "net_gateway", rl->rgi.gateway.addr, -1); -#ifdef ENABLE_DEBUG +#if > defined(ENABLE_DEBUG) && !defined(ENABLE_SMALL) > print_default_gateway (D_ROUTE, &rl->rgi); #endif } > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTYByqAAoJEJgCyj0AftKI5W4IAIuVh/DeCIgSJrpKOoRFGyFe lkNaZYQIsAo1v2MpCO4K66X4mMPOJPWyErvaSaSRNPxPugfkcNt/6EQsX4CV2R14 TFwP0HzC2yqsp4FOFqfOsvWd7Zl0YQFSAOCj3gbNSzpiUtysX7oMNr+nX0alwIcu e23uSOwrN6CaL+6zO+eANTZnD8nNU3RwWCDUTS0ckD7Crys1F36qWuvkmxUC9tvB 2jbBEWfbRTll/lq+kaVUrUCK5Kofr5Am6armr3Y4WieBVVAOxmz2gDGry5eOvrqa ym7acRj73FTej+iGS9l0cTBJKrkGdhgke0vGUNXFkAXHnsoL9hqnGVtxBCUvgVo= =iiDj -----END PGP SIGNATURE----- 

Calls to print_default_gateway() depended on #ifdef ENABLE_DEBUG, but the actual function wasn't compiled in #ifdef ENABLE_SMALL, so the combination "configure --enable-small --enable-debug" didn't work. Fix. Fix trac #397 Signed-off-by: Gert Doering <ge...@gr...> --- src/openvpn/options.c | 2 +- src/openvpn/route.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/openvpn/options.c b/src/openvpn/options.c index 40210e6..fe9b99d 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -4144,7 +4144,7 @@ add_option (struct options *options, read_config_file (options, p[1], level, file, line, msglevel, permission_mask, option_types_found, es); } -#ifdef ENABLE_DEBUG +#if defined(ENABLE_DEBUG) && !defined(ENABLE_SMALL) else if (streq (p[0], "show-gateway")) { struct route_gateway_info rgi; diff --git a/src/openvpn/route.c b/src/openvpn/route.c index 1d9da42..12f5b62 100644 --- a/src/openvpn/route.c +++ b/src/openvpn/route.c @@ -579,7 +579,7 @@ init_route_list (struct route_list *rl, if (rl->rgi.flags & RGI_ADDR_DEFINED) { setenv_route_addr (es, "net_gateway", rl->rgi.gateway.addr, -1); -#ifdef ENABLE_DEBUG +#if defined(ENABLE_DEBUG) && !defined(ENABLE_SMALL) print_default_gateway (D_ROUTE, &rl->rgi); #endif } -- 1.8.3.2 

ACK. Sorry for the long delay. Tested against reference tap server with "--mssfix 1000", verified with tcpdump without/with the patch and IPv4 and IPv6 TCP SYNs. Your patch has been applied to the master and release/2.3 branches. commit db037c20086587a609ef33127c15de080270f2cb (master) commit 7227af1131a5d7ae2ea4d8d1cd3cba3001440326 (release/2.3) Author: Dmitrij Tejblum Date: Sat Feb 8 19:33:49 2014 +0400 Fix is_ipv6 in case of tap interface. Signed-off-by: Dmitrij Tejblum <dt...@ya...> Acked-by: Gert Doering <ge...@gr...> Message-Id: <139...@ya...> URL: http://article.gmane.org/gmane.network.openvpn.devel/8259 Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

Hi all, I built OpenVPN 2.3.3 installers that contain tap-windows6 (NDIS 6) drivers: <http://build.openvpn.net/downloads/temp/ndis6> Note the build number, "605", where the first digit ("6") means "comes with an NDIS 6 driver". I tested the 64-bit version on Win7 64-bit and it seemed to work ok, but my testing was anything but extensive. So, if [some of] you happen to have a non-critical Windows box(es) lying around it'd be great if you could test whether the new driver works ok in your environment. I suggest removing any previous OpenVPN installations, installing the new package and then verifying the driver version using the Device Manager; the NDIS 5 driver version is 9.9.2, whereas this new driver is 9.21.0 Note that as tap-windows6 is still an unproven driver it can BSOD. We haven't experienced any problems with it, but it's best too keep that possibility in mind. We will soon start offering the OpenVPN installer with NDIS 6-driver as an option and hopefully soon afterwards make them the default option for Windows Vista and above. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Cosmetic issue. Apply this after the full patch. (Or just delete the 5 characters from the full patch before applying.) Sorry about the noise. From 0ec2da0e86dd39a474705e099a1b4085b9602590 Mon Sep 17 00:00:00 2001 From: Timothe Litt <li...@ac...> Date: Mon, 28 Apr 2014 18:42:42 -0400 Subject: [PATCH] Remove validation hook in syslog facility patch. While validating, PACKAGE_NAME (mixed case) was used as a default logger program name to ensure coverate of a corner case. This wasn't reverted prior to release of the patch. This switches to the intended PACKAGE (lower case) default. Released as a separate patch so as not to invalidate any review of the full patch. Signed-off-by: Timothe Litt <li...@ac...> --- src/openvpn/error.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/openvpn/error.c b/src/openvpn/error.c index fb0abbd..af7d486 100644 --- a/src/openvpn/error.c +++ b/src/openvpn/error.c @@ -563,7 +563,7 @@ open_syslog (const char *pgmname, bool stdio_to_null) /* Default program name */ if (!*pname) - pname = PACKAGE_NAME; + pname = PACKAGE; /* Convert extracted facility name to code */ -- 1.7.10.4 -- Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. 

Users want this because it allows them to have syslog put all OpenVPN messages in specific file(s) by using syslog.conf. Adds --syslog-facility name option, which must precede --daemon and --syslog. Adds ability to specify facility as [name] in --daemon and --syslog's progname argument, which makes it possible to specify the syslog facility name without modifying certain system init scripts. --syslog-facility takes precedence. For example, Debian automatically generates a --daemon vpn-{configname} directive. If you name the config foo[local1].conf, it's as though you were able to specify --syslog-facility local1 --daemon vpn-foo --config foo[local1].conf. Absent this feature, This isn't possible without modifying the distribution-provided init script. --syslog-facility list (or any other undefined name) will list the facilities that the platform supports. The old method of -DLOG_OPENVPN still provides the facility used by default. Thus, the priority is: --syslog-facility --daemon [facility] or --syslog [facility] -DLOG_OPENVPN This is forward and backward compatible with existing scripts & initfiles. Signed-off-by: Timothe Litt <li...@ac...> --- doc/openvpn.8 | 15 ++++++ src/openvpn/error.c | 129 +++++++++++++++++++++++++++++++++++++++++++++++-- src/openvpn/error.h | 1 + src/openvpn/options.c | 19 ++++++++ 4 files changed, 161 insertions(+), 3 deletions(-) diff --git a/doc/openvpn.8 b/doc/openvpn.8 index 34894e5..2c63795 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -2169,6 +2169,12 @@ When unspecified, .B progname defaults to "openvpn". +If --syslog-facility has not been specified and the name +includes [facility], the specified syslog facility name will be used with +the system logger. (This method of specifying the facility name may be +convenient when initialization scripts generate --daemon progname from +the config file name. This avoids the need to edit the script.) + When OpenVPN is run with the .B \-\-daemon option, it will try to delay daemonization until the majority of initialization @@ -2188,6 +2194,15 @@ directive above for description of .B progname parameter. .TP +.B \-\-syslog-faciity name +When logging to syslog, use name (e.g. local1 or daemon) for the facility. +If name is absent or not supported, a platform-dependent list of valid +facility names is provided. + +Must be specified before --daemon and --syslog. +If this is not convenient, the facility name may be specified as [name] in +the name parameter of either directive. +.TP .B \-\-errors-to-stderr Output errors to stderr instead of stdout unless log output is redirected by one of the .B \-\-log diff --git a/src/openvpn/error.c b/src/openvpn/error.c index fd9f19d..fb0abbd 100644 --- a/src/openvpn/error.c +++ b/src/openvpn/error.c @@ -89,9 +89,10 @@ static bool machine_readable_output; /* GLOBAL */ /* Should timestamps be included on messages to stdout/stderr? */ static bool suppress_timestamps; /* GLOBAL */ -/* The program name passed to syslog */ +/* The program name and facility passed to syslog */ #if SYSLOG_CAPABILITY static char *pgmname_syslog; /* GLOBAL */ +static int facility_syslog = -1; /* Unspec (RFC5424 - can not be negative) */ #endif /* If non-null, messages should be written here (used for debugging only) */ @@ -439,6 +440,93 @@ out_of_memory (void) exit (1); } +#if SYSLOG_CAPABILITY +static int syslog_fac_code (const char *name, int default_code) +{ + static struct { + int code; + const char *const name; + } facnames[] = { + { LOG_AUTH, "auth" }, +#ifdef LOG_AUTHPRIV /* Prefered (private), but non-POSIX */ + { LOG_AUTHPRIV, "authpriv" }, +#else + { LOG_AUTH, "authpriv" }, /* Map to non-secure code */ +#endif + { LOG_CRON, "cron" }, + { LOG_DAEMON, "daemon" }, +#ifdef LOG_FTP + { LOG_FTP, "ftp" }, +#endif + { LOG_LPR, "lpr" }, + { LOG_MAIL, "mail" }, + { LOG_NEWS, "news" }, +#ifdef LOG_SYSLOG + { LOG_SYSLOG, "syslog" }, +#endif + { LOG_USER, "user" }, +#ifdef LOG_UUCP + { LOG_UUCP, "uucp" }, +#endif + { LOG_LOCAL0, "local0" }, + { LOG_LOCAL1, "local1" }, + { LOG_LOCAL2, "local2" }, + { LOG_LOCAL3, "local3" }, + { LOG_LOCAL4, "local4" }, + { LOG_LOCAL5, "local5" }, + { LOG_LOCAL6, "local6" }, + { LOG_LOCAL7, "local7" }, + + { 0, NULL }, + }, *fac; + + if (use_syslog) + { + msg (M_ERR, "syslog facility can not be changed after logging has started"); + return; + } + + /* Lookup facility code by name */ + + for (fac = facnames; fac->name; fac++) + { + if (!strcmp (fac->name, name)) + { + return fac->code; + } + } + + /* Not found, look for name of facility that will be used */ + + if (default_code == -1) + default_code = LOG_OPENVPN; + + for (fac = facnames; fac->name; fac++) + { + if (fac->code == default_code) + { + break; + } + } + + /* Warn, and list valid names (they are platform-dependent) */ + + msg (M_WARN, "syslog: %s is not a valid facility name, using %s", name, + (fac->name? fac->name : "default")); + for (fac = facnames; fac->name; fac++) + { + msg (M_INFO, "syslog: %s facility is valid on this platform", fac->name); + } + return default_code; +} + +void set_syslog_facility (const char *name) +{ + facility_syslog = syslog_fac_code (name, -1); +} + +#endif + void open_syslog (const char *pgmname, bool stdio_to_null) { @@ -447,8 +535,43 @@ open_syslog (const char *pgmname, bool stdio_to_null) { if (!use_syslog) { - pgmname_syslog = string_alloc (pgmname ? pgmname : PACKAGE, NULL); - openlog (pgmname_syslog, LOG_PID, LOG_OPENVPN); + char *pname = pgmname_syslog = string_alloc (pgmname ? + pgmname : PACKAGE, NULL); + int facility = facility_syslog; + if (facility == -1) + { + /* Unspecified, default */ + + facility = LOG_OPENVPN; + + /* Attempt to extract from program name (simplifies init files) */ + char *facb, *face; + + /* Decode optional [facilityname] prefix */ + + if ((facb = strchr (pgmname_syslog, '[')) != NULL + && (face = strchr (facb+1, ']')) != NULL) + { + char *facname = malloc (face - facb); /* [name] => name\0 */ + + /* Extract facility name and remove from option string */ + + *face++ = '\0'; + strcpy (facname, facb+1); + memmove (facb, face, strlen(face)+1); + + /* Default program name */ + + if (!*pname) + pname = PACKAGE_NAME; + + /* Convert extracted facility name to code */ + + facility = syslog_fac_code (facname, facility); + free (facname); + } + } + openlog (pname, LOG_PID, facility); use_syslog = true; /* Better idea: somehow pipe stdout/stderr output to msg() */ diff --git a/src/openvpn/error.h b/src/openvpn/error.h index 1e1f2ac..cbd1980 100644 --- a/src/openvpn/error.h +++ b/src/openvpn/error.h @@ -234,6 +234,7 @@ void msg_forked (void); /* syslog output */ +void set_syslog_facility (const char *name); void open_syslog (const char *pgmname, bool stdio_to_null); void close_syslog (); diff --git a/src/openvpn/options.c b/src/openvpn/options.c index 40210e6..e6cc1cc 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -333,9 +333,21 @@ static const char usage_message[] = "--setcon context: Apply this SELinux context after initialization.\n" #endif "--cd dir : Change to this directory before initialization.\n" +#if SYSLOG_CAPABILITY + "--syslog-facility name : When logging to syslog, use name (e.g. \n" + " local1) for the facility. If name is absent or not\n" + " supported, a platform-dependent list of valid\n" + " facility names is provided. Must be specified\n" + " before --daemon and --syslog.\n" +#endif "--daemon [name] : Become a daemon after initialization.\n" " The optional 'name' parameter will be passed\n" " as the program name to the system logger.\n" +#if SYSLOG_CAPABILITY + " If --syslog-facility has not been specified and \n" + " the name includes [facility], the specified\n" + " syslog facility name will be used.\n" +#endif "--syslog [name] : Output to syslog, but do not become a daemon.\n" " See --daemon above for a description of the 'name' parm.\n" "--inetd [name] ['wait'|'nowait'] : Run as an inetd or xinetd server.\n" @@ -4661,6 +4673,13 @@ add_option (struct options *options, VERIFY_PERMISSION (OPT_P_GENERAL); options->up_restart = true; } +#if SYSLOG_CAPABILITY + else if (streq (p[0], "syslog-facility")) + { + VERIFY_PERMISSION (OPT_P_GENERAL); + set_syslog_facility (p[1]); + } +#endif else if (streq (p[0], "syslog")) { VERIFY_PERMISSION (OPT_P_GENERAL); -- 1.7.10.4 -- Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. 

Hi, On 27-04-14 22:10, Steffan Karger wrote: > On 27-04-14 19:53, Gert Doering wrote: >> On Mon, Apr 21, 2014 at 01:10:04AM -0600, James Yonan wrote: The >> attached patch is what I intend to commit to release/2.3 *only*, >> not to master - as agreed at the IRC meeting. "Please ACK" :-) > > Sorry, but NAK. On a more constructive note: attached a new proposal for this patch. > The OpenSSL bits look fine On a closer look, the wrapping "if (tls_version_min > TLS_VER_UNSPEC)" in tls_ctx_set_options() seems redundant, because TLS_VER_UNSPEC < TLS_VER_1_0 < TLS_VER_1_1 < TLS_VER_1_2 and the ifs are checking for "tls_version_min > TLS_VER_1_x". I've removed these changes in the attached patch proposal. > the PolarSSL bits > would also allow for SSL_MINOR_VERSION_0, which is SSLv3 and thus a > reduction in security (and actually increases the handshake complexity). To elaborate a bit: The naming is a bit confusing, but SSL_MAJOR_VERSION_3 + SSL_MINOR_VERSION_O means SSLv3, ... + SSL_MINOR_VERSION_1 means TLSv1.0, ... + SSL_MINOR_VERSION_2 means TLSv1.1, etc. If none are given (what would happen in the previous version of the patch), PolarSSL defaults the minimum version to SSLv3 and maximum to TLSv1.2. The attached patch thus removes the wrapping "if (tls_version_min > TLS_VER_UNSPEC)" and sets the default to TLSv1.0 to TLSv1.2 again. That is equal to the behaviour prior to the TLS versioning patch. -Steffan 

Hi, On 27-04-14 15:22, Gert Doering wrote: > Your patch has been applied to the master branch ONLY, as it doesn't > work with PolarSSL 1.2 (no "x509_crt" type there) - so 2.3.x still has > inconsistency here. Right, different PolarSSL API. Attached a reworked patch for 2.3. Same functionality, slightly different API calls. -Steffan 

> "why is it breaking for you > in particular, while it works for other Linux users just fine" (half > of my testbed is Linux...) Indeed, that is the interesting question. This has to do with how the client certificate is signed by the client, which in TLS1.2 is negotiated between the client and server - and depends on the available/selected ciphers. As I wrote here: http://sourceforge.net/p/openvpn/mailman/message/32265218/, I believe I know where this is coming from, just not why. I'd like to set a breakpoint in the client and forward/back track to find out. George: One way to do that would be what I suggested here: http://sourceforge.net/p/openvpn/mailman/message/32264919/ Is this feasible? At this point, I think it would be the most efficient way to proceed. I could give you instructions for creating a process dump - but a dump file would have more secrets in it than what I suggested. The two referenced mail messages are as far as I got by inspection. On 28-Apr-14 11:22, Gert Doering wrote: > Hi, > > On Mon, Apr 28, 2014 at 04:04:10PM +0100, George Ross wrote: >> OK, with the attached patch it does appear to work for me. I'll give it >> some more exercise tomorrow morning, but in a quick test the tunnel does >> now appear to come up properly. > Thanks. That confirms the theory "it's the TLS negotiation patch", and > in particular "TLS 1.1 works, TLS 1.2 breaks". > > Now the even more interesting question is "why is it breaking for you > in particular, while it works for other Linux users just fine" (half > of my testbed is Linux...) > > gert 

Hi, On Mon, Apr 28, 2014 at 04:04:10PM +0100, George Ross wrote: > OK, with the attached patch it does appear to work for me. I'll give it > some more exercise tomorrow morning, but in a quick test the tunnel does > now appear to come up properly. Thanks. That confirms the theory "it's the TLS negotiation patch", and in particular "TLS 1.1 works, TLS 1.2 breaks". Now the even more interesting question is "why is it breaking for you in particular, while it works for other Linux users just fine" (half of my testbed is Linux...) 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... 

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. 

 >> I'm happy to put your detailed text into the trac ticket, though, so >> someone finding "it does not work!" and looking into trac can find them. > Yeah, about that...I'm not sure your trac is completely healthy. Even > though I submitted issue #306, I get "Warning: No permissions to add a > comment." when trying to add info, there's no way I can close the ticket > (which I think it should be, as it's not an OpenVPN bug in the first > place), and I never got any e-mail notification about your comments on > that ticket either. > > Tore > Hi, If Trac gives you "No permissions" it either means that you're either not logged in or that Trac believes you're not logged in. If you clear cookies from your browser and login again it should be fine. Looking at Trac permissions it seems there's no way to grant a "<x> may close his own tickets" type privileges. Currently only admins (core devs) can close tickets. Email addresses are synced from LDAP to Trac once per day, which would explain the email problem if you logged in to Trac the first time before filing the ticket in question. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Hi, On Sun, Apr 27, 2014 at 11:55:15AM +0200, Arne Schwabe wrote: > The option seems to be supported since Windows Vista. I think we should > add something like this to the windows ifdefs (copied from > http://marc.info/?l=apr-dev&m=121392734329754&w=2): > > +/* Ugly solution - only the Windows 2008 SDK or later have this symbol > defined. > + * The symbol doesn't guarantee that the socket option is supported on > + * the runtime version of Windows, so we define it here (for build > systems) > + * and always check at runtime if it is supported. > + */ > +#ifndef IPV6_V6ONLY > +#define IPV6_V6ONLY 27 > +#endif That's an interesting twist. I wonder why MinGW does not have it (or maybe my MinGW installation is too old). And then we'll see whether it will blow up at run-time on XP or not - having setsockopt() return an error is something our code will handle ("report, go on"), but on Windows, I wouldn't be surprised to see "it fails with OS error" translate to "crash"... 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... 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 27-04-14 19:53, Gert Doering wrote: > On Mon, Apr 21, 2014 at 01:10:04AM -0600, James Yonan wrote: The > attached patch is what I intend to commit to release/2.3 *only*, > not to master - as agreed at the IRC meeting. "Please ACK" :-) Sorry, but NAK. The OpenSSL bits look fine, but the PolarSSL bits would also allow for SSL_MINOR_VERSION_0, which is SSLv3 and thus a reduction in security (and actually increases the handshake complexity). I think the ssl_polarssl.c can stay the way it is, one has to specify tls cipher suites anyway to restrict the handshake. Or am I missing something here? - -Steffan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTXWQgAAoJEJgCyj0AftKILQoH+wa0ojSrip0vhrPKq/AOa6Bw cpVaDzTo6v7KiOoPf+xWfaEw9aNybd5a8GCVZlCGgSB+vOn53bLtJ7hSPL5fVzb1 8UQw5hWhWyjiZRksyCJNyYEHgzE7ZiRK/LhSd/RhYHlwUTPJfJQ6nYHlM/oMMthz mvj0juA6jCYGCznUD/2fioy5JtpGUqpwkJzQ2hIMtqV8sxyHgJ90R6DpV6cP2nRd AAQndNYVRhC5dQfaQtX+4TStMQK65Q7ZlHZDYb3h6TpKk93y/nWdm5tsew1oLbZ+ E27hMtswug0CSWqnSFtT+bW1shYJgrveDnHu7K1Tgh9KJ9DD2SbvXlgADCaao1U= =uc7+ -----END PGP SIGNATURE----- 

Hi, On Mon, Apr 21, 2014 at 01:10:04AM -0600, James Yonan wrote: > For OpenSSL, this means to use TLSv1_(client|server)_method rather > than SSLv23_(client|server)_method combined with SSL_OP_NO_x flags > for specific TLS versions to disable. > > For PolarSSL, this means to avoid calling ssl_set_min_version and > instead implicitly control the TLS version via allowed ciphersuites. As per the discussion on IRC, I've adapted the patch to 2.3 only (some small incompatibilities in ssl_polarssl.c), and added a section in the openvpn.8 man page. I have tested OpenSSL and PolarSSL builds, talking to a git master server. With OpenSSL: no --tls-version-min in config --> TLSv1 is used --tls-version-min 1.0 or 1.2 --> TLSv1.2 is used (clearly visible in both server and client logs) With PolarSSL, I always get TLSv1.2, and can't really see whether or not it makes a difference. But given James' comments, this seems to be expected (I didn't play with --tls-cipher settings). The attached patch is what I intend to commit to release/2.3 *only*, not to master - as agreed at the IRC meeting. "Please ACK" :-) 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... 

ACK. (I had a really nice test case for this, as my "test-compile 2.3 with polar 1.2" tree only builds if the compile flags are honoured...) Your patch has been applied to the master and release/2.3 branches. commit ea31bc680fc83946b2cc8d0c93544a1ab2a01d63 (master) commit c2faef04e61378ef5f112401b586fc9af6168f33 (master) Author: Steffan Karger Date: Mon Apr 21 13:37:18 2014 +0200 Fix build system to accept non-system crypto library locations for plugins. Signed-off-by: Steffan Karger <st...@ka...> Acked-by: Gert Doering <ge...@gr...> Message-Id: <139...@ka...> URL: http://article.gmane.org/gmane.network.openvpn.devel/8576 Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

Patch has been applied to the master and release/2.3 branches. commit 2a97e69e71d4afb9c32268890e13db19cb73196b (master) commit 268e211b2cf77f88f7ebb69a241337c82b3cc086 (release/2.3) Author: Gert Doering Date: Sat Apr 26 13:30:54 2014 +0200 More IPv6-related updates to the openvpn man page. Signed-off-by: Gert Doering <ge...@gr...> Acked-by: Tore Anderson <to...@fu...> Message-Id: <139...@gr...> URL: http://article.gmane.org/gmane.network.openvpn.devel/8642 -- kind regards, Gert Doering 

ACK. Tested both OpenSSL and PolarSSL builds on the server side, and certificate reporting is consistent, if differing in uppercase/lowercase: OpenSSL: tls_serial_0=22 tls_serial_1=13617978572412530086 tls_serial_hex_0=16 tls_serial_hex_1=bc:fc:c7:5c:47:87:ad:a6 PolarSSL: tls_serial_0=22 tls_serial_1=13617978572412530086 tls_serial_hex_0=16 tls_serial_hex_1=BC:FC:C7:5C:47:87:AD:A6 (I'm too lazy right now to actually multiply out whether the hex representation of cert 1 matches the decimal representation, but if both libraries return the same thing, that is good enough for me) Your patch has been applied to the master branch ONLY, as it doesn't work with PolarSSL 1.2 (no "x509_crt" type there) - so 2.3.x still has inconsistency here. commit f80a52b09eed8e5e0cad990c56ec99256d6cc2d0 (master) Author: Steffan Karger Date: Sun Apr 27 10:49:20 2014 +0200 Make serial env exporting consistent amongst OpenSSL and PolarSSL builds. Signed-off-by: Steffan Karger <st...@ka...> Acked-by: Gert Doering <ge...@gr...> Message-Id: <139...@ka...> URL: http://article.gmane.org/gmane.network.openvpn.devel/8649 Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering