jails Issues with 13.3: openvpn in vnet jails

[PMc]

Problem with vnet jails: when running openvpn, the jail cannot be stopped and restarted anymore.

This happens with the current 13.3-BETA1, and I reproduced it on a clean (locally unpatched) 13-STABLE stable/13-n257197-0efd4b792290 GENERIC

Normally, with a vnet jail, the active interface is moved from the host into the jail, and is moved back to the host when the jail is stopped.
But as soon as you start openvpn in that jail (even when only for a moment and without any network connection), then when terminating the jail, the interface will not be moved back to the host and you will loose it.

As a workaround you can manually move the interface back up to the host, with
ifconfig NAME -vnet NN, before terminating the jail.
.
In either case, the jail will stay in the "dying" state and never fully terminate. Apparently something that openvpn does, is damaging the kernel vnet structures in a way that they can not be orderly removed anymore.
This was not the case with 13.2-RELEASE

 

[PMc]

This is now worked on in PR 276862

The problem is with dynamic creation of tun interfaces, i.e.. when you do something like cat /dev/tun42 the tun is automatically created.
With current versions of 13-STABLE when doing this inside a vnet jail, it brings the vnet structure in somewhat disorder, and when later stopping the jail, that vnet will not cleanly disappear.

A practical workaround is to add requred tun devices to "cloned_interfaces", so that the system will precreate them.

 

[ClintBSD]

This is now worked on in PR 276862

The problem is with dynamic creation of tun interfaces, i.e.. when you do something like cat /dev/tun42 the tun is automatically created.
With current versions of 13-STABLE when doing this inside a vnet jail, it brings the vnet structure in somewhat disorder, and when later stopping the jail, that vnet will not cleanly disappear.

A practical workaround is to add requred tun devices to "cloned_interfaces", so that the system will precreate them.

So you add the tun interface to cloned_interfaces on the host? Do you know how to do this manually with ifconfig?

 

[PMc]

Well, there is indeed news to that issue: PR 276862 has been closed due to the creators of the regression not bothering about fixing it.

This is actually a new feature for getting rid of the PRs: people create bug reports because something is broken, then nobody gives a damn about the broken things and the bug reports can simply be closed again.

So you add the tun interface to cloned_interfaces on the host?

No. I add it to cloned_interfaces in the jail.

Do you know how to do this manually with ifconfig?

I'd assume ifconfig create

 

[ClintBSD]

Well, there is indeed news to that issue: PR 276862 has been closed due to the creators of the regression not bothering about fixing it.

This is actually a new feature for getting rid of the PRs: people create bug reports because something is broken, then nobody gives a damn about the broken things and the bug reports can simply be closed again.


No. I add it to cloned_interfaces in the jail.

I'd assume ifconfig create

I just finished upgrading the openvpn application in my vnet jail about a month ago. I am on version 2.6.15 now, I don't remember what the previous version was nor do I recall having this issue on the previous version. I need to reboot the entire system to get it to work again.

I will give your suggestion a go and report back. Another observation is that the jail hangs on stop with:
Stopping jails: ovpnqjail: ovpnq: sh /etc/rc.shutdown: exited on signal 9

I suspect this is to do with the vnet jail not being removed cleanly as you said.

 

[ClintBSD]

I just finished upgrading the openvpn application in my vnet jail about a month ago. I am on version 2.6.15 now, I don't remember what the previous version was nor do I recall having this issue on the previous version. I need to reboot the entire system to get it to work again.

I will give your suggestion a go and report back. Another observation is that the jail hangs on stop with:
Stopping jails: ovpnqjail: ovpnq: sh /etc/rc.shutdown: exited on signal 9

I suspect this is to do with the vnet jail not being removed cleanly as you said.

PMc, I was unable to get my VPN up and running again, when the jail restarts, the routes can't be added by openvpn:
2025-10-13 09:47:08 ERROR: FreeBSD route add command failed: external program exited with error status: 1

Only after I destroy the interface created by cloned_interfaces it is able to create the routes. Did you experience this same issue?

Perhaps you can share your host and vnet jail rc.conf bits related to the tun interface.

 

[PMc]

Hm, I'm currently not really deep inside this matter (nor do I really have time to).

There is no respective config on the host; a vnet jail is a fully standalone node network-wise. The host only brings up the netgraph bridges etc.etc. for jail interconnectivity, before starting the jails.

Then, in the respective jail rc.conf this happens:
cloned_interfaces="tun1 tun3 tun5 tun6"
There is nothing else done with these, they are left to openvpn to configure. (Obviousely the jail's devfs must make them visible).

Then there is a bunch of routes statically from rc.conf, there is another bunch of routes to be engaged when switching certain traffic from one tunnel to another, and also there is a bunch of routes for openvpn to activate after linkup (mainly ipv6 with specific fibs, via external script).

An issue I observe is, when stopping openvpn, it cannot remove it's own routes because now it is chroot. Thats usually not a problem because when bringing it up again, it would just reinstall these same routes.
More serious modifications then would require stop and restart the whole jail.

I was unable to get my VPN up and running again, when the jail restarts, the routes can't be added by openvpn:
2025-10-13 09:47:08 ERROR: FreeBSD route add command failed: external program exited with error status: 1

Probably you shoud try and figure out why exactly that external program fails: figure out what gets called, replace that with an executable shellscript for a test, and log all that happens..

Only after I destroy the interface created by cloned_interfaces it is able to create the routes. Did you experience this same issue?

Not really. If I remember correctly, my issue was that the tun device somehow falls into a gap between jail and host and disappears into limbo, and then after jail stop neither the tun (with that number) nor the jail (whth that number) can be used again until platform rebooted.

Perhaps you can share your host and vnet jail rc.conf bits related to the tun interface.

There is nothing on host.
Only in jail rc.conf is the line as quoted above.
And then in the various openvpn-configs is respective dev tunX.

Then the tun have default route each in a different fib, and ipfw puts the fibs onto the desired packets.