OpenVPN 2.6.8 client does not detect tunnel interface status

[adityavik]

IMPORTANT NOTE
OpenVPN 2.6.8 running as client does not detect tunnel interface status , hence leaks the traffic.

Describe the bug
I am using 2.6.8 client (binary running on MacOs) and 2.6.8 server (running on Linux). I have built both of these binaries. In this case only tunnel interface on the client side is down but internet connectivity to reach out to server is good. I manually shut down the tunnel interface which led to deleting the routing entries pointing to tunnel interface (expected) . My understanding is that ping packets (in built feature of openVPN) do not use client side tunnel interface and openVPN client software stack will prepare a packet and apply encryption and push it out to server , response will also terminate to openVPN software only hence looks like tunnel interface is not being used for this . I was expecting openVPN client side software would detect tunnel interface status and reestablish the session to avoid the traffic leak.

To Reproduce

1 - Built and run 2.6.8 server on Linux.
2- Built and run 2.6.8 client on MacOs.
3- Connect and establish session , as part of this on Macos tun interface is created.
4- Manually shutdown the tunnel interface on MacOs.
5- OpenVPN client does not detect that tun interface is down and ping packets continues to work, please note these packets are between openVPN client and server (not the application using VPN)

Expected behavior
Expectation is that openVPN client should detect that interface is down (VPN routes are deleted) and should trigger reestablishing the connection or terminate the connection.

Version information (please complete the following information):

• Client OS: MacOs Ventura
• Sever OS - Linux
• OpenVPN version: 2.6.8

Additional context
Add any other context about the problem here.

[cron2]

"manually shutting down the tunnel interface" is not an error condition handled by OpenVPN, and we do not intend to handle this.

(Same thing as "manually removing routes and then complaining that packets to these routes do not go into the tunnel interface").

Both conditions can only be detected by adding code to monitor routing table activity while the connection is active, and this is highly system specific (= MacOS code won't work on Linux, etc.) and quite a bit of work to implement and test.

[adityavik]

I agree that routing table can be manipulated in a way that would leak the traffic and this is outside the scope of openVPN. I was expecting openVPN to detect the state of tunnel interface, also health check to cover the tunnel interface as well , current health check seems to be shallow and does not really cover tunnel interfaces. I am not system expert so I just used simple method (manually shutdown) , not sure if there are other ways to inject the same fault but that's not the main issue here. Looks like this is expected behavior.

[cron2]

There is no way to determine "tunnel interface has been shutdown" from within OpenVPN (except "no more packets are coming in", but that could be perfectly normal). The operating system will not signal to OpenVPN, and there is no way to do "a health check".

But this all does not really matter - this sort of manipulation can only happen if a user with superuser privileges messes around while OpenVPN is running. In that case, if that user is malicious, security of the system is compromised and "the tun interface is no longer active" is the least of your worries.