Messages

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

At least we cannot be sure of that. From time to time we stumble upon another piece of the puzzle.

And for the record: This was a (small) security problem that had been fixed in the other BSD project and ported to FreeBSD, but only in parts (that seemed to matter). It was never clearly communicated which parts where fixed, because the fixes were done incrementally and augmented via several bug reports. Some of those were simply disregarded, because they were not reported on "pure" FreeBSD, but on OpnSense, laying the burden of proof on users.

So, to answer your question, you would have to take the initial fix and compare it across all over the place in FreeBSD. Would you like to volunteer?

All we know is that there were documented missing parts of specific ICMPv6 handling that were left out and led to the exact bug sighting that were to be expected from it, all sidelined with pure denial of these facts and pointing how this must be done - with each of the missing parts tracked down according to the FreeBSD process.

AFAIK, OpnSense itself uses no privacy extensions for its own outbound connections. With IA_NA, it just cannot, because that would be a /128 and even with IA_PD, it does not, which has been criticised in the past.

Thus, I suspect you try to achieve something different? Dynamic DNS is out of the question, because you would rely on the redundant EUI-64 based parts for that, so what is your intention?

You are correct about that there is a certain relation between up- and downstream that must be met in order to allow traffic at all. That is because the ACK stream takes up upstream bandwidth.

However, I measured during the downstream part of the Waveform test and got these results:

You cannot view this attachment.

This shows 4 GByte downstream data and ~130 MByte Upstream, of which 80% was TCP ACKs, so roughly a 3.25% of the downstream needed for upstream. AFAIR, that is about to be expected at a theoretical worst case of ~4% and a more practical 2% (RFC 1122).
AFAIK, that should also explain your rate of 1000/35 Mbps: Your ISP wants you to have full 1000 Mbps downstream, but only the mere neccessity for the upstream with nothing left for server applications. There are some more providers which offer only a small downstream even if there is no technical neccessity to do so, like with DOCSIS.

So, in theory, you should be able to use the full 1000 Mbps downstream, not only 600?

I can imagine two things that may shift the results:

1. With TCP ACKs, you can have pure ACKs and SACKs, so the number of packets used can be severly lower than the number of data packets. That is obviously the case in my test. You did not show the downstream part of your test, you we cannot know if SACK was used, which would be dependend on the client.

2. Regardless of the net data being transferred, pure ACK packets are way shorter than data packets, so they incur a larger overhead, so the net data results may not mirror the real bandwitdhs used.

IDK. If you feel that is a bug, create a bug request on Github.

It does not do that per default. Identity association is the new version of the former "Track Interface". Thus, it depends on how many bits you have in your parent interface's prefix delegation size. AFAIK, you need a shorter than /64 prefix in order to be able to supply a full /64 prefix to any interface.

Maybe your ISP does not give you a /56 (which is pretty much the default) or you did not request as much on your WAN. How many bits is your IA_PD prefix?

Perhaps you should take a look at the official docs: https://docs.opnsense.org/manual/ipv6.html

Or my IPv6 guide (which is still based on track interface): https://forum.opnsense.org/index.php?topic=45822.0