openvpn-devel Mailing List for OpenVPN

Hi, On Fri, Mar 29, 2019 at 03:33:24PM -0400, Selva Nair wrote: > > + else if (family == AF_INET6) > > + { > > + if (ack.error_number != NO_ERROR) > > + { > > + msg(M_NONFATAL, "TUN: setting IPv6 mtu using service > > failed: %s [status=%u if_index=%d]", > > + strerror_win32(ack.error_number, &gc), > > ack.error_number, mtu_msg.iface.index); > > + } > > Though this repetition is fine with me and may be we do > the same in other similar contexts, cant we combine these > two cases into one by defining a string "IPv4" or "IPv6" > based on the value of family? > > The same applies to windows_set_mtu() as well. Yes please, Newer code already tries to do this (like most of the service-related stuff calling a common function for ipv4-or-ipv6 stuff). (We don't do this for the existing ifconfig orgy because it would not really help readibility... but hopefully that one will get cleaned up more thoroughly eventually) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ge...@gr... 

Hi, On Fri, Mar 29, 2019 at 6:25 AM Christopher Schenk <cs...@ma...> wrote: > > Hi, > > On 28/03/2019 16:00, Selva Nair wrote: > > I would go a step further to say we should not add new features that > > do not work when started using the interactive service. > > > > Secondly, we should avoid the old style use of netsh and instead use the > > iphelper API as far as possible. It should be possible to > > set MTU using the SetIfEntry() or SetIpInterfaceEnrty() function -- I > > haven't > > checked which one is appropriate here. > > I agree on the point that we should add this functionality to the > interactive service as well. So i modified the patch accordingly. > I also modified my patch so that it uses the SetIpInterfaceEnrty > function instead of netsh. Thanks for the update. Looks okay, but would prefer a version sent out by git-send-email so that we can apply and test the patch. Some minor comments below. > > --- > diff --git a/include/openvpn-msg.h b/include/openvpn-msg.h > index 66177a21..f59c5a21 100644 > --- a/include/openvpn-msg.h > +++ b/include/openvpn-msg.h > @@ -39,6 +39,7 @@ typedef enum { > msg_del_block_dns, > msg_register_dns, > msg_enable_dhcp, > + msg_set_mtu, > } message_type_t; > > typedef struct { > @@ -117,4 +118,11 @@ typedef struct { > interface_t iface; > } enable_dhcp_message_t; > > +typedef struct { > + message_header_t header; > + interface_t iface; > + short family; > + int mtu; > +} set_mtu_message_t; > + > #endif /* ifndef OPENVPN_MSG_H_ */ > diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c > index 48a8fdf7..9fe8444f 100644 > --- a/src/openvpn/tun.c > +++ b/src/openvpn/tun.c > @@ -69,6 +69,10 @@ static void netsh_ifconfig(const struct > tuntap_options *to, > const in_addr_t netmask, > const unsigned int flags); > > +static void windows_set_mtu(const int iface_indey, iface_indey -> iface_index ? > + short family, > + const int mtu); > + > static void netsh_set_dns6_servers(const struct in6_addr *addr_list, > const int addr_len, > const char *flex_name); > @@ -201,6 +205,63 @@ out: > return ret; > } > > +static bool > +do_set_mtu_service(const struct tuntap *tt, const short family, const > int mtu) > +{ > + DWORD len; > + bool ret = false; > + ack_message_t ack; > + struct gc_arena gc = gc_new(); > + HANDLE pipe = tt->options.msg_channel; > + > + set_mtu_message_t mtu_msg = { > + .header = { > + msg_set_mtu, > + sizeof(set_mtu_message_t), > + 0 > + }, > + .iface = {.index = tt->adapter_index,.name = tt->actual_name }, > + .mtu = mtu, > + .family = family > + }; > + > + if (!send_msg_iservice(pipe, &mtu_msg, sizeof(mtu_msg), &ack, > "Set_mtu")) > + { > + goto out; > + } > + > + if (family == AF_INET) > + { > + if (ack.error_number != NO_ERROR) > + { > + msg(M_NONFATAL, "TUN: setting IPv4 mtu using service > failed: %s [status=%u if_index=%d]", > + strerror_win32(ack.error_number, &gc), > ack.error_number, mtu_msg.iface.index); > + } > + else > + { > + msg(M_INFO, "IPv4 MTU set to %d on interface %d using > service", mtu, mtu_msg.iface.index); > + ret = true; > + } > + } > + else if (family == AF_INET6) > + { > + if (ack.error_number != NO_ERROR) > + { > + msg(M_NONFATAL, "TUN: setting IPv6 mtu using service > failed: %s [status=%u if_index=%d]", > + strerror_win32(ack.error_number, &gc), > ack.error_number, mtu_msg.iface.index); > + } Though this repetition is fine with me and may be we do the same in other similar contexts, cant we combine these two cases into one by defining a string "IPv4" or "IPv6" based on the value of family? The same applies to windows_set_mtu() as well. > + else > + { > + msg(M_INFO, "IPv6 MTU set to %d on interface %d using > service", mtu, mtu_msg.iface.index); > + ret = true; > + } > + } > + > +out: > + gc_free(&gc); > + return ret; > +} > + > #endif /* ifdef _WIN32 */ > > #ifdef TARGET_SOLARIS > @@ -984,6 +1045,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char > *ifname, int tun_mtu, > { > do_address_service(true, AF_INET6, tt); > do_dns6_service(true, tt); > + do_set_mtu_service(tt, AF_INET6, tun_mtu); > } > else > { > @@ -1000,6 +1062,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char > *ifname, int tun_mtu, > netsh_command(&argv, 4, M_FATAL); > /* set ipv6 dns servers if any are specified */ > netsh_set_dns6_servers(tt->options.dns6, tt->options.dns6_len, > ifname); > + windows_set_mtu(tt->adapter_index, AF_INET6, tun_mtu); > } > > /* explicit route needed */ > @@ -1391,9 +1454,16 @@ do_ifconfig_ipv4(struct tuntap *tt, const char > *ifname, int tun_mtu, > case IPW32_SET_NETSH: > netsh_ifconfig(&tt->options, ifname, tt->local, > tt->adapter_netmask, > NI_IP_NETMASK|NI_OPTIONS); > - > break; > } > + if (tt->options.msg_channel) > + { > + do_set_mtu_service(tt, AF_INET, tun_mtu); > + } > + else > + { > + windows_set_mtu(tt->adapter_index, AF_INET, tun_mtu); > + } > } > > #else /* if defined(TARGET_LINUX) */ > @@ -5236,6 +5306,46 @@ out: > return ret; > } > > +static void > +windows_set_mtu(const int iface_index, const short family, > + const int mtu) > +{ > + DWORD err = 0; > + struct gc_arena gc = gc_new(); > + MIB_IPINTERFACE_ROW row; > + InitializeIpInterfaceEntry(&row); > + row.Family = family; > + row.InterfaceIndex = iface_index; > + row.NlMtu = mtu; > + > + err = SetIpInterfaceEntry(&row); > + if (family == AF_INET) > + { > + if (err != NO_ERROR) > + { > + msg(M_WARN, "TUN: Setting IPv4 mtu failed: %s [status=%u > if_index=%d]", > + strerror_win32(err, &gc), err, iface_index); > + } > + else > + { > + msg(M_INFO, "Successfully set IPv4 mtu on interface %d", > iface_index); > + } > + } > + else if (family == AF_INET6) > + { > + if (err != NO_ERROR) > + { > + msg(M_WARN, "TUN: Setting IPv6 mtu failed: %s [status=%u > if_index=%d]", > + strerror_win32(err, &gc), err, iface_index); > + } > + else > + { > + msg(M_INFO, "Successfully set IPv6 mtu on interface %d", > iface_index); > + } > + } See the comment above.. > +} > + > + > /* > * Return a TAP name for netsh commands. > */ > diff --git a/src/openvpnserv/interactive.c b/src/openvpnserv/interactive.c > index 623c3ff7..6e6a63fe 100644 > --- a/src/openvpnserv/interactive.c > +++ b/src/openvpnserv/interactive.c > @@ -33,6 +33,7 @@ > #include <sddl.h> > #include <shellapi.h> > #include <mstcpip.h> > +#include <netioapi.h> > > #ifdef HAVE_VERSIONHELPERS_H > #include <versionhelpers.h> > @@ -1198,6 +1199,20 @@ HandleEnableDHCPMessage(const > enable_dhcp_message_t *dhcp) > return err; > } > > +static DWORD > +HandleMTUMessage(const set_mtu_message_t *mtu) > +{ > + DWORD err = 0; > + MIB_IPINTERFACE_ROW row; > + InitializeIpInterfaceEntry(&row); > + row.Family = mtu->family; > + row.InterfaceIndex = mtu->iface.index; > + row.NlMtu = mtu->mtu; > + > + err = SetIpInterfaceEntry(&row); > + return err; > +} > + > static VOID > HandleMessage(HANDLE pipe, DWORD bytes, DWORD count, LPHANDLE events, > undo_lists_t *lists) > { > @@ -1210,6 +1225,7 @@ HandleMessage(HANDLE pipe, DWORD bytes, DWORD > count, LPHANDLE events, undo_lists > block_dns_message_t block_dns; > dns_cfg_message_t dns; > enable_dhcp_message_t dhcp; > + set_mtu_message_t mtu; > } msg; > ack_message_t ack = { > .header = { > @@ -1276,6 +1292,12 @@ HandleMessage(HANDLE pipe, DWORD bytes, DWORD > count, LPHANDLE events, undo_lists > ack.error_number = HandleEnableDHCPMessage(&msg.dhcp); > } > break; > + case msg_set_mtu: > + if (msg.header.size == sizeof(msg.mtu)) > + { > + ack.error_number = HandleMTUMessage(&msg.mtu); > + } > + break; > > default: > ack.error_number = ERROR_MESSAGE_TYPE; > Selva 

Acked-by: Gert Doering <ge...@gr...> Thanks. Changes look reasonable. I have *not* applied this to release/2.4 as I assume that stuff like "openssl version" and "configure output" will look different, so it would bring in incorrect "improvements". (Can you do a 2.4 version as well, please? :) ) Your patch has been applied to the master branch. commit 6099ab67122429c04d743443a50d258b11ac1f07 Author: David Sommerseth Date: Wed Mar 27 13:06:04 2019 +0100 docs: Update INSTALL Signed-off-by: David Sommerseth <da...@op...> Acked-by: Gert Doering <ge...@gr...> Message-Id: <201...@op...> URL: https://www.mail-archive.com/ope...@li.../msg18307.html Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

With modern Clients and server initialising the crypto cipher later and not when reading in the config, most users never the warning when having selected BF-CBC in the configuration. This patch adds the logic to print out warning to init_key_type. Main reason for this patch is a personal experience with someone who was strictly against putting 'cipher' into a config file because he did not like hardcoding a cipher and "OpenVPN will do AES-GCM anyway" and thinks that it is better to not have it in configuration even after told by me that 15 year defaults might not be good anymore. Signed-off-by: Arne Schwabe <ar...@rf...> --- src/openvpn/crypto.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c index ff9dbfdc..8a92a8c1 100644 --- a/src/openvpn/crypto.c +++ b/src/openvpn/crypto.c @@ -736,6 +736,17 @@ crypto_max_overhead(void) +max_int(OPENVPN_MAX_HMAC_SIZE, OPENVPN_AEAD_TAG_LENGTH); } +static void warn_insecure_key_type(const char* ciphername, const cipher_kt_t *cipher) +{ + if (cipher_kt_insecure(cipher)) + { + msg(M_WARN, "WARNING: INSECURE cipher (%s) with block size less than 128" + " bit (%d bit). This allows attacks like SWEET32. Mitigate by " + "using a --cipher with a larger block size (e.g. AES-256-CBC).", + ciphername, cipher_kt_block_size(cipher)*8); + } +} + /* * Build a struct key_type. */ @@ -763,6 +774,7 @@ init_key_type(struct key_type *kt, const char *ciphername, kt->cipher_length = keysize; } + /* check legal cipher mode */ aead_cipher = cipher_kt_mode_aead(kt->cipher); if (!(cipher_kt_mode_cbc(kt->cipher) @@ -779,6 +791,10 @@ init_key_type(struct key_type *kt, const char *ciphername, { msg(M_FATAL, "Cipher '%s' not allowed: block size too big.", ciphername); } + if(warn) + { + warn_insecure_key_type(ciphername, kt->cipher); + } } else { @@ -831,9 +847,10 @@ init_key_ctx(struct key_ctx *ctx, const struct key *key, cipher_ctx_init(ctx->cipher, key->cipher, kt->cipher_length, kt->cipher, enc); + const char* ciphername = translate_cipher_name_to_openvpn(cipher_kt_name(kt->cipher)); msg(D_HANDSHAKE, "%s: Cipher '%s' initialized with %d bit key", prefix, - translate_cipher_name_to_openvpn(cipher_kt_name(kt->cipher)), + ciphername, kt->cipher_length *8); dmsg(D_SHOW_KEYS, "%s: CIPHER KEY: %s", prefix, @@ -841,13 +858,7 @@ init_key_ctx(struct key_ctx *ctx, const struct key *key, dmsg(D_CRYPTO_DEBUG, "%s: CIPHER block_size=%d iv_size=%d", prefix, cipher_kt_block_size(kt->cipher), cipher_kt_iv_size(kt->cipher)); - if (cipher_kt_insecure(kt->cipher)) - { - msg(M_WARN, "WARNING: INSECURE cipher with block size less than 128" - " bit (%d bit). This allows attacks like SWEET32. Mitigate by " - "using a --cipher with a larger block size (e.g. AES-256-CBC).", - cipher_kt_block_size(kt->cipher)*8); - } + warn_insecure_key_type(ciphername, kt->cipher); } if (kt->digest && kt->hmac_length > 0) { -- 2.21.0 

Hi, On 28/03/2019 16:00, Selva Nair wrote: > I would go a step further to say we should not add new features that > do not work when started using the interactive service. > > Secondly, we should avoid the old style use of netsh and instead use the > iphelper API as far as possible. It should be possible to > set MTU using the SetIfEntry() or SetIpInterfaceEnrty() function -- I > haven't > checked which one is appropriate here. I agree on the point that we should add this functionality to the interactive service as well. So i modified the patch accordingly. I also modified my patch so that it uses the SetIpInterfaceEnrty function instead of netsh. --- diff --git a/include/openvpn-msg.h b/include/openvpn-msg.h index 66177a21..f59c5a21 100644 --- a/include/openvpn-msg.h +++ b/include/openvpn-msg.h @@ -39,6 +39,7 @@ typedef enum {      msg_del_block_dns,      msg_register_dns,      msg_enable_dhcp, +    msg_set_mtu,  } message_type_t;  typedef struct { @@ -117,4 +118,11 @@ typedef struct {      interface_t iface;  } enable_dhcp_message_t; +typedef struct { +    message_header_t header; +    interface_t iface; +    short family; +    int mtu; +} set_mtu_message_t; +  #endif /* ifndef OPENVPN_MSG_H_ */ diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index 48a8fdf7..9fe8444f 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -69,6 +69,10 @@ static void netsh_ifconfig(const struct tuntap_options *to,                             const in_addr_t netmask,                             const unsigned int flags); +static void windows_set_mtu(const int iface_indey, +                                short family, +                               const int mtu); +  static void netsh_set_dns6_servers(const struct in6_addr *addr_list,                                     const int addr_len,                                     const char *flex_name); @@ -201,6 +205,63 @@ out:      return ret;  } +static bool +do_set_mtu_service(const struct tuntap *tt, const short family, const int mtu) +{ +    DWORD len; +    bool ret = false; +    ack_message_t ack; +    struct gc_arena gc = gc_new(); +    HANDLE pipe = tt->options.msg_channel; + +    set_mtu_message_t mtu_msg = { +        .header = { +            msg_set_mtu, +            sizeof(set_mtu_message_t), +            0 +        }, +        .iface = {.index = tt->adapter_index,.name = tt->actual_name }, +        .mtu = mtu, +        .family = family +    }; + +    if (!send_msg_iservice(pipe, &mtu_msg, sizeof(mtu_msg), &ack, "Set_mtu")) +    { +        goto out; +    } + +    if (family == AF_INET) +    { +        if (ack.error_number != NO_ERROR) +        { +            msg(M_NONFATAL, "TUN: setting IPv4 mtu using service failed: %s [status=%u if_index=%d]", +                strerror_win32(ack.error_number, &gc), ack.error_number, mtu_msg.iface.index); +        } +        else +        { +            msg(M_INFO, "IPv4 MTU set to %d on interface %d using service", mtu, mtu_msg.iface.index); +            ret = true; +        } +    } +    else if (family == AF_INET6) +    { +        if (ack.error_number != NO_ERROR) +        { +            msg(M_NONFATAL, "TUN: setting IPv6 mtu using service failed: %s [status=%u if_index=%d]", +                strerror_win32(ack.error_number, &gc), ack.error_number, mtu_msg.iface.index); +        } +        else +        { +            msg(M_INFO, "IPv6 MTU set to %d on interface %d using service", mtu, mtu_msg.iface.index); +            ret = true; +        } +    } + +out: +    gc_free(&gc); +    return ret; +} +  #endif /* ifdef _WIN32 */  #ifdef TARGET_SOLARIS @@ -984,6 +1045,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char *ifname, int tun_mtu,      {          do_address_service(true, AF_INET6, tt);          do_dns6_service(true, tt); +        do_set_mtu_service(tt, AF_INET6, tun_mtu);      }      else      { @@ -1000,6 +1062,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char *ifname, int tun_mtu,          netsh_command(&argv, 4, M_FATAL);          /* set ipv6 dns servers if any are specified */          netsh_set_dns6_servers(tt->options.dns6, tt->options.dns6_len, ifname); +        windows_set_mtu(tt->adapter_index, AF_INET6, tun_mtu);      }      /* explicit route needed */ @@ -1391,9 +1454,16 @@ do_ifconfig_ipv4(struct tuntap *tt, const char *ifname, int tun_mtu,              case IPW32_SET_NETSH:                  netsh_ifconfig(&tt->options, ifname, tt->local,                                 tt->adapter_netmask, NI_IP_NETMASK|NI_OPTIONS); -                  break;          } +        if (tt->options.msg_channel) +        { +            do_set_mtu_service(tt, AF_INET, tun_mtu); +        } +        else +        { +            windows_set_mtu(tt->adapter_index, AF_INET, tun_mtu); +        }      }  #else  /* if defined(TARGET_LINUX) */ @@ -5236,6 +5306,46 @@ out:      return ret;  } +static void +windows_set_mtu(const int iface_index, const short family, +    const int mtu) +{ +    DWORD err = 0; +    struct gc_arena gc = gc_new(); +    MIB_IPINTERFACE_ROW row; +    InitializeIpInterfaceEntry(&row); +    row.Family = family; +    row.InterfaceIndex = iface_index; +    row.NlMtu = mtu; + +    err = SetIpInterfaceEntry(&row); +    if (family == AF_INET) +    { +        if (err != NO_ERROR) +        { +            msg(M_WARN, "TUN: Setting IPv4 mtu failed: %s [status=%u if_index=%d]", +                strerror_win32(err, &gc), err, iface_index); +        } +        else +        { +            msg(M_INFO, "Successfully set IPv4 mtu on interface %d", iface_index); +        } +    } +    else if (family == AF_INET6) +    { +        if (err != NO_ERROR) +        { +            msg(M_WARN, "TUN: Setting IPv6 mtu failed: %s [status=%u if_index=%d]", +                strerror_win32(err, &gc), err, iface_index); +        } +        else +        { +            msg(M_INFO, "Successfully set IPv6 mtu on interface %d", iface_index); +        } +    } +} + +  /*   * Return a TAP name for netsh commands.   */ diff --git a/src/openvpnserv/interactive.c b/src/openvpnserv/interactive.c index 623c3ff7..6e6a63fe 100644 --- a/src/openvpnserv/interactive.c +++ b/src/openvpnserv/interactive.c @@ -33,6 +33,7 @@  #include <sddl.h>  #include <shellapi.h>  #include <mstcpip.h> +#include <netioapi.h>  #ifdef HAVE_VERSIONHELPERS_H  #include <versionhelpers.h> @@ -1198,6 +1199,20 @@ HandleEnableDHCPMessage(const enable_dhcp_message_t *dhcp)      return err;  } +static DWORD +HandleMTUMessage(const set_mtu_message_t *mtu) +{ +    DWORD err = 0; +    MIB_IPINTERFACE_ROW row; +    InitializeIpInterfaceEntry(&row); +    row.Family = mtu->family; +    row.InterfaceIndex = mtu->iface.index; +    row.NlMtu = mtu->mtu; + +    err = SetIpInterfaceEntry(&row); +    return err; +} +  static VOID  HandleMessage(HANDLE pipe, DWORD bytes, DWORD count, LPHANDLE events, undo_lists_t *lists)  { @@ -1210,6 +1225,7 @@ HandleMessage(HANDLE pipe, DWORD bytes, DWORD count, LPHANDLE events, undo_lists          block_dns_message_t block_dns;          dns_cfg_message_t dns;          enable_dhcp_message_t dhcp; +        set_mtu_message_t mtu;      } msg;      ack_message_t ack = {          .header = { @@ -1276,6 +1292,12 @@ HandleMessage(HANDLE pipe, DWORD bytes, DWORD count, LPHANDLE events, undo_lists                  ack.error_number = HandleEnableDHCPMessage(&msg.dhcp);              }              break; +        case msg_set_mtu: +            if (msg.header.size == sizeof(msg.mtu)) +            { +                ack.error_number = HandleMTUMessage(&msg.mtu); +            } +            break;          default:              ack.error_number = ERROR_MESSAGE_TYPE; 

...resending as I apparently tried to send this from my personal email account. --- Hi, Here's the summary of the IRC meeting. --- COMMUNITY MEETING Place: #openvpn-meeting on irc.freenode.net Date: Wednesday 27th March 2019 Time: 11:30 CET (10:30 UTC) Planned meeting topics for this meeting were here: <https://community.openvpn.net/openvpn/wiki/Topics-2019-03-27> The next meeting is scheduled to 3rd April 11:30 CEST. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> SUMMARY cron2, dazo, mattock, ordex, plaisthos and syzzer participated in this meeting. -- Discussed future meeting schedule: https://doodle.com/poll/qbnsw7d4mvb5iysn#table It was agreed to have weekly meetings which alternate between - Wed 11:30 CET/CEST - Thu 20:00 CET/CEST This enables most developers, even those in the U.S., to participate in the meetings every other week. Next week's meeting will be on Wed at 11:30 CET/CEST. The meeting one week from that will be on Thu at 20:00 CET/CEST. -- Talked about OpenVPN's INSTALL file. Dazo will overhaul it as it contains quite a bit of obsolete information. -- Talked about OpenVPN's ChangeLog file in the "master" branch. It contains essentially the same information as "git shortlog" but has not been updated in two years and nobody had complained until now. Agreed to remove that file from Git "master" as useless. It will still be present in release branches where it is actually recreated at release time. -- Discussed the OpenVPN T-shirts. Mattock sent T-shirts to most already. Cron2, janjust and ecrist please (re?)send your postal address to mattock and you will receive T-shirts as well. -- Discussed tap-windows6 HLK testing. Fixing the HLK tests should be "ready" and the work is in here: https://github.com/sgstair/tap-windows6/tree/hlkwork https://github.com/sgstair/tapdiag We also have basic instructions from Stephen on how to run the HLK tests (the tap-windows6-specific part, plus openvpn configs). So the plan now is to start merging his work patch by patch and simultaneously start (or rather, resume) setting up the HLK environment. Mattock is fighting to get a real, physical Windows Server 2016 box for running the WHQL compliance HLK tests, as a VM won't cut it for Microsoft. -- Full chatlog attached. 

Hi, On Thu, Mar 28, 2019 at 09:33:43AM -0700, Marvin Adeff wrote: > From a user perspective, there should probably be a way to disable any programmatic setting of mtu. In our usage, the same network interface that OpenVPN traffic goes out on often also must carry large traffic to other destinations that not uncommonly go through some low mtu path. In these cases we have to manually set mtu to a setting that most likely is much lower than OpenVPN might sense it as. OpenVPN will not touch the LAN MTU, just its own tun/tap interface (and it does not look at "outgoing interface MTU" anyway - it will do path MTU sensing if supported, or just statically calculated). gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ge...@gr... 

Hi, From a user perspective, there should probably be a way to disable any programmatic setting of mtu. In our usage, the same network interface that OpenVPN traffic goes out on often also must carry large traffic to other destinations that not uncommonly go through some low mtu path. In these cases we have to manually set mtu to a setting that most likely is much lower than OpenVPN might sense it as. Marvin > On Mar 28, 2019, at 8:00 AM, Selva Nair <sel...@gm...> wrote: > > Hi > >> On Thu, Mar 28, 2019 at 9:13 AM Arne Schwabe <ar...@rf...> wrote: >> Am 28.03.19 um 13:27 schrieb Christopher Schenk: >> > From: Christopher Schenk <Chr...@ho...> >> > >> > --- >> > src/openvpn/tun.c | 39 ++++++++++++++++++++++++++++++++++++++- >> > 1 file changed, 38 insertions(+), 1 deletion(-) >> > >> > diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c >> > index 48a8fdf7..93d028c8 100644 >> > --- a/src/openvpn/tun.c >> > +++ b/src/openvpn/tun.c >> > @@ -69,6 +69,12 @@ static void netsh_ifconfig(const struct tuntap_options *to, >> > const in_addr_t netmask, >> > const unsigned int flags); >> > >> > +static void netsh_set_mtu_ipv4(const char *flex_name, >> > + const int mtu); >> > + >> > +static void netsh_set_mtu_ipv6(const char *flex_name, >> > + const int mtu); >> > + >> > static void netsh_set_dns6_servers(const struct in6_addr *addr_list, >> > const int addr_len, >> > const char *flex_name); >> > @@ -1000,6 +1006,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char *ifname, int tun_mtu, >> > netsh_command(&argv, 4, M_FATAL); >> > /* set ipv6 dns servers if any are specified */ >> > netsh_set_dns6_servers(tt->options.dns6, tt->options.dns6_len, ifname); >> > + netsh_set_mtu_ipv6(ifname, tun_mtu); >> > } >> > >> > /* explicit route needed */ >> > @@ -1391,9 +1398,9 @@ do_ifconfig_ipv4(struct tuntap *tt, const char *ifname, int tun_mtu, >> > case IPW32_SET_NETSH: >> > netsh_ifconfig(&tt->options, ifname, tt->local, >> > tt->adapter_netmask, NI_IP_NETMASK|NI_OPTIONS); >> > - >> > break; >> > } >> > + netsh_set_mtu_ipv4(ifname, tun_mtu); >> > } >> > >> > #else /* if defined(TARGET_LINUX) */ >> > @@ -5236,6 +5243,36 @@ out: >> > return ret; >> > } >> > >> > +static void >> > +netsh_set_mtu_ipv4(const char *flex_name, >> > + const int mtu) >> > +{ >> > + struct argv argv = argv_new(); >> > + argv_printf(&argv, "%s%sc interface ipv4 set subinterface %s mtu = %d store=active", >> >> The spacing here looks a bit odd. I would have expected mtu=%d instead. >> Is this necessary or was there a reason for doing this? >> >> Patch looks okay enough to ACK but: >> >> In general, this patch adds a missing feature (setting MTU) with one >> windows interface only (netsh). And more commonly used interface >> (interactive service)would be different then leading to harder to debug >> problems. > > I would go a step further to say we should not add new features that > do not work when started using the interactive service. > > Secondly, we should avoid the old style use of netsh and instead use the > iphelper API as far as possible. It should be possible to > set MTU using the SetIfEntry() or SetIpInterfaceEnrty() function -- I haven't > checked which one is appropriate here. > > Selva > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

Hi On Thu, Mar 28, 2019 at 9:13 AM Arne Schwabe <ar...@rf...> wrote: > Am 28.03.19 um 13:27 schrieb Christopher Schenk: > > From: Christopher Schenk <Chr...@ho...> > > > > --- > > src/openvpn/tun.c | 39 ++++++++++++++++++++++++++++++++++++++- > > 1 file changed, 38 insertions(+), 1 deletion(-) > > > > diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c > > index 48a8fdf7..93d028c8 100644 > > --- a/src/openvpn/tun.c > > +++ b/src/openvpn/tun.c > > @@ -69,6 +69,12 @@ static void netsh_ifconfig(const struct > tuntap_options *to, > > const in_addr_t netmask, > > const unsigned int flags); > > > > +static void netsh_set_mtu_ipv4(const char *flex_name, > > + const int mtu); > > + > > +static void netsh_set_mtu_ipv6(const char *flex_name, > > + const int mtu); > > + > > static void netsh_set_dns6_servers(const struct in6_addr *addr_list, > > const int addr_len, > > const char *flex_name); > > @@ -1000,6 +1006,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char > *ifname, int tun_mtu, > > netsh_command(&argv, 4, M_FATAL); > > /* set ipv6 dns servers if any are specified */ > > netsh_set_dns6_servers(tt->options.dns6, tt->options.dns6_len, > ifname); > > + netsh_set_mtu_ipv6(ifname, tun_mtu); > > } > > > > /* explicit route needed */ > > @@ -1391,9 +1398,9 @@ do_ifconfig_ipv4(struct tuntap *tt, const char > *ifname, int tun_mtu, > > case IPW32_SET_NETSH: > > netsh_ifconfig(&tt->options, ifname, tt->local, > > tt->adapter_netmask, > NI_IP_NETMASK|NI_OPTIONS); > > - > > break; > > } > > + netsh_set_mtu_ipv4(ifname, tun_mtu); > > } > > > > #else /* if defined(TARGET_LINUX) */ > > @@ -5236,6 +5243,36 @@ out: > > return ret; > > } > > > > +static void > > +netsh_set_mtu_ipv4(const char *flex_name, > > + const int mtu) > > +{ > > + struct argv argv = argv_new(); > > + argv_printf(&argv, "%s%sc interface ipv4 set subinterface %s mtu = > %d store=active", > > The spacing here looks a bit odd. I would have expected mtu=%d instead. > Is this necessary or was there a reason for doing this? > > Patch looks okay enough to ACK but: > > In general, this patch adds a missing feature (setting MTU) with one > windows interface only (netsh). And more commonly used interface > (interactive service)would be different then leading to harder to debug > problems. > I would go a step further to say we should not add new features that do not work when started using the interactive service. Secondly, we should avoid the old style use of netsh and instead use the iphelper API as far as possible. It should be possible to set MTU using the SetIfEntry() or SetIpInterfaceEnrty() function -- I haven't checked which one is appropriate here. Selva 

Am 28.03.19 um 13:27 schrieb Christopher Schenk: > From: Christopher Schenk <Chr...@ho...> > > --- > src/openvpn/tun.c | 39 ++++++++++++++++++++++++++++++++++++++- > 1 file changed, 38 insertions(+), 1 deletion(-) > > diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c > index 48a8fdf7..93d028c8 100644 > --- a/src/openvpn/tun.c > +++ b/src/openvpn/tun.c > @@ -69,6 +69,12 @@ static void netsh_ifconfig(const struct tuntap_options *to, > const in_addr_t netmask, > const unsigned int flags); > > +static void netsh_set_mtu_ipv4(const char *flex_name, > + const int mtu); > + > +static void netsh_set_mtu_ipv6(const char *flex_name, > + const int mtu); > + > static void netsh_set_dns6_servers(const struct in6_addr *addr_list, > const int addr_len, > const char *flex_name); > @@ -1000,6 +1006,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char *ifname, int tun_mtu, > netsh_command(&argv, 4, M_FATAL); > /* set ipv6 dns servers if any are specified */ > netsh_set_dns6_servers(tt->options.dns6, tt->options.dns6_len, ifname); > + netsh_set_mtu_ipv6(ifname, tun_mtu); > } > > /* explicit route needed */ > @@ -1391,9 +1398,9 @@ do_ifconfig_ipv4(struct tuntap *tt, const char *ifname, int tun_mtu, > case IPW32_SET_NETSH: > netsh_ifconfig(&tt->options, ifname, tt->local, > tt->adapter_netmask, NI_IP_NETMASK|NI_OPTIONS); > - > break; > } > +	netsh_set_mtu_ipv4(ifname, tun_mtu); > } > > #else /* if defined(TARGET_LINUX) */ > @@ -5236,6 +5243,36 @@ out: > return ret; > } > > +static void > +netsh_set_mtu_ipv4(const char *flex_name, > + const int mtu) > +{ > +	struct argv argv = argv_new(); > +	argv_printf(&argv, "%s%sc interface ipv4 set subinterface %s mtu = %d store=active", The spacing here looks a bit odd. I would have expected mtu=%d instead. Is this necessary or was there a reason for doing this? Patch looks okay enough to ACK but: In general, this patch adds a missing feature (setting MTU) with one windows interface only (netsh). And more commonly used interface (interactive service)would be different then leading to harder to debug problems. Are you planning on adding MTU setting to the interactive service as well? If we have patches for MTU setting for both, I have problem to ACK both. Arne 

