Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 10 subscribers
  • Views 2113 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

BUG: unable to handle kernel NULL pointer dereference at 00000000000018

Marcel Bro

Hallo,

erst einmal ein paar Infos zu meiner Umgebung:

- virtualisierte XG auf Proxmox 8.0.3 (4 CPUs, 6GB RAM) im HA active-passive Mode

- Board auf dem die primäre Firewall läuft: Odroid H3

Völlig zufällig (mal nach ein paar Stunden oder ein paar Tagen..) friert die virtualisierte primäre Firewall ein mit folgendem Fehlerbild:

Screenshot aus der Proxmox Console. Die VM lässt sich nicht mehr (in der Console) bedienen und ist netzwerktechnisch auch nicht mehr erreichbar.

Bereits habe ich folgendes versucht:

- XG neuinstalliert + Config Backup eingespielt, HA neu eingerichtet

Der Fehler scheint nur auf der primären FW aufzutauche (Andere VMs in der Proxmox Umgebung machen keine Probleme). Die sek. FW läuft auf einem ähnlichen Board (Odroid H2)

Den Fehler gab es wohl mal in Zusammenhang mit SSL VPN. Ist aber schon Jahre her...

community.sophos.com/.../sophos-notification-advisory-sophos-xg-firewall-reboot-after-upgrading-to-v18-if-ssl-vpn-is-being-used

Ebenfalls scheint dieser Fehler nicht gerade neu zu sein und ist schon in der UTM aufgetaucht:

https://www.avanet.com/en/blog/sophos-utm-9-5-new-features-for-sandstorm-and-web-application-firewall/

Hat jemand eine Idee was man hier noch machen könnte?

Viele Grüße



This thread was automatically locked due to age.
Parents
  • 0

    Hallo,

    du schriebst „nur auf der primären FW“ …

    … egal welcher Node gerade der aktive ist?

    oder immer auf der gleichen Hardware?


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 0 in reply to dirkkotte

    Hi,

    sorry ich meinte immer die selbe Node(1). Egal ob diese Primär oder Sekundär ist im HA.

    Scheint also irgendwo an der Hardware des Hosts zu liegen..

    Marcel

  • 0 in reply to Marcel Bro

    oder an proxmox …

    wenn du die beiden Instanzen mal über Kreuz auf den hypervisoren tauschst, wäre klar, ob die xg mitverursachter ist.

    evtl brauchen die anderen VM‘s ein anfälliges Feature gerade nicht und daher laufen die stabil.

    Hast du noch weitere linux-vm‘s laufen?


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 0 in reply to dirkkotte

    getauscht hatte ich damals schon als es "angefangen" hat. Da traten keine Probleme auf

    Aber damals war der Absturz auch komischerweise regelmäßiger als jetzt, wo es sein kann das es nach einer Stunde Uptime passiert oder erst nach Tagen...

    Linux VMs laufen nicht auf dem selben Host, wo die Node 1 sich befindet, nicht. Nur unprivilegierte LXC's und eine Windows VM.

    Ich glaube wenn es so weitergeht werde ich die XG mal auf einen Host schieben wo nur diese eine VM dann läuft. Zur Not auch baremetal

  • 0 in reply to Marcel Bro

    Ich würde mal genau die CPU und deren Parameter im BIOS überprüfen. Sind alle hosts hardwaretechnisch identisch?

    Sind bei der Node1 VM vielleicht noch irgendwelche Hardwarekomponenten direkt durchgeschleift? GPU, Disk, etc.?

  • 0 in reply to LHerzog

    Hosts sind hardwaretechnisch nicht gleich. CPU ist jeweils ein Intel N5105 bei der Node1 und Node2 ist ein Intel J4115. Ansonsten sind die Einstellungen gleich was RAM, Disk usw. angeht..

    Ich habe bei der Node1 einfach mal den CPU auf Host gesetzt, wodurch CPU technisch mehr Anweisung möglich sein sollen anstatt bei KVM64. Ist bei der Node2 zwar nicht so eingestellt aber da gibt es ja auch keine Probleme. Momentan Uptime fast seit 5 Tagen.. was aber noch lange nichts bedeutet

Reply
  • 0 in reply to LHerzog

    Hosts sind hardwaretechnisch nicht gleich. CPU ist jeweils ein Intel N5105 bei der Node1 und Node2 ist ein Intel J4115. Ansonsten sind die Einstellungen gleich was RAM, Disk usw. angeht..

    Ich habe bei der Node1 einfach mal den CPU auf Host gesetzt, wodurch CPU technisch mehr Anweisung möglich sein sollen anstatt bei KVM64. Ist bei der Node2 zwar nicht so eingestellt aber da gibt es ja auch keine Probleme. Momentan Uptime fast seit 5 Tagen.. was aber noch lange nichts bedeutet

Children
Unfiltered HTML