Messages

Hallo, mit 18.1 ist das Thema wieder aktuell: Ich habe erst das Upgrade durchlaufen lassen, Absturz beim Hochfahren. Ok, also Neuinstallation mit dem identischen Ergebnis: Freeze beim Booten mit etwa dieser letzten Zeile:

Timecounter "HPET" frequency ...

Danach passiert nichts mehr. Ich habe gegoogelt und bin darauf gestoßen, folgende Zeile in die loader.conf einzufügen:

hint.hpet.0.clock=0

Damit funktionierte das Hochfahren manchmal, aber auch nicht immer. Gelegentlich hing sich der SATA-Treiber danach mit einem Timeout auf. Überhaupt besteht der Boot-Log mit dem neuen Kernel aus jeder Menge Fehlermeldungen, auch wenn das System dann tatsächlich hochgefahren ist und das nicht erst seit 18.1. Also habe ich erstmal ein Downgrade gemacht.
Testweise habe ich 18.1 auf einem alten Intel NUC mit USB-LAN als zweites LAN installiert. Das ganze hat keine 10 Minuten gedauert und lief sofort.

Kann es sein, dass der Kernel von FreeBSD immer etwas der aktuellen Hardware hinterher hinkt, ähnlich wie Linux? Wäre es sinnvoll, auf ein nächstes Minorrelease zu warten und es dann noch einmal zu versuchen?

Hier mal zur Vollständigkeit im Anhang der komplette Screenshot der korrekten NAT-Einstellungen. Leider schweigt sich das Wiki dazu noch ziemlich aus, lediglich zur pfsense findet man im Netz haufenweise zu dem Thema Tutorials.

Destination ist nicht lan net sondern "WAN IP" - nämlich die IP, an die die Fritzbox die Verbindung weiterleitet.

DAS wars!! Danke danke danke!!   :D :D :D

Ich gebe ehrlich zu, dass ich etwas Schwierigkeiten damit hatte, was nun Destination und was die Source ist. Ich bin immer davon ausgegangen, Source = externe IP, Destination = IP Cam. Da stimmt meine Denke offensichtlich noch nicht ...?

Ich habe mal Screenshots der betreffenden Einstellungen gemacht, aufgrund der Uploadrestriktionen hier erstmal für NAT.

Würde also mal davon ausgehen, dass deine Portweiterleitung auf der OPNsense nicht funktioniert.

Also dass der NAT-Eintrag noch nicht so ganz ok ist? Oder müssen hier noch andere Regeln definiert werden? Aktuell ist folgendes drin:

FLoating: nix
LAN: Bisher nur die Default-Regeln, die alles durchlassen, also "LAN net" mit überall "*" für IPv4 und IPv6
WAN: Testweise auch eine komplette Durchleitung eingebaut, um überhaupt mal eine Verbindung zu bekommen. Also: IPv4 mit überall "*"

Muss ich vielleicht an anderen Stellen noch etwas anpassen, z.B. bei den Interfaces?

Sehe es gerade: Obej steht, dass du 8085 umleitest, bekommst die Verbindung aber von der Fritzbox auf 8080 umgeleitet.

Was den Port angeht: Bin testweise auf 8085 gewechselt, um einen Unterschied im Log zu entdecken (Weiterleitung in der Fritzbox habe ich natürlich auch angepasst). Stimmt also soweit: Aufruf über http://100.100.100.100:8085 schlägt ebenso fehl.

muss in deinem Fall auch im WAN erlaubt sein - gefiltert wird auf OPNsense eingehend.

Habe ich vergessen zu schreiben, ist natürlich auch in WAN ausgeschaltet.  ;)

Würde tcpdump für den Fall mal auf der OPNsense zum testen verwenden.

Hm ... die einzige "Firewall", die ich bisher "konfiguriert" habe, war die der Fritzbox.  :o Daher kann ich damit gerade nicht so viel anfangen. Wäre das quasi ein Sniffer für die OPNSense, um mitzuschneiden, was da passiert?

