Messages

I wonder what you are doing different from us.

Regardless of whether I save the file via the web UI or via sftp or Nextcloud, I can always see the timestamp in the name. And via Github, I even see the versions directly (together with the timestamps of the changes).

Also, in the history, I can diff any two versions.

Honestly, I do not understand how you cannot see the timestamps of your configuration backups. For me, the backups are named like "config-OPNsense.xxx.yy-20250718013839.xml", so I see both the timestamp and the hostname of the device I backup.

And of course, if you have to setup the device from scratch, you have to get the config.xml into your device first. You will have to fetch it from your storage server, be it Github, Nextcloud or an sftp server. Mind you, all of these are types of storage, not neccessarily cloud instances - you can well host any of them them in your own LAN and transfer the backups locally to a USB stick to use during install.

I use pictures as well with no problems - yet I have not tried one that uses >10 MByte in base64 coding.

The speed is so ridiculously close to exactly 1 Gbit/s that I would believe the negotiated link speed is at 1 GBit/s for one or both interfaces. Did you inspect the settings? With these types of interfaces, often times it is neccessary to manually set link speeds.

From what that shows, the listed ports are transmitted one per line, separated by a newline character, not by a comma. A range would probably be given by 1:18, not 1-18.

Tja, das ist deckungsgleich mit dem, was Du von außen gesehen hast. Mir ist immer noch schleierhaft, was auf Ports 8080,8112,8228 und 1011 läuft.

Port 137 und 139 könnten aus Sicherheitsgründen vom Provider geblockt sein, weshalb Du die von intern nicht mehr siehst.
3128 ist der Squid-Proxy, 80 und 443 wahrscheinlich das Web-UI Deiner OpnSense. Anscheinend alle offen.

Das können an sich nur Floating-, WAN- oder Portweiterleitungsregeln sein, die fehlerhaft angelegt sind. Per Default lässt OpnSense nichts rein.

Du hast nicht den selben Scan durchgeführt wie von extern. Das zuletzt waren nur die wichtigsten Ports, nicht 1-65535.

Dann sind noch zwei weitere Fragen offen: Was zeigt der DS-Lite Test und was passiert, wenn Du von innen scannst?

Außerdem kannst Du auch von zu Hause einen solchen Scan anstoßen, z.B. hier: https://pentest-tools.com/network-vulnerability-scanning/port-scanner-online-nmap

Ich denke immer noch, dass die Ergebnisse auf eine Fehlmessung hindeuten, weil sie offene Ports anzeigt, wo gar keine sind. Selbst, wenn Du eine Fehlkonfiguration hättest, gibt es nicht solche Ergebnisse.

Du hast nicht zufällig den Scan durchgeführt, während der Wireguard-Tunnel zu Deinem Netz aktiv war, oder?

Your problem has nothing to do with the OP's problem. Please open new a new thread in such cases.

Obviously, you have allocated 10 GByte of virtual memory, of which most is free. Memory usage of FreeBSD within a Proxmox VM will always be shown as ~90% in Proxmox, regardless of how much is really in use within the VM.

If your VM stops working, then it is because you overcommitted the memory and then, the OOM reaper will stop VM processes as needed. You should be fine with much less allocated memory for your OpnSense VM. 4 GByte should usually be enough, so your overall memory consumption will be 6 Gbytes less and if that can be met, there will be no more process killing.

Beides.

1&1 VDSL macht teilweise DS-Lite. Du würdest es typischerweise daran sehen, dass die in OpnSense angezeigte WAN-IP eine aus dem Bereich 100.64.0.0/10 oder eine RFC1918 ist. Diese unterscheidet sich oft auch von der IP, die nach außen sichtbar wird, wenn man Verbindungen aufbaut.
Das würdest Du sehen, wenn bei https://wieistmeineip.de eine andere WAN-IP angezeigt wird als in Deinem Dashboard.

Es gibt hier auch einen Test dafür: https://ip.zuim.de/

Wenn das kein voller Dual-Stack ist, dann hast Du ein Router-behind-Router-Szenario, bei dem Du Dir die WAN-IP mit mehreren Kunden teilst. Es ist dabei nicht möglich, einen Port per IPv4 weiterzuleiten (der wäre nur für den Provider selbst erreichbar), bzw. bewirkt es nichts.

Bei Scans von außen erreichst Du also gar nicht Deine OpnSense, sondern den vorgeschalteten Router.

Kea is DHCP and DHCP only. So, if your DNS is no longer available, it cannot be blamed on Kea, but on whatever you use for DNS (probably Unbound). That is, unless Kea distributes the wrong IP for the DNS server to the clients.

Das sollte so gehen. Du musst halt ein VLAN (7) zur Trennung des PPPoE-Traffics einrichten. Wenn Du auf die Oberfläche des Glasfaser-Modems drauf willst, zusätzlich noch eins für untagged Traffic am 2.5 GBit/s Port. Die beiden VLANs schaltest Du dann als separate Interfaces auf die OpnSense.

Scan mal von innen Deine OpnSense. Ich wüsste nicht, wie die Ports 8080, 8118, 137,139 usw. überhaupt auftauchen sollten, weil die ja schon lokal nicht offen sind - wie also von außen?

Hast Du die richtige IP gescannt? Hast Du einen DS-Lite-Anschluss?

Meine NI sagt: Glaskugel ist kaputt, zu wenig Information.

Unter Voraussetzung wahrscheinlicher Annahmen (nämlich: Du hast aus Deinem LAN den Scan gestartet und nicht von der WAN-Seite aus) würde ich vermuten, dass die standardmäßig auf dem LAN-Interface vorhandene Allow-Any-Regel den Zugriff auf alle Ports auf der OpnSense erlaubt.

Dieser Scan kann eigentlich kaum von außen stattgefunden haben, da Du mutmaßlich nur eine öffentliche IPv4 (hast Du die gescannt?) hast und outbound NAT jeden Zugriff verhindert, falls keine Portweiterleitungen eingerichtet wurden, was Du ja ausschließt.

Wenn Du das doch von außen gemacht hast, stellen sich Fragen: Was für ein WAN-Anschluss ist das, wie ist die Topologie?

How did you generate the SSH key on OpnSense? Just via the command line using ssh-keygen? In that case, it will be stored into /root/.ssh/identity, if you do not specify otherwise.

The web UI needs it to be setup correctly by pasting the key which looks like:

Code Select Expand

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
...
eQ69Cx/pRf8kqkgLOr/YAAAACXJvb3RAYmxvYgECAwQ=
-----END OPENSSH PRIVATE KEY-----

into the SFTP settings. That in turn will create the /conf/backup/sftp/identity with the correct contents.

Normalerweise sind es die ipflags, die nicht passen. Kann aber auch sein, dass die TCP-Sequence-Nummer nicht mehr passt.

Wenn man das analysieren will, muss man einen Paketmitschnitt machen und die in Wireshark importieren, dann kann man sehen, wie die Flows laufen. Ich habe das nie gemacht, solange keine Probleme auftreten. Das ist der tiefere Grund, wieso man normalerweise die Default-Block-Regel nicht protokollieren lässt.

Ich mache eher explizites Logging bei Regeln für bestimmte Blocklisten, wo ich sehen kann, welche "echten" Angriffe reinkommen.

Schau Dir die Details des Blocks an. Meistens sind es out-of-state Pakete. Die können entstehen, wenn eine Verbindung in der Firewall bereits einen Timeout hatte, der Webserver aber weiterhin versucht, die bestehende TCP-Verbindung zu nutzen.