You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...)
The text was updated successfully, but these errors were encountered:
If OpenVPN crashes instead of exiting orderly (for example after hitting the
--multihome --proto tcp
bug) the kernel sidetunX
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...)
The text was updated successfully, but these errors were encountered: