Fails to work after first connection

[facboy]

I haven't got very far with diagnosing this, i'm using ovpn-dco-win 0.7.6 from the releases page, along with openvpn-gui and openvpn3 (built from master, with @lstipakov change to omi.hpp: OpenVPN/openvpn-gui#327 (comment)).

on first connection the VPN comes up fine, but on subsequent connections (ie disconnect, then conect again) it gets stuck Sending PUSH_REQUEST to server... repeatedly and then fails. i can unstick it by disabling the DCO adapter and letting it connect to the same VPN server using the TAP adapter, then the DCO adapter can be re-enabled and will connect, but again, only for the first connection.

i suspect it's not related, but when it is connected i've noticed that the DCO driver seems to set up different routes to the TAP driver - i get a very low metric (2) default route via the VPN gateway, whereas on the TAP driver there is no such route.

[lstipakov]

Could you post connection logs?

[facboy]

After a reboot it seems like it can't even use the DCO device properly, i have to uninstall and reinstall it (i'm using devcon to do this):

ovpn-dco-ioctl_fail.log

Then it seems to work ok on first connect:

ovpn-dco-works.log

Then it times out after you disconnect and try to connect again:

ovpn-dco-timeout.log

Using TAP works fine:

ovpn-tap-works.log

After connecting and disconnecting with TAP, DCO seems to work again:

ovpn-dco-works-after-tap.log

(not shown, but it will similarly time out again if you try to reconnect with DCO).

[lstipakov]

Hi,

• what comes to timeout (Sending PUSH_REQUEST to server...) - like you said this is probably not related to DCO. When you connect to the same server with the same certificate after disconnect, server will send PUSH_REPLY no earlier than 30 sec after sending previous PUSH_REPLY. On the other hard, from the logs you provided the interval between disconnect and new connect is longer than 30 sec. Is this behavior dco specific? Could you reproduce it with tap-windows6?

• I tried to simulate this timeout issue by fast reconnect and stopping server in the middle of PUSH: Received control message: 'PUSH_REQUEST' messages. I got timeout on the client side, however when I started the server I was able to connect without any problems. Is there any chance for me to be able to connect to your server? You could send me profile to [email protected]

• It is hard to say what is the reason for OVPN_IOCTL_NEW_PEER failure - could you run traceview to get logs from kernel module? See instructions here.

Also, thank you for testing dco-win and helping make it better!

[facboy]

kernel module log attached (i hope):

ovpn-dco-win.etl.gz

[facboy]

• what comes to timeout (Sending PUSH_REQUEST to server...) - like you said this is probably not related to DCO. When you connect to the same server with the same certificate after disconnect, server will send PUSH_REPLY no earlier than 30 sec after sending previous PUSH_REPLY. On the other hard, from the logs you provided the interval between disconnect and new connect is longer than 30 sec. Is this behavior dco specific? Could you reproduce it with tap-windows6?

no, i can connect/disconnect/conncet just fine with TAP.

• I tried to simulate this timeout issue by fast reconnect and stopping server in the middle of PUSH: Received control message: 'PUSH_REQUEST' messages. I got timeout on the client side, however when I started the server I was able to connect without any problems. Is there any chance for me to be able to connect to your server? You could send me profile to [email protected]

hum, probably not i'm afraid. i have yet to get on the server to check the logs.

[lstipakov]

I don't see any dco log messages there. Could you try following steps:

• in administrative command prompt, run wpr -start ovpn-dco-win.wprp, that file could be found here.
• connect with dco-win and reproduce the problem(s)
• in administrative command prompt, run wpr -stop log.etl

[facboy]

that's what i did :(. but only for the OVPN_IOCTL_NEW_PEER failure, is that what you meant? or did you mean for the other failures too?

[facboy]

so after reboot i still can't use the DCO device without uninstalling and reinstalling it. i've noticed (from ovpncli) that it logs this message when the connection fails:

