If OpenVPN crashes instead of exiting orderly (for example after hitting the --multihome --proto tcp bug) the kernel side tunX interface is kept around. On OpenVPN restart, OpenVPN will just allocate the next one, but routing is all messed up (same IP subnet configured on both tun interfaces), so it looks like it should be working but it isn't, and this is hard to diagnose ("openvpn log is all good").
tun(4) interfaces autodestruct on all platforms today (unless explicitly created in a persistent way), and so should dco(4) interfaces.
(We've discussed this in the past, and I thought I convinced you, but it seems the change still did not happen...)
If OpenVPN crashes instead of exiting orderly (for example after hitting the
--multihome --proto tcpbug) the kernel sidetunXinterface is kept around. On OpenVPN restart, OpenVPN will just allocate the next one, but routing is all messed up (same IP subnet configured on both tun interfaces), so it looks like it should be working but it isn't, and this is hard to diagnose ("openvpn log is all good").tun(4) interfaces autodestruct on all platforms today (unless explicitly created in a persistent way), and so should dco(4) interfaces.
(We've discussed this in the past, and I thought I convinced you, but it seems the change still did not happen...)