After last changes to tun device in stable/12, security/vpnc is unable to destroy its tun device on exit. service vpnc stop leaves ifconfig tun0 destroy process in D state.
Manual attempt to destroy tun device hangs as well.
Reverting if_tun.c back to r345285 restores expected behavior.
This looks similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238500
Created attachment 208067 [details]
svn(1) diff against the ports tree
Please try the attached patch- it had the same issue as net/ocserv in that the forked child didn't do the tunnel hand-off properly.
Indeed, the patch works.
Thank you, Kyle!
This might fix it for people running stable/12 but will break it for everyone on a lower version.
There should be at least some version handling in the code. Can you pinpoint the change that caused the breakage?
No, there should be no breakage. TUNSIFPID has existed for about 20 years and is technically how this should have happened all along. It will do no harm in earlier branches (except now ifconfig output will now reflect actual pid using the tunnel)
Unfortunately I do not have any accounts to test this with. I've just released maintainership of this port. Assign bug back to queue.
Hi Kyle Evans,
I had the same problem. Couldn't destroy the tunnel interface, and everytime I re-started vpnc it would increment a new tunnel name (tun4, tun5, tun6 etc...). This would break my firewall and nat rules.
I have confirmed this patch works on my custom setup on OpnSense running the following:
OpenSSL 1.0.2s 28 May 2019
I guess I'm taking it, now that it's unmaintained. =-)
I did relax the misbehavior in head because software's not quite ready for it. I'd still like to commit this, because I turned it into a syslog message nagging that the tun was ultimately closed by not-the-controller.