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