From: Christopher Schenk <Chr...@ho...> --- src/openvpn/tun.c | 39 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index 48a8fdf7..93d028c8 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -69,6 +69,12 @@ static void netsh_ifconfig(const struct tuntap_options *to, const in_addr_t netmask, const unsigned int flags); +static void netsh_set_mtu_ipv4(const char *flex_name, + const int mtu); + +static void netsh_set_mtu_ipv6(const char *flex_name, + const int mtu); + static void netsh_set_dns6_servers(const struct in6_addr *addr_list, const int addr_len, const char *flex_name); @@ -1000,6 +1006,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char *ifname, int tun_mtu, netsh_command(&argv, 4, M_FATAL); /* set ipv6 dns servers if any are specified */ netsh_set_dns6_servers(tt->options.dns6, tt->options.dns6_len, ifname); + netsh_set_mtu_ipv6(ifname, tun_mtu); } /* explicit route needed */ @@ -1391,9 +1398,9 @@ do_ifconfig_ipv4(struct tuntap *tt, const char *ifname, int tun_mtu, case IPW32_SET_NETSH: netsh_ifconfig(&tt->options, ifname, tt->local, tt->adapter_netmask, NI_IP_NETMASK|NI_OPTIONS); - break; } +	netsh_set_mtu_ipv4(ifname, tun_mtu); } #else /* if defined(TARGET_LINUX) */ @@ -5236,6 +5243,36 @@ out: return ret; } +static void +netsh_set_mtu_ipv4(const char *flex_name, + const int mtu) +{ +	struct argv argv = argv_new(); +	argv_printf(&argv, "%s%sc interface ipv4 set subinterface %s mtu = %d store=active", +	get_win_sys_path(), +	NETSH_PATH_SUFFIX, +	flex_name, +	mtu); + +	netsh_command(&argv, 3, M_WARN); +	argv_reset(&argv); +} + +static void +netsh_set_mtu_ipv6(const char *flex_name, +	const int mtu) +{ +	struct argv argv = argv_new(); +	argv_printf(&argv, "%s%sc interface ipv6 set subinterface %s mtu = %d store=active", +	get_win_sys_path(), +	NETSH_PATH_SUFFIX, +	flex_name, +	mtu); + +	netsh_command(&argv, 3, M_WARN); +	argv_reset(&argv); +} + /* * Return a TAP name for netsh commands. */ -- 2.21.0.windows.1 

