@papajuliett Moin :) Snort ist gruselig, würde ich gerade zu Beginn erstmal HART davon abraten den anzufassen. Erstmal Grundsetup wieder herstellen und ordentlich ans Fliegen bekommen, dann mit pfB-NG nachlegen und warm werden mit dem Ganzen. Wo klemmt es denn jetzt genau noch, wo stehst du bzw. wo kann man helfen? Cheers

@Owly Wenn es zur gleichen Zeit von intern geht, kann man da leider relativ wenig sagen. Wenn es von extern nicht mehr geht wäre es am Einfachsten, wenn man dann von intern mal den Packet Capture anwirft und sich anschaut, ob von extern wirklich überhaupt was ankommt. Also bspw. nen Handy mit OVPN Client via LTE versucht connecten zu lassen. Oft stellt sich dann nämlich raus - nanu! da kommt gar nichts an. Dann wäre das Problem beim Provider/Modem davor zu suchen, nicht bei der Firewall, darum sollte man erstmal eingrenzen wo es herkommt. Wenn nach langem Warten via HTTPS der 504 kommt wie oben - nunja der kommt wie gesagt von einem Timeout von PHP - dann sind wohl alle Worker ausgelastet und können keine Antwort geben. Das sollte aber bspw. dann den OVPN nicht tangieren, der hat da kaum Abhängigkeiten zu und wenn der sich trotzdem nicht connecten will, dann scheints andere Probleme zu geben. Wenn das Problem Richtung PHP liegt, könnte die Kiste auch einfach überlastet/ausgelastet sein, das kann dann auch an Fehlkonfiguration oder einem schieflaufenden Paket liegen. Kann man leider alles nicht so einfach hellseherisch debuggen :) Cheers \jens

@Timo-1 said in PFSense mit echtem statischen IPv6 Subnet: von meinem Provider habe ich ein nicht geroutetes statisches IPv6 /48 Netz erhalten wie z.B. (2a05:bec0:1234::/48 Gateway 2a05:bec0:1234::1) Hi, was ist denn ein "nicht geroutetes, statisches IPv6/48 Netz" in deiner Definition? Ein /48er sollte eigentlich immer geroutet werden, da es 0,0% Sinn macht, jemand auf einem Interface ein /48er Netz draufzuwerfen. Das sollte wenn überhaupt ein Netz wie 2a05:bec0:1234::/48 geroutet auf 2a05:bec0:1234::2 /64 mit GW ::1 /64 sein Alles andere ist ja bekloppt. Du willst ja nicht Trillionen Adressen auf einer Firewall oder einem Router verschwenden, sondern die weiter routen. Und wenn dein GW nicht weiß, dass das /48er HINTER deiner gehosteten Firewall liegt, dann macht das ja keinen Sinn. Da würde ich also zuerst ansetzen und den Kollegen da sagen, sie mögen doch den Router auf der ::1 in ein /64 packen und dort in die Routing Table dein /48 dann bitte mit Ziel ::2/64 routen. Alles andere kannst du sonst erstmal knicken, weil die Pakete sonst nie an dich geroutet werden. Cheers \jens

@viragomann said in Störung IPSec Aufbau nach Interntdowntime: Eine Erklärung für das Nicht-Upgraden ist hier praktisch obligatorisch. Anderenfalls drohen schlaue Weisungen oder gar ein regelrechter Shit-Storm. Antworten naja der Sturm nicht ;) aber da 2.7 und 2.7.2 schon etliche Updates gerade bei IPsec gemacht haben, würde es sich natürlich SEHR anbieten, erstmal auf den aktuellen Stand zu kommen. @hnoack85 said in Störung IPSec Aufbau nach Interntdowntime: etzt gab es am zweiten Standort einen kurzen Internetausfall, jedoch konnte die IPSec Verbindung nach Wiederherstellung der Internetverbindung nicht mehr automatisch aufgebaut werden. Erst nachdem ich den IPSec Dienst am zweiten Standort manuell neu gestartet habe, wurde die Verbindung wieder hergestellt. Aus dem IPSec Log habe ich dazu folgenendes heraus gelesen: Das hört sich sehr danach an, als könnte zwar Seite A mit B aber B nicht mit A die Verbindung aufbauen, was u.a. an NAT wie @viragomann geschrieben hat liegen kann. Ich würde da empfehlen auf beiden Seiten mal in der P1 den Verbindungsaufbau zu disablen (reply only) damit keine der beiden Seiten die Verbindung aufbaut. Dann manuell disconnecten. Dann auf Seite A versuchen aufzubauen und das ganze Spiel nach nochmals mit Seite B. Dann bekommt man schnell raus, ob es in beide Richtungen sauber läuft oder nicht, was ich hier denke nicht der Fall ist. Ansonsten ist der NO_PROP Error vielfältig, das liest sich im ersten Moment dann wie ein P1 oder P2 Encyption Fehler - also nicht exakt gleich eingestellte Phasen. Zusätzlich: wenn beide Seiten Sensen sind, dann nutzt da bitte auch AES-GCM-256 und nicht CBC wie es im proposal steht. Ich würde da beide Seiten fix auf AES-256-GCM, AES-XCBC (oder SHA-256) und DH20 stellen (ecp256 oder ecp384). Alles andere ist eigentlich unnötig überzogen. Ich weiß nie warum irgendwelche Hersteller da statt GCM sauber zu unterstützten immer noch mit "ja aber wir machen SHA512 und DH 21 mit ECP521!" - ja toll, aber das wichtige wäre GCM weils die CPU/Crypto entlastet und schneller ist und nicht irgendwelche Hashes oder Secrets die dann ultra doll verschlüsselt sind Cheers \jens

