Notes on ocserv (0.11.3) compatibility with FreeBSD 10.2/10.3

[Nikos Mavrogiannopoulos]

On Sun, Jul 3, 2016 at 6:01 PM, jvi <v8kjvi0j6 at gmail.com> wrote:
>>> Workaround: Custom/advanced routes can be set through a connect script
>>> (connect-script = "")
>> Could you elaborate on that? What syntax is missing? Note that ocserv
>> cannot allow free-form syntax as it has to send valid data to the
>> clients.
> Review https://www.freebsd.org/cgi/man.cgi?query=route&sektion=8
> and compare with your code. From what I've noticed surely -net and -host
> parameters end in errors, and -fib is completely ignored. Surely more.

I don't think that the man page you point provides new information to
me. Please be explicit on what you request is.

>>> 3) Support for multiple routing tables
>>> There is none. At the core of FreeBSD routing lays multi-fib
>>> management, especially if there are several jails involved. Preparing
>>> ocserv for it should be fairly simple. Hence ocserv could get its on
>>> routing table(s) separated from the system default/any other routing
>>> table, perhaps even one for each user; for convenience, safety and
>>> foolproofing, which would be a brilliant feature.
>> It is unclear to me what do you mean here. Is it about providing
>> different routes to different users? That is already allowed.
> I meant what I wrote, "routing tables" and not "routes". Why wouldn't
> this be unclear? One can have many routing tables (cryptically called
> "fib", forward information base) defined at many varied levels, per
> users, interfaces, jails, etc., whatever is needed.
>
> Review:
> https://www.freebsd.org/cgi/man.cgi?query=setfib&sektion=1
> https://www.freebsd.org/cgi/man.cgi?query=setfib&sektion=2
> https://www.freebsd.org/cgi/man.cgi?query=netstat&sektion=1
> A case study so you could understand this better:
> Let's say we want to have an ocserv's group "Tor" and route everything
> through tor network. Let's say we bind tor ports to a cloned lo
> adapter, now for convenience named tor0. Let's say it was assigned
> 10.31.0.1 and it listens for transparent proxy and dns connections on
> its ports. Let's say our ocserv works with plaintext auth and a user
> can select a group they want on connect, so e.g. 'default' or 'tor'
> and routing depends on the selected group. Default is IPv4 standard
> routing (with 'route = default') using default system routing table.
> What is the easiest way to add routes for tor? Of course one could
> fuck around with default routing table and packet filter definitions
> to both make it happen and isolate it, but assigning a new and empty
> routing table to a dynamically cloned tun adapter and hence defining
> default gateway and other router is both cleaner and more efficient,
> let's say routing table number 12.
> So using connect-script we assign a new routing table to the tun clone
> which is being created, say, tun3, and then using the same script we
> assign a few custom routes to that routing table, effectively
> populating it.

Could you propose a patch for that feature?

regards,
Nikos