phantom issue with tunnelblick tap connection

[nix]

Hi,
I’m encountering a recurring issue with Tunnelblick when using TAP, and I wonder if anyone has dealt with something similar.
The problem manifests as follows:
The routes remain intact.
DNS servers are still configured correctly according to the system settings.
No resolve for any resource by nslookup.
The traceroute does not reach the gateway.
The session is still active in the Tunnelblock client, but there are literally no events in the Tunnelblick, VPN server, or corporate firewall.
The connection restores itself after a minute or two without intervention, but I can also force a reconnection manually. This occurs intermittently on around 10% of devices, across various macOS versions (from 12 to 15), and different client versions (from 3.8.2 to latest beta).
Everything seems to indicate a local issue, but I haven’t found any logs that could explain it.
So far, the only idea I have is to timestamp when the pings fail and start digging into that specific moment in the console for any events.
Do you have any suggestions on other debugging methods or logs I might be overlooking?
Thanks in advance for any help!

[nix]

I would also like to mention that the DNS servers are working okay. When we try to use a different protocol like Forti, it works as stable as you can imagine.

понедельник, 7 октября 2024 г. в 21:34:20 UTC+3, nix:

[nix]

I found a way to reproduce the issue. You need to execute the following commands:

ifconfig tap0 down;  ifconfig tap0 up

This way, the client does not detect the disconnection, and the session remains active. I tested affecter user's config on a completely clean macOS, and the problem persists. How can I determine which factors influenced the status of the tap0 interface?

понедельник, 7 октября 2024 г. в 21:48:29 UTC+3, nix:

[Tunnelblick Developer]

Please post the diagnostic info obtained by following the instructions at Read Before You Post.

You should modify the instructions to get the VPN up, then do tap0 down and tap0 up to reproduce the problem, wait for the reconnection (you said it takes a minute or so), then disconnect, then get the diagnostic info.

[nix]

Hello again

1) I found out that switching tap0 reproduces only the symptoms of the problem and not the problem itself, which I originally described, so I do not use it as a way to reproduce, however, it is worth noting that when tap0 is turned off, all routes are deleted and the client does not notice this, I do not know if this can be considered a bug :)
2) I attach a log, replaced the asterisks with information that may be sensitive
3) the problem occurred at about 17:00-17:02, access to resources and dns resolve disappeared, and then, as I described, it was restored on its own, there is nothing in the logs for this timestamp
4) this log uses the old version of mac os and the client, but I assure you that in the latest beta of the client and any versions of macos, this is reproduced

just in case, let me remind you that we tested a completely clean version of mac os sonoma restored via dfu, as well as macos sequoia also restored via dfu

link for the log - https://drive.google.com/file/d/1yeVxW1z2ZSo8HfrP25z3qjnt5c00tuSw/view?usp=sharing

idk how to attach txt file to this discussion

четверг, 10 октября 2024 г. в 00:02:47 UTC+3, Tunnelblick Developer:

[Tunnelblick Developer]

Thanks for providing the diagnostic info.

The only unusual thing I see is that "Run MTU maximum size test after connecting" is checked in the "While Connected" tab of Tunnelblick's "Advanced" settings. That is a Tunnelblick setting which causes OpenVPN to run a test with different packet sizes. I doubt that's causing the problem because the test ended at 16:53:33, which is long before the problem occurred. However, there is ordinarily no reason to run the test, so I recommend un-checking the checkbox and seeing if the problem still occurs.

I don't see anything else that is unusual or would explain the problem. There's no indication that Tunnelblick detected a change to the network configuration, which is a common cause of problems like this.

[nix]

we tested the mtu parameter as part of the problem diagnosis, tried manually setting different values (less and more than the standard one) and also turning it on and off in the client, this does not affect in any way

perhaps you know what events can be viewed in the system log for debugging? what other diagnostic methods are there?
there is no traffic at all on the corporate firewall at such moments, the trace from the server does not show packets from the client, so I assume the tunnel is actually tearing from the client side but without logs

пятница, 11 октября 2024 г. в 19:46:40 UTC+3, Tunnelblick Developer:

[Tunnelblick Developer]

Sorry, but aside from using Wireshark on the client I don’t have any other suggestions.