OpenVPN
Short no net period on a VPN connection
Describe the bug It looks like with the 2.6.4 version there is a short period of time when there is no net after the connection is made. What can be seen from the ping log.
To Reproduce
- Get OpenVPN 2.6.4 installation file from Community Downloads | OpenVPN, install
- Run ping 1.1.1.1 -t in the separate command line window.
- Run C:\Program Files\OpenVPN\bin>openvpn.exe --config "{configFile}.ovpn"
Expected behavior
Stable connection without short no net.
Actual result
Short period of time when there is no net after the connection is made.
Version information (please complete the following information):
- OS: Windows 11 Pro
- OpenVPN version: 2.6.4
The issue is quite important for us. Could you please check it and confirm or deny the problem?
Having a small period of non-connectivity during a VPN setup is not something that is uncommon or unexpected and so far no one has seen it as a problem. So also no one has looked into an issue like this. Why is this such a big issue for you?
FWIW, I can reproduce this on Windows when route to the destination (say 1.1.1.1) is redirected through the tunnel. OpenVPN completes the route setup with no delay, so I guess this is something to do with the way Windows detects routing change. No such delay on Linux.
As the traffic is not bypassing the tunnel, but just getting stalled for a few seconds, this doesn't look critical to me.
@schwabe In our case, the app has additional custom actions right after vpn connect to finalize the connection process. The previous version of openvpn.exe didn't have a small period of non-connectivity like the current one and custom actions worked as expected. It seems we should have an additional delay when the app just waits these 2-3 seconds, which would increase the overall connection process duration. Moreover, it is not clear if is it enough to have just 2-3 seconds or if it may be longer. @selvanair Agree, it is doesn't look critical from the security perspective, but this undocumented feature(or bug?) may bring an additional effort to vpn users, in case they have some automation/action that uses an internet connection.
@schwabe @selvanair Hello, I would like to inform that I also faced this issue on specific 2.6.4 version[Windows machine]. Please investigate this issue on your side, a few seconds delay of no net doesn't sounds critical but it is increases the whole connection process. This behaviour was not detected in your previous versions.
@benass12 If it's caused by a recent change I would be interested in looking into it. Could you point out the latest released version where you have not seen such a delay?
@selvanair I've checked the 2.4.7 openvpn.exe version with TAP driver, works as expected without a delay.
@oblomingo do you see a delay with TAP driver in 2.6.4? If you add "disable-dco" to the .ovpn profile.
@lstipakov No delay with TAP driver ("disable-dco" in *.ovpn config) and 2.6.3 version. It seems it is a problem with the latest DCO (0.9.3) driver. Should I move the issue to https://github.com/OpenVPN/ovpn-dco-win repository?
Not sure if it is a driver issue or userspace code around the driver. I also managed to reproduce it:
Reply from 1.1.1.1: bytes=32 time=12ms TTL=58
Reply from 1.1.1.1: bytes=32 time=13ms TTL=58
Reply from 1.1.1.1: bytes=32 time=13ms TTL=58
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
Reply from 1.1.1.1: bytes=32 time=51ms TTL=58
Reply from 1.1.1.1: bytes=32 time=87ms TTL=58
Reply from 1.1.1.1: bytes=32 time=94ms TTL=58
First part is before connection is established, second is "transmit failed" and the third one is when connection has settled down.
@lstipakov What do mean when say "userspace code around the driver"? I just run two command lines without any extra logic:
devcon install ovpn-dco.inf ovpn-dco
openvpn.exe --config config.ovpn
The problem doesn't seem to be in the dco driver itself, since it can be also reproduced with another driver, wintun. One difference is that with tap-windows6 we use DHCP to assign IP address and with other drivers we use IPAPI.
@lstipakov Oh I see now, thank you. @selvanair Does it look critical for you when we know more about the issue? If yes, are you going to investigate and fix it?
No delay with TAP driver ("disable-dco" in *.ovpn config)
In case of tap-windows you will notice that there is a delay of a few seconds between setting the address and setting up routes. Consequently connection establishment takes that much longer too. In contrast, with wintun and dco where IP is set by IPAPI, there is no such built-in delay. You can emulate a similar behaviour by adding route-delay n to the config. n= 3 to 5 (in seconds) may be enough. It seems Windows takes a few seconds before starting to route traffic through an interface after setting IP.
This route-delay adds a hard delay, so you will have to find an optimal value that is just enough.