On Thu, Mar 28, 2019 at 12:51 AM Gert Doering <ge...@gr...> wrote: > > Hi, > > On Wed, Mar 27, 2019 at 02:56:26PM -0700, Rosen Penev wrote: > > Also removed initialization with OpenSSL 1.1 as it is no longer needed and > > causes compilation errors when disabling deprecated APIs. > > > > Same with SSL_CTX_set_ecdh_auto as it got removed. > > The Subject: line is a bit misleading - shouldn't this be more something > like "Avoid calling deprecated-API calls of OpenSSL 1.1" or similar? Yeah. The patch doesn't fully fix it though. I ended up with a somewhat workable solution though. https://github.com/neheb/openvpn/commit/945f190a1bfbde3d6bf11f5b576f5c9e5ec1b0f3 I can squash both of these so that they get the same Subject line. > > (People *do* look at commit logs, and the current subject does not cover > making the SSL_library_init() call conditional, etc.) > > On the patch itself, I have no strong opinion and would welcome a review > from Steffan or Arne :-) - the Subject: line I can fix at commit time. > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh Mistress > > Gert Doering - Munich, Germany ge...@gr... 

 > diff --git a/configure.ac b/configure.ac > index dfb268ca..2617f344 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -922,6 +922,8 @@ if test "${with_crypto_library}" = "openssl"; then >	SSL_CTX_get_default_passwd_cb \ >	SSL_CTX_get_default_passwd_cb_userdata \ >	SSL_CTX_set_security_level \ > +	X509_get0_notBefore \ > +	X509_get0_notAfter \ >	X509_get0_pubkey \ >	X509_STORE_get0_objects \ >	X509_OBJECT_free \ > diff --git a/src/openvpn/openssl_compat.h b/src/openvpn/openssl_compat.h > index a4072b9a..788843a2 100644 > --- a/src/openvpn/openssl_compat.h > +++ b/src/openvpn/openssl_compat.h > @@ -89,6 +89,14 @@ EVP_MD_CTX_new(void) > } > #endif > > +#if !defined(HAVE_X509_GET0_NOTBEFORE) > +#define X509_get0_notBefore X509_get_notBefore > +#endif > + > +#if !defined(HAVE_X509_GET0_NOTAFTER) > +#define X509_get0_notAfter X509_get_notAfter > +#endif > + This is fine. > #if !defined(HAVE_HMAC_CTX_RESET) > /** > * Reset a HMAC context > diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c > index 8bcebac4..e41cafa5 100644 > --- a/src/openvpn/ssl_openssl.c > +++ b/src/openvpn/ssl_openssl.c > @@ -76,12 +76,13 @@ int mydata_index; /* GLOBAL */ > void > tls_init_lib(void) > { > +#if (OPENSSL_VERSION_NUMBER < 0x10100000L && !defined(LIBRESSL_VERSION_NUMBER)) > SSL_library_init(); > -#ifndef ENABLE_SMALL > +# ifndef ENABLE_SMALL > SSL_load_error_strings(); > -#endif > +# endif > OpenSSL_add_all_algorithms(); > - > +#endif Please add a comment like /* On OpenSSL 1.1.0 or above, then the library will initialize itself automatically. */ Otherwise people will be very confused why this code is that way. > mydata_index = SSL_get_ex_new_index(0, "struct session *", NULL, NULL, NULL); > ASSERT(mydata_index >= 0); > } > @@ -89,9 +90,11 @@ tls_init_lib(void) > void > tls_free_lib(void) > { > +#if (OPENSSL_VERSION_NUMBER < 0x10100000L && !defined(LIBRESSL_VERSION_NUMBER)) > EVP_cleanup(); > -#ifndef ENABLE_SMALL > +# ifndef ENABLE_SMALL > ERR_free_strings(); > +# endif > #endif > } Same as above. > > @@ -541,7 +544,7 @@ tls_ctx_check_cert_time(const struct tls_root_ctx *ctx) > goto cleanup; /* Nothing to check if there is no certificate */ > } > > - ret = X509_cmp_time(X509_get_notBefore(cert), NULL); > + ret = X509_cmp_time(X509_get0_notBefore(cert), NULL); > if (ret == 0) > { > msg(D_TLS_DEBUG_MED, "Failed to read certificate notBefore field."); > @@ -551,7 +554,7 @@ tls_ctx_check_cert_time(const struct tls_root_ctx *ctx) > msg(M_WARN, "WARNING: Your certificate is not yet valid!"); > } > > - ret = X509_cmp_time(X509_get_notAfter(cert), NULL); > + ret = X509_cmp_time(X509_get0_notAfter(cert), NULL); > if (ret == 0) > { > msg(D_TLS_DEBUG_MED, "Failed to read certificate notAfter field."); > @@ -634,10 +637,13 @@ tls_ctx_load_ecdh_params(struct tls_root_ctx *ctx, const char *curve_name > else > { > #if OPENSSL_VERSION_NUMBER >= 0x10002000L > +#if (OPENSSL_VERSION_NUMBER < 0x10100000L && !defined(LIBRESSL_VERSION_NUMBER)) > + > /* OpenSSL 1.0.2 and newer can automatically handle ECDH parameter > * loading */ > SSL_CTX_set_ecdh_auto(ctx->ctx, 1); > return; > +#endif > #else > /* For older OpenSSL we have to extract the curve from key on our own */ > EC_KEY *eckey = NULL; > In general it be better split this patch into two: renaming the get/set methods and removing the initialisation from OpenSSL >=1.1.0 Arne 

