Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback

[Marvin Adeff]

Selva,

Please allow me to back up a moment and restate this:
1.  I installed the beta3 msi from the web site logged in as a user that has 
admin privileges.  But no elevation was used to install it, just double-click 
on the file. 
2.  I only used the GUI as installed, with no elevation, to start OpenVPN. 
3.  With TAP selected in my .ovpn config file, everything works normally. 
4.  I am reporting that (from the same login) if I change the .ovpn to use 
wintun (all edits done through the GUI selection), it fails with the error I 
showed below. 

Is 4. what you are saying is not supported?  In our use, as we have done for 
the past decade, the client boxes are used for M2M monitoring.  OpenVPN has to 
connect on bootup (.ovpn config file contains inline certificates) regardless 
if there is a user logged in or not as M2M monitoring occurs in the background. 
 And if a user does login, most often it is with credentials that have admin 
privileges.  I am trying to understand if what you’re telling me is that this 
will no longer work, or if we will need to do something different now?  My 
testing used the GUI to see how things will work with wintun so we can continue 
testing. 

Do I need to NOT use the GUI to get wintun to work?  

Marvin 

> On Sep 9, 2020, at 9:56 PM, Selva Nair  wrote:
> 
> Hi,
> 
>> On Thu, Sep 10, 2020 at 12:19 AM Marvin  wrote:
>> Hi Selva,
>> 
>>> The GUI did not have this error unless run as administrator which you 
>>> should not and will never work.   
>> So you are saying that if OpenVPN is installed by a user who has admin 
>> privileges (as our case does) that v2.5 with wintun will not work?
> 
> You mean OpenVPN started using the GUI? If so, no, I'm not saying that. The 
> GUI just works even with beta1 or with beta3. On Windows user's processes run 
> with limited privileges even if the user is an "admin". At least that is the 
> default because of UAC. 
>  
> Installation can be done when logged in as admin or as a limited user 
> (provided you know admin credentials) as the installer prompts for elevation 
> as required. 
> 
> That qualifier I added was because: the GUI running with privileges (admin) 
> has been discouraged in 2.4 ever since we introduced the interactive service. 
> And that continues with 2.5. It will work for some things and not for some 
> other things. Same with running the GUI with interactive service disabled. As 
> such uses are not supported, don't complain about it :)
> 
> Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] tun.c: enable using wintun driver under SYSTEM

[Marvin Adeff]

No need to rush.  I’m happy to wait until Wednesday for beta2. 

Cheers,
Marvin 

Sent from my iPhone

> On Aug 22, 2020, at 12:20 AM, Gert Doering  wrote:
> 
> Hi,
> 
>> On Fri, Aug 21, 2020 at 07:37:27PM -0700, Marvin Adeff wrote:
>> When will this be available as an installable (beta) msi?
> 
> I'll merge the commit today or tomorrow (sorry for the lag on my side,
> was travelling and had only limited access to "Internet and focus").
> 
> My plan is to do a formal "beta2" tag on Wednesday, but of course
> Samuli/Lev could do a new installer ("beta1_1") earlier.
> 
> 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 g...@greenie.muc.de


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] tun.c: enable using wintun driver under SYSTEM

[Marvin Adeff]

Hi,

When will this be available as an installable (beta) msi?

Marvin 

