On Wed, May 06, 2009 at 11:14:21PM +0400, Vadim Zhukov wrote: > On Wednesday 06 May 2009 21:39:15 Jason Dixon wrote: > > On Wed, May 06, 2009 at 08:48:06PM +0400, Vadim Zhukov wrote: > > > On Wednesday 06 May 2009 19:20:43 Jason Dixon wrote: > > > > So apparently OpenVPN is a douche of an application by > > > > destroying/recreating any tun devices you ask it to bind to. This > > > > causes havoc with pf/altq if you queue on those tun interfaces. > > > > > > > > I've asked on the openvpn-users mailing list if there's any way to > > > > have OpenVPN avoid teardown of an existing tun(4) interface but > > > > nobody had any useful answers (besides "use the up/down > > > > scripts")... yeah, thanks. Has anyone here used OpenVPN in server > > > > mode and overcome this? > > > > > > See "persist-tun" option. > > > > This only affects restarts, not the initial startup. > > The idea is that you pre-create tun device (possibly in startup script, > or in /etc/rc.local) and then OpenVPN uses it.
You're missing the point. I create the necessary tun devices at boot with hostname.tun* so that we get no pf/altq load errors. But as soon as OpenVPN runs from rc.local, it destroys the tun device and recreates it. This breaks altq because the file descriptor (/dev/tun*) changes. Having OpenVPN create the tun device does me no good. I'd still have to re-load pf/altq after the file descriptor is created. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
