Messages

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.

Ich kenne das aus solch großen Installationen nur so, dass ohnehin mehrere Firewalls verschiedener Anbieter in Serie eingesetzt werden, falls eine eine Sicherheitslücke aufweist. Und dann macht man die Konfiguration sowieso automatisiert, weil man sicher nicht von Hand die selben Regeln auf mehreren Instanzen einspielen will.

Dabei kommt es eher auf die Automationsfähigkeiten der Systeme (also z.B. APIs) als auf deren UI an und man hat die Verwaltung der Objekte eh selbst in der Hand. Meist sind die aufgrund von diversen Vorschriften ohnehin in einer Konfig-DB.

Vielleicht kommt nur mir das Kriterium deswegen so schräg vor.

Wieso "fürchtest" Du das? Wenn das das entscheidende Kriterium ist... ¯\_(ツ)_/¯

[I guess you are using iperf3 on OpnSense itself, which will yield totally different results (for me, as well). This is a no-no, see https://forum.opnsense.org/index.php?topic=42985.0, point 10.]

I can do >500 MBit/s with only one iperf thread and one J4125 and one N100 CPU with OpnSense 25.7.7_4 with either TCP or UDP, so I think there is nothing wrong with OS itself. Maybe the virtualisation layer eats something away.

BTW: When I use iperf3 with "-u", I also have to use "-b 0", otherwise the UDP bandwidth will be limited to 1 MBit/s, as documented for the Linux version. Judging from the fact that you did not see that limitation, I guess you are using iperf3 on OpnSense itself, which will yield totally different results (for me, as well). This is a no-no, see https://forum.opnsense.org/index.php?topic=42985.0, point 10.

Ist aber echt eine Notlösung. Die quasi "zufällige" Reihenfolge in der Auswahl fand ich schon immer schlecht. Und bei >1000 Aliasen praktisch nicht handhabbar. Kategorisierung und alphabetische Sortierung wäre da wirklich hilfreich - sollte man vielleicht mal einen Feature Request für machen.

"Namen sind nicht das, was sie bedeuten" - sonst könntest Du ja gleich den Inhalt hinschreiben.

Was die o.a. Übersicht angeht: Dort könnte man ja auch nach Typ filtern, aber bei der Auswahl von Aliasen in Firewall-Regeln gibt es diese Möglichkeit leider nicht. Die Aliase sind nicht einmal alphabetisch sortiert, nur anhand der "möglichen" Typen eingeschränkt. Man kann allerdings den Präfix eingeben und bekommt dann eine eingeschränkte Liste - insofern ist die Präfizierung mit dem Typ hilfreich.

Schöner wäre es, wenn die Auswahlliste selbst nach Typ strukturiert wäre - aktuell ist bei einer Quelle oder bei einem Ziel nur "Alias" und "Netzwerk" getrennt.

[ACME-Server]

Ich habe folgendes verstanden:

1. Du hast zwei interne CAs in OpnSense. Haken dran.
2. Diese können per ACME Zertifikate ausstellen. Wie das?

Bei 2 verlierst Du mich. ACME ist ein Protokoll/Verfahren, mit Hilfe dessen man Zertifikate ausstellen kann. OpnSense kann zwar Zertifikate ausstellen, unterstützt m.W. dazu aber nicht das ACME-Verfahren als ACME-Server. ACME wird nur per Plugin in der Rolle als ACME-Client, d.h. als Anforderer, nicht als Aussteller von Zertifikaten in OpnSense unterstützt.

Unabhängig davon werden in jedem Client natürlich nur die in der CA-Chain eingetragenen Root-CAs unterstützt. Wenn Du also auf einem Client per Curl irgend etwas abrufst, was von einer Deiner CAs ausgestellt wurde, musst Du auf dem entsprechenden Client auch die ausstellende CA eingetragen haben oder per Curl-Switch die Verifikation abschalten. Bei OpnSense selbst geht das elegant über "System: Trust: Authorities".

Systematisch testen. Wird der zu erreichende Hostname korrekt aufgelöst (nslookup)? IPv4 und IPv6 (-query=A / -query=AAAA)? Falls nein -> DNS.

Kann man den Host pingen bzw. ist der für den Dienst zuständige Port geöffnet (nmap -Pn -pX -4)? A. von der OpnSense aus und b. vom LAN aus?

Falls A nein: Routing? Falls B nein: Firewall-Regeln oder NAT?

Yes, GUI and wg0.conf will agree, but eventually, the contents of config.xml will overwrite wg0.conf again, destroying your efforts.

If you want to do such a thing, use the OpnSense API like already correctly answered in answer #1.