Messages

I just found it very convenient being able to add the hostnames to the table with a click. Now that click removes the IP addresses which are my primary reference when using the live log. I do not necessarily know in the first place to which subnet a hostname belongs. So I have to disable / enable that checkmark multiple times while looking at the logs. In my eyes this is a step backwards in terms of usability.

Maybe this can be optional?

Can we somehow get the old behavior back?

Hi,

prior to the 25.7.10 release, when ticking the "Lookup hostnames" checkbox in the firewall live log, a new column appeared. Now, when that box is ticked, the "Source" column is replaced by the "Source Hostname" column. This means we can no longer see both the IP address and the hostname simultaneously in the live view.

Is this a bug or an intended change?

Zweite Frage habe ich wohl beantwortet. Ich konnte von einem anderen Gerät ein Portmapping auf die 192.168.100.20 anlegen, nicht jedoch auf andere Adressen. Die ACL bestimmt also nur, welche Ports auf welchen Geräten geöffnet werden können.

Wie kann ich also das Gerät 192.168.100.20 zum "Master" machen, so dass es Portweiterleitungen auf alle anderen Geräte im Netzwerk anlegen kann?

Hallo,

mit dem 25.7.9 Update gibt es neue Optionen für das UPnP IGD & PCP Port Mapping.

Erste Frage:

"The access control list (ACL) specifies which IP addresses and ports can be mapped. IPv6 is currently always accepted unless disabled."

Also kann ich hier keine Regel für IPv6 definieren? Ich habe ACLs definiert, damit nur bestimmte Hosts bestimmte Ports öffnen dürfen. Ich muss also IPv6 Mapping komplett deaktivieren, wenn ich nicht möchte, dass irgendwelche Geräte irgendwelche Regeln erstellen dürfen?

Zweite Frage:

"Allow third-party mapping: Allow adding port maps for non-requesting IP addresses."

Bedeutet das, ich lege nun eine ACL an, z.B. "allow 1-65535 192.168.100.20/32 1-65535" und dieses Gerät darf dann Port Mappings auf jede IP-Adresse anlegen? Oder lege ich damit komplett die ACLs lahm?

Kurze Rückmeldung zum Thema: Seit dem DSLAM Line-Reset ist das Problem vollständig verschwunden. Alles funktioniert seit Juli wieder einwandfrei.

Das Problem lag offensichtlich auf Seite der Telekom und nicht bei mir.

Das schon. Aber auch in einem Platzhalter sollte man doch Beispiele verwenden, die sich zumindest an gängigen Standards orientieren. meinedomain.internal oder meinedomain.home.arpa wären da als Platzhalter besser geeignet, finde ich 😉

Auf dem Host dahinter laufen mehrere Dienste die zum Teil viele Ports benötigen. Daher wäre mir das zu fummelig für jeden Port einzeln eine NAT-Regel anzulegen.

Dafür gibt es Aliase. Du bündelst die Ports in einem Alias und legst mit diesem dann eine NAT-Regel an.

Woher der DNS Suffix kommt "local" erschließt sich mir nicht. Habe das nirgends eingetragen.

.local ist mDNS https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS

Offiziell vorgesehen für Heimnetze ist .home.arpa; .internal kommt neu dazu und ist in der Standardeinstellung noch keine local-zone in Unbound.

Man könnte das RAM widget auch anpassbar machen, dann kann sich jeder das einstellen was er sehen möchte.

Das wäre natürlich sehr cool.

Außerdem würde dann bei allen Usern auf dem Dashboard plötzlich deutlich mehr belegter RAM angezeigt. Welche Diskussionen das auslöst kann man sich vorstellen.

Daher sehe ich von einem Pull Request erstmal ab.

Ich fände das schon sinnvoll. Denn der im tmpfs belegte RAM steht dem System ja definitiv nicht zur Verfügung. Daher finde ich die Anzeige im Widget irreführend. Und /var/log und /var/tmp als tmpfs ist ja nicht unüblich auf der OPNSense.

Bei Upstream (FreeBSD) liegt kein Problem vor. Der Speicher wird als "inactive" gezählt. Schon immer. Die Frage ist ob das Widget "inactive" als frei oder als belegt anzeigen soll.

Achso, ja ich meinte auch eigentlich als fix für das Widget im OPNSense Repo. Nicht upstream bei FreeBSD.

Das sieht schon weitaus näher an der Realität aus, danke :)

Diesen Patch kann ich einfach so anwenden, ohne für zukünftige Updates irgendwas kaputtzumachen? Ich bin da eher vorsichtig :)

Wenn das sinnvoll ist, könnte man das ja mal Upstream einbauen?

Swap habe ich jetzt mal mit swapoff -a und auskommentieren der Zeilen in der fstab ganz abgeschaltet. Brauche ich nicht bei der Menge an RAM. Die Firewall loggt um die 700 MB / Tag, da reichen die 32 GB tmpfs locker für 31 Tage.

Aber wenn 18 GB an filter Logs im tmpfs liegen, dann muss der RAM doch belegt sein?

Hm, das verstehe ich nicht. Das 32 GB tmpfs ist doch fest. Wenn der RAM voll läuft, werden dann Logs gelöscht? Wie soll das funktionieren?

Wenn da 18 GB Logs im tmpfs legen, gehe ich davon aus, dass dieser RAM anderen Anwendungen nicht zur verfügung steht. Falsch?

Ich habe mittlerweile etwas aufgeräumt und nur noch 5,8 GB Logs in /var/log.

Top sagt:

Code Select Expand

Mem: 361M Active, 20G Inact, 4410M Wired, 104K Buf, 38G Free
Die Anzeige des Widget stimmt immer noch nicht. Das zeigt 2,4 GB belegten RAM an, während alleine die Logs 5,8 GB im tmpfs belegen.

Code Select Expand

Filesystem    Size    Used   Avail Capacity  Mounted on
tmpfs          32G    5.9G     26G    18%    /var/log