Messages

Würde wahrscheinlich auch alles gut gehen. Ich bin da nur immer etwas übervorsichtig 🙃 Die neusten Updates sind aber auch jeden Fall ein Muss.

Hast du deine Nextcloud im Internet veröffentlicht? Prinzipiell ist es normal, dass aus dem Internet ständig, im Sekundentakt, irgendwelche Verbindungsversuche auf die eigene IP-Adresse ankommen. Das sind meistens Scan-Bots, sowohl in guter als auch in böser Absicht.

Eine kurze Suche bei AbuseIPDB bestätigt das: https://www.abuseipdb.com/check/45.190.151.203

Wenn du jetzt deine Nextcloud im Internet veröffentlicht hast (das würde ich persönlich mich niemals trauen, lieber über VPN) dann kannst du zumindest eine GeoIP Blocklist erstellen. Dann können z.B. nur deutsche Adressen auf deine freigegebene Ressource zugreifen.

Wie genau er das dynamisch ändert weiß ich auch nicht, aber ich kann sagen, dass er die IP-Adressen im roten Rahmen vom Screenshot innerhalb weniger Sekunden von alleine ändert :) Wie gesagt, das sind von der Firewall selbst erstellte Regeln. Da ich in der VPN-Konfiguration als Endpunkt eine DynDNS Adresse angegeben habe, scheint er die Regel ständig zu aktualisieren.



Aber ja, wenn ich ANY ANY mache, dann wird es natürlich gehen. Ich wollte es einfach nur mal hier dokumentieren, da ich denke, dass das so eigentlich nicht sein soll.

Tatsächlich handelt es sich um einen bzw. 2 IPsec-Tunnel. Das hatte ich in meinem Beitrag nicht erwähnt. Nach Wechsel der Fritzbox WAN-IP-Adresse sehe ich auch im Log vom IPsec der OPNsense keine Pakete mehr von der Fritzbox ankommen. Auch im Log der Fritzbox steht "Timeout" bzw. Gegenstelle nicht erreichbar. Es handelt sich also definitiv um eine Firewall Problem.

Folgendes Problem:
Ich habe 2 VPN Site-2-Site Tunnel zwischen meiner OPNsense und 2 Fritzboxen am laufen. Diese Tunnel laufen an sich auch ohne Probleme. Sowohl die IPv4 WAN-Adressen der Fritzboxen als auch die der OPNsense sind dynamisch und nicht fest. Nun passiert es, dass bei einem Wechsel der WAN-IP-Adressen der Fritzboxen sich die VPN-Tunnel nicht von alleine wieder neu aufbauen. Ich hatte erst eine Fehlkonfiguration der VPN-Parameter vermutet, konnte es aber jetzt auf die Firewall-Regeln eingrenzen. Natürlich habe ich in den VPN-Parametern dynDNS Adressen als Endpunkte konfiguriert. Ändert sich nun eine WAN-IP-Adresse, so kann man sehen, dass sich diese Adresse auch innerhalb weniger Sekunden im "Automatically generated rules" Ruleset ändert. Also der Inhalt der automatisch generierten Rule für den VPN-Tunnel ändert sich dynamisch. Trotz alledem scheint die Firewall die neue WAN-IP-Adresse zu blockieren. Wenn ich jetzt eine minimale Änderung am Firewall-Regelwerk durchführe, sei es einfach bei einer völlig anderen Regel das Logging einmal ein- und wieder auszuschalten, kommt der VPN-Tunnel sofort hoch.

Meine Vermutung also:
Der Inhalt der automatisch generierten Firewall-Regel für den VPN-Tunnel ändert sich wie gewünscht innherlab weniger Sekunden dynamisch zur neuen WAN-IP-Adresse des VPN-Endpunktes, das Regelwerk der Firewall scheint aber dabei nicht neu geladen zu werden. Wahrscheinlich arbeitet die Firewall dann noch mit einem im Cache gespeichertem Regelwerk, wo noch die alte WAN-IP-Adresse eingetragen ist. Sobald man minimale Änderungen am Firewall-Regelwerk vornimmt und diese "Applied", wird das Regelwerk neu geladen und dann wird auch die neuen WAN-IP-Adresse verwendet.