@viragomann said in PPPOE Fehler oder Provider Störung: @heiko3001 Hallo, das Log zeigt einen Authentifizierungsfehler. Wenn Username und Passwort in Ordnung sind, muss das Problem beim Provider liegen. War eine Provider-Störung, trotzdem Danke!

@viragomann Vielen Dank für den Tipp ich habe festgestellt, das ich blöderweise eine Annahme gemacht habe. Die Interfaces sind vom Namen und Beschriftung verkehrtherum. Demnach hast du recht da war kein Kabel dran ich habe es über den Log gesehen das: LAN1 = igb5 LAN2 = igb4 LAN3 = igb3 LAN4 = igb2 LAN5 = igb1 LAN6 = igb0 Da ist der Fehler

Problem ist behoben. Mit den DrayTek Modems funktioniert DNS-Auflösung nun einwandfrei.

Update: Wenn ich die Firewall mit "pfctl -d" ausschalte, liegt der volle 1 Gbit bei IPv6 im Upload an (getestet mit einer VM im LAN). Die Frage ist nun, was mit "pfctl -d" alles deaktiviert bzw. gebypassed wird. Hat hier jemand einen besseren Überblick - das würde mir unglaublich weiterhelfen. VM IPv6-Iperf3 mit ausgeschalteter Firewall -> "pfctl -d": https://pastebin.com/g5V2j49w VM IPv6-Iperf3 mit aktivierter Firewall -> "pfctl -e": https://pastebin.com/V21ByqTB

@AlmanAchim https://www.youtube.com/watch?v=4BpDpos6Vco

@alex303 Danke. Ich evaluiere eben OPNsense... Einstweilen mit differenziertem Zwischenstand. Ein paar Dinge sind besser gelöst, andere weniger komfortabel. Mal sehen.

@jma791187 Das ist ein wenig hoch gegriffen. Es kann auch schlicht sein, dass es Probleme mit dem WAN/Internet, DNS o.ä. gibt und deshalb kein neues Update abgerufen werden kann. Normalerweise kann man das über die UI kurz erzwingen, in dem man den branch manuell mal auf "Developer" oder "old Stable" schaltet, wartet und dann wieder zurück auf latest stable. Dann wird das oftmals abgerufen wenn sich die PKGs verklemmt haben. Darum meldet man sich aber auch beim Newsletter an um Updatemeldungen zu bekommen oder/und schaut ab und an mal bei den Release Notes/Changelogs rein, was sich tut. Ja es sollte hier angezeigt werden, aber es kann halt auch immer mal was kaputt gehen. Und eine Box ab Werk wird kaum immer mit der aktuellen Version geliefert werden, da die dort meistens auch eine Zeit X rumliegen bis zum Verkauf. Update nach Kauf ist fast immer das Tool der Wahl. Und mal ganz ehrlich - spätestens hier im Forum ist man schon 3x drüber gefallen, dass die aktuellste Version 23.09(.1) ist, also wenn ich die nicht angezeigt bekomme, bin isch schon von Grund auf misstrauisch! ;) Und noch mehr, wenn ich so ein verkorkstes Update von nem uralten Branch gemacht habe - da ist das erste was ich checke, ob die Updates gehen und Pakete installiert werden können. Denn System Patches ist inzwischen schlicht Pflicht für alle Systeme. Cheers :)

@JeGr Habe den Wert mal etwas höher gestellt, Fehler ist bisher nicht mehr aufgetreten, ich werde es weiter beobachten. Danke für den Hinweis.

