Tun device seems to randomly change upon connection?

[HybridZach]

Been using openvpn3 for a good while now and its been fine, however lately I have noticed something strange.
When I connect (and this seems to only happen when I initially connect), it will connect fine on tun0, but sometimes work for a bit (like I will be able to open websites and have traffic flow (other times it will not even let me communicate because it will be in the process of switching to tun1 already)) but then seemingly randomly it will change it to tun1. This poses an issue for me (and it could be due to my firewall set up this is happening in the first instance). I can only communicate over tun0 because of the way I have my firewall set up, when it switches randomly to tun1 my firewall blocks the communication.

Is there a way to help diagnose why this is happening, and or an intended feature of some kind?

I have tried to make sure its not a conflict, like make sure there is no old connections on tun0 still, but its not that, it just seems to randomly decide to switch to tun1 most of the time when connecting.

I am using the command openvpn3 sessions-start --config #CONFIGHERE is there a way to force tun0 only?

If I connect and it switches to tun1, using openvpn3 session-manage -I tun1 -D then reconnecting will always make it work again on tun0 it seems every time, so I think something strange is happening here I am not aware of.

[dsommers]

Hi,

This is an expected behaviour, actually. It is the only way to ensure network traffic expected to be routed via the VPN does not leak when there are connectivity issues with the VPN link. The old approach was to tear down the tun interface, create it again and then setup up IP addresses and routing. This had the potential of leaking network traffic via your default gateway in the time window the VPN IP address and routes were not present on your system; they disappears when the network interface is removed.

In OpenVPN 3, when there is a connectivity issue and a full reconnect is required, a new tun interface is created and configured and then the old interface is removed. The problem here with this approach is that the new tun interface cannot have the same interface name as the old one. Hence the device name change.

I would recommend you to use --dev tunA in your configuration file (or if you want to go more fancy, use --dev vpnA --dev-type tun). This should create an interface tunA0 and tunA1. Your firewall rules, like iptables, can then use wildcards in the interface name ... like -i tunA+.

However, it is generally considered even better and more flexible to not be dependent on device names themselves, but rather do the firewall filtering based on subnets instead. But I do see that there are use cases where this might not be as easy - like when forwarding traffic from the public Internet.

[HybridZach]

Just a quick update, I have tried a bunch of times to reproduce this issue, for some reason it is just not doing it anymore. I just now thought it may be because of me adding tun1 to my firewall, but I removed that and restarted and still, it is connecting just fine.

However, I will still keep trying to reproduce it and tell you the logs when it does happen next, and I am going to keep tun1 out my firewall for now to see if that triggers it from happening again.

[HybridZach]

Update.
After quite some time of it working perfectly, it finally reproduced the issue I was having before.
I believe this issue only occurs when connecting via my GUI (this uses python os.popen())
I finally was able to grab some logs of what happens when it flakes out.

Initially today it worked right away, and I had data and it was letting me communicate seemingly okay, but after a short while it made everything hang, then suddenly nothing communicates. So then I tired to quickly scramble to enable the log things and caught this stuff for you. (I hope it helps, and I hope its okay me omitting some IPS and stuff).

If I am not mistaken this is the issue?
Session invalidated: KEEPALIVE_TIMEOUT

I have attached the log file - log.txt
...I made with all the verbose information.

LMK if there is anything else you need me to do to help diagnose this.

[dsommers]

KEEPALIVE_TIMEOUT means that the client lost connection to the server; the link between the client and server broke down. And the connection was re-established by reconnecting to the server. This will trigger a new tun interface to be created when the reconnection starts. So this is all just as expected.

[HybridZach]

Hmm fair enough. So it is an issue on the VPN providers side I assume?, I have not gotten the issue again today. This time it happened switching VPN servers, so it could be that the server was experiencing issues maybe IDK. Thank you for your continued responses and assistance. If I get it again and its different in the logs I will keep you updated.

[dsommers]

Hard to say without seeing server logs. It can be a server side issue. And it can be general network issues between your local side and all the way to the server side, so anything from general routing issues, network outages as well as some networks having strict NAT rules which times out too quickly.

[HybridZach]

I think its safe to say I no longer experience what ever it was that was causing this issue. Thanks for your time in replying and helping diagnose this. Its safe to say it's an issue on my end not the software.