Hi, On Wed, Mar 27, 2019 at 02:56:26PM -0700, Rosen Penev wrote: > Also removed initialization with OpenSSL 1.1 as it is no longer needed and > causes compilation errors when disabling deprecated APIs. > > Same with SSL_CTX_set_ecdh_auto as it got removed. The Subject: line is a bit misleading - shouldn't this be more something like "Avoid calling deprecated-API calls of OpenSSL 1.1" or similar? (People *do* look at commit logs, and the current subject does not cover making the SSL_library_init() call conditional, etc.) On the patch itself, I have no strong opinion and would welcome a review from Steffan or Arne :-) - the Subject: line I can fix at commit time. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ge...@gr... 

Also removed initialization with OpenSSL 1.1 as it is no longer needed and causes compilation errors when disabling deprecated APIs. Same with SSL_CTX_set_ecdh_auto as it got removed. Signed-off-by: Rosen Penev <ro...@gm...> --- configure.ac | 2 ++ src/openvpn/openssl_compat.h | 8 ++++++++ src/openvpn/ssl_openssl.c | 18 ++++++++++++------ 3 files changed, 22 insertions(+), 6 deletions(-) diff --git a/configure.ac b/configure.ac index dfb268ca..2617f344 100644 --- a/configure.ac +++ b/configure.ac @@ -922,6 +922,8 @@ if test "${with_crypto_library}" = "openssl"; then	SSL_CTX_get_default_passwd_cb \	SSL_CTX_get_default_passwd_cb_userdata \	SSL_CTX_set_security_level \ +	X509_get0_notBefore \ +	X509_get0_notAfter \	X509_get0_pubkey \	X509_STORE_get0_objects \	X509_OBJECT_free \ diff --git a/src/openvpn/openssl_compat.h b/src/openvpn/openssl_compat.h index a4072b9a..788843a2 100644 --- a/src/openvpn/openssl_compat.h +++ b/src/openvpn/openssl_compat.h @@ -89,6 +89,14 @@ EVP_MD_CTX_new(void) } #endif +#if !defined(HAVE_X509_GET0_NOTBEFORE) +#define X509_get0_notBefore X509_get_notBefore +#endif + +#if !defined(HAVE_X509_GET0_NOTAFTER) +#define X509_get0_notAfter X509_get_notAfter +#endif + #if !defined(HAVE_HMAC_CTX_RESET) /** * Reset a HMAC context diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c index 8bcebac4..e41cafa5 100644 --- a/src/openvpn/ssl_openssl.c +++ b/src/openvpn/ssl_openssl.c @@ -76,12 +76,13 @@ int mydata_index; /* GLOBAL */ void tls_init_lib(void) { +#if (OPENSSL_VERSION_NUMBER < 0x10100000L && !defined(LIBRESSL_VERSION_NUMBER)) SSL_library_init(); -#ifndef ENABLE_SMALL +# ifndef ENABLE_SMALL SSL_load_error_strings(); -#endif +# endif OpenSSL_add_all_algorithms(); - +#endif mydata_index = SSL_get_ex_new_index(0, "struct session *", NULL, NULL, NULL); ASSERT(mydata_index >= 0); } @@ -89,9 +90,11 @@ tls_init_lib(void) void tls_free_lib(void) { +#if (OPENSSL_VERSION_NUMBER < 0x10100000L && !defined(LIBRESSL_VERSION_NUMBER)) EVP_cleanup(); -#ifndef ENABLE_SMALL +# ifndef ENABLE_SMALL ERR_free_strings(); +# endif #endif } @@ -541,7 +544,7 @@ tls_ctx_check_cert_time(const struct tls_root_ctx *ctx) goto cleanup; /* Nothing to check if there is no certificate */ } - ret = X509_cmp_time(X509_get_notBefore(cert), NULL); + ret = X509_cmp_time(X509_get0_notBefore(cert), NULL); if (ret == 0) { msg(D_TLS_DEBUG_MED, "Failed to read certificate notBefore field."); @@ -551,7 +554,7 @@ tls_ctx_check_cert_time(const struct tls_root_ctx *ctx) msg(M_WARN, "WARNING: Your certificate is not yet valid!"); } - ret = X509_cmp_time(X509_get_notAfter(cert), NULL); + ret = X509_cmp_time(X509_get0_notAfter(cert), NULL); if (ret == 0) { msg(D_TLS_DEBUG_MED, "Failed to read certificate notAfter field."); @@ -634,10 +637,13 @@ tls_ctx_load_ecdh_params(struct tls_root_ctx *ctx, const char *curve_name else { #if OPENSSL_VERSION_NUMBER >= 0x10002000L +#if (OPENSSL_VERSION_NUMBER < 0x10100000L && !defined(LIBRESSL_VERSION_NUMBER)) + /* OpenSSL 1.0.2 and newer can automatically handle ECDH parameter * loading */ SSL_CTX_set_ecdh_auto(ctx->ctx, 1); return; +#endif #else /* For older OpenSSL we have to extract the curve from key on our own */ EC_KEY *eckey = NULL; -- 2.17.1 

