Messages

With certain Intel CPU series, there were hangups from 25.7 on, especially when you use UFS instead of ZFS, which is now recommended. The symptoms are much like yours, so I suggest that this is your problem - even more so, because it seems reproducible.

You can avoid them by applying the tuneables that are described in the links I gave you. Also, on most platforms, the firmware does not have the latest CPU microcode updates, so you should install the appropriate packages.

You should do this before the upgrade to 25.1. If you want a clean install on 25.7.x, use ZFS (but still apply the tuneables).

Ich würde mal die MTU auf den Clients aus die üblichen 1500 Bytes reduzieren. Das bringt sowieso so gut wie nichts mit der Jumbo MTU.

Look at this. It is also mentioned here: https://forum.opnsense.org/index.php?topic=42985.0, point 23.

That is strange. If a TLS client does not send the hostname any more, how would name based access in HAproxy work? It serves as the selector for the presented certificate in the first place. Of course, there is a fallback that you can create in HAproxy, but this would only be used for really ancient clients, IP-based access or a catch-all for unknown hostnames.

It that something "new" for IOS 26? If so, it will sure break things.

I have never encountered any compatibility problems with 10G DAC cables.

Ah, verstehe. Du verwendest gar nicht die OpnSense CA. Normalerweise sollte curl alle Zertifikate, die in System: Trust: Authorities eingetragen sind, akzeptieren. Bei mir tut es das, ich verwende auch eine eigene, externe CA.

Ich denke, es ist Zenarmor - auch ohne Blocking. Die Hardware sollte locker 1 GBit/s schaffen, siehe meine Signatur.

1. Wie und von wo aus gemessen? Nicht von der OpnSense selber messen, immer "drüber". iperf mit -Pn nutzen.
2. Rahmenbedingungen: IDS/IPS aktiv oder reines Routing?
3. RSS aktiv?
4. Hardware-Offloading konsequent aus?

Alles klar, Du hast es aber falsch verstanden: Du kannst entweder eigene Zertifikate direkt in der UI selbst erzeugen oder Dir per ACME.sh solche von einer offiziellen ACME-CA holen. Die interne OpnSense-CA beherrscht das ACME-Protokoll nicht, also sind diese Wege nicht kombinierbar, wie ich oben bereits erklärte.

Beide Typen von Zertifikat kannst Du u.a. für das OpnSense Web UI nutzen.

I use Uptime Kuma only for all of my services being basically "up / present", which are quite a lot, so I also put them into groups. The services do not even have individual alerts, those are only enabled at the group level. Actually, I use a HomeAssistant alert to sent a voice notice to my Amazon Echo Dot.

This is a health check only.

On top of this, for real monitoring purposes, I use the well-established telegraf/influxdb/grafana combo. For most Linux boxes, there is a dashboard and also for OpnSense and many more, like for Proxmox.

I just did that and it works fine the way you described it - although the $.status probably is only the request status, not the status of a specific gateway in the response (you would have to select that).

Of course, you have to have an API key and secret, those must not be quoted in the Uptime Kuma input fields. You can use them verbatim as in the curl parameters. The key must be associated to a user that has the appropriate permissions, but if it did not, you would be getting an error with curl as well.

Since you do not get any qualified error at all: Can your Uptime Kuma instance access the HTTPS port of your OpnSense or is it blocked by a firewall rule? You can check by using a plain HTTPS request.

Usually, you will want an "in" rule like "allow any to any" for normal LANs and there is such a default rule for the first LAN.

However, this is generally too broad, because it allows access to any other (V)LAN when applied to all (V)LANs. The general recommendation is to use a "block any to RFC1918" rules before the "allow any to any" rule, with RFC1918 created as an alias for all RFC1918 ranges.

You can achieve the same effect if you deny access for specific destination interfaces.

Usually, you will have one or more (V)LANs that really have the permission to allow access to all other (V)LANs, like your main LAN or a Management VLAN. Only for those, you will not define a block rule.

Dann ändere den Thread-Titel bitte und hänge [Solved] davor.

At this point, I am inclined to believe it may be a limitation of the SFP slots. Intel did some trickery with those w/r to detection of some branded modules (I thin I remember that there are driver settings for that). Also, it might be a firmware thing.

The reason is that the limit occurs at 1 Gbit/s, which points to a hardware limit, not one that is induced by software or CPU capacity.

[outside]

I am all for blocking inbound ICMP, but, as I said: By using your rationale you could fordbid any kind of outbound traffic, because "there are attack techniques" that use that kind.

Once attackers are able to craft ICMP packets for exfiltration from inside your network, it is already too late, because they obviously have infiltrated your network already.

Which means: You can stop exfiltration only by blocking any outbound traffic, because any kind can be used to transport data. On the other hand, this obviously also refers to inbound traffic, because any connection can be used both ways.

A firewall should keep attackers outside in the first place. Once they are in, you cannot do much with a firewall, unless you are willing to sacrifice basic functionality or create the equivalent of a "sneakernet" (i.e. have no internet access at all).

Basically, you need endpoint security to evade exfiltration or in the case of IoT or other untrusted devices, confine them to a VLAN where they cannot exfiltrate anything worthwhile.

Everyone is free to apply any measure to reduce attack surface at any level. I just wanted to point out that the leverage in this case is fairly limited, so your efforts may be put to better use.