Re: Non default VPN route patch, 1.369

[Bill Moss <bmoss clemson edu>]

On Mon, 16 May 2005, Tomislav Vujec wrote:

> > Hi all,
> >
> > I made some changes to the current CVS head, which allow setting up
> > non-default routes for the VPN. In case your home connection is much
> > better than through the office, you don't want your default route to go
> > through the VPN.
> >
> > This only works for the RedHat back end now, but it should be easy to
> > adjust for other distributions. You'll need an additional gconf key,
> > called routes in your VPN set up. It should be a list of strings, each
> > of them representing a single non default route, e.g. "172.16.0.0/16"
> > which you want to pass through the VPN. If the list is empty, the
> > behavior should stay the same.
>  
Dan wrote
Cool!  One thing I noticed with VPN setup was that the subnet mask passed back 
from the concentrator that gets set on tun0 isn't inclusive enough to even 
include the nameservers that the concentrator sends back.  That really seems 
like a config error, and that was one reason why the default was to route 
everything through tun0...  But using 172.16.0.0/16 would solve that.

Bill:
How could this potentially  mesh with your vpnc config?  Would we need to add 
additional functionality to allow your config to be used?


Bill's reply:
With vpnc-0.3.2, I stole the vpnc-connect script from Debian and used it 
with Fedora Core. The Debian script added an additional key to vpnc.conf 
called 'Target networks'. The functionality added is precisely what 
Tomislav has added with his patch and the new GConf key 'routes'. I have 
tested it and it works. The motivation for this patch is well stated by 
Tomislav: "In case your home connection is much better than through the 
office, you don't want your default route to go through the VPN. The 
route I use for the office is for the subnet that holds all the critical 
servers I use. I don't need access to the rest of the campus."

On May 14, vpnc-0.3.3 came out. I was expecting it to be backward 
compatible with vpnc-0.3.2 as far as NM is concerned but I was wrong. 
When I try it, vpnc fails to start but I get no error messages from NM. 
Version 0.3.3 outputs more environment variables than 0.3.2. I put the 
list below. When the VPN enabled NM hits the 'streets' this may be an 
issue for people downloading vpnc.

Information is passed from vpnc via enviroment variables:

#* reason                       -- why this script was called, one of: 
pre-init connect disconnect
#* VPNGATEWAY                   -- vpn gateway address (always present)
#* TUNDEV                       -- tunnel device (always present)
#* INTERNAL_IP4_ADDRESS         -- address (always present)
#* INTERNAL_IP4_NETMASK         -- netmask (often unset)
#* INTERNAL_IP4_DNS             -- list of dns serverss
#* INTERNAL_IP4_NBNS            -- list of wins servers
#* CISCO_DEF_DOMAIN             -- default domain name
#* CISCO_BANNER                 -- banner from server
#* CISCO_SPLIT_INC              -- number of networks in split-network-list
#* CISCO_SPLIT_INC_%d_ADDR      -- network address
#* CISCO_SPLIT_INC_%d_MASK      -- subnet mask (for example: 255.255.255.0)
#* CISCO_SPLIT_INC_%d_MASKLEN   -- subnet masklen (for example: 24)
#* CISCO_SPLIT_INC_%d_PROTOCOL  -- protocol (often just 0)
#* CISCO_SPLIT_INC_%d_SPORT     -- source port (often just 0)
#* CISCO_SPLIT_INC_%d_DPORT     -- destination port (often just 0)



--
Bill Moss
Professor, Mathematical Sciences
Clemson University