Übrigens erhalte ich jetzt einen Logeintrag über eine Blockade, aus dem ich aber nur bedingt schlau werde, weil der Port nicht der ist, den ich eingegeben habe. Ursprünglich war die Eingabe: http://100.100.100.100:8080

Im Log stehen nun einige Einträge dieser Art:

Source: 100.100.100.100:25844
Destination: 192.168.1.20:8080 (also die IP der OPN im Netz der Fritzbox)

Was ist das für ein merkwürdiger Port? In jedem Fall läuft hier nun eine Blockade auf.

Alles klar, NAT habe ich angepasst. Dafür schon mal Danke!  :)

Bei Interfaces habe ich bei LAN die Blockade beider Netzarten deaktiviert.

Leider kommt noch immer nichts durch. Ist das normal, dass ein Ping aus dem Netz der Fritzbox auf der WAN-IP der OPN nicht ankommt?

Guten Abend!

Ich habe alles Mögliche versucht und hoffe nun, dass man mir hier den initialen Tipp geben kann. Ich möchte folgendes:

Ich habe als Router und Telefonanlage eine Fritzbox 7490. Dahinter befinden sich einige IP-Cams, die ich vor OPNSense-Zeiten einfach per Portforwarding durchgeroutet hatte, so dass ich die von Außen abfragen konnte. Jetzt möchte ich den Aufbau um eine innere Firewall erweitern, die OPNSense.
Es läuft auch alles, allerdings bekomme ich den Zugriff per NAT ums Verrecken nicht durch die Firewall. Diese befindet sich um Netz der Fritzbox (192.168.1.1) und erhält darin per DHCP immer die WAN-IP 192.168.1.20.

Innerhalb des OPN-Netzes erhält OPN auf LAN die 192.168.2.1 mit aktiven DHCP. Die Cam hat darin z.B. die 192.168.2.10.

Mein bisheriges funktionierendes Verfahren:
Die externe IP-Adresse (z.B. 100.100.100.100) fragt aufg dem entsprechenden Port (z.B. 8080) bei der Fritzbox an und von dieser an die betreffende IP der Cam unter Port 80 weitergeleitet. Schema:

ext. IP:8080 => Fritzbox:8080 => Cam:80

Jetzt beabsichtigt:
Die externe IP-Adresse (z.B. 100.100.100.100) fragt auf dem entsprechenden Port (z.B. 8080) bei der Fritzbox an und von dieser an die OPN (192.168.1.20) weiterhin mit Port 8080 weitergeleitet. Dort wird die dann per NAT auf die Cam (192.168.2.10) auf Port 80 weitergeleitet.  Schema:
ext. IP:8080 => Fritzbox:8080 => OPN:8080 => Cam:80

Soweit die Theorie. Praktisch kommt wirklich nichts durch! Ich habe in der OPN folgende Einstellungen:

NAT - Port Forward:
Interface: WAN
TCP/IP: IPv4
Protocol: TCP
Source: 192.168.1.1 (Fritzbox)
Source port range: any to any (extra großzügig)
Destination: LAN net
Destination port range: 8085 - 8085
Redirect target IP: Single host or Network => 192.168.2.10
Redirect target port: 80
NAT reflection: Use system default
Filter rule association: Pass

Ich habe hier schon alles mögliche durchprobiert, u.a. zusätzlich auch eine Firewallregel, die komplett aus * besteht, also alles durchlässt.
Das Resultat ist aber, dass die OPN die Anfrage komplett ignoriert, so als ob die Weiterleitung von der Fritzbox nicht funktioniert. Es erscheint nicht mal ein Eintrag im Log über eine blockierte Anfrage.  :-\ Übrigens funktioniert auch ein Ping aus dem Fritzboxnetz auf die OPN nicht.

Hat jemand einen Tipp??

