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…  ;)

So, jetzt funktioniert es. Ich habe gestern nochmal alles neu aufgesetzt und die Routerfirmware aktualisiert.

WAN am pfsense steht auf DHCP
LAN IP am pfsense ist 192.168.1.1; DHCP ist aktiv, aber nur von 192.168.1.2 - 192.168.1.2 (also eine Adresse - ob das sinnvoll ist muss ich noch testen)

WAN IP am Router steht fest auf 192.168.1.2; "enable static routes" ist aktiviert.
LAN IP am Router ist auf 10.10.10.1 gesetzt;
DHCP am Router ist aktiv im Berich 10.10.10.10 - 10.10.10.100
DNS Server und Gateway am Router stehen auf 192.168.1.1

Verbindung ins Netz klappt, auch wenn mir der erste Seitenaufruf noch ein wenig zögerlich vorkommt. Die Geschwindigkeit meiner Kabelleitung (50/5 MBit/s) wird laut ookla Speedtest erwartungsgemäß auch über die pfsense Box erreicht.

Ich vermute den Eintrag "enable static routes" am Asus Router als Ursache. Ob ich diesen Punkt in der alten Firmware nicht als Option verfügbar hatte oder ob ich das schlicht übesehen hatte kann ich leider nicht mehr sagen…

Ich hatte mich jetzt fast ein Jahr nicht mehr eingeloggt. Danke für die Antwort! Sorry für die späte Rückmeldung!

Ich habe es zwischenzeitlich folgendemaßen gelöst gemacht:

Mehrere virtuelle Netzwerkkarten:

WAN: IP 1.2.7.2 /29
GW: 1.2.7.1
WAN2: IP 1.2.7.3 /32
GW: none
WAN3: IP 1.2.7.4 /32
GW: none

Das bewirkt, dass ich alle 3 öffentlichen IPs nutzen kann. pfsense routet dann alles über den Default-GW: 1.2.7.1 nach draußen und verwendet dann scheinbar auch die MAC von WAN.

Es klappt also! Keine Ahnung, warum ich das nicht mal direkt getestet habe.. über Konsole hätte ich das ja genauso konfiguriert.. Aber sobald eine GUI dazukommt, setzt das Hirn aus.. ;)

VG

@JeGr:

Sehr Schwierig. Mit deiner jetzigen Konstellation eigentlich gar nicht machbar, denn die Lösung für IP ist auch ein böser Hack, da ein Interface eigentlich keine unterschiedlichen MAC Adressen halten sollte. Da Hetzner das auch noch auf den Switches entsprechend kontrolliert und erzwingt, kann man sich da ganz übel an die Wand fahren.

Die einzige Frage ist: brauchst du die anderen beiden IPs bzw. brauchst du 2-6 öffentliche IPs? Wenn ja, ist die einzig sinnvolle Möglichkeit, von den 3 zusätzlichen Adressen 2 zu kündigen. Die eine die funktioniert behältst du und orderst ein /29er IPv4 Subnetz. Ich weiß, das ist teurer als 2-3 einzelne IPs, aber dafür ist die Handhabung ein Hundertfaches einfacher. Bei der Bestellung eines kleinen IPv4 Ranges kannst du nämlich angeben, dass dieser bitte auf die vorhandene zusätzliche IP geroutet werden soll (die ja funktioniert). Anschließend kannst du das Mini-Netz dann nach gusto vergeben. Entweder in eine Art DMZ oder du machst bspw. 1:1 NAT oder VIPs auf dem WAN Interface. Das bleibt dann dir überlassen. Am Sinnvollsten, da man ja noch ein v6 Netz dazubekommt, wäre z.B. in einem relativ einfachen Setup, dass du intern für die VMs für v4 interne Adressen nimmst (10.10.10.x bspw.) und die Maschinen die wirklich extern erreichbar sein müssen per 1:1 NAT bedienst. Gleichzeitig kannst du jeder Kiste eine v6 Adresse aus dem Hetzner Netz verpassen (pfSense 2.1 vorausgesetzt) indem du das auch entsprechend auf der Sense auflegst.

Anders wird es höchstens eine Wanderbaustelle mit Einsturzgefahr, denn "sauber" bleibt sonst nur der Weg ganz ohne Routing-VM. Dann hat man aber weder vor dem ESXi noch vor den VMs eine Firewall, sondern muss das selbst auf der Maschine erledigen, was mir persönlich nicht ganz so gut gefällt. Dann könnte man aber mit den 3 Einzel-IPs leben, denn diese kann man via Interface Bridging dann der VM direkt zuweisen (sprich, der VM wird die MAC und IP von Hetzner auf dem Bridge Interface zugewiesen).

Hallo

Was für eine WG hast du ? … sehe gerade WG X750 ...