> On Aug 21, 2020, at 2:13 PM, Selva Nair  wrote:
> 
> Hi,
> 
>> On Wed, Aug 19, 2020 at 3:08 AM Lev Stipakov  wrote:
>> From: Lev Stipakov 
>> 
>> Commit 6d19775a468 has removed SYSTEM elevation hack,
>> but introduced regression - inability to use wintun without interactive 
>> service.
>> 
>> Proceed with ring buffers registration even if iservice is unavailable and 
>> display
>> relevant error message.
>> 
>> Trac #1318
>> 
>> Signed-off-by: Lev Stipakov 
>> ---
>>  src/openvpn/tun.c | 30 +-
>>  1 file changed, 25 insertions(+), 5 deletions(-)
>> 
>> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
>> index 30454454..62557364 100644
>> --- a/src/openvpn/tun.c
>> +++ b/src/openvpn/tun.c
>> @@ -6158,12 +6158,32 @@ wintun_register_ring_buffer(struct tuntap *tt, const 
>> char *device_guid)
>>  }
>>  else
>>  {
>> -msg(M_FATAL, "ERROR:  Wintun requires SYSTEM privileges and 
>> therefore "
>> - "should be used with interactive service. If you want 
>> to "
>> - "use openvpn from command line, you need to do SYSTEM "
>> - "elevation yourself (for example with psexec).");
>> -}
>> +if (!register_ring_buffers(tt->hand,
>> +   tt->wintun_send_ring,
>> +   tt->wintun_receive_ring,
>> +   tt->rw_handle.read,
>> +   tt->rw_handle.write))
>> +{
>> +switch (GetLastError())
>> +{
>> +case ERROR_ACCESS_DENIED:
>> +msg(M_FATAL, "ERROR:  Wintun requires SYSTEM privileges 
>> and therefore "
>> + "should be used with interactive service. 
>> If you want to "
>> + "use openvpn from command line, you need 
>> to do SYSTEM "
>> + "elevation yourself (for example with 
>> psexec).");
>> +break;
>> +
>> +case ERROR_ALREADY_INITIALIZED:
>> +msg(M_NONFATAL, "Adapter %s is already in use", 
>> device_guid);
>> +break;
>> 
>> +default:
>> +msg(M_NONFATAL | M_ERRNO, "Failed to register ring 
>> buffers");
>> +}
>> +ret = false;
>> +}
>> +
>> +}
>>  return ret;
>>  }
> 
> Looks good and running as SYSTEM works now as expected. Tested on 64 bit 
> Windows 10.
> 
> Acked-by: selva.n...@gmail.com 
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Marvin Adeff]

I noticed the same issue.  I tried upgrading from an earlier version with an 
.ovpn file (with all settings and inline certs etc that was working 
previously).  The .ovpn is configured as client to receive dhcp address from 
the server.  

But when we ran the upgrade .msi, which created both a TAP and wintun 
interfaces, the TAP was fine but the wintun had static IPs selected with no IPs 
entered.  Unless someone has some programming smoke and mirrors, that’s asking 
for a failure.  

So it didn’t read the .ovpn (to select dhcp) and it didn’t have anything to 
populate the IP/subnet/dns etc.  This can’t be right.  At the least it should 
be set to dhcp by default with static IPs added later if necessary.  Or am I 
doing something wrong?

Marvin 

> On Aug 18, 2020, at 11:03 PM, Gert Doering  wrote:
> 
> Hi,
> 
>> On Tue, Aug 18, 2020 at 07:30:12PM -0300, Rafael Gava wrote:
>> Inspecting the wintun interface through the properties I saw that on the
>> TCP/IPv4 Properties the default option selected is "Use the following IP
>> address" but the IP address and the Subnet mask were empty. Should that be
>> a problem?
> 
> No.  OpenVPN will set what is needed.
> 
> 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 g...@greenie.muc.de
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Marvin Adeff]

Hi Gert,

I’m sorry for the confusing response.  

Our systems do M2M monitoring and need to run OpenVPN even without a user 
logged in.  In previous versions we created a script run as a service (as 
SYSTEM) that started OpenVPN (using certificates for authentication).  It also 
monitored tunnel status and restarted OpenVPN if necessary.  We never used the 
GUI. 

So we are watching how v2.5 develops to know how we will need to implement the 
new version.  We are also very interested in seeing what speed improvements 
wintun will offer. 

I hope that is clearer. 

Marvin 

> On Aug 18, 2020, at 11:18 AM, Gert Doering  wrote:
> 
> Hi,
> 
> On Tue, Aug 18, 2020 at 08:55:31AM -0700, Marvin Adeff wrote:
>>> An additional check in openvpn.exe whether it's started as SYSTEM could be
>>> useful as well, but less critical, IMO.
>> Yes Please!  We run 2500+ systems that run it this way as SYSTEM.  
> 
> "this way" is quite a bit unclear here - in the thread context,
> "this way" would be "run from the GUI", which never runs as SYSTEM.
> 
> Can you elaborate a bit more how you run OpenVPN?
> 
> 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 g...@greenie.muc.de


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Marvin Adeff]

Hi,

> An additional check in openvpn.exe whether it's started as SYSTEM could be
> useful as well, but less critical, IMO.
Yes Please!  We run 2500+ systems that run it this way as SYSTEM.  

Marvin ___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] compatibility of 2.3 server with git master client

[Marvin Adeff]

Thank you I will try this. 

Marvin 

