OpenVPN DCO error

[mihaifpopa]

Hi there. When configuring an OpenVPN DCO server instance, I get these errors in the logs:

Cannot open TUN/TAP dev /dev/ovpn1: No such file or directory (errno=2)
Exiting due to fatal error.

Any idea what's going in?
Thanks!

[franco]

Can you give more context? What system did you install and what have you updated it to? The development version on 24.1.x for example will offer DCO but the FreeBSD 13 kernel doesn't know it.


Cheers,
Franco

[mihaifpopa]

Sure, sorry for not giving more context from the start.

So, I clean installed 24.7-BETA (which seems to be FreeBSD 14.1) on a Lenovo M920s (i3-8100, 8GBRAM, 128GB SSD, i350-T2) directly, so, not virtualized. Have done some configuration, one of which was setting up OpenVPN and I directly set it up with DCO (experimental). I have followed this how-to on how to set it up, but on the type, I selected DCO: https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html.

I also went through and upgraded to RC1 and then RC2, but still seems to not work. When switching to TUN, for example, the OpenVPN service starts normally. Instead, when setting the type to DCO, it crashes with the error I mentioned.

Thanks!

[Patrick M. Hausen]

OPNsense does not run on Linux so neither modprobe nor mnod exist.

[mihaifpopa]

So, might this be a bug? Or maybe I have set up something wrong?

[franco]

@Patrick I think you fell for a Chat GPT spam bot

@mihaifpopa looking at it now, something is not right

[newsense]

So, might this be a bug? Or maybe I have set up something wrong?

Bugs can be squashed, incompetent devs not so easily...

Looks like Franco built a kernel for you to test.

Code: [Select]

opnsense-update -zkr 24.7.r2_3

[franco]

My fault for trying to rectify the weirdest anti-pattern design choices leading to message-less hardcoded OpenVPN daemon code:

https://github.com/OpenVPN/openvpn/blob/37b696a207548df88fe65aa130fe6d522e7ce920/src/openvpn/dco_freebsd.c#L616

What amazes me is that OpenVPN devs go all the way to pass dco_available(int msglevel) but then one simply doesn't use it at all for logic that potentially breaks the whole use case silently.

The latest kernel will indeed unbreak it and so 24.7 is going to be fine (given the circumstances).


Cheers,
Franco

[mihaifpopa]

Will test it later today. Thanks a lot!

[mihaifpopa]

Yep, it doesn't crash anymore when I switch to DCO (experimental), although when I'm trying to connect with a client to the OpenVPN DCO server, it just errors out with "problem with tun vs tap setting" error. Tried reinstalling OpenVPN on the client machine, but still doesn't work. I'm guessing a configuration issue? Is this link accurate for DCO setup as well? https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html

Thank you!

[newsense]

24.7 is just around the corner will bring OpenVPN 2.6.12, probably best to wait for it.

Unsure if it will "magically" fix the issue or not, so I'd recommend opening a Github ticket for tracking this - referencing this thread - as it may require further troubleshooting on the OPNsense side too.

[mihaifpopa]

Managed to fix it by setting dev tun instead of dev ovpn in the client config file. All seems to be working fine. Still have to tweak MTU, but looking good. Thanks for your help, @franco and @newsense!

[franco]

Funnily enough OpenVPN doesn't care about "ovpn" and you do set "tun" as always.

You actually can set disable-dco if you don't want it (when it is supported and would apply to your config).

The downsides of this approach is that it may turn off silently and you can't force it and not get a useful error out of OpenVPN that DCO is not working for whatever reason.


Cheers,
Franco

[mihaifpopa]

@franco: What I mean is that when doing the client export from OPNsense, it automatically exports with "dev ovpn" instead of "dev tun" when creating an OpenVPN server instance. Maybe an improvement can be made so it automatically goes with how it adds on the TUN type, "dev tun". Maybe it's just a bug? At least, that's how I understand it.

[franco]

You're right. Can you try this commit and re-export? https://github.com/opnsense/core/commit/228ccc072

# opnsense-patch 228ccc072


Thanks,
Franco