Ist das nun ein Bug? Ich vermute ja, da sonst dynamische Einträge im Firewall-Regelwerk keinen Sinn haben, wenn sie eh nicht sofort übernommen werden. Gibt es hier evtl. eien Workaround, um das Regelwerk dynamisch neu zu laden?

Sofern du als Accesspoint einen Ubiquiti hast, da gibt es seit kurzem PPSK. Du hast eine SSID, kannst aber unterschiedliche Passwörter vergeben, welche dann alle in ein anderes VLAN gehen. Oder du baust eine eigene SSID nur für die Kinder. Hilft natürlich dann nur bei drahtlosen Geräten  ;D

Ich wollte mich nochmal zurückmelden. Danke für eure Hinweise. Ja, leider habe ich die Version mit dem 13900 :( Ich habe jetzt testeshalber was im BIOS mit den E-Cores eingestellt. Bisher läuft die Firewall seit 6 Tagen. Mal abwarten...

Wie der Titel schon verrät, habe ich seit einiger Zeit alle paar Tage einen großen Crash meiner OPNsense. Betrieben wird das ganze bare metal auf einem Minisforum MS-01. Ich bekomme auch einen Crashreport dazu und schicke den immer feißig ab an die Entwickler. Das Problem tritt bei der aktuellsten Firmware, aber auch mit der vorherigen Firmware auf. Gibt es irgendwas, dass ich tun kann. Evtl. wird man aus dem Crashlog schlau? Irgendwie ist das so doof, weil ich immer damit rechnen muss, dass gleich wieder ein Crash kommt. Ich bezweifel, dass das Einsenden der Crashreports mir schnell weiterhelfen wird.

Was auffällig ist, ist dass es immer einen Kernel Panic gibt:

Code Select Expand

Fatal trap 9: general protection fault while in kernel mode
cpuid = 15; apic id = 36
instruction pointer = 0x20:0xffffffff811464b2
stack pointer         = 0x28:0xfffffe0125e7cbf0
frame pointer         = 0x28:0xfffffe0125e7cc20
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 69240 (python3.11)
trap number = 9
panic: general protection fault
cpuid = 15
time = 1720868700
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0125e7ca10
vpanic() at vpanic+0x151/frame 0xfffffe0125e7ca60
panic() at panic+0x43/frame 0xfffffe0125e7cac0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe0125e7cb20
calltrap() at calltrap+0x8/frame 0xfffffe0125e7cb20
--- trap 0x9, rip = 0xffffffff811464b2, rsp = 0xfffffe0125e7cbf0, rbp = 0xfffffe0125e7cc20 ---
pmap_try_insert_pv_entry() at pmap_try_insert_pv_entry+0xc2/frame 0xfffffe0125e7cc20
pmap_copy() at pmap_copy+0x570/frame 0xfffffe0125e7ccc0
vmspace_fork() at vmspace_fork+0xca0/frame 0xfffffe0125e7cd40
fork1() at fork1+0x428/frame 0xfffffe0125e7cda0
sys_fork() at sys_fork+0x54/frame 0xfffffe0125e7ce00
amd64_syscall() at amd64_syscall+0x10c/frame 0xfffffe0125e7cf30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0125e7cf30
--- syscall (0, FreeBSD ELF64, syscall), rip = 0x82562adca, rsp = 0x82112bce8, rbp = 0x82112bd40 ---
KDB: enter: panic
panic.txt0600003014644457534  7151 ustarrootwheelgeneral protection faultversion.txt0600007514644457534  7555 ustarrootwheelFreeBSD 13.2-RELEASE-p11 stable/24.1-n255023-99a14409566 SMP

Code Select Expand

/var/crash/textdump.tar.0:

ddb.txt06000014000014644457534  7112 ustarrootwheeldb:0:kdb.enter.default>  run lockinfo
db:1:lockinfo> show locks
No such command; use "help" to list available commands
db:1:lockinfo>  show alllocks
No such command; use "help" to list available commands
db:1:lockinfo>  show lockedvnods
Locked vnodes
db:0:kdb.enter.default>  show pcpu
cpuid        = 15
dynamic pcpu = 0xfffffe009fce1300
curthread    = 0xfffffe011fff8720: pid 69240 tid 106457 critnest 1 "python3.11"
curpcb       = 0xfffffe011fff8c30
fpcurthread  = 0xfffffe011fff8720: pid 69240 "python3.11"
idlethread   = 0xfffffe00c7262000: tid 100018 "idle: cpu15"
self         = 0xffffffff82c1f000
curpmap      = 0xfffffe0124667128
tssp         = 0xffffffff82c1f384
rsp0         = 0xfffffe0125e7d000
kcr3         = 0x80000002326954e8
ucr3         = 0x8000000240877ce8
scr3         = 0x240877ce8
gs32p        = 0xffffffff82c1f404
ldt          = 0xffffffff82c1f444
tss          = 0xffffffff82c1f434
curvnet      = 0
db:0:kdb.enter.default>  bt
Tracing pid 69240 tid 106457 td 0xfffffe011fff8720
kdb_enter() at kdb_enter+0x37/frame 0xfffffe0125e7ca10
vpanic() at vpanic+0x182/frame 0xfffffe0125e7ca60
panic() at panic+0x43/frame 0xfffffe0125e7cac0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe0125e7cb20
calltrap() at calltrap+0x8/frame 0xfffffe0125e7cb20
--- trap 0x9, rip = 0xffffffff811464b2, rsp = 0xfffffe0125e7cbf0, rbp = 0xfffffe0125e7cc20 ---
pmap_try_insert_pv_entry() at pmap_try_insert_pv_entry+0xc2/frame 0xfffffe0125e7cc20
pmap_copy() at pmap_copy+0x570/frame 0xfffffe0125e7ccc0
vmspace_fork() at vmspace_fork+0xca0/frame 0xfffffe0125e7cd40
fork1() at fork1+0x428/frame 0xfffffe0125e7cda0
sys_fork() at sys_fork+0x54/frame 0xfffffe0125e7ce00
amd64_syscall() at amd64_syscall+0x10c/frame 0xfffffe0125e7cf30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0125e7cf30
--- syscall (0, FreeBSD ELF64, syscall), rip = 0x82562adca, rsp = 0x82112bce8, rbp = 0x82112bd40 ---
db:0:kdb.enter.default>  ps

Liebe Grüße

Das kannte ich noch nicht, sehr interessant! Ich hatte heute morgen kurz auf meinen MS-01 geschaut, die Einstellung ASPM auf die Schnelle aber nicht gefunden. Ist das irgendwo versteckt?

Grüße

Hallo zusammen,
ich betreibe bei mir zu Hause eine kleine Netzwerinfrastruktur mit einer OPNsense auf meinem neu angeschafften Minisforum MS-01. Mein Telekom Glasfaser-WAN terminiere ich direkt auf der OPNsense ohne Probleme. Zudem verwende ich im LAN 7 VLANs. Am LAN-Anschluss hängt ein Ubiquiti Switch, der die VLANs auf die einzelnen Ports/Geräte verteilt.

Seit dem ich auf die neue Appliance umgezogen bin, stelle ich fest, dass immer wieder mal nach 24-48 Stunden der DHCP-Server (ISC DHCPv4) seinen Dienst einstellt und ich finde einfach nicht die Ursache. Der Fehler stellt sich dar indem die Clients nach Lease-Ablauf ihre IP-Adresse verlieren und keine neue bekommen. Dies ist auch im Log vom DHCP zu sehen. Ich habe 2 Wireshark Mitschnitte, einmal direkt auf meinem PC und einmal auf der OPNsense im entsprechenden VLAN gemacht. Dabei stellte sich heraus, dass mein PC definitiv "DHCP-Offers" schickt. Diese kommen aber im VLAN auf der OPNsense nie an. Nachdem ich die OPNsense neustarte ist das Problem erstmal wieder weg. Ein einfaches neustarten des DHCP-Dienstes hat keine Wirkung.

Woran könnte das liegen und welche Troubleshooting-Ansätze könnte ich noch verfolgen? In den allgemeinen Logs sind keine Errors zu sehen.

OPNsense 24.1.8-amd64


Liebe Grüße

Hallo zusammen,
gibt es eine Möglichkeit Firewall-Regeln zu monitoren und Hits irgendwie weiterzuleiten? Eventuell über SNMP und einer Monitoring-Lösung meiner Wahl (incinga, PRTG usw.). Ich würde ganz gerne zu bestimmten Firewall-Hits eine Alarmierung bekommen, gerne auch per Push auf mein Handy.

Grüße

Befindet sich dein Proxmox im selben Subnetz/VLAN wie der Client, von dem du drauf zugreifen willst?
Wenn ja, sind der Client und der Server am selben Switch angeschlossen oder sind sie auf unterschiedlichen Interfaces der OPNsense angeschlossen? Wenn nicht im selben Subnetz/VLAN, hast du eine Allow-Regel erstellt?

Grüße

Die Funktion die ich mir wünschen würde ist eben eine Firewallregel, die nur für bestimme SRC IPs greift, die in einem Objekt gespeichert sind. + eine Funktion die mir die SRC IP Objekt automatisch und dynamisch erstellt für die IPs die authentifiziert sind.
Also User Authentifiziert sich an einem Portal, seine IP wird in ein Objekt geschrieben, zusammen mit einer Zeitstempel. Nach einer konfigurierbaren Zeit wird die IP aus diesem Objekt entfernt.
Dann könnte ich einen Regel definieren: src:authentifizierteIPs, dst:MinecraftSrv, Accept.

Wie du selbst schon gesagt hast, könnte man das mit einer "URL Table" unter Aliases realisieren, ähnlich der Spamhaus-Liste: https://www.spamhaus.org/drop/drop.txt. Diese Liste müsstest du per Scripts automatisch befüllen bzw. leeren lassen. Die IPs müsstest du mit einem Webserver, der die Authentifizierung macht, einsammeln und dann eben mit dem Script an die URL-Table weitergeben. Der Webserver kann sogar wo anders stehen (z.B. wenn man eh schon ein Hostingpaket bei Strato etc. hat, um den Server nicht im eigenen Netz stehen zu haben). Oder wenn man es selbst hosten will z.B. mit einem Nginx. Am Ende bleibt die philosophische Frage, ob der Webserver dann nicht das größere Einfallstor ist, andererseits selbst wenn jemand auf den Webserver kommt, er könnte sich dann im schlimmsten Fall (eine vernünftige DMZ vorausgesetzt) nur selbst whitelisten und müsste dafür auch erstmal wissen, dass der Webserver in Verbindung mit dem Minecraftserver steht.

Alles in allem schon viel Aufwand aber definitiv ein cooles Projekt :) Manchmal geht es ja auch nicht um die Sinnhaftigkeit sondern ums Schaffen, also viel Erfolg!

