On Wed, May 06, 2009 at 03:21:16PM -0400, Mark Shroyer wrote: > On Wed, May 06, 2009 at 11:20:43AM -0400, 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? > > Weird. I ran an OpenVPN server on my OpenBSD gateway until just > recently, and I'm 98% sure that it never did this to me. Are you > specifying both "dev-type" and "dev" in the VPN configuration?
I'm specifying "dev tun0". Per the openvpn(8) man page, dev-type should only be used "if the TUN/TAP device used with --dev does not begin with tun or tap". Were you actually using altq on your tun device? > Actually, that's one thought... are you sure that the "dev-type" > setting in your OpenVPN configuration file and the configuration of your > tun(4) device are either both as tun or both as tap? One of the things > that caught me off-guard about setting up OpenVPN on OpenBSD is that > OpenBSD's tap interfaces are actually called "tunX", they just have the > link0 flag set. (So you could properly end up with, e.g., "dev-type > tap" and "dev tun0" in your OpenVPN configuration.) Could be that if > OpenVPN expects one type of device but gets the other, it automatically > destroys and replaces it... As mentioned, "dev-type" is unnecessary. We have no problems with this configuration other than OpenVPN destroying the device at runtime which causes the file-descriptor to change, confusing pf/altq. Thanks, -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