The INSTALL file contained several minor errors, typos and was generally not up-to-date in regards to what ./configure provides today. In addition, several URL references have moved around to new homes. Signed-off-by: David Sommerseth <da...@op...> --- INSTALL | 104 +++++++++++++++++++++++++++++++++++--------------------- 1 file changed, 65 insertions(+), 39 deletions(-) diff --git a/INSTALL b/INSTALL index 7c6c34e8..0ba3bba6 100644 --- a/INSTALL +++ b/INSTALL @@ -1,6 +1,6 @@ Installation instructions for OpenVPN, a Secure Tunneling Daemon -Copyright (C) 2002-2018 OpenVPN Inc. This program is free software; +Copyright (C) 2002-2019 OpenVPN Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation. @@ -10,26 +10,30 @@ as published by the Free Software Foundation. QUICK START: Unix: - ./configure && make && make-install + ./configure && make && make install ************************************************************************* -To download OpenVPN, go to: +To download OpenVPN source code of releases, go to: - http://openvpn.net/download.html + https://openvpn.net/community-downloads/ OpenVPN releases are also available as Debian/RPM packages: https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos +OpenVPN development versions can be found here: + + https://github.com/OpenVPN/openvpn + https://gitlab.com/OpenVPN/openvpn + https://sourceforge.net/p/openvpn/openvpn/ci/master/tree/ + +They should all be in sync at any time. + To download easy-rsa go to: https://github.com/OpenVPN/easy-rsa -To download tap-windows (NDIS 5) driver source code go to: - - https://github.com/OpenVPN/tap-windows - To download tap-windows (NDIS 6) driver source code go to: https://github.com/OpenVPN/tap-windows6 @@ -40,15 +44,11 @@ To get the cross-compilation environment go to: For step-by-step instructions with real-world examples see: - http://openvpn.net/howto.html + https://community.openvpn.net/openvpn/wiki/GettingStartedwithOVPN https://community.openvpn.net/openvpn/wiki + https://openvpn.net/community-resources/ -For examples see: - - http://openvpn.net/examples.html - -Also see the man page for more information, usage examples, and information on -firewall configuration. +Also see the man page for more information. ************************************************************************* @@ -73,7 +73,7 @@ REQUIRES: TUN/TAP Driver Configuration section below for more info. OPTIONAL (but recommended): - (1) OpenSSL library, necessary for encryption, version 0.9.8 or higher + (1) OpenSSL library, necessary for encryption, version 1.0.1 or higher required, available from http://www.openssl.org/ (2) mbed TLS library, an alternative for encryption, version 2.0 or higher required, available from https://tls.mbed.org/ @@ -100,11 +100,12 @@ CHECK OUT SOURCE FROM SOURCE REPOSITORY: Clone the repository: git clone https://github.com/OpenVPN/openvpn + git clone https://gitlab.com/OpenVPN/openvpn git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn Check out stable version: - git checkout -b 2.2 remotes/origin/release/2.2 + git checkout release/2.4 Check out master (unstable) branch: @@ -134,7 +135,7 @@ BUILD A TARBALL FROM SOURCE REPOSITORY CHECKOUT:	autoreconf -i -v -f	./configure -	make dist +	make distcheck ************************************************************************* @@ -160,24 +161,19 @@ environment. See tests/t_client.rc-sample for details. OPTIONS for ./configure: --disable-lzo disable LZO compression support [default=yes] - --enable-lzo-stub don't compile LZO compression support but still - allow limited interoperability with LZO-enabled - peers [default=no] + --disable-lz4 Disable LZ4 compression support + --enable-comp-stub Don't compile compression support but still allow limited interoperability with compression-enabled peers --disable-crypto disable crypto support [default=yes] - --disable-ssl disable SSL support for TLS-based key exchange + --disable-ofb-cfb disable support for OFB and CFB cipher modes [default=yes] --enable-x509-alt-username enable the --x509-username-field feature [default=no] - --disable-multi disable client/server support (--mode server + - client mode) [default=yes] --disable-server disable server support only (but retain client support) [default=yes] --disable-plugins disable plug-in support [default=yes] --disable-management disable management server support [default=yes] --enable-pkcs11 enable pkcs11 support [default=no] - --disable-socks disable Socks support [default=yes] - --disable-http-proxy disable HTTP proxy support [default=yes] --disable-fragment disable internal fragmentation support (--fragment) [default=yes] --disable-multihome disable multi-homed UDP server support (--multihome) @@ -187,44 +183,74 @@ OPTIONS for ./configure: --disable-debug disable debugging support (disable gremlin and verb 7+ messages) [default=yes] --enable-small enable smaller executable size (disable OCC, usage - message, and verb 4 parm list) [default=yes] - --enable-password-save allow --askpass and --auth-user-pass passwords to be - read from a file [default=yes] + message, and verb 4 parm list) [default=no] --enable-iproute2 enable support for iproute2 [default=no] --disable-def-auth disable deferred authentication [default=yes] --disable-pf disable internal packet filter [default=yes] + --disable-plugin-auth-pam + disable auth-pam plugin [default=platform specific] + --disable-plugin-down-root + disable down-root plugin [default=platform specific] + --enable-pam-dlopen dlopen libpam [default=no] --enable-strict enable strict compiler warnings (debugging option) [default=no] --enable-pedantic enable pedantic compiler warnings, will not generate a working executable (debugging option) [default=no] + --enable-werror promote compiler warnings to errors, will cause + builds to fail if the compiler issues warnings + (debugging option) [default=no] --enable-strict-options enable strict options check between peers (debugging option) [default=no] --enable-selinux enable SELinux support [default=no] --enable-systemd enable systemd support [default=no] + --enable-async-push enable async-push support for plugins providing + deferred authentication [default=no] ENVIRONMENT for ./configure: + PLUGINDIR Path of plug-in directory [default=LIBDIR/openvpn/plugins] IFCONFIG full path to ipconfig utility ROUTE full path to route utility IPROUTE full path to ip utility NETSTAT path to netstat utility MAN2HTML path to man2html utility GIT path to git utility + SYSTEMD_ASK_PASSWORD + path to systemd-ask-password utility + SYSTEMD_UNIT_DIR + Path of systemd unit directory [default=LIBDIR/systemd/system] + TMPFILES_DIR + Path of tmpfiles directory [default=LIBDIR/tmpfiles.d] + +ENVIRONMENT variables adjusting parameters related to dependencies + TAP_CFLAGS C compiler flags for tap - OPENSSL_CFLAGS - C compiler flags for OpenSSL, overriding pkg-config - OPENSSL_LIBS - linker flags for OpenSSL, overriding pkg-config - POLARSSL_CFLAGS - C compiler flags for polarssl - POLARSSL_LIBS - linker flags for polarssl - LZO_CFLAGS C compiler flags for lzo - LZO_LIBS linker flags for lzo + LIBPAM_CFLAGS + C compiler flags for libpam + LIBPAM_LIBS linker flags for libpam PKCS11_HELPER_CFLAGS C compiler flags for PKCS11_HELPER, overriding pkg-config PKCS11_HELPER_LIBS linker flags for PKCS11_HELPER, overriding pkg-config + OPENSSL_CFLAGS + C compiler flags for OpenSSL + OPENSSL_LIBS + linker flags for OpenSSL + MBEDTLS_CFLAGS + C compiler flags for mbedtls + MBEDTLS_LIBS + linker flags for mbedtls + LZO_CFLAGS C compiler flags for lzo + LZO_LIBS linker flags for lzo + LZ4_CFLAGS C compiler flags for lz4 + LZ4_LIBS linker flags for lz4 + libsystemd_CFLAGS + C compiler flags for libsystemd, overriding pkg-config + libsystemd_LIBS + linker flags for libsystemd, overriding pkg-config + P11KIT_CFLAGS + C compiler flags for P11KIT, overriding pkg-config + P11KIT_LIBS linker flags for P11KIT, overriding pkg-config ************************************************************************* -- 2.17.1 