So, also lange warten hat geholfen. Nach gefühlten 397 mal Timeout ging es tatsächlich weiter und die Installation lief durch. Was nicht funktionierte, war die Installation per USB-Stick. Dieser wird im Laufe der vielen Timeouts unmounted. Mit der SD-Karte lief alles bestens, auch wenn die Geschwindigkeit sehr zu wünschen übrig ließ. Er blieb während der Installation locker eine Stunde bei 73% stehen, aber die HD-LED und der unregelmäßig drehende Slash signalisierte mir, dass er noch immer was tut.
Jetzt läuft alles und ich kann per Web konfigurieren. Nun muss ich erstmal schauen, wie ich mir SSH mit einem dafür passenden User scharf schalte. Aktuell meckert mein Mac wegen dem Zertifikat.

Edit: SSH-User ist auch am Start. Danke für den entscheidenden Hinweis.

Allerdings kommt der erwähnte Timeout noch immer und sorgt so für eine ziemlich lange Bootzeit. Ich habe gelesen, dass sich durch Modifikation einiger Kerneldateien das Problem beheben lässt. Ist das sinnvoll oder sollte ich eher auf ein Update von FreeBSD warten?

Und noch eine Frage: Gibt es im System einen Watchdog, oder muss der separat installiert werden?

die Meldungen kommen mir vim CI323 bekannt vor, abder läuft OPNsense soweit ganz gut.
gibst du immer gleich auf oder wie lange wartest du mit der Meldung am Schirm, bis du es als Absturz klassifizierst? beim hochfahren hab ich die Meldungen auch, aber nach wenigen Minuten bin ich im OS und kann damit arbeiten...

Danke für den Hinweis. Ich habe letztens mal das Teil einfach laufen lassen, naja, eigentlich hatte ich es vergessen, während ich im Netz weiter gesucht hatte, und da lief tatsächlich irgendwann etwas weiter. Allerdings war auch das gespickt mit Fehlermeldungen. Ich werde das mal weiter verfolgen.

Was ist denn auf der Karte? Schon mal das Nano Image darauf geflasht und gebootet? Dann braucht man ja nicht installieren...

Auf der Karte hatte ich ebenfalls das normale Installationsimage. Nano hatte ich noch nicht probiert, da ich das System nicht auf der Karte betreiben wollte. Ich gehe aber davon aus, dass hier das gleiche passieren würde, da das Problem vermutlich eher in der Zusammenarbeit mit FreeBSD und nicht mit OPNSense liegt.

Wenn das an dieser Stelle so lange dauert, liegt es entweder an der SD Karte oder am Kartenlesegerät in der ZBox. Die SD Karte ist ja auch über USB angebunden, versuche das ganze doch am besten mal mit einem USB Stick, falls eine andere SD Karte nicht funktionieren sollte.

USB-Stick hatte ich auch probiert, der wird irgendwann vom System nach n Fehlermeldungen abgemeldet.

Guten Abend,

bei mir stürzt die Installation immer mit einem Timeout ab. Ich habe schon einige Tage diverse Foren gewälzt und so ziemlich mit meinem Latein am Ende. Zugegeben ist mein Latein, was FreeBSD angeht, auch nicht sonderlich umfangreich. Im Anhang ist die Fehlermeldung zu sehen. Da kommt in regelmäßigen Abständen immer eine neue dazu.

Was habe ich probiert: eigentlich alles Mögliche bis zur Modifikation der Kernelparameter auf verschiedene Arten (hints), ohne Erfolg. Der Absturz ist immer gleich. Gemäß diverser Foren gibt es Schwierigkeiten mit dem SD-Kartenlaufwerk, wenn es leer ist. Allerdings erzeugt ein Boot des Installationsmediums von der SD-Karte den gleichen Fehler.
Das Bios ist aktuell.

Hat jemand eine Idee? Ich wäre für jeden Tipp dankbar!  :-\