Hi, On Fri, Jun 26, 2015 at 12:46:48PM +0200, Holger Kummert wrote: > >So - help me understand the scenario. Why are you using persistant tun > >interfaces but want dynamically added and removed addresses? > > well, I pass the device name on the command line of the call of openvpn > because I need explicit named tun-devices for firewalling purposes > (the firewall on the system also needs to know the name of the device in > use). > So it's created on start of openvpn. > After exiting openvpn the device will be brought down. > > There are no additional services depending on the tun device except > the firewall which is in charge for the device only if the tunnel > is established. > > So the tun device is merely used like a dynamic one, but with a fixed name.
Mmmh. Now I am even more confused.
I assumed you were using persistant tuns because "just" using a named
tunnel ("--dev tun3") should not cause this issue - as the addresses
should nicely go away when the tun3 device is closed and the system
destroys it...
And I actually *do* test for this in one of my t_client test runs... :-)
openvpn --client ... --nobind --comp-lzo --verb 3 --dev tun3 --proto
tcp6-client --remote conn-test-server.openvpn.org --port 51194
--server-poll-timeout 10
... and it "just works" - "ip -6 addr add ... dev tun3" on connect, nothing
special on disconnect, and "no problems" (on Gentoo Linux, but "ip" should
be sufficiently standard):
Fri Jun 26 13:18:05 2015 /bin/ip -6 addr add fd00:abcd:194:1::100c/64 dev tun3
Fri Jun 26 13:18:05 2015 /bin/ip -6 route add fd00:abcd:194::/48 dev tun3
...
Fri Jun 26 13:18:46 2015 event_wait : Interrupted system call (code=4)
Fri Jun 26 13:18:46 2015 /bin/ip route del 10.194.0.0/16
Fri Jun 26 13:18:46 2015 /bin/ip route del 10.194.1.1/32
Fri Jun 26 13:18:46 2015 delete_route_ipv6(fd00:abcd:194::/48)
Fri Jun 26 13:18:46 2015 /bin/ip -6 route del fd00:abcd:194::/48 dev tun3
Fri Jun 26 13:18:46 2015 Closing TUN/TAP interface
Fri Jun 26 13:18:46 2015 /bin/ip addr del dev tun3 local 10.194.1.54 peer
10.194.1.53
So, what is different on your end? Why is the tun<x> keeping its address?
> >(I can see that OpenVPN misbehaves but I'm not sure I understand what
> >"the best" solution should be - maybe go for "if that address is already
> >there, do not touch it, otherwise, remove existing address and add
> >new one" instead?)
>
> Your proposal would probably also do the job. I didn't dive deeply into
> the dependencies
> but just adjusted the behavior of handling ipv6 addresses to the handling of
> ipv4 addresses on the device.
>
> With the provided patch the handling is at least symmetric for ipv4 and
> ipv6 and works in the described
> case (and would also work for the setup as described in trac #141).
Yes, your patch will make it nicely symmetric and solve the issue at
hand (while my approach would need infrastructure that is totally not
there today to find out "what IPv6 addresses are already configured on
interface tun<X>?").
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 :) ).
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-35655025 g...@net.informatik.tu-muenchen.de
pgpZqE6puZJkJ.pgp
Description: PGP signature
