Das wird auf jeden Fall keine lustige Situation. Vom Netzwerker Standpunkt aus ist das einfach: eines der Modems muss weichen. Da beißt keine Maus nen Faden ab. Wenn beide Modems an der pfSense hängen sollen, geht es einfach nicht, dass du gleiche Netze auf unterschiedlichen Interfaces hast. Und dann auch noch gleiche Endgeräte IPs (.1). Das wird gerade für MultiWAN definitiv ein Desaster. Irgendeines der Modems umzustellen ist von allen Möglichkeiten noch die einfachste und schmerzfreieste. Und gerade wenn man vom gleichen Provider 2 hat, sollte der so kulant sein und einem dabei helfen. Grüße

Lösung gefunden!!! iptables des RADIUS Servers deaktiviert!! 8)

In Kürze vor Schlaf: Mach eine 1:1 NAT von WAN auf intern, dann hast du auch ausgehend die richtige IP. Zusätzlich muss dann auf dem WAN noch eine Firewall Regel raus mit Destination auf die !interne! IP (da der Filter erst nach der NAT greift und damit den Zugriff auf die interne 10.x und nicht auf eine a.b.c.x Adresse sieht). Ansonsten noch Logging der Regel anmachen, dann sollte auch was zu sehen sein unter FW Logs. Gruß

Vielen Dank für Eure Antworten! Dann werde ich mein System auf SSD umstellen. Ich bin schon beruhigt, dass ich meine Konfiguration einfach einspielen kann. LG Thomas

Hallo habe hingekriegt, das lag an Firewall regel, Pfsense HTTPS. Habe pfsense auf andern port laufen lassen, und die Ferewall regeln  bei WAN  Dest. addr auf WAN adresse geändernt und tatatat  alles gut. Übrigens habe pfsense auch neuinstalliert. Danke!

Aber sobald HAVP Parent ist, geht der traffic beim SSL-Bump ja an ihm vorbei.

@Satras so liest es sich, ja. @kr99 custom configuration options können in der entsprechenden OpenVPN Oberfläche in einem extra Textbox Feld eingetragen werden, damit genau der von dir beschriebene Fall NICHT passiert. Wenn du selbst an den Dateien herumschraubst und dich dann wunderst, dass die GUI und pfSense die Dateien via Konfiguration neu erzeugt und somit deine eingebauten Änderungen überschreibt, wirst du nicht weiterkommen. Es ist vollkommen normal, dass die Dateien ggf. neu erzeugt werden wenn es ggf. auf gebundenen Interfaces zu einem Neustart kommt, damit der OVPN Daemon wieder Verbindungen aufnehmen kann. Entweder du packst deine Spezialkonfiguration in die GUI wo sie auch hingehört, oder du musst dir einen anderen Mechanismus überlegen, um die Konfiguration nach jeder Änderung wieder herzustellen. Grüße

Dann ist die Antwort von Satras genau die richtige und entspricht der Nutzung wie bei der FB. Dort ist der Reconnect ja ebenfalls an einen Knopf gebunden (neu verbinden). Grüße

@JeGr: Ich habe diesbezüglich mal eine Anfrage gestellt, vielleicht bekomme ich ja was heraus. Ich bin mir nicht ganz sicher was ich beitragen könnte, aber wenn es was zu tun gibt kann ich meine Hilfe hier schon mal anbieten. Offene Lösungen kann man so nun mal an besten weiterbringen

Hallo Sobo, hast du auch mal hier im Forum gesucht? Irgendwie werde ich das Gefühl nicht los, dass dieser Thread https://forum.pfsense.org/index.php?topic=81508.0 mitunter (zumindest einen Teil) deines Problems beschreibt. Da du aber nichts über deine Hardware oder die pfSense Version schreibst, ist alles andere "Glaskugellesern" vorbehalten. PFsense Version, Variante (embedded/full), Hardware (bei embedded bspw. wg. RAM etc.) usw. sind nunmal wichtig um überhaupt eine Aussage über den Grund machen zu können. Grüße

