Re: [Openvpn-devel] [PATCH v2] Drop recursively routed packets

[Lev Stipakov]

So, following changes are required for V3:

1) No drop_if_recursive() call for P2P
2) Same for TAP
3) Add an option to disable it

Sounds reasonable?


2016-08-24 16:13 GMT+03:00 Gert Doering :

> Hi,
>
> On Wed, Aug 24, 2016 at 10:12:54AM +0200, Jan Just Keijser wrote:
> > may I suggest to make this configurable,
>
> Well...
>
> > i.e. the user can specify
> > whether rec routed packets should be dropped?  I'm afraid that we might
> > end up with code that drops packets that really should not be dropped -
> > people do weird things with routing: in 99% of the cases in error, but
> > in 1% of the cases because they want to do something funky.
>
> There is no way that this might ever work(*).
>
> If your tunnel gateway is 1.2.3.4, and you send packets to 1.2.3.4 into
> the tunnel, how are these going to arrive?
>
> Packet goes to TUN, is ecapsulated, and sent to 1.2.3.4.
>
> 1.2.3.4 route points to TUN, so packet goes to TUN, gets another layer
> of openvpn, and is sent to 1.2.3.4.
>
> 1.2.3.4 route points to TUN, so packet goes to TUN, gets a *third* layer
> of openvpn, and is sent to 1.2.3.4.
>
> repeat, until the packet hits 1500 byte MTU, and gets fragmented into
> *two* packets that loop forever...
>
> gert
>
>
> (*) it will work if and only if there are multiple routing tables involved,
> that is, packets sent by openvpn itself are not subject to the routing
> tables that would move packets *into* the tunnel - so the Android client
> wouldn't need it (VPN API takes care of this), and with the work on
> Github #13 to suport network name spaces on linux and multiple routing
> tables on *BSD, there are indeed scenarios where this makes sense...
>
> ... so you're right, v3 needs to have an option...
>
> (This started out really small and simple :-) )
> --
> 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
>



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

Re: [Openvpn-devel] Time to change the default cipher?

[Jens Neuhalfen]

Hi

> On Mon, Aug 29, 2016 at 08:45:52PM +0200, Jan Just Keijser wrote:
>> uhoh:  https://sweet32.info/
>> 
>> shall we change the default cipher in the master tree to AES-256 (if not 
>> done so already) ?
> 
> 

[…]

> OTOH, what we could do is: indeed *change+ the default, and add a big fat
> warning ("you have not specified a --cipher directive.  The default has
> been changed from 2.3 to 2.4, so please ensure your config matches the
> other end" or something like that)

This seems like a good idea, maybe like so?

- A “default will change” warning on “2.3” when no chipher is selected
- When used, a “You are using 64 bit block ciphers and this is a bad idea” 
message on 2.3 and 2.4
- AES-256-GCM as new default for 2.4

jens

> 
> gert


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

Re: [Openvpn-devel] [PATCH (master)] Drop gnu89/c89 support, switch to c99

[Jens Neuhalfen]

Hi all,

hopefully this message is not completely garbled by Apple Mail ...

> 
> 
> […]

> 
> Just some more benchmarks.  I just compiled successfully with -std=c99
> on an old Scientific Linux 6.5 (RHEL 6.5 clone) I found.  Another
> important detail, RHEL5 will reach the "End of Production" phase March
> 2017, OpenVPN have generally stopped supporting the oldest RHEL
> releases once it hits EOL.  RHEL 5 subscribers may purchase an
> extended life cycle, but we have not cared too much about that so far.
> 
> […]

I just checked. Extended Support is basically “you can download the old files, 
and maybe we help you” [1], so yes indeed, we can totally ignore RHEL5: 

For versions of products in the Extended Life Phase, Red Hat will provide 
limited ongoing technical support. No bug fixes, security fixes, hardware 
enablement or root-cause analysis will be available during this phase, and 
support will be provided on existing installations only.

[1] 
https://access.redhat.com/support/policy/updates/errata/#Extended_Life_Cycle_Phase

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

Re: [Openvpn-devel] [PATCH (master)] Drop gnu89/c89 support, switch to c99

[Jens Neuhalfen]

Hi all,

hopefully this message is not completely garbled by Apple Mail ...

> 
> 
> […]

> 
> Just some more benchmarks.  I just compiled successfully with -std=c99
> on an old Scientific Linux 6.5 (RHEL 6.5 clone) I found.  Another
> important detail, RHEL5 will reach the "End of Production" phase March
> 2017, OpenVPN have generally stopped supporting the oldest RHEL
> releases once it hits EOL.  RHEL 5 subscribers may purchase an
> extended life cycle, but we have not cared too much about that so far.
> 
> […]

I just checked. Extended Support is basically “you can download the old files, 
and maybe we help you” [1], so yes indeed, we can totally ignore RHEL5: 

For versions of products in the Extended Life Phase, Red Hat will provide 
limited ongoing technical support. No bug fixes, security fixes, hardware 
enablement or root-cause analysis will be available during this phase, and 
support will be provided on existing installations only.

[1] 
https://access.redhat.com/support/policy/updates/errata/#Extended_Life_Cycle_Phase

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