Sent from my iPhone

> On Jul 13, 2020, at 7:34 AM, Gert Doering  wrote:
> 
> Hi,
> 
>> On Mon, Jul 13, 2020 at 07:23:59AM -0700, Marvin Adeff wrote:
>> I???m wondering if the opposite of this scenario has been tested, where the 
>> server is running 2.3.18 (on Linux) and a client running 2.5 (on Windows) 
>> tries to connect?
> 
> It should work, but this is a "should".  It's hard enough to test all
> possible combinations of clients and features against git master, so we
> do not normally test current clients against out-of-service releases
> on the server.
> 
> On the other hand we do not purposely break client-server protocol, 
> so it *should* work.  It's just not regularily tested.
> 
> If you test, and it breaks, please show client and server logs so we can
> fix it :-)
> 
> 
>> I know, I know, we should upgrade.  Unfortunately in this case OpenVPN 
>> server is running on an appliance that cannot be upgraded past Linux 2.6, 
>> and I don???t think 2.4.x can run on Linux 2.6. 
> 
> You do not want to have an appliance that is running an ancient linux
> version connected to the Internet either...
> 
> But besides that, compiling OpenVPN 2.4 should be no big problem - it is
> not very demanding regarding system environment or OpenSSL version.
> 
> For OpenVPN 2.5 (git master) you'll need an update openssl library - but
> this is also not hard, you can compile it and install it to a non-default
> place ("/usr/local/openssl-1.1.1") and point OpenVPN's configure script
> at it.
> 
> One of my test clients is FreeBSD 7.4, which stopped receiving updates
> in 2013 - but with a local openssl installation, it works fine, with
> git master  (this is sort of a "are we using fancy features that break
> older unixes now?" lithmus test, not something you want exposed on the
> Internet, or something I'd recommend).
> -- 
> "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 g...@greenie.muc.de


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] git master crashes on connect of 2.3 client with --enable-small

[Marvin Adeff]

I’m wondering if the opposite of this scenario has been tested, where the 
server is running 2.3.18 (on Linux) and a client running 2.5 (on Windows) tries 
to connect?

I know, I know, we should upgrade.  Unfortunately in this case OpenVPN server 
is running on an appliance that cannot be upgraded past Linux 2.6, and I don’t 
think 2.4.x can run on Linux 2.6. 

Marvin 


Sent from my iPhone

> On Jul 13, 2020, at 1:57 AM, Arne Schwabe  wrote:
> 
>> Am 13.07.20 um 08:58 schrieb Gert Doering:
>> Hi,
>> 
>>> On Mon, Jul 13, 2020 at 08:33:03AM +0200, Gert Doering wrote:
 On Mon, Jul 13, 2020 at 08:10:23AM +0200, Gert Doering wrote:
 Ouch.  This is not good.  My gut feeling is "2.3 with --enable-small = 
 no OCC *and* no NCP = the server runs across a NULL pointer here".
