openvpn: proto handler

[systemcrash]

📦 Package Details

Rewrite openvpn scripts as a proto handler.

I want to get some initial feedback from openvpn users and catch any behaviour changes. If you must use DEPRECATED options, add the flag option allow_deprecated '1'.

Put the proto handler script in /lib/netifd/proto/, chmod +x and graft your openvpn config into /etc/config/network:

e.g. openvpn config

config openvpn 'test'
	option ...

becomes network config

config interface 'test'
	option proto 'openvpn'
	option ...

ping @egc112

---

🧪 Run Testing Details

• OpenWrt Version: 25.12-snapshot
• OpenWrt Target/Subtarget: x86_64

[egc112]

I added your PR to my build and I can see that it tries to convert my existing OpenVPN.

However I have

Unsupported protocol type
Install protocol extensions

lib/netifd/proto/openvpn.sh is present
When i just tried to execute it I got:

./openvpn.sh: line 189: add_protocol: not found

Unfortunately I have very little time this week to research it further :(

[systemcrash]

However I have

In the UI? Yes - of course. That part's still cooking. Then everything is as it should be.

You don't execute the proto handler yourself - netifd calls it - simply just issue a service network restart and it brings your tunnels up.

[egc112]

However I have

In the UI? Yes - of course. That part's still cooking. Then everything is as it should be.

You don't execute the proto handler yourself - netifd calls it - simply just issue a service network restart and it brings your tunnels up.

Sorry for my delayed response, I did not use the GUI to create it , I did that manually according to this PR but was thrown off by the unsupported protocol and had no time to investigate further.

I can now confirm that openvpn is started and a tunnel is established, only thing is I get a duplicate config on the command line:

root@MT-6000:~# ps | grep [o]penvpn
15547 root      8436 S    openvpn --dev-type tun --cd /etc/openvpn --status /var/run/openvpn.proton_nl_09.status --syslog openvpn_proton_nl_09 --config /etc/openvpn/proton_09.ovpn --config /etc/openvpn/proton_09.ovpn

It does however work and pinging through the tunnel is also OK

root@MT-6000:~# ifconfig tun1
tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.16.0.13  P-t-P:10.16.0.13  Mask:255.255.0.0
          inet6 addr: fe80::9315:86ae:91ee:784f/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:4284 (4.1 KiB)  TX bytes:2848 (2.7 KiB)

root@MT-6000:~# ping -I tun1 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=118 time=16.154 ms
64 bytes from 8.8.8.8: seq=1 ttl=118 time=16.047 ms
64 bytes from 8.8.8.8: seq=2 ttl=118 time=16.982 ms

root@MT-6000:~# cat /var/run/openvpn.proton_nl_09.status
OpenVPN STATISTICS
Updated,2026-02-11 11:22:06
TUN/TAP read bytes,2020
TUN/TAP write bytes,2772
TCP/UDP read bytes,10280
TCP/UDP write bytes,5823
Auth read bytes,2852
pre-compress bytes,0
post-compress bytes,0
pre-decompress bytes,0
post-decompress bytes,0
END

Anything else you want me to test?

[egc112]

I am also looking into PBR.

I added the device to the network config of openvpn:

config interface 'proton_nl_09'
	option proto 'openvpn'
	option config '/etc/openvpn/proton_09.ovpn'
	option device 'tun0'

I noticed that network_get_device from /lib/functions/network.sh is not working yet.
It would be nice if we could add a device, which is used by OpenVPN, to the interface config e.g. tun0 which could then be queried with network_get_device

[systemcrash]

That's great. Thank you @egc112. I fixed the duplicate --config thing after you downloaded it. The device portion is a bit more tricky. A tun only makes the device at up time. And only some taps are available before the tunnel comes up. So I'm not certain how to reconcile this unless I blacklist the --dev-type parameter and enforce it based on the presence of an underlying and already present device. That can go in a future version, since it never existed in the procd script.

In the UI I have, it's possible to name the --dev, so there's something predictable for pbr to use, at least. Maybe @stangri can give me a high-level overview - does it hook into netifd events? Or does it just mandate stable presence of an interface?

Maybe just the hotplug script is enough.

Otherwise I don't think network_get_device returns anything interesting for an openvpn interface. What does yours show for an ovpn tunnel when you do ubus call network.interface dump?

[egc112]

As tun only makes the device at up time. And only some taps are available before the tunnel comes up

Yes I am aware of this and PBR deals with this at the moment in the following way:
The user ads an interface with proto none and device the same as the device used in the openvpn config.

So in the old way an interface is made with the device according to the openvpn config:

config interface 'proton_nl_09'
	option proto 'none'
	option device 'tun1'

The device can be read with network_get_device and that is what PBR is using now

I tried it in the new interface like this:

config interface 'proton_nl_09'
	option proto 'openvpn'
	option config '/etc/openvpn/proton_09.ovpn'
	option device 'tun1'      <<<<< Added

My hope was that this could also be read back with network_get_device, at this moment that is not working.

But adding a Device entry box with text that it should mimic the device in the openvpn config and make it so that network_get_device will show the device entered in the config would be really helpful , not only for PBR but possible also needed for the Firewall?

If that of this is not possible or feasible then we can still use the old way just adding an other interface with proto none and adding the device according to the openvpn config like we are doing now

I already pinged Stan about it :)

[systemcrash]

Did you restart the tun/iface after this?

option device 'tun1' <<<<< Added

I think netifd needs this device to exist. So for tuns and taps with no dev...

use the old way just adding an other interface with proto none and adding the device according to the openvpn config like we are doing now

That's what it looks like we should do so netifd and proto layer stuff works out. An interface which points to an interface/dev :) (plus maintaining this behaviour isn't a bad thing, if users are already familiar with this modus operandi)

[systemcrash]

ping @GeorgeSapkin for initial comments

[egc112]

Did you restart the tun/iface after this?

Yes I did but the device is not reproduced with network_get_device

But no big deal, the old way still works 🙂

[egc112]

Just tested your latest changes and everything is working, thanks 👍

[systemcrash]

Great. I have a UI which you can also test once I get some other fixes out...

[feckert]

Good work. But a silly question without me looking into the source in more detail. What about the server side? My openwrt router acts as a server and my clients are connected to it via the internet. Is that still possible with this protocol?

[egc112]

Nice, will test it again the coming days.

About all the options why not do it with only the most important options available in the GUI and then add a text box where users can add openvpn option in OpenVPN style which will be added as is to the config that way, then you have the best of both worlds, most other firmwares I know do it this way.
I never use the options I just have my own openvpn config file must easier and consistent 😉

[systemcrash]

Good work. But a silly question without me looking into the source in more detail. What about the server side? My openwrt router acts as a server and my clients are connected to it via the internet. Is that still possible with this protocol?

@feckert yes, it is. Everything continues to work. netifd manages the process lifecycle.

@egc112 that's what I thought. Alas, everyone needs something different.

[systemcrash]

OK - all set. If you're happy @feckert we can get this in for 25.