Re: [Openvpn-users] OpenVPN 2.0-test26 released

[James MacLean <macleajb@xxxxxxxxxxx>]

On Fri, 30 Apr 2004, James Yonan wrote:

> James MacLean <macleajb@xxxxxxxxxxx> said:
> > On Thu, 29 Apr 2004, James Yonan wrote:
> > > A new release of the 2.0 beta is available.
> > Hi James,
> > We have started to look at how we can make use of the single daemon mode
> > of OpenVPN, but after playing with options and doing some searching we
> > thought it best to post and get direct answers to 2 things that are
> > stopping us from using this in place of the 1 process per link for
> > connecting many sites together. We realize the push was more for roaming 
> > users, but it apears it might work in our scenario too.
> > 1. Is there any way, or may we add to the wish list, the ability to route
> > a subnet through Openvpn (inside the internal router). As we understand it
> > now it will only accept IPs, yet we are trying to use it to connect remote
> > subnets together as we do now with the single daemon method. They are /16 
> > subnets.
> 
> Yes, it is possible now, using the --iroute option.  When a client connects to
> the server, the server can have a client-specific configuration, either a file
> in the --client-config-dir directory or dynamically generated by a
> --client-connect script.  The --iroute option tells OpenVPN to internally
> route packets in an IP range to a particular client as identified by that
> client's common-name.  You should also preemptively set up those routes so
> that the kernel will route them to OpenVPN when the daemon actually starts up,
> before the client has connected.
> Note that --iroute currently has one weakness, and that is that it only accepts IP
> ranges (i.e. start-IP and end-IP) rather than a real subnet-based routing
> table, and cannot accept really large ranges without consuming a lot of
> hash-table space.  If it was /24 or even /22 subnets it would be no problem,
> but /16 will require raising a constant in the source, and you will need a
> larger hash table.

I guess this is our problem. We had viewed it along the same lines of 
setting up IPSEC where we trust networks behind both ends of the tunnel 
and wanted to have all IP's from the remote subnet have access to the 
local subnet back-and-forth. As you suggest, it would be more like having 
the ability to open up a subnet with --iroute, not just an ip range.

We were looking at connecting many, many sites together in this manner, so
with the range option, we would require a very huge hash and I agree that
does not seem to be the way to go at this time. If entries in --iroute
could be subnets :), then we'd be all set ;).
 
> > 2. We can not find how to bring up routes when clients connect.  Or be
> > able to run a client-up script that would be allowed to add routes (to the
> > remote subnets).
> 
> On the server, use --push "route x.x.x.x" to push a route from server to
> client (this directive can be in the master config file or in a
> client-specific config file depending on whether you want it pushed to all
> clients or only certain clients).
> 
> To add a route on the server when a client connects, use --route and
> --iroute.  Think of --route as routing the traffic from the kernel to OpenVPN
> and --iroute routing from OpenVPN to the actual client.  When routing from the
> kernel to OpenVPN always use the remote --ifconfig endpoint as the destination.

In our instance we would like to run a script which applies a security 
profile to the connection. This ability to run a local script on the 
server end is what appears to be unavailable, or is there a similar per 
client option to run a script on connection?

> James

thanks for the prompt response,
JES
-- 
James B. MacLean        macleajb@xxxxxxxxxxx
Department of Education 
Nova Scotia, Canada