Sat Jul 16 08:58:35 2022 TAP ADAPTERS:
guid='{ECE13581-A967-43BC-BB3F-1F1CF9197282}' index=28 name='Local Area Connection'

Open TAP device "Local Area Connection" PATH="\\?\ROOT#NET#0000#{cac88484-7515-4c03-82e6-71a87abac361}\{ECE13581-A967-43BC-BB3F-1F1CF9197282}" SUCCEEDED
Sat Jul 16 08:58:35 2022 Sat Jul 16 08:58:35 2022 EVENT: DISCONNECTED
connect error: TUN_SETUP_FAILED: DeviceIoControl(OVPN_IOCTL_NEW_PEER) failed with code 1
Thread finished

but when it succeeds it logs this:

Sat Jul 16 08:59:57 2022 TAP ADAPTERS:
guid='{67768572-A977-4652-9F52-A0C76FC318A4}' index=28 name='Local Area Connection'

Open TAP device "Local Area Connection" PATH="\\?\ROOT#NET#0000#{cac88484-7515-4c03-82e6-71a87abac361}\ovpn-dco" SUCCEEDED
Sat Jul 16 08:59:57 2022 Connecting to [vpn.mydomain.net]:1194 (1.2.3.4) via UDPv4-DCO

and then goes on to successfully connect. i notice that last part of the path is ovpn-dco when it is working, but the guid when it is not.

i'm installing the device using devcon, is this the wrong approach?

C:\bin\Hardware\devcon.exe install D:\tmp\openvpn\win11\ovpn-dco.inf ovpn-dco

[facboy]

in other news, now i can use DCO with a different VPN server (a work one) it connects and reconnects fine, so it must be something peculiar to the one i was using. let me see if i can set up a dead-end connection that you can test against.

[lstipakov]

Hi,

Sorry for the delay, I was on vacation without access to my laptop.

