OPNsense Forum

English Forums => Development and Code Review => Topic started by: juanperiz on May 17, 2016, 10:28:59 pm

Title: Advice - Several OPNSense as Containers
Post by: juanperiz on May 17, 2016, 10:28:59 pm
Hi5 to all my new and shiny OPNSensers' friends...



I'd like to build a *server* box (32GB RAM / i7 CPU / 4x 1GBps NICs) that runs several OPNSense deployments at the same time NOT as a *VM* each one of them, but as *CONTAINER*.

As far as I'm concerned, due to being based on top of FreeBSD, I can choose from this alternatives;

* BSD (Native) Jails

* Docker for FreeBSD

* JetPack

* BSD VPS

Which I haven't tested as a PoC, sp I need some advice regarding this issue...

* You guys thinks it's "doable"?
* You guys thinks some alternative is better than other? Just why?

Thanks in advance,
Best regards,

Juan Periz

P.S.: each "tiny" and isolated OPNSense deployment is meant to be managed by different IT-admin-know-it-all boys at my University...

Title: Re: Advice - Several OPNSense as Containers
Post by: franco on May 18, 2016, 09:44:16 am
Hi Juan,

Some people have asked for jail support about a year ago, but I really don't know the state of it. Problem is pf(4) kernel packet filter, which needs to be administered by all jails, which can break setups for others.

You can certainly try to set up a jail, I can provide a tar package if you want, although it would need the right kernel so it needs to be a jail on top of a OPNsense-ish FreeBSD anyway.

Getting OPNsense to natively support "multi-tenancy" would probably be a another approach here, but it's a very large amount of work, half a year just as an educated guess.

If you have FreeBSD as the base you should try bhyve(4) native VM:

https://wiki.freebsd.org/bhyve

Hope this helps. We can always discuss this in more depth if you want. :)


Cheers,
Franco
Title: Re: Advice - Several OPNSense as Containers
Post by: juanperiz on May 18, 2016, 09:08:29 pm
I thank you fast and kind reply!

Franco, we can strecht out this chat anytime you want...

I'm gearing towards "Cointaner-ized OPNSense" because of CPU benefits of this technology, instead of I/O benefits coming form "Virtual-ized OPNSense".

I'd not label it 'multi-tenant' as the same way Paid FW's do; but I do think this kind of deployment should involve a "MASTER/handler & driver" OPNSense (over bare metal) which deals with real ETHER & FIBER ports, memory management and particularly IOCtl system calls to pf(4); each sort of "jailed OPNSense appliance" would talk to this MASTER FW an negotiate ACID rule management over pf(4) (NAT, rules, etc., etc.)...

What do you think about that?

Best Regards,
Juan...
Title: Re: Advice - Several OPNSense as Containers
Post by: franco on May 18, 2016, 09:57:13 pm
Hi Juan,

Forgive me, I tend to get sentimental about "paid FW" terminology where I spent most of my professional time.

Well, when you tell it like that it would probably be good to have API parts for all of those intricate parts that you name. We're working towards that goal, because with the abstraction of what a resource is and how it is negotiated it's easier to build more complicated GUI logic around it that is not restricted by the current GUI code itself. In fact this is also interesting for centralised management which is similar, but not quite. The proverbial "same same but different".

API is also a long-term target especially for old and most vital subsystems, so you still want a middle ground. Let's start from the top... What do you want to offer each client? If we can limit the feature set it may be easier to do than expected. A Mini-OPNsense with a full feature set is a lot harder to implement although it sounds so natural. :)


Cheers,
Franco
Title: Re: Advice - Several OPNSense as Containers
Post by: juanperiz on May 20, 2016, 04:16:04 am
Franco...

Maybe we can let "JAILs OPNSense" far more than "Multi-Tenant API" in a 'virtual' RoadMap I dream; I didn't dig a lot about OPN BackEnd (Python, am I right?) dealing with pf(4), but I noticed "CATEGORY" field at the FrontEnd which I supposed it's backed by some type of DB where later BackEnd impacts over pf.

I think adding another field called "TENANT" which also can be backed on this DB (don't know if there's any DB!) and  then those "TENANT" rules could be conjugated into a single ruleset that would be feed to pf(4).

This "Multi-Tenant API" I refer should only by some sort of code that has to be feeded with every ruleset and determine/conjugate when it make up its mind each type of ACID operations over the entire RuleSet pf(4) handles...

Finally, could you be so kind considering if this post should be moved to Development Forum? I'm offering my code programming abilities in order to get this "Multi-Tenant API" done...

Best Regards,
Juan!