Hey Arne, On Mon, Mar 25, 2019 at 11:23 AM Arne Schwabe <ar...@rf...> wrote: > I wish you good luck in this endeavour and welcome the prospect of > having a better tun driver for Windows. We know that our own TAP/TUN > driver is a pain point for us as well and having a better alternative is > something we would definitively like to have/support a more modern driver. > The lack of tap is not a big deal for OpenVPN anymore. The world shifted > quite a bit and tap support is not needed that much anymore. Android > does not support it. MacOS client supports tun natively (utun) and tap > requires extra kext. And so on... That's good to know. I wasn't aware that that perspective was there for OpenVPN as well. It certainly makes things simpler. In that case, I'll certainly try to continue to keep OpenVPN in mind when developing this. And depending on everybody's time availability, maybe at some point we could work together in adding experimental support for Wintun in OpenVPN. > I am afraid our project members are currently busy and cannot really > contribute much to your new shiny driver. We barely have enough time for > OpenVPN itself. But if you have something that is good enough at least > for testing and has a reasonable stable API just an extra mail and I > think we can implement it as alternative to our own driver. Great. I'll send a follow-up when we're at that point. At the moment we're working out some details with IO_CSQ, and then we'll try to put together some half-decent API documentation to make this easy. Then, I'll poke you and we can get rolling with this. > Frome the site: The source code is provided under the GPL 2.0 and is > available via git: > > One detail here. If you have/add a file that defines the API for > external programs, to license it under a freeer license for 3rd party to > include that API file without license worries. Like our tap-windows.h > (https://github.com/OpenVPN/tap-windows6/blob/master/src/tap-windows.h). > This was primarily requested by the Freeswan developer iirc. That's a good point. I'll certainly do something like that. Or, possibly I'll just relicense the whole driver to MIT so nobody has to worry. Will give it some thought. Jason 

