Hallo!

@bitboy0:

UDP geht nicht. Ich muss TCP verwenden. Das war aber auch beim alten Server so, sollte also nicht das Problem sein.
PS: Wenn ich "fragment 1364;mssfix;" unter "Advanced" stelle, startet der OpenVPN-Server nicht mehr … das wäre sonst die Idee gewesen

Die beiden Parameter sind für UDP gedacht.
Du kannst es mit "tun-mtu 1464" versuchen.

Grüße

Freut mich, dass es nun klappt, wie erwartet. Danke für die Rückmeldung.

Übrigens, in meinen Kreisen gilt eine solche "Firewall" wohl nicht zu Unrecht als verpönt. Doch sollte auch diese sich so einstellen lassen, dass der nötige Traffic drüber geht, oder wenn nicht nötig, die Firewall für das OpenVPN-Interface ganz deaktivieren, wenn das überhaupt hilft.  ;)

Grüße

Es war halt ein Portbereich… da war der Port mit eingeschlossen, aber nicht genau so in der Liste angegeben. Deswegen hab ich den in der Suche auch nicht finden können.
Aber ich hätte da schon auchselber drauf kommen müssen, finde ich ... das ärgert mich, wenn ich dann so viel Zeit verplempere und dabei ist der Fehler direkt vor der nase :(

Nochmals danke! Da muss ich noch mal tiefer ins Thema einsteigen.

LG
Thomas

Habs gefunden die VB hatte das Netzwerk em0 gesperrt.
Muss man erlauben.
Jetzt gewhts los :D

Danke für diese Info!
Da kann ich es ja lange ausprobieren :-)
Ich habe es nur nicht ganz verstanden ob es ggf. mit iOS 9.1 wieder klappt. Ich probiere es in den nächsten Tagen mal aus.

ok danke mach ich

@ksibln:

Die Outbound-Regeln stehen bei mir tatsächlich auf "Automatic", wie im Werkszustand. Wobei ich auch gestehen muss, dass dies für mich völliges Neuland ist…  Mir ist bisher nicht klar, was man dort eigentlich genau einstellt - klar, irgendetwas mit den Portnummern, die im Rahmen des NAT vergeben werden, aber der Rest ist für mich zurzeit noch sehr rätselhaft...

Outbound NAT transferiert die Quell-IP u. den -Port der Pakete beim Verlassen von pfSense.

@ksibln:

Eigentlich hätte ich gedacht, dass die Sache so funktioniert (ohne an den NAT-Regeln herumdoktorn zu müssen):

Der Terminalserver sendet an Port 21091 an die Fritzbox das Sync zum Verbindungsaufbau für den Mailserver, unter einem Antwort-Port von z.B. 50000.

Die Fritzbox leitet das weiter unter Port 25 an die PFSense, unter einem Absenderport von z.B. 40000, und merkt sich den zugehörigen Port 50000 für das Antwortpaket, das sie unter der 40000 zurückerhalten wird.

Ähnlich dann bei der PFSense:
Die erhält unter Port 25 das Paket von der Fritzbox mit Absenderport 40000 und leitet das weiter an den Mailserver unter Port 25 mit dem Absenderport z.B. 30000.

Der Mailserver erhält dann das Paket mit dem Sync unter Port 25 und sendet das zugehörige ACK Paket zurück an die PFSense unter Port 30000, die PFSense sendet es weiter unter dem gemerkten Port 40000 an die Fritzbox, und die Fritzbox leitet es dann weiter unter dem zugehörig gemerkten Port 50000 an den Terminalserver.

Ist mein Gedankengang denn soweit richtig?

Wenn die beiden Geräte wirklich so arbeiten, kannst du dir Outbound NAT wohl sparen. Das würde ich aber mit einem Sniffer überprüfen. Auf der pfSense kannst du dafür Packet Capture aus dem Diagnostics Menü verwenden. Ob die FB auch eine solche Möglichkeit bietet, weiß ich nicht.

Übrigens gibt es hier im Deutschen Forum einen nicht all zu alten Thread bezüglich einer pfSense hinter einer Fritzbox. Ob da das Thema "Betrieb eines Servers" hinter der pfSense behandelt wird, weiß ich aber nicht. Den hab ich nicht verfolgt.

