search

OpenVPN / openvpn

OpenVPN is an open source VPN daemon
http://openvpn.net
Other
11k stars 3.01k forks source link

Short no net period on a VPN connection #343

Open oblomingo opened 1 year ago

oblomingo commented 1 year ago

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

  1. Get OpenVPN 2.6.4 installation file from Community Downloads | OpenVPN, install
  2. Run ping 1.1.1.1 -t in the separate command line window.
  3. Run C:\Program Files\OpenVPN\bin>openvpn.exe --config "{configFile}.ovpn"

Expected behavior Stable connection without short no net. success

Actual result Short period of time when there is no net after the connection is made. fail

Version information (please complete the following information):

oblomingo commented 1 year ago

The issue is quite important for us. Could you please check it and confirm or deny the problem?

schwabe commented 1 year ago

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?

selvanair commented 1 year ago

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.

oblomingo commented 1 year ago

@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.

benass12 commented 1 year ago

@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.

selvanair commented 1 year ago

@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?

oblomingo commented 1 year ago

@selvanair I've checked the 2.4.7 openvpn.exe version with TAP driver, works as expected without a delay.

lstipakov commented 1 year ago

@oblomingo do you see a delay with TAP driver in 2.6.4? If you add "disable-dco" to the .ovpn profile.

oblomingo commented 1 year ago

@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?

lstipakov commented 1 year ago

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 commented 1 year ago

The same (transmit failed) behavior is with windows-driver wintun.

oblomingo commented 1 year ago

@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
lstipakov commented 1 year ago

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.

oblomingo commented 1 year ago

@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?

selvanair commented 1 year ago

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.