Am 23.03.19 um 02:04 schrieb Jason A. Donenfeld: > Hi everybody, > > [Cross-posting to WireGuard, OpenVPN, and Nmap/npcap mailing lists.] > > Simon and I are pleased to announce the start of a new project, made > for WireGuard and for others too: Wintun, a layer 3 TUN driver for > Windows. I wish you good luck in this endeavour and welcome the prospect of having a better tun driver for Windows. We know that our own TAP/TUN driver is a pain point for us as well and having a better alternative is something we would definitively like to have/support a more modern driver. > Wintun is our attempt at making a dumb layer 3 pipe, that doesn't do > anything fancy, and just shuffles bundles of packets between userspace > and the kernel driver. It's being used for WireGuard's Windows port. > We'd like to make it available and easy to use for other projects too > that need layer 3 userspace tunneling capabilities, like OpenVPN and > SoftEther. (Also, it may be just a matter of time before somebody > takes the tiny base of it, sticks the crypto in the kernel, and makes > WireGuard super fast on Windows.) If someone does that, it would be nice to have a bit more generic so we can also push our openvpn keys to the driver. Our AEAD-GCM data format and Wireshark's data format are reasonable close to use the same code for it. The lack of tap is not a big deal for OpenVPN anymore. The world shifted quite a bit and tap support is not needed that much anymore. Android does not support it. MacOS client supports tun natively (utun) and tap requires extra kext. And so on... > Have we succeeded in accomplishing our goals? Certainly not yet. At > the present moment [folks reading this in the future: check the date > of this email], I'd except for Wintun to be slower, buggier, and lower > quality than anything else out there. But we thought it'd be a good > idea to release sooner rather than later in order to have some more > eyeballs on it. It's the kind of codebase that _certainly_ needs some > cleanup and a thorough security audit. On the plus side, cloc(1) tells > me that it's only 950 lines. Still, NT programming is hard, and I'm > pretty certain we've made mistakes and left ugly corners. Consider > this email a statement of intent rather than an announcement of a > completed project. I am afraid our project members are currently busy and cannot really contribute much to your new shiny driver. We barely have enough time for OpenVPN itself. But if you have something that is good enough at least for testing and has a reasonable stable API just an extra mail and I think we can implement it as alternative to our own driver. > Details are over on https://www.wintun.net/ where you may also find > rabbits bringing windows into tunnels. Enjoy! Frome the site: The source code is provided under the GPL 2.0 and is available via git: One detail here. If you have/add a file that defines the API for external programs, to license it under a freeer license for 3rd party to include that API file without license worries. Like our tap-windows.h (https://github.com/OpenVPN/tap-windows6/blob/master/src/tap-windows.h). This was primarily requested by the Freeswan developer iirc. Arne 

