Messages

I nearly fell for it.... April Fools.

@drosophila: But that does not change the way how most of this is done within OpnSense, by creating the interfaces aorund the specific implementation of the various services, like that currently, even the actual MAC->IPv4 tables are edited and saved for each service individually. @pfry put it right: There currently is no abstraction layer.

Also, that abstraction layer could catch even more than the uniform usage of different services, but also the jump from the MAC->IP to the IP->DNS layer, including aliases. It could also cover the problems around the dynamic to static transition of devices.

What I mean by that is that now, with Kea, when you first put a device on the network, it will get a dynamic IPv4. Yes, you can make that static - but that does not work at all, because the lease is not deleted and conflicts with the static reservation, thus creating a big problem in its wake.

Imagine a "client" entry that can be created manually or automatically upon first contact, where you just fill in the blanks, like change the DNS name, add DHCP options or DNS aliases and so forth, thereby creating a static reservation, while deleting the Kea lease underneath.

But doing that would be an initial design choice, trading limiting capabilities for ease of use. I doubt that it could or even should be tried in OpnSense.

I do not understand your problem with the reordering, because dynv6.com allows you to use the variable "ipv6", which you can have derived from any EUI-64 that you like, like I depicted in my screendump above. You only need to specify the EUI-64 part that you want plus the interface that it should be combined with. No scripting needed.

And you would never, ever use a temporary (dynamically-created) EUI-64, always the "mgmtaddr", because OpnSense would not know when a tempaddr changes, so you must know in advance which EUI-64 to use and which interface it is connected to.

I was merely talking about what design goals and expectations would be against something like this. When you omit flexibility and do that in a consolidated way instead of configuring any single specific service, you can do that.

Like: model the data, the relations between them, make that editable from the UI and then generate the split configurations for all needed services (of which there exists only the respective one you need to fulfill the needs of your model). All of those services can be hidden behind the surface, because the user does not need to know which exactly is being used.

An example: Someone coming into the forum and asking: "I heard that ISC DHCP is EOL - there is Kea or DNSmasq, which should I choose?" is a pointless discussion. The very fact of which DHCP service is in use under the blanket could be hidden and is only to be determined by the developers. The users only need to fill in MACs and IPs in case of reservations - which service is being used to actually do the job should not be relevant to them.

[Not]

There is soo much already out there so what do you need exactly that they can not offer ?!

They could offer a decent UI with more limited features, but aimed at what most clueless people who come in here think a firewall should do. There are countless examples of voicing that, the last of which was this one.

That is: Not 3 different DHCP services, 4 different DNS servers, loose coupling between MAC / IP and DNS names that must be consolidated manually over the configuration of two services, not even counting the associated firewall rules.

It is very hard to down-size an existing appliance like OpnSense that has grown over the years and adapted many tools and plugins. The decline of FreeBSD poses a chance to start from scratch, with a specific clientele in mind.

What the Fritzbox does not is better in the direction of simplicity, but worse in the way of flexibility, e.g. you cannot have DNS aliases, making the use of name-based reverse proxies or having several services on one IP very difficult. Also, it lacks something like Adguard Home or Pi-Hole.

While IPfire and other Linux-based firewalls may have the correct feature-set, they suck even more on the "complexity" side for such users than OpnSense.

P.S.: To be clear: I like OpnSense for what it is. But, as I often said, it is not suited for the average Joe who does want "a little bit more" than what consumer routers offer. There are more of those these days with IoT and homelabbing. Such users just want the benefits, but are unable or unwilling to grasp the underlying concepts and need a stringent UI, which OpnSense does not offer.

So, this is a growing market that is neither met by Fritzboxes, IPfire, OpenWRT, nor by OpnSense and all the others. Yet, I think that despite there being a lot of people who would love to have it, they are also the same people who do not want to pay for that luxury.

I understand why it is not feasible to port OpnSense to Linux. Instead, what COULD be done is to invent a new firewall from scratch with Linux underneath, aiming exactly at prosumer users, who want more security or features than what an average consumer router (like a Fritzbox) offers, but with less complexity (at the expense of overwhelming features) than OpnSense.

I would bet that this is a tough spot, though: You do not have businesses as paying customers (like OpnSense and the "other product"), and you do not offer the hardware appliance that can be monetarized like AVM's Fritzbox.

Having had a company that tried to reach that market in vain, I know that those prosumers are enthusiastic for features and quality, but less so for paying the effort that goes along with it.

You must be very careful with dual-homed hosts:

a. they should not route packets between interfaces
b. that includes setting the gateway on the correct interface

Normally, you use this only in order to be able to reach the machine via a second "leg". I do that sometimes, when I have a VM that lies behind a reverse proxy with a "LAN" leg and I still have a direct IPv6 connection. In such cases, the LAN side has no gateway at all, because the reverse proxy accesses it via its own LAN IP.

As I said, the same purpose can be had without any installation on OpnSense at all. So there is one big risk and it can be avoided.