Gerne :) Was du oben schreibst: Wir haben pro Internetverbindung deshalb mehre Interfaces, da die Internetleitungen zum Teil die gleiche Performance wie die LAN Schnittstelle aufweisen. Sprich wenn ich jetzt nur ein LAN Interface hätte jedoch 6 WAN Interfaces… würde das einzige LAN Interface die Performance der WAN Schnittstellen drosseln. stimmt so nicht ganz. Klar, wenn du an einer pfSense 3x Gigabit UpLinks hängen hast, wäre es (theoretisch) ein Bottleneck, wenn du nur einen Gigabit Link ins LAN hast. Ist allerdings nicht ganz korrekt, da man selten einen Link komplett ausnutzt (your mileage may vary) man die Uplinks selten parallel in voller Breite ausnutzt (denn dann würde sich eher die Frage stellen, warum nicht ein dickerer Upstream Link?) das häufig dazu dient, Dienste auf verschiedene Links auszulagern damit sie sich im Extremfall nicht gegenseitig behindern Sollte man die Einzel-Links aus $Gründen tatsächlich brauchen, gäbe es sinnvolle Optionen, das mit einem LAN Link zu lösen: LACP mit mehreren Links 10GE Interface an Switch Damit wären dann auch interne Mechanismen wie LoadBalancing, Policy based Routing etc. ohne Probleme nutzbar und nicht auf irgendwelche Interfaces gebunden. Grüße

Nunja ganz doof gesagt "es funktionieren alle Gateways" kann sein, dass wirklich alle gehen, oder dass du einen Fehler eben jetzt ignorierst (was auch nicht unbedingt sinnvoll ist). Ohne apinger weiß aber pfSense nicht, welches Gateway (oder damit gesagt welche Dial Up Line) gerade evtl gestört ist oder nicht aktiv ist und kann so sein Loadbalancing/Failover/etc. nicht einsetzen und auch keine Umschaltung triggern. Macht also in diesem Szenario eigentlich gar keinen Sinn. Grüße

Da hat Flix ganz recht. Da muss nichts gebridgt werden, du kannst hier einfach die Geräte in der DMZ entweder ausgehend oder generell NATten und dafür auch mehrere IPs nutzen kannst. Was du genau anstellen willst, müsstest du ggf. erläutern (was ist denn die Wunschvorstellung wie es optimalerweise sein sollte), dann könnte man auch konkrete Umsetzungsvorschläge machen. Grüße

Ich habe den "timeout" im CaptivePortal sehr hoch gesetzt (idle: 180 hard: 240); laut LOG-Datei findet das Beenden der Verbindung statt. Die LogOut-Page nutze ich nicht. Grüsse

Ja, Ja (aber das sollte schon passiert sein, weil du sonst von keinem Client ins Internet kommen würdest) Ich muss dennoch kurz Ausholen. Mein Setup ist deinem recht ähnlich, ich habe auch eine FB vorgeschaltet, allerdings arbeite ich nicht mit Exposed Host und schalte die Ports an der FB einzeln  frei die ich brauch. Ist Geschmackssache, und es verkompliziert einige Dinge ganz leicht, aber als ich pfSense das erste mal getestet hatte, habe ich der ganzen Sache nicht so vertraut, deshalb der extra step :) Anyway, deine Clients bekommen eine IP von pfSense verteilt, da ist eine GW IP mit angegeben, die der pfSense, mehr müssen die clients in dem Moment nicht wissen. Die pfSense hat am WAN Anschluss bei dir 192.168.178.0/24 anliegen und somit muss die pfSense das GW 192.168.178.1 (schätze ich mal) kennen. Denn auch als exposed host bekommst du keine Öffentliche IP, die FB macht immer noch NAT, ledeglich alle Ports werden von der FB direkt auf die pfSense weitergeleitet. Erklärt es dir das ?

Ich finde es auch sehr seltsam, somal es auf meiner Alix und auf einer VM Läuft, nur halt nicht die identische konfig. @JeGr Mein Zweitsystem hab ich momentan auf meinem Schreibtisch in dem besagten zickigen Zustand stehen. Wenn ich irgendwas abfragen soll (Logs, States, whatever) sag bescheid. Der Packetfilter (Prozess) arbeitet auf dem System weiter nicht, obwohl Outbound NAT wieder auf Auto steht. Im Englischen Forumsbereich (NAT) werde ich momentan mit Unverständnis konfrontiert, weil ich zwei Nat Mappings vom gleichen LAN-Netz in zwei unterschiedliche WAN-Interfaces manuell gesetzt habe. Das wäre angeblich der Grund für das Versagen von Packetfilter.  Vielleicht liegt es daran, dass sie mich mangels meiner Englischkenntissen, nicht richtig verstehen oder umgekehrt  :/ (Google Translator ist fürn Ar****)

Alles klar, danke für den Tip. Werd ich gleich mal testen…  ;)