Hi everybody, [Cross-posting to WireGuard, OpenVPN, and Nmap/npcap mailing lists.] Simon and I are pleased to announce the start of a new project, made for WireGuard and for others too: Wintun, a layer 3 TUN driver for Windows. Homepage: https://www.wintun.net/ A TUN driver lets userspace programs act as virtual network cards, reading and writing packets directly into the network stack, as though they came from a real network adapter. While Linux and the BSDs have had /dev/tun for ages, Windows typically hasn't had any native facilities. Recently, Microsoft released a VPN UWP API, but it's lacking in features, documentation is under NDA, and after reversing it for a bit, it doesn't seem capable of doing many of the more advanced routing and roaming things we want. Indeed it turns out that having a real network adapter and some basic file handles is much preferable to layers of API and abstraction. On the flipside, OpenVPN's tap-windows6 project and the numerous drivers from SoftEther have all provided similar functionality for many years, and these efforts have produced something moderately stable. We were, in fact, quite inspired by SoftEther's Neo6 driver. However, these projects were written in a different age, the era of NDIS5, and then ported later to NDIS6. This means they haven't benefited from things like Windows 7's NdisMediumIP, which allows for native layer 3 tunneling, without having to do layer 2 emulation. Drivers like OpenVPN's tap-windows6 also do some somewhat nasty things, like emulate DHCP from inside the kernel for network configuration. The code is old and complicated. As usual, I wanted instead something tiny and dumb that we can reason about, which does things in a "right" and "boring" way for a narrower use case: layer 3 TUN. Wintun is our attempt at making a dumb layer 3 pipe, that doesn't do anything fancy, and just shuffles bundles of packets between userspace and the kernel driver. It's being used for WireGuard's Windows port. We'd like to make it available and easy to use for other projects too that need layer 3 userspace tunneling capabilities, like OpenVPN and SoftEther. (Also, it may be just a matter of time before somebody takes the tiny base of it, sticks the crypto in the kernel, and makes WireGuard super fast on Windows.) Have we succeeded in accomplishing our goals? Certainly not yet. At the present moment [folks reading this in the future: check the date of this email], I'd except for Wintun to be slower, buggier, and lower quality than anything else out there. But we thought it'd be a good idea to release sooner rather than later in order to have some more eyeballs on it. It's the kind of codebase that _certainly_ needs some cleanup and a thorough security audit. On the plus side, cloc(1) tells me that it's only 950 lines. Still, NT programming is hard, and I'm pretty certain we've made mistakes and left ugly corners. Consider this email a statement of intent rather than an announcement of a completed project. So, if you're interested in NDIS programming and want to lend a hand, don't hesitate to get in touch. We're eager for smart NT folks to help us out. Details are over on https://www.wintun.net/ where you may also find rabbits bringing windows into tunnels. Enjoy! Regards, Jason 

Hi all, On 20/03/2019 21:04, Antonio Quartulli wrote: > Hi all, > > As mentioned today on IRC, I have prepared a doodle to help us choose > when to schedule the next community meetings. > > The doodle targets next week, but the idea is to choose a time slot that > is good "from now on". > To clarify: since most of the OpenVPN contributors live in Central Europe, the meeting time slot will follow the CET->CEST transition and back (as we did in the past). This means that if the winning time slot it 8PM CET (UTC+1), next month it will become 8PM CEST (UTC+2). Regards, -- Antonio Quartulli 

Correcion >From: Selva Nair <sel...@gm...> > >Make clear that --dhcp-option is not processed on >non-Windows clients > This thread was _initially_ about pushing DNS to Linux clients. I mean "non-windows" clients. 

 On 20/03/2019 18:12, tincanteksup wrote: > bonjour > > On 20/03/2019 17:25, Selva Nair wrote: >> On Wed, Mar 20, 2019 at 10:52 AM tincanteksup <tin...@gm...> >> wrote: >>> >>> >>> >>> On 20/03/2019 13:25, Selva Nair wrote: >>>> Hi, >>>> >>>> On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli <a...@un...> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> On 18/03/2019 22:30, tincanteksup wrote: >>>>>> Hi, >>>>>> >>>>>> this situation has been hanging around for so long is this brief note >>>>>> really enough? Considering that the manual has numerous other URLs >>>>>> why >>>>>> not include this URL here: >>>>>> https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients >>>>>> >>>>>> We already have this: >>>>>> https://community.openvpn.net/openvpn/wiki/SWEET32 >>>>>> >>>>> >>>>> the problem with URLs is that they become obsolete and we need to >>>>> re-patch the manual in order to update them (or ensure the URL always >>>>> work/redirect to something). >>>> >>>> >>>> I have the same opinion about URLs. On top of that the wiki >>>> description is inadequate and inaccurate. But that's a different >>>> topic. >>> >>> Inadequate: >>> Compared to NOTHING, the page is at least a step toward documentation. >>> >>> Inaccurate: >>> Please expand .. >> >> The wiki states that on Windows using version 2.4, >> OpenVPN-GUI+interactive >> service required for processing this option. Not so. > > I am actively promoting 2.4 use, I am not re-writing the manual. > >> Just as in 2.3, it works if run as admin. In fact, several setups run >> OpenVPN on boot using OpenVPNService, and --dhcp-option does work for >> them. >> With 2.4, it also works as limited user if started using the interactive >> service (for example, using OpenVPN-GUI). > > I am actively demoting 2.3 use, I am not re-writing the manual. > >> In both 2.3 and 2.4, the critical piece is not overriding --ipwin32 >> method >> (adaptive or dynamic is required and the latter is the >> default). >> > > I am actively promoting the use of the Interactive Service. > I am not rewriting the manual .. > > If a problem arises from using Openvpn as the page describes then, > depending on the cause, a resolution can be pursued .. > > thanks > tct > This thread was _initially_ about pushing DNS to Linux clients. 

Hi all, As mentioned today on IRC, I have prepared a doodle to help us choose when to schedule the next community meetings. The doodle targets next week, but the idea is to choose a time slot that is good "from now on". The meeting duration is still fixed to 1 hour. Please, fill the doodle with your votes by Sunday (March 24th, 2019) night, so that on Monday morning Samuli can send out the invitation with the elected day/time. Link: https://doodle.com/poll/qbnsw7d4mvb5iysn#calendar Thanks! -- Antonio Quartulli 

bonjour On 20/03/2019 08:00, Antonio Quartulli wrote: > Hi, > > On 18/03/2019 22:30, tincanteksup wrote: >> Hi, >> >> this situation has been hanging around for so long is this brief note >> really enough? Considering that the manual has numerous other URLs why >> not include this URL here: >> https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients >> >> We already have this: >> https://community.openvpn.net/openvpn/wiki/SWEET32 >> Reinserted from my original post: >> Please consider adding it. > > the problem with URLs is that they become obsolete and we need to > re-patch the manual in order to update them (or ensure the URL always > work/redirect to something). > > > However, I was thinking that a WARNING in the log when parsing a > dhcp-option without any script configured (on non-windows platform) may > also be beneficial. > > Not many people will read it, but at least it will be there to be seen > at the first attempt of understanding what's wrong. > > What do you think? The argument against using URLs in the Manual has these facts to refute: * URLs are already in use in the manual * I cited another example of using a URL in the manual. * Some URLS in use in the manual are external to openvpn.net * Using URLs in online documentation is The standard practice. * There are even URLs in the Openvpn log files .. It is easier to maintain linked documentation than it is to have to patch the source so, given that the link is under the openvpn.net wing, this seems perfectly reasonable to me. Adding a warning for this problem in the log file is unsuitable: * When the situation changes the source will have to be maintained. * The situation will change. * It is easier to maintain linked documentation to account for change. * Log files are for diagnosing problems and should not have any URLs.. (Except for one URL to ${help}.openvpn, a URL which is unlikely to change and can therefore be easily maintained by OpenVPN Inc and remove that burden from the FOSS Openvpn development team) my2c thanks tct > > This said, the warning could/should be implemented as a separate patch. > > Regards, > 

bonjour On 20/03/2019 17:25, Selva Nair wrote: > On Wed, Mar 20, 2019 at 10:52 AM tincanteksup <tin...@gm...> > wrote: >> >> >> >> On 20/03/2019 13:25, Selva Nair wrote: >>> Hi, >>> >>> On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli <a...@un...> wrote: >>>> >>>> Hi, >>>> >>>> On 18/03/2019 22:30, tincanteksup wrote: >>>>> Hi, >>>>> >>>>> this situation has been hanging around for so long is this brief note >>>>> really enough? Considering that the manual has numerous other URLs why >>>>> not include this URL here: >>>>> https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients >>>>> >>>>> We already have this: >>>>> https://community.openvpn.net/openvpn/wiki/SWEET32 >>>>> >>>> >>>> the problem with URLs is that they become obsolete and we need to >>>> re-patch the manual in order to update them (or ensure the URL always >>>> work/redirect to something). >>> >>> >>> I have the same opinion about URLs. On top of that the wiki >>> description is inadequate and inaccurate. But that's a different >>> topic. >> >> Inadequate: >> Compared to NOTHING, the page is at least a step toward documentation. >> >> Inaccurate: >> Please expand .. > > The wiki states that on Windows using version 2.4, OpenVPN-GUI+interactive > service required for processing this option. Not so. I am actively promoting 2.4 use, I am not re-writing the manual. > Just as in 2.3, it works if run as admin. In fact, several setups run > OpenVPN on boot using OpenVPNService, and --dhcp-option does work for them. > With 2.4, it also works as limited user if started using the interactive > service (for example, using OpenVPN-GUI). I am actively demoting 2.3 use, I am not re-writing the manual. > In both 2.3 and 2.4, the critical piece is not overriding --ipwin32 method > (adaptive or dynamic is required and the latter is the > default). > I am actively promoting the use of the Interactive Service. I am not rewriting the manual .. If a problem arises from using Openvpn as the page describes then, depending on the cause, a resolution can be pursued .. thanks tct