Ok, dann deckt sich deine Antwort mit dem, was ich mir auch schon gedacht habe. Vielen Dank für deine ausführliche Erklärung  :)

Hallo,
in diesem YouTube Video:

https://www.youtube.com/watch?v=IsUFzuhwsME

erklärt jemand, wie man Portforward Regeln anlegt. Zum Punkt Interface sagt er bei Minute 4:16, dass man für eine funktionierende NAT-Reflection nicht nur das WAN-Interface sondern auch die Interfaces auswählen muss, die innerhalb des Netzwerks, also auf der LAN Seite liegen, von denen aus man auf den von außen erreichbaren Dienst zugreifen möchte. In meinem Fall ist das ein Ts3-Server. Bisher hatte ich für die Portforward-Regel immer nur das WAN-Interface ausgewählt. Wenn ich mich nun vom LAN-Interface zum Ts3-Server verbunden habe, könnte ich in den Serverlogs sehen, dass ich mich mit meiner internen Adresse (192.168....) verbunden habe, die Reflection also super funktioniert.

Deshalb frage ich mich jetzt, hat er in dem Video unrecht oder handelte es sich bei ihm (wie von ihm bereits vermutet) um einen Bug in seiner OPNsense Version? Oder habe ich das ganze falsch verstanden und meine Reflection funktioniert garnicht?

Liebe Grüße