Thank you for the very informative reply! On Fri, 2012-05-25 at 16:27 +0100, David Woodhouse wrote: > On Fri, 2012-05-25 at 08:01 -0700, Jon Dufresne wrote: > > What is the best way to handle a script run by a normal user, but still > > able to establish the VPN connection. I want to limit the use of sudo > > and root as much as possible. > > You didn't specify, but I'm assuming you're doing this under Linux. Yes, correct. Scientific Linux 6 and Fedora 17. > You can almost certainly eliminate the *teardown* step though, and then > 'openconnect --setuid' would work. If you don't change the DNS setup to > use the VPN's DNS servers, and if you don't change your *default* route > to go via the VPN, then there's nothing to tear down. If there's just > the tun device with a simple route to one subnet like 172.16.0.0/20, > then it'll just go away naturally when openconnect exits, and everything > will be back to normal. So you could use 'openconnect --setuid' with > your own little script which is a *wrapper* around vpnc-script, and just > clears the INTERNAL_IP4_DNS variable and sets its own CISCO_SPLIT_INC* > variables to route just the IP addresses/subnets you need, before > invoking the real vpnc-script. > > You still need to invoke openconnect as root for that though. And you > wouldn't get VPN DNS, although your scripts *could* manually look up > things on the VPN's DNS servers and access services by IP address ? the > servers would be *reachable*, but just not listed in /etc/resolv.conf. > This approach looks like the easiest given my situation. I gave it a shot. The wrapper script simply unset the INTERNAL_IP4_DNS environment variable, then called vpnc-script with all arguments. I was able to successfully connect to the VPN. My resolv.conf was unchanged. After connected, openconnect successfully changed ownership to a non-privileged user. While connected to VPN my non-VPN network continued to work properly. I then killed openconnect as the non-privileged user. After successful shutdown, I was unable to use the non-VPN network interface. Any idea why this might be and steps I could take to fix this? I'd be happy to provide any output or diagnostic if you think that would help. Thanks, Jon
