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

[jvi]

On Thu, Jun 30, 2016 at 11:10 AM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> On Wed, Jun 29, 2016 at 10:14 PM, jvi <v8kjvi0j6 at gmail.com> wrote:
>> 2) Routes
>> ocserv accepts only the most crude and basic route definitions (route
>> = "") from the configuration file. Any more details and complicated
>> syntax is either ignored or ends up as an error. Perhaps ocserv could
>> simply set whatever is defined through route = "" option instead of
>> trying to process and check its syntax? That would do it. Leave making
>> sure route definitions are correct to the user.
>>
>> 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.

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

/sbin/ifconfig $DEVICE fib 12
/sbin/route add -host 10.31.0.1 -iface tor0 -fib 12
/sbin/route add default 10.31.0.1 -fib 12
/sbin/route add -host $IP_LOCAL -iface $DEVICE -fib 12
/sbin/route add -host $IP_REMOTE -iface $DEVICE -fib 12

Done, any tun for any user choosing the 'tor' group gets own fib, so
everybody's nicely isolated. And we get:

tun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1353
        options=80000<LINKSTATE>
        inet 10.30.2.1 --> 10.30.2.9 netmask 0xffffffff
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        fib: 12

Routing tables (fib: 12)

Internet:
Destination        Gateway            Flags      Netif Expire
default            10.30.0.1         UGS        tor0
10.30.2.1         tun0               UHS        tun0
10.30.2.9         tun0               UHS        tun0
10.31.0.1         tor0               UHS        tor0


Now imagine this could be done at ocserv level, and every tun clone
its creates could, if only config is set so, gets own fib, or a fib
per group or whatever else. Why not? One could this way e.g. several
different actual VPNs with its connected users easily seeing each
other inside the virtual network, etc.

\o/

jvi