>>> 
>>> Bäm.  Fully reproduceable here
>>> 
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x77af51be in ?? () from /lib64/libc.so.6
>>> (gdb) where
>>> #0  0x77af51be in ?? () from /lib64/libc.so.6
>>> #1  0x555d4a7b in ncp_get_best_cipher (server_list=, 
>>>server_cipher=0x555f28da "BF-CBC", 
>>>peer_info=peer_info@entry=0x556781c0 
>>> "IV_VER=2.3.18\nIV_PLAT=freebsd\nIV_PROTO=2\n", remote_cipher=0x0, 
>>> gc=gc@entry=0x5565e070) at ssl_ncp.c:231
>> 
>> ... and this is why (added a msg() call):
>> 
>> 2020-07-13 08:36:59 us=802772 ncp_get_best_cipher(), peer_ncp_list=, 
>> tmp_ciphers=AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-192-CBC:AES-256-CBC, 
>> remote_cipher=(null), server_cipher=BF-CBC
>> 
>> if "remote_cipher" is NULL (= no OCC) we pass that to "strcmp()", and that
>> does not want it.
>> 
>> 
>> Returning NULL from ncp_get_best_cipher() if there is nothing the client
>> has to offer works fine, though it triggers this warning
>> 
>> 2020-07-13 08:43:01 us=483904 cron2-freebsd-tc-amd64-23/194.97.140.21:30927 
>> PUSH: No common cipher between server and client.Expect this connection not 
>> to work. Server ncp-ciphers: 
>> 'AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-192-CBC:AES-256-CBC', client 
>> supported ciphers ''
>> 
>> 
>> which we might want to reword for this case ("No information about cipher 
>> support received from client, cannot ensure correct operation" or so).
>> 
>> Patch appended.
>> 
>> Comments?
> 
> 
> 
> 
> +}
> +else
> +{
> +msg(M_INFO, "PUSH: No cipher info received from
> client "
> +"(no NCP and no OCC).  Cannot ensure
> compatibility.");
> +}
> gc_free();
> 
> 
> This is misleading. peer_chipers == "" only says that the peer does not
> send IV_CIPHERS/IV_NCP.  I think I would rather do something change the
> message to:
> 
> 
>msg(M_INFO, "No NCP data received from peer, falling back to --cipher
> '%s'. Peer reports in OCC --cipher '%s'", o->ciphername,
> np(tls_multi->remote_ciphername));
> 
> 
> This avoid adding another if else for now. And yes for clients without
> occ you get that annoying warning in the log but that is okay.
> 
> 
> Otherwise ACK.
> 
> Arne
> 
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Setting adapter mtu on windows systems

[Marvin Adeff]

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  wrote:
> 
> Hi
> 
>> On Thu, Mar 28, 2019 at 9:13 AM Arne Schwabe  wrote:
>> Am 28.03.19 um 13:27 schrieb Christopher Schenk:
>> > From: Christopher Schenk 
>> > 
>> > ---
>> >  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(, 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(>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(, "%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
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Minimum Linux Version for OpenVPN 2.4.x

[Marvin Adeff]

Thank you Jan, Gert et al for the replies.  Especially Jan for going to all 
that trouble!

Jan, to all your points — yes I agree. Upgrading this device to a newer kernel 
will be a major undertaking, I won’t bother you all with the details here. I 
asked the question to get an idea of how recent we can go in OpenVPN version in 
the interim while we plan our overall system upgrade (it is currently at 2.3.4 
with OpenSSL 1.01h and lzo 2.02).

Thanks again all!  I really appreciate your attention. 

Best,
Marvin

> On May 23, 2018, at 3:25 AM, Jan Just Keijser  wrote:
> 
> Hi,
> 
> 
>> On 22/05/18 22:47, Gert Doering wrote:
>>> On Tue, May 22, 2018 at 09:10:10PM +0200, David Sommerseth wrote:
 On 22/05/18 19:32, Marvin wrote:
 Can someone tell me the minimum Linux version that OpenVPN 2.4.x will build
 and run on?  We have an older appliance the runs on an older 2.4.31 kernel
 (cannot be upgraded -- but it's very hardened so really doesn't need to be 
 for
 our use.)
>>> 
>>> But I do know there has been some
>>> code changes over the years which is strictly 2.6 kernel and newer; but its
>>> quite a long time ago so I don't recall exactly what and when.
>> For OpenVPN 2.4, I think we kicked out some old method to set up Linux
>> tunnels.  OTOH, that was 2.2.x stuff, if I remember correctly...
>> (86e2fa5597fd1ad8e010)
>> 
>> 
> as usual, Gert is right ...
> I've  dusted off and fired up a really ancient VM running CentOS 3.9, which 
> is based on kernel 2.4.21. After falling off my chair in amazement and 
> climbing back on, I then copied over openssl 1.0.2, lzo-2.03 and openvpn 
> 2.4.5; openssl builds, as does lzo. As Gert predicted:
> OpenVPN 2.4.5 fails to build on tun.c , line 2092: 'TUNSETGROUP' undeclared.
> 
> I then copied over openvpn 2.3.18 and built that: it builds and runs just 
> fine.
> So in short: openvpn 2.3.X is the last version that can be run on a 2.4 
> kernel.
> 
> Now stop and think about this:
> - WHY?!?!?!?!!? would you want to do this?
> - as others have said, the 2.4 kernel series is no longer updated , and 
> 2.4.31 is not even the last version (that's 2.4.37). I would not  consider 
> any device running a 2.4 kernel secure enough to run a secure VPN on it, 
> especially over the internet.
> - why do would you need openvpn 2.4.x in the first place for such a device?  
> if it's AES-GCM that you are looking for then there's a good chance that  it 
> will be SLOWER on embedded hardware compared to AES-256-CBC+SHA256.
> 
> 
> JM2CW,
> 
> JJK
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Depreciate IPv4-related options.

[Marvin Adeff]

Antonio,
I certainly don’t disagree with you. 

However I think I’ve taken up enough bandwidth over this topic on 
Openvpn-devel. Thank you all. 

Marvin

> On Apr 1, 2018, at 7:20 PM, Antonio Quartulli <a...@unstable.cc> wrote:
> 
>> On 02/04/18 10:12, Marvin Adeff wrote:
>> Even on the internet I can tell country, ISP etc. Very useful for security 
>> ACLs etc. Unless I’m completely mistaken, I don’t believe this is easily 
>> done in ipv6. 
> 
> mostly because at this very moment Tunnel Brokers are widely used and
> they act as a "proxy", effectively covering the real location of the
> client host.
> 
> Many websites just show you (client) as connecting from the country
> where your Tunnel Broker is located.
> 
> When using native IPv6 this problem does not exists anymore.
> 
> Therefore, the proper way to get over this "limitation" (even though I
> don't think is a real problem, but this is of course my perspective) is
> to speed up the transition and move everybody over native IPv6 (which is
> something we can't achieve if we continue to be "afraid" of using IPv6
> in our everyday life).
> 
> Cheers,
> 
> -- 
> Antonio Quartulli
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Depreciate IPv4-related options.

[Marvin Adeff]

Gert,

Without invalidating the reason for your frustration, I am breathing a sigh of 
relief.

As a complete aside, in some ways ipv4 is actually more useful to me in my 
work. In a private network I can tell where in the network the traffic is 
coming from. Even on the internet I can tell country, ISP etc. Very useful for 
security ACLs etc. Unless I’m completely mistaken, I don’t believe this is 
easily done in ipv6. 

BTW, a big thank-you to you and all the devs in the OpenVPN project!

Marvin

> On Apr 1, 2018, at 12:34 PM, Gert Doering <g...@greenie.muc.de> wrote:
> 
> Hi,
> 
>> On Sun, Apr 01, 2018 at 12:21:53PM -0700, Marvin Adeff wrote:
>> I had not considered the extra work and code required to maintain both 
>> versions. But I get it now. Here is the unfortunate position this puts us in:
> [..]
> 
> Well, that part of my e-mail was a bit of frustration speaking - I've
> been advocating IPv6 for over 20 years now, and while large parts of
> the access networks are offering IPv6 now, other parts are still being
> *built* with IPv4 only, or stubbornly stick to IPv4 only...  thus, double
> work everywhere, not only in OpenVPN, seemingly for a lifetime.
> 
>> So if OpenVPN lost ipv4 support anytime soon, we would be in a world of hurt.
> 
> As far as OpenVPN is concerned, I am not aware of any plans to remove 
> IPv4 support.
> 
> The extra code adds some maintenance and testing effort, but since this
> is all in place now (especially the test setups with "connect over IPv4
> or IPv6" and "send IPv4 and IPv6 packets through the test VPN") it would
> be more work to rip out IPv4 now... :-)
> 
> 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 g...@greenie.muc.de

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Depreciate IPv4-related options.

[Marvin Adeff]

Ok, I’ll only discard the irate part  ;-]

I had not considered the extra work and code required to maintain both 
versions. But I get it now. Here is the unfortunate position this puts us in:

We use OpenVPN for connection from 1000’s of devices located at customer 
facilities back to us. These devices/software have a lifespan of greater than 
10 years and most are extremely expensive (not easily replaced). So a large 
quantity are incapable of ipv6 (and frankly many customer facility networks are 
not fully functional with ipv6). Also some of the devices/software at our end 
that interface with those legacy customer devices are also not ipv6 capable. 

So if OpenVPN lost ipv4 support anytime soon, we would be in a world of hurt.  
There is much more detail about all this, but I wanted to keep this a short 
email. 

Thanks for listening. 

Marvin

> On Apr 1, 2018, at 11:39 AM, Gert Doering <g...@greenie.muc.de> wrote:
> 
> Hi,
> 
>> On Sun, Apr 01, 2018 at 11:19:57AM -0700, Marvin Adeff wrote:
>> Think of us poor mail list lurkers. Practically gave this one a heart 
>> attack!  Not having seen that private reply, I hope that means I can discard 
>> the long-ass (and quite irate) reply I was working on?
> 
> Please share!
> 
>> (Sent from an ipv4 address)
> 
> Whatever journey OpenVPN takes, the Internet as a whole will need to 
> either finish the move to IPv6, or give up and return to IPv4-only -
> running dual-stack is just too expensive in the long run.  Like, twice
> the amount of code needed for routing, address parsing, firewalling, ...
> 
> 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 g...@greenie.muc.de

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Depreciate IPv4-related options.

[Marvin Adeff]

Think of us poor mail list lurkers. Practically gave this one a heart attack!  
Not having seen that private reply, I hope that means I can discard the 
long-ass (and quite irate) reply I was working on?

Marvin
(Sent from an ipv4 address)

> On Apr 1, 2018, at 8:52 AM, Jonathan K. Bullard  wrote:
> 
> Hi,
> 
>> On Sun, Apr 1, 2018 at 11:34 AM, Gert Doering  wrote:
>> Hi,
>> 
>>> On Sun, Apr 01, 2018 at 10:19:37AM -0400, Selva Nair wrote:
 On Sun, Apr 1, 2018 at 2:30 AM, Gert Doering  wrote:
 
 As discussed in trac #208 and on IRC with Antonio, OpenVPN 2.5 will
 be IPv6-only.  Removal of IPv4-related code and options will dramatically
 reduce code complexity, confusing options, bugs and user questions.
>> [..]
>>> 
>>> Nice try :)
>> 
>> Hah, caught in the act ;-)
>> 
>> (Apologies to Jonathan for scaring you about new user support issues...)
> 
> No apologies necessary! I fell for it completely and have no excuse. I
> probably laughed as hard as anyone else when I read your private reply
> that pointed out today's date.
> 
> Best regards,
> 
> Jon
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] options: allow setting default --ca argument value

[Marvin Adeff]

A User's Perspective:
We've been doing just this since ovpn began allowing inline certs. Works great! 
Recommend. 

Marvin

Sent from my iPhone

> On Jan 15, 2017, at 9:53 AM, David Sommerseth 
>  wrote:
> 
>> On 15/01/17 14:52, Pavel Raiskup wrote:
>>> On Sunday, January 15, 2017 11:08:38 AM CET David Sommerseth wrote:
 On 15/01/17 07:17, Pavel Raiskup wrote:
 Adding a new --with-ca-bundle configure option.  It's argument is
 used as default CA file when no --ca option is specified at
 runtime.
 
 This option is primarily designed for systems where users are
 allowed to manage trusted authorities for whole system (in one
 consolidated file; usually implemented in 'ca-certificates'
 package).
 
 Signed-off-by: Pavel Raiskup 
 ---
 configure.ac  | 5 +
 src/openvpn/options.c | 9 +
 2 files changed, 14 insertions(+)
>>> 
>>> As this was mentioned on a Red Hat Bugzilla (bz #1413343 [1]) as well,
>>> I'm reiterating my argument here for closing that bugzilla as notabug.
>>> 
>>> I completely agree with Steffan, this is a NAK.  Such a feature would be
>>> a dreamscenario for The Great Firewall of China and similar national
>>> routing instances which implements complete network surveillance.  It
>>> would make it extremely trivial for them to implement a MITM OpenVPN
>>> server which would affect users not being aware of this issue.
>>> 
>>> This feature would elude users configuring OpenVPN it is no problem
>>> using certificates from public CA issuers.  This is a VERY BAD idea!  We
>>> should help users configure OpenVPN in a secure way by default.  Not the
>>> opposite.
>> 
>> Ack, I originally thought about this as tool to solve "packaging issue".
>> We have corporate-wide authority, and people usually have it stored in
>> bundle.  But I got the point, and such a shame mistake -- there's too many
>> trusted CAs.
> 
> I would recommend seeing the CA file being part of the configuration
> instead of a packaging detail.  And you can embedd the CA inside the
> configuration file ... just do this in the config:
> 
>  
>  -BEGIN CERTIFICATE-
>  
>  
>  
>  -END CERTIFICATE-
>  
> 
> This replaces the 'ca /path/to/ca.pem' line in the configuration file.
> 
> Otherwise, for enterprises doing their own packaging ... it is also
> possible to install the OpenVPN CA file in /etc/pki/ which is easily
> done with RPM files which again can be pushed out through internal
> repositories or Satellite.  The distributed configurations would then
> just need to use 'ca /etc/pki/tls/cert/openvpn-ca.pem'.
> 
> It all depends on how often it is expected to distribute configuration
> files vs how often the CA certificate is renewed.
> 
> 
> -- 
> kind regards,
> 
> David Sommerseth
> OpenVPN Technologies, Inc
> 
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] launch openvpn-gui at windows startup

[Marvin Adeff]

How about a "preferences" file in %Users%\AppData...?  The installer would 
apply whatever basic choices during install (%defaultUser%\AppData). Then  a 
user could set his personal preferences which WinGUI would save to 
%Users%\AppData.

Sent from my iPhone

> On Nov 25, 2016, at 8:39 AM, Selva Nair  wrote:
> 
> 
>> On Fri, Nov 25, 2016 at 10:27 AM, Gert Doering  wrote:
>> On Fri, Nov 25, 2016 at 09:38:31AM -0500, Selva Nair wrote:
>> > Even if the GUI cjecks HKLM and HKCU, toggling the option will not work as
>> > the GUI cannot reset HKLM values. We do not want to be requiring admin
>> > rights to run the GUI and that option becomes "readonly" for the user if
>> > startup is set in HKLM.
>> 
>> How do other packagages handle "this is the system default, but users
>> can change their own setting"?  (So the admin could say "I want this started
>> by default, for all users" and individual users can uncheck this "leave
>> me alone!")
>> 
>> Just thinking aloud, no idea how much effort this is, and whether it's
>> a useful consideration in the first place.
> 
> The installer could enumerate all users and adds the setting to their HKCU's. 
> But its not perfect as new users will not get the setting.
> 
> A more sophisticated approach is to use the "active-setup" feature. I have 
> never used it but its supposed to work like this:
> 
> Installer adds a reg key
> "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed 
> Components\OpenVPNUserSetup" with two values:
> Version = "2.4.1"  <-- update this every install
> StubPath = "some_cmd"  <-- see below
> 
> When the user logs system will check the value of Version and if new, will 
> execute "some_cmd". So we can set som_cmd to just add teh required reg-key in 
> HKCU like this:
> 
> reg add HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run /v 
> "OPENVPN-GUI" /d "path_to_openvpn_gui" /t REG_SZ /f"
> 
> I haven't tested it. For more details see: 
> https://helgeklein.com/blog/2010/04/active-setup-explained/  or google active 
> setup.
> 
> Selva
> --
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] launch openvpn-gui at windows startup

[Marvin Adeff]

Hi,

Power User Perspective:
Please ensure that these [X] selections can be controlled (as in "disabled") if 
openvpn is installed by command line (quiet mode). 

Thanks,
Marvin Adeff


> On Nov 21, 2016, at 11:46 AM, Gert Doering <g...@greenie.muc.de> wrote:
> 
> Hi,
> 
>> On Tue, Nov 22, 2016 at 12:41:24AM +0500,  ?? wrote:
>> should we also start openvpn-gui if "launch gui on windows startup" is
>> selected ?
> 
> I tend to de-couple this - what about a second checkbox "launch gui now"?
> 
> (With both defaulting to [X] checked)
> 
> gert
> 
> -- 
> USENET is *not* the non-clickable part of WWW!
>   //www.muc.de/~gert/
> Gert Doering - Munich, Germany g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
> --
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] p2p topology on Windows

[Marvin Adeff]

I may be wrong, but this sounds suspiciously like what we use Gava's client-nat 
patch for. To enable us to NAT the device's local IP to the one assigned 
dynamically by openvpn (dhcp). 

Marvin

Sent from my iPhone

> On Sep 23, 2016, at 4:21 PM, David Woodhouse  wrote:
> 
>> On Sat, 2016-09-24 at 00:01 +0200, Jan Just Keijser wrote:
>> 
>> sorry for asking, but what's the use case for this?
> 
> The use case for point-to-point? It allows you to use a single IP
> address per client instead of having to set aside a whole /30 subnet
> per client as with the 'net30' mode.
> 
> (And in my case, because some Cisco servers end up being configured
> thus, their own client copes with it under Windows and users were
> complaining.)
> 
>> And you say "configure it with the local IP address" - which address is 
>> that? the address that OpenVPN assigns? or the address of a local 
>> adapter on the Windows host?
> 
> The address that OpenVPN assigns.
> 
> -- 
> dwmw2
> 
> 
> --
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel