OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of Viplex92 »
  • Show Posts »
  • Topics
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

  • Messages
  • Topics
  • Attachments

Topics - Viplex92

Pages: [1]
1
German - Deutsch / Ständige Crashes meiner OPNsense
« on: July 16, 2024, 03:50:13 pm »
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]
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]
/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

2
German - Deutsch / Eigenartige DHCP Fehler
« on: June 05, 2024, 09:57:16 pm »
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

3
German - Deutsch / Monitoring von Firewall-Regeln
« on: March 28, 2024, 05:26:17 pm »
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

4
German - Deutsch / Verständnisfrage zu NAT-Reflection
« on: February 01, 2024, 10:52:37 am »
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

5
German - Deutsch / Seltsame Leistungseinbrüche bei FTTH-Anschluss DTAG
« on: January 30, 2024, 09:59:39 am »
Hallo zusammen,
vor kurzem habe ich meinen FTTH Anschluss der Telekom bekommen. Gebucht habe ich eine 500Mbit Leitung.
Dazu habe ich das Telekom Glasfasermodem gekauft. Nachdem ich alles angeschlossen und eingerichtet habe lief es so wie es soll. Leckere 580Mbit down und um die 100 Mbit up. Ich habe aber festgestellt, dass nach ein paar Stunden (ca. 6) die Downloadgeschwindigkeit auf ca. 80Mbit zusammenbricht. Der Upload ist davon unberührt. Ein Neuverbinden des PPPoE oder abziehen der Glasfaser aus dem Modem und wieder einstecken bringt keine Beserung. Lediglich wenn ich die OPNsense neustarte ist alles wie so, wie es soll. Der Fehler bzw. der Workaround ist reproduzierbar. Hat evtl. jemand eine Ahnung, woran das liegen könnte? Ich habe da überhaupt keinen Anhaltspunkt. Die CPU der Appliance (nicht virtuell) ist nie über 50% ausgelastet. Ich weiß, dass es einen Flaschenhals mit PPPoE und der ersten CPU gibt. Aber wie gesagt, das Package ist nicht groß ausgelastet.

Glasfaser -> Modem -> WAN-PPPoE(OPNsense) -> Verschiedene VLANs


Vielleicht hat da jemand eine Idee

Pages: [1]
OPNsense is an OSS project © Deciso B.V. 2015 - 2024 All rights reserved
  • SMF 2.0.19 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2