P.S.: NPM and LZ (see: https://www.youtube.com/watch?v=aoag03mSuXQ) are at least controlled by some well-known contributors (even if they did not notice the attacks, but I doubt AI would have caught this, either).

I think there is a difference between well though-out attacks that went over months like with LZ and the thing we are witnessing now, which is offering some AI-generated tools that first seem to do something useful, but can be exploited later on, because they are not audited at all. There are discussions about the same thing in Proxmox, too:

https://forum.proxmox.com/threads/onboard-sata-controller-durchreichen-wo-finde-ich-ihn.181699/post-845202

[BUT]

Normally, I would suggest this thread for immediate deletion to the forum moderators, because in the last few weeks, there have been several attempts by first-time-posters to advertise tools with "flashy" names hosted on Github that do one thing or another - always coded with the help of Claude, BTW.

In almost all of those cases, the tools were from first-time-releasers on Github, too, so it became all too obvious what their real purpose was - or at least: could have been.

That being said, I know your are a real person (and also a fellow "arctic pole vault contributor") and I do not think this follows the same pattern, but (and this is a big BUT):

You should be aware that the alert level rises when anybody from outside augments OpnSense with external code that must be installed with high privileges and could - even if it currently poses no risk (not that I even bothered checking) - take over control of a security appliance like OpnSense.

I, for instance, would not point curl at any abitrary internet URL, fetch a script and let it execute on my OpnSense - even if I like the idea and could use it.

My suggestion for you would be to create an OpnSense plugin and try to create a PR for OpnSense. In that case, any further iteration could be controlled by trusted parties and more people would likely use your tool.

If Deciso finds your tool is not eligible for that approach, you should at least think about the following:

Both the Unifi inform API and the Deciso API to get the needed info from are open to use remotely. That access can be controlled to allow read-only access without a risk of OpnSense being modified by bad actors. Thus, you could as well create a docker container that runs independently and does not have to be integrated as executable code into OpnSense, thereby causing no risk at all.

Could also be a faulty port on the switch or on your firewall or bad NIC support if Realtek NICs are in use.

@silke61: Wie ich hier bereits erläuterte:

- Man muss die Prinzipien selbst verstehen, anderenfalls kann man die kleinen Ungenauigkeiten, die sich 100%ig einschleichen, nicht erkennen und auch nicht heilen.
- Dazu hilft es, die offiziellen Dokumentation zu lesen und die zugrunde liegenden Prinzipien zu verinnerlichen.
- Dann gibt es den READ ME FIRST-Artikel, der die häufigsten Fallen behandelt. Ich empfehle, ihn von vorne bis hinten zu lesen - irgendwann auf der Reise kommt man wohl an jedem Punkt einmal vorbei (ein paar hast Du ja schon durch).
- Darüber hinaus gibt es für bestimmte Spezialthemen, die immer wieder vorkommen, HOWTOs in der Tutorial-Sektion des Forums, darunter die zum Spezialthema Proxmox, Fritzbox oder IPv6 u.v.a.m.
- Schritt-für-Schritt Tutorials "from the ground up" helfen nur sehr bedingt, denn jeder Jeck ist anders...
- Jede Abweichung oder "Vergessen" eines Schritts oder wie hier die falsche Reihenfolge bei Firewall-Regeln würde die Funktion verhindern (übrigens: by design).
- Auch die "Entwickler" können das nicht für Dich vereinfachen, weil man nicht jede Verästelung voraussehen oder abbilden kann. Der Gedanke daran wird also "wishful thinking" bleiben.

Zum Thema mögliche Freiheitsgrade: Nimm Dich selbst als Beispiel - Du hast Dir quasi den "GAU" ausgesucht, nämlich nicht nur OpnSense "pur", was an sich schon nicht so einfach ist, wie viele sich das vorstellen, nachdem sie ein Youtube-Video gesehen haben, sondern "router-behind-router" plus VLANs plus "Virtualisierung" (a: Haben wir schon über die Hardware gesprochen? b: Dass man "niemals nicht" UFS nimmt, steht übrigens auch im Proxmox-Guide. c: IPv6 läuft?). Jedes dieser Themen ist ein Minenfeld für sich.

Der erfahrene Handwerker weiß: Eine zöllige Schraube passt nicht in eine metrische Mutter.

Zusammengefasst: NICHTS an OpnSense ist wirklich einfach. Sorry, aber isso...

Oh, I forgot: With services that actually allow to set a specific IP, you can use this to set the __MYIP__ variable for a custom get request with an interface prefix plus a specific EUI-64:
You cannot view this attachment.

So you see how the cat jumps. You call it angry on the first encounter, some call it plain hostility after having experienced it multiple times. I understand your approach to cool down tempers and try to get to basics (I once did in vain), but that is an uphill battle that Franco has ceased to take. The FreeBSD folks are unwilling to change it for good, so that is that.

P.S.: "Frankenstein PF", I like that. Maybe we should call the other one "Zombie ICMPv6" (for missing parts). ;-)

I do that completely differently: Whatever the outbound IPv6 is, it will always have the same /56 prefix, because I use IA_NA only.

Thus, the lower 68 Bits consist of the interface ID + 64 bits of whatever any client or OpnSense has. In order to make services available, it is best to refrain from privacy addresses (because they change!) and use the (fixed) EUI-64 part. There are many dynamic DNS providers that are capable of chopping off the lower bits and only change the prefix to the incoming connection. I happen to use my own.

Thus, they keep whatever you manually configure the lower bits to be. This makes it possible to have dynamic DNS updates done by OpnSense "in lieu" of any client.

[10.110.0.1/24]

Vergleich mal:

VLAN:
Tag: 50
Name: vlan01
VLAN-Schnittstelle:
Aktiviert
Statische IP: 10.110.0.1/24

Aktiv auf der VLAN-Schnittstelle
Adressbereich: 10.110.1.2 – 10.110.1.254