Opened 13 years ago
Closed 9 years ago
#141 closed Bug / Defect (fixed)
Cannot restart openvpn more than once per boot if using persistent tunnels and IPv6 payload
Reported by: | rajkosto | Owned by: | Gert Döring |
---|---|---|---|
Priority: | major | Milestone: | release 2.3.8 |
Component: | IPv6 | Version: | OpenVPN 2.3.0 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | testing ipv6 payload persistent misconfiguration add ip |
Cc: |
Description
Basically, when persistent tunnel is enabled, the tun0 device and it's ip addresses will stay when openvpn is stopped. The IPv6 payload patch didn't anticipate that, so when I restart it, I get this:
Wed Jun 1 22:26:47 2011 OpenVPN 2.x-master i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110522-1 (2.2.0)] built on Jun 1 2011 Wed Jun 1 22:26:47 2011 WARNING: You have disabled Crypto IVs (--no-iv) which may make OpenVPN less secure Wed Jun 1 22:26:47 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables Wed Jun 1 22:26:47 2011 Diffie-Hellman initialized with 1024 bit key Wed Jun 1 22:26:47 2011 ******* WARNING *******: null MAC specified, no authentication will be used Wed Jun 1 22:26:47 2011 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1443) Wed Jun 1 22:26:47 2011 Socket Buffers: R=[114688->131072] S=[114688->131072] Wed Jun 1 22:26:47 2011 ROUTE default_gateway=85.17.92.126 Wed Jun 1 22:26:47 2011 ROUTE6: default_gateway=UNDEF Wed Jun 1 22:26:47 2011 TUN/TAP device tun0 opened Wed Jun 1 22:26:47 2011 TUN/TAP TX queue length set to 100 Wed Jun 1 22:26:47 2011 do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=1 Wed Jun 1 22:26:47 2011 /sbin/ifconfig tun0 172.16.0.1 netmask 255.255.255.0 mtu 1443 broadcast 172.16.0.255 Wed Jun 1 22:26:47 2011 /sbin/ifconfig tun0 inet6 add 2001:470:d76b:b055::1/64 SIOCSIFADDR: File exists Wed Jun 1 22:26:47 2011 Linux ifconfig inet6 failed: external program exited with error status: 1 Wed Jun 1 22:26:47 2011 Exiting due to fatal error
This was freshly checked out from openvpn-testing allmerged today and compiled with no parameters (./configure, make, make install)
openvpn --version
OpenVPN 2.x-master i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110522-1 (2.2.0)] built on Jun 1 2011 Originally developed by James Yonan Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net> $ ./configure Compile time defines: ENABLE_CLIENT_SERVER ENABLE_DEBUG ENABLE_EUREPHIA ENABLE_FRAGMENT ENABLE_HTTP_PROXY ENABLE_MANAGEMENT ENABLE_MULTIHOME ENABLE_PORT_SHARE ENABLE_SOCKS USE_CRYPTO USE_LIBDL USE_LZO USE_PF_INET6 USE_SSL
Change History (13)
comment:1 Changed 13 years ago by
Cc: | gert@… added |
---|---|
Owner: | set to Gert Döring |
Status: | new → assigned |
comment:2 Changed 13 years ago by
to make the persistent tunnel, do
openvpn --mktun --dev tun0
then i can use dev tun0 instead of tun
proto udp dev tun0 tls-server ca /root/keys/ca.crt cert /root/keys/server.crt key /root/keys/server.key dh /root/keys/dh1024.pem local SERVERIP port SERVERPORT server 172.16.0.0 255.255.255.0 topology subnet client-config-dir /etc/openvpn/ccd ifconfig-pool-persist /etc/openvpn/ipp.txt #ipv6 stuff server-ipv6 2001:470:d76b:b055::/64 cipher AES-256-CBC #cipher none auth none no-iv yes keepalive 10 30 persist-tun persist-key verb 3 #vpn server is gateway towards ipv4 world push "redirect-gateway def1 bypass-dhcp" #vpn server is gateway towards ipv6 world push "route-ipv6 2000::/3" #networks using this vpn route-gateway 172.16.0.1 client-to-client #behind 172.16.0.101 route 172.16.1.0 255.255.255.0 push "route 172.16.1.0 255.255.255.0" #behind 2001:470:d76b:bo55::1001:1 route-ipv6 2001:470:d76b:bee2::/64 push "route-ipv6 2001:470:d76b:bee2::/64" #behind 172.16.0.102 route 172.16.2.0 255.255.255.0 push "route 172.16.2.0 255.255.255.0" #behind 2001:470:d76b:bo55::1002:1 route-ipv6 2001:470:d76b:da7a::/64 push "route-ipv6 2001:470:d76b:da7a::/64" link-mtu 1464 mssfix 1464 fragment 0
i find it useful because i specify some services to bind on the ipv4 and ipv6 ip of the TUN interface, and they wont bind if tun0 doesnt exist (like if openvpn isnt started when they want to start)
comment:3 Changed 11 years ago by
This is still happening in OpenVPN 2.3.2, since IPv6 payload support is completely native now, maybe take a look into it ?
comment:4 Changed 11 years ago by
Cc: | gert@… removed |
---|---|
Milestone: | → release 2.3.3 |
Version: | git master branch → 2.3.0 |
Yeah. It has not been forgotten, I just had so many other open issues and just too little time :-(
This is actually somewhat more complicated than I initially thought. Of course we could just cleanup at exit (= remove the IPv6 addresses from the interface, which we currently don't do), but wouldn't that confuse the application if it's address goes away?
Looking at tun.c, close_tun() for Linux (about line 1650 in release/2.3 branch) I see that the IPv4 address *is* de-configured on exit - which is why it can be re-configured on the next run. This could be done for IPv6 as well, if it's not interfering with your use case...
Could you paste me a log that shows what OpenVPN is doing for cleanup in your case, anything done between detecting that it should exit (ctrl-c, for example) and the actual program end?
comment:5 Changed 10 years ago by
Milestone: | release 2.3.3 → release 2.3.5 |
---|
Asking again for the log, see last comment
comment:6 Changed 10 years ago by
First startup
root@host:~# openvpn --mktun --dev tun0 Wed Apr 30 10:48:44 2014 TUN/TAP device tun0 opened Wed Apr 30 10:48:44 2014 Persist state set to: ON root@host:~# nano /etc/openvpn/server.conf root@host:~# openvpn /etc/openvpn/server.conf Wed Apr 30 10:49:06 2014 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 27 2013 Wed Apr 30 10:49:06 2014 Diffie-Hellman initialized with 1024 bit key Wed Apr 30 10:49:06 2014 ******* WARNING *******: null MAC specified, no authentication will be used Wed Apr 30 10:49:06 2014 Socket Buffers: R=[229376->131072] S=[229376->131072] Wed Apr 30 10:49:06 2014 ROUTE_GATEWAY SERVERGW Wed Apr 30 10:49:06 2014 ROUTE6: default_gateway=UNDEF Wed Apr 30 10:49:06 2014 TUN/TAP device tun0 opened Wed Apr 30 10:49:06 2014 TUN/TAP TX queue length set to 100 Wed Apr 30 10:49:06 2014 do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=1 Wed Apr 30 10:49:06 2014 /sbin/ip link set dev tun0 up mtu 1403 Wed Apr 30 10:49:06 2014 /sbin/ip addr add dev tun0 172.16.0.1/24 broadcast 172.16.0.255 Wed Apr 30 10:49:06 2014 /sbin/ip -6 addr add 2001:470:d76b:b055::1/64 dev tun0 Wed Apr 30 10:49:06 2014 /sbin/ip route add 172.16.1.0/24 via 172.16.0.1 Wed Apr 30 10:49:06 2014 /sbin/ip route add 172.16.2.0/24 via 172.16.0.1 Wed Apr 30 10:49:06 2014 add_route_ipv6(2001:470:d76b:bee2::/64 -> 2001:470:d76b:b055::2 metric -1) dev tun0 Wed Apr 30 10:49:06 2014 /sbin/ip -6 route add 2001:470:d76b:bee2::/64 dev tun0 Wed Apr 30 10:49:06 2014 add_route_ipv6(2001:470:d76b:da7a::/64 -> 2001:470:d76b:b055::2 metric -1) dev tun0 Wed Apr 30 10:49:06 2014 /sbin/ip -6 route add 2001:470:d76b:da7a::/64 dev tun0 Wed Apr 30 10:49:06 2014 UDPv4 link local (bound): [AF_INET]SERVERIP:443 Wed Apr 30 10:49:06 2014 UDPv4 link remote: [undef] Wed Apr 30 10:49:06 2014 MULTI: multi_init called, r=256 v=256 Wed Apr 30 10:49:06 2014 IFCONFIG POOL IPv6: (IPv4) size=252, size_ipv6=65536, netbits=64, base_ipv6=2001:470:d76b:b055::1000 Wed Apr 30 10:49:06 2014 IFCONFIG POOL: base=172.16.0.2 size=252, ipv6=1 Wed Apr 30 10:49:06 2014 IFCONFIG POOL LIST Wed Apr 30 10:49:06 2014 Initialization Sequence Completed
hit CTRL-C
^CWed Apr 30 10:50:23 2014 event_wait : Interrupted system call (code=4) Wed Apr 30 10:50:23 2014 /sbin/ip route del 172.16.2.0/24 Wed Apr 30 10:50:23 2014 /sbin/ip route del 172.16.1.0/24 Wed Apr 30 10:50:23 2014 delete_route_ipv6(2001:470:d76b:da7a::/64) Wed Apr 30 10:50:23 2014 /sbin/ip -6 route del 2001:470:d76b:da7a::/64 dev tun0 Wed Apr 30 10:50:23 2014 delete_route_ipv6(2001:470:d76b:bee2::/64) Wed Apr 30 10:50:23 2014 /sbin/ip -6 route del 2001:470:d76b:bee2::/64 dev tun0 Wed Apr 30 10:50:23 2014 Closing TUN/TAP interface Wed Apr 30 10:50:23 2014 /sbin/ip addr del dev tun0 172.16.0.1/24 Wed Apr 30 10:50:23 2014 SIGINT[hard,] received, process exiting root@host:~#
Try to start again
root@host:~# openvpn /etc/openvpn/server.conf Wed Apr 30 10:50:47 2014 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 27 2013 Wed Apr 30 10:50:47 2014 Diffie-Hellman initialized with 1024 bit key Wed Apr 30 10:50:47 2014 ******* WARNING *******: null MAC specified, no authentication will be used Wed Apr 30 10:50:47 2014 Socket Buffers: R=[229376->131072] S=[229376->131072] Wed Apr 30 10:50:47 2014 ROUTE_GATEWAY SERVERGW Wed Apr 30 10:50:47 2014 ROUTE6: default_gateway=UNDEF Wed Apr 30 10:50:47 2014 TUN/TAP device tun0 opened Wed Apr 30 10:50:47 2014 TUN/TAP TX queue length set to 100 Wed Apr 30 10:50:47 2014 do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=1 Wed Apr 30 10:50:47 2014 /sbin/ip link set dev tun0 up mtu 1403 Wed Apr 30 10:50:47 2014 /sbin/ip addr add dev tun0 172.16.0.1/24 broadcast 172.16.0.255 Wed Apr 30 10:50:47 2014 /sbin/ip -6 addr add 2001:470:d76b:b055::1/64 dev tun0 RTNETLINK answers: File exists Wed Apr 30 10:50:47 2014 Linux ip -6 addr add failed: external program exited with error status: 2 Wed Apr 30 10:50:47 2014 Exiting due to fatal error root@host:~#
comment:7 Changed 10 years ago by
thanks, this is helpful. Will work on this as soon as time permits (but due to other pressing appointments, this will not be in the next 3 weeks, sorry for that)
comment:8 Changed 10 years ago by
Milestone: | release 2.3.5 → release 2.3.7 |
---|
comment:9 Changed 9 years ago by
Actuall, re-reading this, I'm wondering again.
If OpenVPN removes the IPv4 addresses on exist from the (persistant) tun0, wouldn't those services just fail to bind, and not start either?
Or are you telling the services to bind to "tun0", and they do not truly care about the addresses configured, as long as the interface exists (and will eventually have an address)?
Of course our behaviour should be consistent for IPv4 and IPv6, but I think that our current IPv4 behaviour doesn't really work for your use case ("bind to IP, even if OpenVPN is not running") either...
comment:10 Changed 9 years ago by
Four years and this is still a thing :D
Yes, if i set some service like bind9 to use specific VPN ip to bind to, and it starts before the VPN is up, it will fail to start.
So maybe it would be best to leave all the IPs there, but on startup clear them all out and add whatever new ones would be needed (instead of clearing on exit for ipv4 but not doing it for ipv6 and then failing when we can't re-add on startup).
comment:11 Changed 9 years ago by
Milestone: | release 2.3.7 → release 2.3.8 |
---|
bouncing to 2.3.8 - not forgotten, but we want to get 2.3.7 out and this needs more time
comment:12 Changed 9 years ago by
This is a bit embarrassing... yes, 4 years and still a thing... but a discussion about this happened on openvpn-devel today, and Holger Kummert nicely sent in a patch, so I have no more excuses to stall on this :-)
So, the patch is actually just the straightforward extention of "if we remove the IPv4 address, let's also remove the IPv6 address" - but in the discussion, it also turns out that there is --ifconfig-noexec, which helps the use case "I need the address on the interface to be always there, even if openvpn is not". So you'd do:
# openvpn --mktun tun0
# ip addr add 192.0.2.1/24 dev tun0
# ip -6 addr add 2001:db8::1/64 dev tun0
# openvpn --ifconfig-noexec --dev tun0 ...
which would make openvpn just "leave all addresses on the tun0 alone". Of course the stuff you set up with ifconfig would have to match what openvpn expects to be there...
(A really nice change would be to make openvpn check the addresses that are there, and if needed, change them, and otherwise just leave them alone - but the infrastructure for "check what is there" is currently not existing, so it would be quite a bit of work to get there)
So, here's the patch :-)
commit e5f71d674e3b119d6a252d7cef1c17b5c2b36a9a (master)
commit 40e6c586124e6d7a764b859dad8515998c89c693 (master)
Author: Holger Kummert
Date: Thu Jun 25 18:01:20 2015 +0200
Del ipv6 addr on close of linux tun interface
Acked-by: Gert Doering <gert@…>
Message-Id: <1435248080-12670-1-git-send-email-Holger.Kummert@…>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9810
comment:13 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Well - only thing left to do: close the ticket and rejoyce :-) - will be part of the 2.3.8 release "coming soon".
could you please share your config (without the keys, of course).
I've never used persistant tunnels, so I need to have something to test with.
(Not that I've ever seen the need for a persistent tunnel... normal stuff will
just happily be cleared on disconnect and tunnel close)