Bug 241039 - security/vpnc can not destroy tun device on exit
Summary: security/vpnc can not destroy tun device on exit
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Kyle Evans
Depends on:
Reported: 2019-10-03 15:45 UTC by Hrant Dadivanyan
Modified: 2019-10-07 08:29 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (ehaupt)

svn(1) diff against the ports tree (3.50 KB, patch)
2019-10-03 15:51 UTC, Kyle Evans
kevans: maintainer-approval? (ehaupt)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Hrant Dadivanyan 2019-10-03 15:45:48 UTC

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

Thank you,
Comment 1 Kyle Evans freebsd_committer 2019-10-03 15:51:59 UTC
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.


Kyle Evans
Comment 2 Hrant Dadivanyan 2019-10-03 17:44:10 UTC
Indeed, the patch works.
Thank you, Kyle!
Comment 3 Emanuel Haupt freebsd_committer 2019-10-04 08:27:08 UTC
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?

Comment 4 Kyle Evans freebsd_committer 2019-10-04 11:51:28 UTC
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)
Comment 5 Emanuel Haupt freebsd_committer 2019-10-04 12:46:07 UTC
Unfortunately I do not have any accounts to test this with. I've just released maintainership of this port. Assign bug back to queue.
Comment 6 Jesse Espinoza 2019-10-04 18:30:10 UTC
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:

OPNsense 19.7.4_1-amd64
OpenSSL 1.0.2s 28 May 2019


Comment 7 Kyle Evans freebsd_committer 2019-10-06 02:20:45 UTC
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.