Port OPNsense to Linux?

[Patrick M. Hausen]

It's not exactly a one VLAN limit but a four zones total limit as I found out. For whatever reasons. Seems silly.

But surely improving on that project to allow an arbitrary number of zones will be easier than "porting" OPNsense. What would the latter even mean? You can port parts of the UI but definitely not the rules and NAT sections because all of this works completely different (I am repeating myself ;-). So better focus on a Linux based product to begin with or create a new one. That's essentially my only point.

[Patrick M. Hausen]

@Patrick
Can the functions be added to Linux's kernel, and would it make sense, if someone was to convince Linus about the importance of it?

No, definitely not. Linux suffers greatly from NIH (not invented here) syndrome, and while in BSD land (specifically FreeBSD) not everything is perfect - far from it, there is historic evidence that Linux in general and Linus in particular refused again and again to import working concepts and software for taste/political reasons more than technological ones.

E.g. netgraph, dtrace, ZFS, ...

ZFS is the only thing where I can relate to Linus. He more or less stated: "Unless I have a written statement by Larry Ellison (read: Oracle's legal department) that it's ok, I won't integrate ZFS into the Linux kernel for copyright reasons." Understandably so.

The barrier to get pf into the Linux kernel is huge - just forget it.

Linux has a working kernel firewall (or two or whatever - what do I know?) and that's what a Linux based firewall has got to use.

HTH,
Patrick

[drosophila]

It's not exactly a one VLAN limit but a four zones total limit as I found out. For whatever reasons. Seems silly.

AFAICS this is a legacy concept that originated from SmoothWall, before it became IPCop, before it became IPFire. Or somesuch as I didn't follow the development closely.
They had originally "colored" the physical interfaces, which made perfect sense back in the day as there aren't too many even now. Probably the simplicity of the concept kept it around, even though with VLANs it should be updated to at least "8 bit colors". :)

[pfry]

It's not exactly a one VLAN limit but a four zones total limit as I found out. For whatever reasons. Seems silly.[...]

IPFire (or its progenitor) actually implemented very limited VLAN support (one VLAN per interface/zone...?) before Ben Greear's VLAN code was upstreamed, and they kept that model for historical reasons. From "Zone Configuration":

Code Select Expand

Please note that:
- Due to backwards compatibility reasons, you can't assign more than one VLAN to a zone
- One NIC can't be accessed natively by more than one zone
- You can't use the same VLAN tag more than once per NIC
[...]

IPFire is definitely its own thing.

[pfry]

[...]Can the functions be added to Linux's kernel, and would it make sense, if someone was to convince Linus about the importance of it?

Heh. Even the reprogrammed, sensitive and politically correct Linus would have some choice words about that.

Why not get serious and add a pf (filter) and IPFW (shaper compatibility layer) plugin to VPP? No kernel mods required. Porting OPNsense (and maintaining the port) would be a bit of a nightmare. And VPP itself is a moving target - there's a reason it's not packaged for any distro (that is, available via a package manager [Edit: standard repository. I knew what I meant.]).

[MrWizard]

I saw a guide on a guy making a Lenovo Tiny into a 10/10 Debian router. The UI may not be the best for the average user.

IPFire does not get recommended.

OPNsense does, so ppl come here, if they need more then OpenWrT but are not Linux sysadmins.
That has increased manyfold as ppl distrust Chinese & US vendors, myself included.
Many today also run a ad-removal service on their router like Pi-hole.


@Patrick

Thx.

[Monviech (Cedrik)]

There is also nothing quite like Poudriere or the whole ports ecosystem where you can build the whole system reproducibly and declaratively from source. The whole build ecosystem is different between FreeBSD and Linux.

In Linux, maybe NixOS can do it declaratively, but that is a very fickle beast.

The main issue isnt just to do some translation layers, its a multi layered issue through many different systems and dependencies.

I also do not miss systemd in the slightest to be honest. :D

[nero355]

There is also nothing quite like the whole ports ecosystem where you can build the whole system reproducibly and declaratively from source.

Another thing that's really annoying in Linux : Distro Release X leaves you stuck with Application Release Y

While in FreeBSD I can simply do my own thing via the Ports and install a newer version :)

I also do not miss systemd in the slightest to be honest. :D

Another weird thing :
- The Linux distro uses SystemD.
- But it does not use it's networking component and uses NetworkManager instead for example.

Result : Sometimes the whole timing between the Network Interfaces coming UP and services bound to a specific IP Address like OpenSSH Server getting started miss their timing and things go horribly wrong...

There is a SysCtl workaround for this, but still... What the heck ?!?! :(