On Tue, Nov 17, 2015 at 8:28 AM, Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote: >> I would prefer a more generic approach where missing variables >> (routes+DNS) are made available to the connect/disconnect scripts. >> To support the specific scenario you describe you could include >> sample connect/disconnect scripts. > It would be a good idea to also add these variables to the > connect/disconnect scripts, but these scripts are for the local > administrator to modify. I was thinking of making the firewall rule > application a standard option of ocserv, and that would have to be > through a separate script which is not intended to be modified by the > administrator. Which other use cases did you have in mind that couldn't > be handled by the default rules that I described? I've committed an implementation of it, and it is something in between of the initial proposal and yours. It introduces a new script /usr/bin/ocserv-fw [0] which restricts the user to the routes he has access to (currently the script is for iptables only) and denies access to no-routes. That script is being run as the connect-script if "restrict-user-to-routes = true" in either the global configuration or the per-user configuration. If there is a connect-script set, it will be run by ocserv-fw. I think that this approach is pretty simple, and it can be completely overridden by the admin as you suggested by simply not using "restrict-user-to-routes = true" in the configuration. regards, Nikos [0]. https://gitlab.com/ocserv/ocserv/blob/master/src/ocserv-fw
