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

["James Yonan" <jim@xxxxxxxxx>]

> > > 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.

Good news, --iroute in the next 2.0 beta release will handle subnets rather
than ranges.

> 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?

Take a look at --client-connect, I think it's what you're looking for. 
--client-connect designates a script to be run on the server immediately after
authentication but before any options have been pushed back to the client, and
before the server-side client instance object has been finalized.  The script
knows the client's common name and connecting IP address.  The script can
actually dynamically generate --iroute options (or --push and several other
option types) to be applied to the server-side client instance.

If you want a script to be run before authentication (and therefore be able to
provide input back to OpenVPN on whether or not the connection should be
approved), then see the --tls-verify option.

James