Here is a patch to make net-misc/vpnc (/etc/vpnc/vpnc-script) use /sbin/resolvconf if available. Reproducible: Always Steps to Reproduce:
Created attachment 113983 [details, diff] Patch to use /sbin/resolvconf if available
Just to be sure, this applies to =net-misc/vpnc-0.4.0-r2 and was tested with it.
(In reply to comment #2) > Just to be sure, this applies to =net-misc/vpnc-0.4.0-r2 and was tested with > it. You haven't sent it upstream?
I've mailed the list right now (although I don't know if they allow non-subscribed users to post).
Ok, I tested the patch. It won't use the backup resolv.conf file generated by vpnc, so a restart of the init script fails here as my DNS server is different for VPN and non-VPN connection. This is because the comment on the top "VPNC_GENERATED" is overwritten by resolvconf and vpnc-script won't find it anymore. No time on my side to work on it further, so maybe you have an idea, Gustavo.
In the current form not really usable. Sorry, WONTFIX
What is going wrong? To be honest, I don't understand the problem description in which way the patch doesn't work. As I'd like to merge the patch into vpnc directly and it *looks* good to me it would be helpful to understand what is going wrong.
vpnc modifies /etc/resolv.conf: #@VPNC_GENERATED@ -- this file is generated by vpnc # and will be overwritten by vpnc # as long as the above mark is intact domain foo nameserver 127.0.0.1 It will only restore the old resolv.conf file if it finds the @VPNC_GENERATED@ mark. My complete traffic to the internet goes out over VPN, so I rely that when shutting down the original nameserver 192.168.1.1 is restored so the start-up service vpnc finds the VPN server. resolvconf will overwrite /etc/resolv.conf and destroy the mark, rendering it unusable on service restart. Adding Jörg to CC, remove yourself if you don't wish that.
The GENERATED stuff is only used by the vpnc selfmade resolv.conf modification code. With the patch, that code should be completely bypassed and replaced by /sbin/resolvconf. So as long as you start and stop vpnc with the same version of the script, everything is supposed to just work (unless I completely misread the patch). So as long as you don't update the script/package while a connections exists, everything should work as expected.
Ok, I think something went badly wrong when I first tested the patch...I did take the precautions you, Jörg, outlined then, but something else must have happened. Anyway, it works. So bring it into upstream, if it is not in the next soon-to-come release, we will patch vpnc.
Committed to vpnc svn trunk revision 197. Thanks! Jörg
As it will be in the next release, closing this bug as UPSTREAM. Gustavo, thanks for the submission.
Created attachment 128450 [details, diff] Slight adjustment to resolvconf patch for "proper" updates The dnsmasq resolvconf "handler" expects VPN-sourced entries to only provide a "domain" listing rather than a "search" listing. This patch is the same as that committed in upstream SVN (trunk/r197), save for using "domain" rather than search. It works correctly on my machine, works EXACTLY how I want it, so only VPN related queries get passed to the VPN-sourced DNS servers. NOTE: the dnsmasq handling does seem to require resolvconf-gentoo-1.4 to function properly
In which respect is this a "bug" in vpnc and not dnsmasq/the dnsmasq module for resolvconf? How are we going to handle the case when there is not a single domain but a domainlist?
(In reply to comment #14) > In which respect is this a "bug" in vpnc and not dnsmasq/the dnsmasq module for > resolvconf? I wouldn't claim it to be a "bug" in vpnc, just an alternate version of the patch attached to this "bug" to enable resolvconf support. If it came across that way, I apologize. As far as I know, dnsmasq has the only resolveconf "handler" that is doing this per-VPN domain/dns separation. That's why "proper" is in quotes, I don't know what is supposed to be the correct way as dnsmasq appears to be the only one doing it. (In reply to comment #14) > How are we going to handle the case when there is not a single > domain but a domainlist? I wasn't thinking about that case, as I believed the current vpnc-script (and the environmental variables it uses) to only support one domain (CISCO_DEF_DOMAIN) per VPN connection, rather than multiple. The better long term solution would be something added to resolvconf to handle these private networks differently, but for the here and now, it doesn't. I am perfectly happy to just continue to patch my vpnc-script with the change so it works for me, I was just trying to help others who might be in the same situation I am.
You are right. Changed.
