Re: [Openvpn-devel] [PATCH] Del ipv6 addr on close of linux tun interface

[Holger K. <Hol...@So...>]

Hello,

Am 26.06.2015 um 16:36 schrieb Gert Doering:
> Hi,
>
> On Fri, Jun 26, 2015 at 01:24:02PM +0200, Gert Doering wrote:
>> This is more wondering about what we *should* do for persistant tun
>> interfaces...  (and, now, why your tun ifs behave that way even if they
>> are not actually persistant :) ).
>
> Mulling over this for a while, I think I've come to a conclusion on
> "what we should do", and "what we should do in the 'persistant tun'
> case" (#141)
>
>   - normal case: we do "ip addr add" and "delete" - proper housekeeping,
>     and having IPv4 and IPv6 in sync  (so, Holger's patch for Linux,
>     and possible similar additional code for all the other OSes)

I looked at some other OSes in tun.c and found no other with this flaw
at a first glance (other do simply a 'destroy' or 'unplumb' of the 
interface). But probably I oversaw something here.

>
>   - if someone really wants/needs a persistant device (created with
>     "openvpn --mktun --dev tun3" on Linux / "ifconfig tun3 create"
>     on *BSD), and expect it to always keep the addresses on it, they
>     should call "openvpn --ifconfig-noexec".

Yes, this sounds like a good idea to me. Had also something like
"--ifconfig-notouch" in mind, but your proposal is shorter.

>
>     This will then neither add *nor delete* the IP addresses on the
>     interface (of course, in that case you need to run the ifconfig /
>     ip addr statements manually before starting OpenVPN, or from an --up
>     script which can then choose to just ignore the error if the address is
>     already there).  So this would cover the case "I want <daemon x> to
>     listen on my tun device, but it cannot rebind if the interface goes
>     away".
>
> Simple and pragmatic enough?

I second this proposal, and it would solve a long outstanding bug.


Holger

>
> (Having OpenVPN check addresses for persistant tun interfaces, and only
> add them if needed, and actually *change* them if needed would be a cool
> thing to have, but we have no infrastructure yet to do so)
>
> gert
>