Before that, white trying to reproduce your issue I found a bug in openvpn3 dco code which in some cases breaks reconnect functionality. Using openvpn-gui with openvpn3 triggered that case. The fix is now merged and pushed to GitHub (OpenVPN/openvpn3@e1a3502) so you might want to take this version (https://github.com/OpenVPN/openvpn3/actions/runs/2609676507) into use.

About the issue you experience. According to logs, adapter GUIDs are different in success / fail case. Could you run this in powershell?

C:\Users\lev> pnputil /enum-devices | Select-String "OpenVPN Data" -Context 1,5

  Instance ID:                ROOT\NET\0002
> Device Description:         OpenVPN Data Channel Offload
  Class Name:                 Net
  Class GUID:                 {4d36e972-e325-11ce-bfc1-08002be10318}
  Manufacturer Name:          OpenVPN, Inc
  Status:                     Started
  Driver Name:                oem50.inf


C:\Users\lev> pnputil /enum-drivers | Select-String "dco" -Context 1,6

  Published Name:     oem50.inf
> Original Name:      ovpn-dco.inf
  Provider Name:      OpenVPN, Inc
  Class Name:         Verkkosovittimet
  Class GUID:         {4d36e972-e325-11ce-bfc1-08002be10318}
  Driver Version:     06/17/2022 0.7.6.0
  Signer Name:        Microsoft Windows Hardware Compatibility Publisher

The way you install the driver looks correct, but you want to make sure that devcon uses the correct version of the driver. You might want to enum existing drivers (as command above does) and remove them (pnputil /remove-driver oemXXX.inf). Alternatively you could install the latest dco driver with the OpenVPN Windows client built from dco branch (https://github.com/lstipakov/openvpn-build/actions/runs/2575026356), that should do the trick.

[facboy]

No problem at all, I took a while to get back to diagnosing it. I did have a couple of old driver versions which I've purged (including a 0.6.5 version), I had to uninstall/reinstall the device again this morning, so this is the output now, after a new install. This time I installed it using the device manager GUI.

PS $> pnputil /enum-devices | Select-String "OpenVPN Data" -Context 1,5

  Instance ID:                ROOT\NET\0000
> Device Description:         OpenVPN Data Channel Offload
  Class Name:                 Net
  Class GUID:                 {4d36e972-e325-11ce-bfc1-08002be10318}
  Manufacturer Name:          OpenVPN, Inc
  Status:                     Started
  Driver Name:                oem93.inf

PS $> pnputil /enum-drivers | Select-String "dco" -Context 1,6

  Published Name:     oem93.inf
> Original Name:      ovpn-dco.inf
  Provider Name:      OpenVPN, Inc
  Class Name:         Network adapters
  Class GUID:         {4d36e972-e325-11ce-bfc1-08002be10318}
  Driver Version:     06/17/2022 0.7.6.0
  Signer Name:        Microsoft Windows Hardware Compatibility Publisher

[facboy]

i need to setup that test server for you, i've been running the latest openvpn3 master for a couple of weeks now and the reconnection problem persists.

on a semi-related note, while trying that out just now i noticed that trying to connection a second VPN config (over DCO) while the first one is still running results in the second VPN taking over the DCO adapter and nuking the original connection without warning - i was kinda expecting it to error out on the second one (like the TAP driver does). is that an openvpn3 issue, a dco issue, or a openvpn-gui issue?

[lstipakov]

Unfortunately at the moment openvpn3 agent doesn't support multiple clients, so this behavior is expected. If you want to use multiple VPN connections simultaneously, you need to use openvpn-gui and openvpn2, which uses "interactive service" as agent replacement, which supports multiple client. You would need to create additional dco adapter for that:

c:\Program Files\OpenVPN\bin>tapctl.exe create --name "dco2" --hwid ovpn-dco
{2941B10A-7C55-44E2-9060-14947A2A1428}

[lstipakov]

Hi @facboy, I think I accidentally (still figuring it out) managed to reproduce IOCTL issue. The workaround would be to pass \\\\.\\ovpn-dco to CreateFile call which opens dco driver handle. I am looking into why this path sometimes (?) is wrong.

[lstipakov]

I believe IOCTL problem should be fixed here: https://github.com/lstipakov/openvpn3/suites/7767498351/artifacts/326654491 Could you please give it a try?

[facboy]

will try to get to it tomorrow. unfortunately it stopped happening after i reinstalled the device using the device manager. i can try removing that and using devcon again to see if that breaks it.

[facboy]

at the moment i haven't been able to get it to happen again, even on the version i'm running atm.

[lstipakov]

I see, thanks. Do you still experience that PUSH_REQUEST issue you've mentioned?

[facboy]

yes, still there.

not strictly related, i am trying to set ovpn3 + dco on a new laptop, and it keeps getting

Fri Aug 26 09:37:05 2022 EXCEPTION
failed to create openvpn process: A required privilege is not held by the client.

in the ovpnagent process when i try to connect (before it even prompts for a password). i seem to recall seeing this before but i don't remember how to fix it.

[lstipakov]

I think you need to install agent as a service - see OpenVPN/openvpn-gui#506 (comment).

[facboy]

the gui log shows some mysterious 'state parameter' error when running as a service (red line in the status windows). it overflows past the end of the window and the whole openvpn-gui crashes almost immediately (0xc0000005) after so i can't tell what it says. this leaves omicliagent.exe running as my user.

interestingly ovpncli client works ok with ovpnagent, even running in the foreground.

[facboy]

ah....i have a feeling this commit is breaking ovpn3: OpenVPN/openvpn-gui@428ee29

i'm not on a machine where i can work on this, but from browsing on github i think ovpn3 doesn't like being sent a "state" command without "on" or "off" etc after it.

EDIT: having downloaded a GHA build from before that commit, it seems to work ok. i can take a look at the code when i'm back next week and submit a PR.

[lstipakov]

I am closing this issue. Feel free to open a new one if you experience issues with dco-win.