Besten Dank für die Hilfe

ich habe deinen Vorschlag versucht und leider gingen wieder alle Mails raus.
Daraufhin habe ich als Quelle den Exchangeserver mit Port "any" und Ziel WAN_Init7 mit "any" genommen und es ging immer noch.
Das hat mir definitiv zum Nachdenken gegeben.

Anschliessend ist mit der obenstehende Post von viragomann nochmals angsehen

"Allerdings muss du meines Wissens in System > Advanced > Miscellaneous den Haken bei "Skip rules when gateway is down" setzen, um zu verhindern, dass pfSense die Regel nicht übergeht, wenn das gesetzte Gateway down ist und die nächstbeste Regel anwendet, die dann alles an jedem beliebigen Gateway erlaubt.
Ja, der Wortlaut der Option ist nicht ganz schlüssig."

–> nun den Haken wieder entfernt - und voila

Jetzt gehen keine Mails mehr raus

Besten Dank

ich habe es geschaft danke für deine hilfe :)

Wenn du es für VOIP brauchst am besten dafür eine eigene Regel machen mit der Quell IP oder Zielport.
Wenn du alles auf Static Port machst könnten dir irgendwann die Ports ausgehen.

Steht dann Outbound NAT auch auf manuell?
States oder Firewall nach dem anpassen mal resetet?

Hallo!

@greenhornxxl:

Soll heissen:
User Gruppe A soll auf VLAN 1
User Gruppe B soll auf VLAN 2
User Gruppe C soll auf VLAN 1 + 2
Zugriff bekommen.

In der Firewall -> Rulesets kann ich lediglich Interfaces und IP's verwalten und mit statischen IP's im Tinnel möchte ich nicht arbeiten.

Ich auch nicht.

Ich hab das für mich so gelöst, dass ich für jede Berechtigungsgruppe (habe auch 3) einen eigenen OpenVPN Server mit verschiedenen Tunnel-Netzen angelegt habe, die eben auf unterschiedliche Ports auf einer IP lauschen. Zwecks besserer Übersicht habe ich den einzelnen Tunneln noch einen ausdrucksvollen Alias gegeben, die ich in den Firewall Regeln verwende.
Ist natürlich auch mit etwas Arbeit verbunden.

Alles klar

Vielen Dank für das Feedback, dann schreibe ich eine schöne Anleitung für die USER ;-)

Hi bakunin,

das Verhalten ist ganz normal, wenn du carp auf beiden Devices konfiguriert hast.
Auf der Backup Firewall macht du nur die Regel für das Netzwerk. Alles andere wird ausschließlich auf der Master Firewall konfiguriert.
Dann funktioniert es auch mit dem Carp ohne Probleme und alles wird syncronisiert.

Viele Grüße
Christian

Moin,

schau mal unter Status –> RRD Graphs --> Traffic
Vielleicht unter System --> Advanced -->  Miscellaneous --> Periodic RRD Backup setzen
Reicht das?

-teddy

Hallo,
ein IPsec VPN von einer Firewall hinter anderen  Firewall per NAT ist immer suboptimal.
Besser und einfacher wäre mit Sicherheit das VPN auf dem lancom aufzubauen oder das Lancom zu entfernen.
Ihr werdet nie den Tunnel von Site B nach Site A initialisieren können, nur umgekehrt.
Es fehlt ESP auf der WAN Seite der pfSense.
Du schriebst, ihr habt eine Allow all Regel der Source  IP auf dem WAN interface erstellt, es muß meiner Meinung nach als Source IP die interne IP der Lancom sein.
Um den Fehler einzugrenzen, bzw. zu beheben empfehle ich eine allow all Regel auf das WAN interface mit logging.
Auf der Gegenseite dann ein Dauerping um den Tunnel zu initialisieren
Dann sieht man in Schritt 1 was in den Firewalllogs ankommt, Schritt 2 wäre dann die IPsesc logs zu prüfen.
Wenn du die logs schickst kann dir wahrscheinlich besser geholfen werden.

Gruß
Christoph

Der Client IST mit Admin-rechten gestartet und bis gestern hat er auch klaglos selber die routen eingetragen. Er trägt auch jetzt einige routen ein, nur die wichtige Route in unser Netz fehlt…

Das ist etwas schräg.