SOLVED OpenVPN - TUN / TUN# Device Problem

[brumnas]

Hello,

I'm trying to run the OpenVPN in a jail. It "almost" works ;-)..

My problem: the TUN device number gets _sometimes_ increased, like "tun5" after the jail restart. But not always. As result, the service start fails like:

Code:

Jun 23 11:16:21 tasks openvpn[70584]: TUN/TAP device /dev/tun0 opened
Jun 23 11:16:21 tasks openvpn[70584]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Jun 23 11:16:21 tasks openvpn[70584]: /sbin/ifconfig tun0 10.8.0.1 10.8.0.2 mtu 1500 netmask 255.255.255.255 up
Jun 23 11:16:21 tasks openvpn[70584]: FreeBSD ifconfig failed: external program exited with error status: 1
Jun 23 11:16:21 tasks openvpn[70584]: Exiting due to fatal error

When I'm lucky, the TUN# stays between restarts and I can update the TUN# based on the "ifconfig" output into the openvpn server.conf (like "dev tun5").

I've read quite a lot now and it seems to boil down to new/old TUN kerner driver and persisting the TUN device etc. - but I'm not sure I didn't miss something much easier here, as this seems to be something pretty basic.

The optimal solution would be to have a TUN and not TUN#, so I can just say "dev tun" and not "dev tun8". It actually worked already a few times, when the X in "dev tunX" matched the ifconfing "tunX" number.

Thank you,
Andrej

 

[dlavigne]

How are you starting it now? If by a script, you could add a variable that checks for the tun#.

 

[brumnas]

Thank you, may be it will be my last fallback when failing the "standard" way everyone seems to use, e.g. by rc startup. I have it in /etc/rc.conf like this:

Code:

openvpn_enable="YES"
openvpn_if="tun"
openvpn_configfile="/openvpn/server.conf"
openvpn_dir=”/usr/local/sbin”
cloned_interfaces="tun"
gateway_enable="YES"
firewall_enable="YES"
firewall_script="/usr/local/etc/ipfw.rules"

I've tried of course defining here a static tunX etc. with no success.

What I didn't found: why is restarting the jail increasing this? Is _this_ behavior called "dynamic" TUN? E.g. is what I'm looking for a static/persistent TUN? Strange I didn't find any similar problems on the net :-o. May be I have to create somehow a persistent TUN with a fixed number and somehow use it - that's my feelings after pretty long frustrating research so far. But it seems the static TUN# is needed for using it for user-based routing and that like; and not for just running the "normal" openvpn server.

I've tried "dev tun" in server.conf and "dev tunX", where X was synced with the random tunX from ifconfig. But this worked only a few times (why???).

 

[brumnas]

My further investigations show, that the tunX+++ interfaces are created under the host - when I create another jail and setup a fresh openvpn environment, the tun19 is the first one created. And although this new tunX doesn't come under ifconfig under the host as it comes under the jail, the corresponding /dev/tunX _does_ come; better yet: all of the /dev/tun0...XXX come here listed. So the jail isolation of these is not as nice as I thought.

I also found a link somewhere describing something different, in relation to permissions - but the point was, that the tun interface should be created inside the host and not the jails itself. This would probably give more control about creation and deletion of the useless tun interfaces. But I don't like the idea to use a host-based tun - somehow it stinks for me from the security point of view. I would like to have an isolated openvpn enviro.

Anyhow, I still don't understand where is the problem nobody writes about . My server.config has "dev tun", which does not match the ever-newly-created-on-restart /dev/tunXXX. If everything fails, I will move the whole thing to a bhyve probably..

Anybody with some great insights ;-)? Thank you,
Andrej

 

[brumnas]

My question was answered by Tomik in FreeBSD Networking forum - in the case somebody is searching this as well: the "cloned_interfaces" must be left out from rc.config, against the tutorials I've found. And I had to reboot the host FreeNAS itself to get rid of all the /dev/tunXXX drivers. Bye, Andrej