@NOCling Ergänzung da die Kiste 4 NICs hat: wenn man sie als transparente Bridge reinhängen will, geht das auch. ETH0 als LAN/MGMT konfigurieren auf eine 192er IP aus dem LAN. An den Switch anklemmen ganz normal. ETH 2+3 als Bridge konfigurieren, zwischen Switch und Router hängen und auf der Bridge dann filtern. Allerdings ist Bridge setup hochgradig advanced was das Setup und die Regeln angeht, da wird der OP kaum Spaß dran haben wenn man nicht aus dem Netzwerk kommt weil das ziemlich schwer verständlich ist und es kein gutes "in/out" gibt was man unterscheiden kann (außer man ändert noch weitere sysctl Einstellungen um auf den Bridge Members zu filtern...) Daher würde ich stark abraten da als Anfänger im Heimnetz zu bridgen und filtern. Lieber den Router davor ändern von der IP, pfSense übernimmt dann die alte Rolle des bisherigen Routers und fein. Cheers

@Benno72 Überprüfe diese Punkte: In der Serverkonfiguration muss das Client-Netzwerk in "Remote Networks" eingetragen sein. Im CSO nochmals dasselbe. Der Commonname muss zu den im Client- Zertifikat oassen Eventuell braucht es noch eine Tunnel IP. Eine aus dem Tunnel -Netzwerk mit der richtigen Subnetzmaske

@kira12 Ohne Details oder Screenshots schlecht nachvollziehbar, da man nicht weiß was er macht. In die Logs schauen bei Verbindungsversuch, nach LAN und Port 22 filtern und schauen was aufschlägt. Wenns über die Sense nicht rausgeht wirds ja offenbar dort auf dem LAN geblockt - also schauen in die Logs, schauen wie es ankommt (falsche Adresse, falscher Prefix, whatever). Tracking Regeln und das ganze IP6 dynamische Geraffel sind da aber auch prädestiniert für Quark zu machen, weswegen man eigentlich feste Prefixe will, aber die bekommt man ja leider nicht ran.

@gtrdriver said in erstmalig 2.7.er Installation - ist da ein Bug im Webinterface ?: Hallo zusammen ja - das ist ein Browser Problem .. Ich hab Cache etc. schon gelöst .. - aber keine besserung Das verrückte ist - sobald ich im Browser den Inkognito Modus nutze gehts ... Seltsam ... Dann ist es kein Cache, sondern das komische "Daten Einfügen" Kram des Browsers. Mit ein Grund, warum wir empfehlen, im Browser keine PWs und keine Daten wie Adressen oder Kreditkarten zu speichern. Das läuft dann über Formulardaten die er sich merkt und da dann entsprechend manchmal Quark einfügt. Im Inkognito Mode ist das Formfelder einfügen dann aus. Würde empfehlen das generell einfach abzustellen und die Formdaten zu löschen, dann solltest du das Problem hoffentlich los sein. Ansonsten hilft manchmal auch (generell) ein zweiter Browser der solchen Kram nicht speichert oder entsprechend konfiguriert ist und den man dann nur für sowas nimmt (wenn man Daten im Browser speichern als Komfortfeature nicht abschalten will). Cheers :)

Ja das sieht gut aus. Dann besser noch mal den Browser Cache löschen, Anzeigefehler sind einen klick später ggf. fatale Konfigurationsfehler.

@Tobias-Kal Ansonsten die Einstellungen (wenn managebar) des Switches mal sichern und zurücksetzen / rebooten. Hast du denn mal verschiedene Speedtests von unterschiedlichen Anbietern genutzt? Evtl. die NICs mal mit iperf durchtesten ob da Auffälligkeiten zu beobachten sind.

Die Netzwerkkarte ist jetzt seit einer Woche getauscht und das Problem ist nicht mehr aufgetreten. Vermutlich hatte die Broadcom vor allem unter Last ein Problem was zu einem PCIe Fehler geführt hat...

@Micki said in Regelsets gesucht: 4.1. Über die Zielkonfiguration die Weboberfläche der Fritzbox zu erreichen. Wäre interessant, ob du das natten oder routen möchtest. Für diesen Zweck sollte NAT okay sein. Wenn du am WAN Interface der pfSense die interne IP der FB als Gateway gesetzt hast, sollte das eigentlich schon funktionieren. 4.2. Einen Regelsatz für einen Webserver im 192er Netz zu erstellen (in der momentanen Konfiguration ist er erreichbar). Hier würde ich routen. Dann erst mal eine statische Route für das 192er Netz einrichten und auf das Sec Gateway zeigen. System > Routing Das Sec GW muss erst als Gateway angelegt werden. Dann sollte es mit eine normalen Port Forwarding Regel (mit assoziierter FW-Regel) schon klappen. Auch ein Regelsatz Port 80 und 443 Fritzbox Lan auf PfS Lan hat nicht geholfen. Bitte nicht auf DMZ varianten verweisen, das ist derzeit noch nicht realisierebar. Dass der Traffic von der FB auf die pfSense weitergeleitet wird, ist nun mal Voraussetzung. Ob das als DMZ oder durch Weiterleitungen einzelner Ports geschieht, ist nicht ausschlaggebend.