Messages

The next step is to understand how to do and implement https inspection.

Easy: You don't. See this, point 12.

Deine Screendumps zeigen ein /56 für das LAN, das wäre falsch, es muss /64 sein. Du musst ein beliebiges /64 Präfix aus Deinem /56er Bereich wählen.

Typischerweise ist die WAN-IP übrigens /128. Geht IPv6 von der OpnSense selbst?

Bad luck on the firewall box (although you probably got your money back from Amazon), congratulations on your electricity rates.

But: depending on where you live, half of 360 Watts running 24/7 sets you back 180/1000*24*365 kWh * 0,30€/kWh = 473€ per year (that is about average in Germany). So, in just something over one year, a (working) specimen of an N1x0 box is amortized, because that only sips 15 Watts.

Reality is a little better, hopefully, because even these things do not even use half of 180 Watts permanently, but you catch the drift...

Anybody can screw up firmware, all good if they fix it later on (even if it takes years after initial product release).

However, the first link seems to be a hardware/design problem, so that one cannot be healed at all, IMHO. The only thing that comes to their rescue is that nobody noticed the hard part before. That is, if not being able to split up a 10 Gbps connection to eight 1 Gbps ports is not bad enough in the first place (at least that is not a complete functional show-stopper).

[just works.]

So this is my last stop before I order a ubiquiti that just works.

Like this? Or this? Want more?

Es gab mal einen Thread, wo darüber berichtet wurde, dass es trotzdem für bestimmte Abfragen noch Traffic über Port 53 gibt - ich weiß nicht mehr, wofür das genau benötigt würde. Mir ging es hier nur darum, festzuhalten, dass es weiterhin Traffic über Port 53 gibt aus mindestens zwei Ursachen:

1. Client -> OpnSense
2. OpnSense -> Internet (trotz DoT)

Es gibt hier zwei Sorten Anfragen:

1. Welche von Deinen Clients zu OpnSense - die laufen auch bei Nutzung von DoT weiter über Port 53.
2. Welche von OpnSense zu den Upstream DNS-Servern. Die hast Du anscheinend auf DoT per Port 853 umgestellt.

Wenn diese #2-Anfragen nicht mehr per normalem DNS auf Port 53 laufen, funktionieren sie auf Port 853 nur verschlüsselt, weil das Zertifikat des Zielservers geprüft wird. Stimmt dort der Name nicht, geht's nicht. Auf welchem Port wirklich DNS-Anfragen rausgehen, kannst Du z.B. per TCPDUMP auf dem WAN-Interface prüfen.

Am Rande bemerkt, gehen nicht alle DNS-Anfrage per 853 raus - beispielsweise die erste nach der IP des DoT-Servers nicht - aus Gründen.

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