@Bob.Dig said in Update pfSense Netgate 6100: Ich meine von JeGr gelesen zu haben, dass es zuletzt Probleme mit manchen OpenVPN-Konfigurationen gab Ich denke das es dieser Beitrag war. DCO So wie ich das lese betrifft das nur wenn DCO aktiviert ist, das wäre bei mir nicht der Fall.

@krabat wir sind hier im Deutschen Bereich, @JeGr kann man den in den englischen Bereich verschieben?

Ja, hatte schon einmal vor einem Jahr das Thema. Da habe ich aber nur Infos zu PPPOE bekommen und den Ratschlag Full Dual Stack zu erfragen. Wo es mir drauf ankommt ist das Thema IPv4 im IPv6 Tunnel. PFsense verarbeitet wohl die Info zum AFTR Server nicht automatisch.

@BulkAndi75 said in pfSense und Windows Server DNS: Ich denke aber, für ein kleines Netzwerk, ist dieses Konzept durchaus vertretbar. Mittlerweile habe ich DHCP und DNS über einen Windows DC laufen und funktioniert unter OPNsense ganz gut und stabil. Ich bin aber dabei beide FWs zu testen und pfSense zickt da noch. Definitiv ein setting Thema. Würde ich auch sehen, unserer Lab Erfahrung nach zickt OPN gern etwas mehr als pf in Virtualisierung, da sich die Projekte da etwas unterscheiden. Da sieht man dann auch den unterschiedlichen Unterbau (FBSD 16 inzwischen bei pf). Hängt aber auch stark vom HV ab. KVM (Proxmox, o.ä.) sehe ich eher weniger Probleme. Bei HyperV gabs da schon etwas mehr. Und manchmal hat man auch seltsam ominöse Probleme in kleineren HV Projekten wie Virtuozzo und Co. @BulkAndi75 said in pfSense und Windows Server DNS: Backup und Restore über Veeam geht ruck zuck. Das ist eine Möglichkeit, ich würde aber empfehlen separat dazu noch die config.xml über einen Job zyklisch wegzusichern damit man damit nochmal eine saubere Config hat und als Basis nutzen kann ohne gleich die ganze Maschine wiederherzustellen. Ansonsten ist das klein und fein und sollte ohne große Probleme laufen. Cheers

@Jochen77 du kannst auch deine Domain bei einem anderen Anbieter sehr einfach mit einem Wildcard Zert ausstaffieren und das auch auf der Sense mit ACME. Du brauchst dazu lediglich deine andere Domain, bei der der Check ja sauber funktioniert und kannst die andere Domain bzw. deren acme-challenge dorthin umleiten. Da du die andere Domain ja augenscheinlich via IP64 o.ä. mit Zertifikat ausstatten kannst, klappt das dann via challenge-alias dann auch mit der anderen Domain. Man leitet quasi mit einem CNAME Eintrag die Challenge Abfrage auf die andere Domain um, stellt das im ACME package entsprechend ein und ACME erstellt dann einen sauberen DNS Eintrag zum Prüfen an der richtigen Stelle. Beispiel: DomainA.de - geht problemlos mit wildcard via DNS64 (oder irgendwas anderes mit API) DomainB.de - geht nicht, weil dooferProvider keine ordentliche API hat. Dann erstellt man ein acme-challenge.DomainB.de Eintrag als CNAME, lässt diesen auf acme-challenge.DomainA.de zeigen und konfiguriert in ACME dann einen Job, der Wildcard.DomainB.de anfordert, macht aber einen Haken bei Challenge Alias und trägt dort DomainA.de ein und wählt dann die korrekten API Infos für DomainA ein. LetsEncrypt bekommt dann die Anfrage für DomainB, sieht dass der acme-challenge ein CNAME ist, fragt den Eintrag von DomainA ab und nickt dann entsprechend das Zertifikat für DomainB ab. Klingt kompliziert, ist aber eigentlich recht simpel. Und dann kann man auch problemlos in HAproxy auch alles ordentlich mit Zertifikat und Offloading einrichten ohne Sonderlocken. Cheers

@Kraeuter ja, die habe ich mit meinem Kabelanschluß genutzt, selbe Qualität wie Fritzbox. die Verbindung hatte alle paar Minuten aussetzer. Erst mit dem TC4400 lief der Anschluß stabil. Gruß ré

@snah0815 Nach meiner kurzen Recherche stimmt das so nicht ganz. Schau am besten noch mal in die Dokumentation deines Anbieters, was genau erwartet wird, und lies dir auch den Erklärungstext auf der Konfigurationsseite durch. [image: 1770369559605-scr-20260206-jlso.png] PS: hast du es jetzt hinbekommen? @snah0815 Ist das damit erledigt, oder bestehen noch Probleme?

Hi, @Jawad9999 said in System crashed after Software update: Hallo leute , mein Netgate Firewall router 4100 ist nach einem Software Update hängen geblieben , software ist 23 noch was, Was heißt gecrasht, hängen geblieben etc? Also wie ist jetzt die Ausgangslage? Geht gar nichts mehr? Bootet nicht mehr? Bootet aber er kommt nicht hoch? Geht es ein klein wenig genauer? :) kann mir jemand sagen was ich tun soll damit ich den wieder gängig machen kann? Wenn du - hoffentlich! - ein Backup der Config hast, was man vor einem Update immer ziehen sollte, dann installier einfach neu mit dem aktuellen Stand (23.x ist enorm veraltet!) und spiel danach einfach die Config wieder ein. Das ist der schnellste und einfachste Weg und räumt gleich noch Altlasten weg. Cheers

