On Fri, 2009-12-04 at 21:33 -0500, Andres Cimmarusti wrote:
> >From the man page of vpnc:
> 
> "The vpnc daemon by itself  does  not  set  any  routes,  but  it
> calls vpnc-script  to  do this job. vpnc-script displays a connect
> banner. If the concentrator supplies a network list for
> split-tunneling these net‐works are added to the routing table.
> Otherwise the default-route will be modified to point to the tunnel."
> 
> It seems the new UMD VPN concentrator is supplying this list, which I
> saw as output using netstat.

Since NetworkManager wants to set up the routes itself, it tells vpnc to
use /usr/libexec/nm-vpnc-service-vpnc-helper instead of vpnc-script.  I
wrapped nm-vpnc-service-vpnc-helper in a shell script to dump out the
information coming from the VPN server.  Surprise: the information is
exactly the same for UMD and UMD-Wireless except for the order in which
the subnets are listed.  So if the OIT client does indeed treat the two
VPNs differently, it must be looking at something in the pcf files,
perhaps the "ISPConnectType" parameter.

> I'm trying to figure out how to override it like Matt pointed out
> using NM, but using just the command-line....If only I wasn't so
> incompetent in shell scripting..

You probably just need to modify vpnc-script to call "set_default_route"
and "reset_default_route" unconditionally.  But I would be curious to
hear why you don't want to use NM.

It looks like vpnc-script recognizes a network entry for 0.0.0.0 to
refer to the default route.  If the OIT folks wanted to make non-NM vpnc
work, they could make the UMD-Wireless server send such an entry.  I
tested NM behavior by having the nm-vpnc-service-vpnc-helper insert the
0.0.0.0 entry, and NM seemed to ignore it.

-- 
Matt

Reply via email to