@magicteddy: sorry, nein. Ich habe auf allen 3 Installationen nur Squid im Einsatz. Squid und bei den ACL Blacklist einfügen oder mit dem Guard zusammen? Der Guard scheint ein wenig komfortabler zu sein, nur leider stürzt dieser immer beim Starten ab.

Hallo, habe den Fehler mittlerweile entdeckt, es lag an SARG das mein Filesystem füllte. Danke für die Hilfe! ;)

Eine Einschränkung ist bspw., dass die Backup-Box so nicht mehr von außen erreichbar ist, hat ja auch keine IP. Es gibt aber noch weitere, aber, so weit ich mich erinnere, verkraftbare Einschränkungen. Wie gesagt, ich kann dich bezüglich CARP IP außerhalb des Interfaces Subnetzes leider nicht mit Erfahrung unterstützen. Aber dass die Subnetzte der CARP IP und der Interface IP dieselbe Größe haben müssen, kann ich mir auch nicht vorstellen. Ergibt ja keinen Sinn. Ich denke, die beiden Interfaces, die du zusammenschaltest, müssen natürlich in einem gemeinsamen Subnetz sein, in dem eben beide Platz haben (min. /31) und ein Datenaustausch zwischen den beiden muss möglich sein, bspw. über Switch. Die CARP IP darf dann irgendwas ganz anderes sein, anderes Subnetz und auch andere Größe. Die WAN Interfaces der beiden Boxen bekommen die neue IP im privaten Bereich und die bisherige WAN-IP wird dann die CARP-VIP. Im Outbound NAT musst du auf manuell umstellen und die Regeln einfach anpassen. Per Default erstellt pfSense die Outbound NAT Regel automatisch auf die Interface-IP, und die ist ja nun eine andere. Daher musst du sie anpassen und bei Translation deine öffentliche IP eintragen. Das WAN Gateway bleibt unverändert. Natürlich musst du die Umstellungen auf CARP auch für deine internen IPs machen. Hier sollte aber die Interface IP im selben Subnetz sein, ansonsten in gleicher Weise. Also die bisherige Interface IP wird die CARP-VIP, denn die verwenden ja vermutlich die Hosts als Gateway, die Interfaces bekommen eine andere IP. Grüße

Auch wenn es jetzt ein wenig Nestbeschmutzung ist, ist eine kleiner Mikrotik Router nicht die günstigere & sinnvollere Wahl? Sowas wie der hier: http://varia-store.com/Wireless-Systeme/Fuer-den-Innenbereich/MikroTik-RouterBoard-RB941-2nD-hAP-Lite-mit-650MHz-CPU-32MB::3594.html Geringerer Anschaffungswiderstand und Unterhaltskosten. -teddy

Moin Greife meinen eigenen Thread nochmal auf. Hab zwei APUs mit aktueller pfsense als site to site VPN in Verwendung. Die Objekte sind Schulen und haben eine eigene Intrastuktur, auf die ich wenig Einfluss habe, ausser Portweiterleitungen anlegen zu lassen. Die Daten wie WAN IP und Gateway sowie DNS habe ich statisch eingetragen. Ping ins Internet zu 8.8.8.8 läuft auch alles. Aber DNS macht Probleme. Auf der PFsense klappt die DNS Abfrage. Auf den Clients nicht. Obwohl per DHCP den Clients das Gateway bzw. DNS mitgeteilt wird (die LAN IP). Hab dann mal testweise statt den default Resolver den Forwarder aktiviert. Damit läuft es sofort. An anderen Anschlüssen mit Fritzboxen als Gateway geht der Resolver einwandfrei. Wo könnte der Grund liegen.? – Rüdiger

Ich habs nun hinbekommen, indem ich im LAN eine neue Firewallregel erstellt habe, die alles erlaubt nach 192.168.0.0/24 jedoch das GW 192.168.1.10 nutzt, statt das Default (welches die pfSense ist). Ich meine früher ging das auch ohne diese Regel…

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.