Um das nochmal kurz festzuhalten: für Pakete und Updates braucht pfSense Internet. WIE sie das bekommt ist an der Stelle egal. Man kann auch einfach wie @micneu das beschrieben hat das WAN ins aktuelle Netz (LAN?) hängen und sich dann das LAN temporär auf irgendwas anderes konfigurieren, damit man an die UI kommt und den Rest konfigurieren kann. Hat man alles soweit auf Paketstand und Co, kann man das WAN auch erstmal wieder abklemmen und dann alle anderen Interfaces soweit einrichten wie benötigt, damit man keine IP Konflikte bekommt. Zu empfehlen ist aber, die ersten zwei Interfaces (WAN/LAN) gleich auch auf WAN und ggf. Management Netz zu konfigurieren, da diese Interfaces fest sind und eine kleine Sonderbehandlung haben ("lan" hat bspw. immer die anti-lockout Regeln, die auf nem management Interface besser aufgehoben sind als in einem Client oder Server Netz). Cheers

Exakt was @Bob.Dig sagt. Statt dem uPNP Quark einfach genau das tun, was unter "alternative Methoden / manuelle Portfreigabe" steht und statt irgendeinem Automatik-Gedöns einfach feste Ports nehmen. Wesentlich einfacher und sinnvoller, weil sich dann der Port nicht nach Mond- und Sonnenstand verändert ;) Schwieriger wirds, wenn man keine echte IPv4 hat. Mit IPv6 gehts wohl auch, aber da ist dann mit "statisch" nicht viel drin. Bzw. ein ganz schöner Aufwand. Da ist es dann wie es in der Anleitung steht wieder einfacher, Tailscale oder Netbird zu nehmen und einfach die Leute mit denen man zusammenspielen will einzuladen und gemeinsam im gleichen P2P Netz zu sein. Cheers

Ich hab das Update heute vollzogen, bis jetzt schaut es sehr gut aus. Gruß Mike

Moin @DanielJoni, meine pfsense (2.8.1) hängt direkt an einem Modem (Vigor 167) bei 1&1. Die verwenden auch VLAN ID7. Wenn man das Vigor 167 mit den Default-Vorgaben auspackt und anschließet. erkennt das automatisch diese VLAN ID7 und konfiguriert sich entsprechend. Das folgende darf es dann in der Config der pfsense NICHT geben: Interfaces/VLAN -> Parent: igc0 -> VLAN tag 7 Sollte sich die Fritte als Modem ähnlich verhalten, musst du das VLAN am WAN entfernen,

@Bob.Dig ; @micneu Die CoDel Rules sind bei mir (entsprechend der Anleitung )auch floating rules, die für alles gelten was hinter der pfSense liegt. Das macht ja so auch Sinn und funktioniert auch tadellos. Ich muss aber zugeben, dass mir das Thema floating rules ein Buch mit 7 Siegeln ist, und ich aufgrund der Warnungen zu diesem Thema auch vermeide solche Rules zu erstellen - da bin ich einfach unsicher. Ich habe jetzt aber trotzdem eine vergleichbare floating Rule gebaut: wenn ich die Destination * setze, greift das auch prima - natürlich wieder für das gesamte Netzwerk. Mein Ziel ist es aber, diese Bandbreitenbeschränkung nur auf bestimmte interne Clients/IP's (via Alias) anzuwenden. Sobald ich aber diesen Alias in der floating Rule als Destination eintrage, wird die Rule offenbar nicht mehr angewendet. (Wenn ich die Doku richtig lese, dann könnte das wohl am NAT liegen - dass also das eingehende Paket als Ziel die externe IP der pfSense hat, und nicht die interne IP des Clients. Bei dem dort erwähnten Thema Marking and Matching steige ich dann aber leider vollkommen aus) Allerdings habe ich habe mir nochmals angesehen, wie ich das vor ein paar Wochen auf der pfSense mit lediglich einer WAN / LAN Verbindung eingerichtet habe - dort ist diese Bandbreitenlimitierungsregel definitiv eine Rule am LAN IF Nachdem es dort aber gar keine floating rules (CoDel) eingerichtet sind, hab' ich jetzt auch versucht einfach einmal meine CoDel Rules (floating) zu deaktivieren. Und siehe da, sobald die floating CoDel Rule (auf der Schnittstelle über die der Traffic aktuell stattfindet) deaktiviert ist, greift auch die Bandbreitenlimitierungsregel am LAN IF vollständig - also nicht nur Upload wie bisher, sondern auch Download... Jetzt bleiben bei mir aber nur noch Fragezeichen im Kopf...

@slu ganz genau. Daher bin ich jetzt ganz froh, dass praktisch überhaupt keine Writes mehr stattfinden. Der Wearlevel ist schon auf 87% runter nach 3 Jahren.