Danke für den Hinweis, habe jetzt erst einmal alles CPU Stromsparfunktionen und HT deaktiviert und bis dato rennt das System - bzgl. dem Update auf 2.2 werde ich die Tage mal testen

Ich habe nichts geändert an Serverpfaden oder ähnlichem. Die Status Box erzählt auch, dass sie das Image downloaded und in der Console sieht man, wie er danach anfängt zu arbeiten und nach Reboot ist halt nichts passiert.

Sicher, kann man manuel flashen, aber trotzdem merkwürdig…

Autsch, dann bleibt die neue hoffentlich trocken ;)

Danke für die Rückmeldung und schön das ich helfen konnte bzw. das es geklappt hat ;)

Achso nochwas, da du ja die Pfsense nicht direkt im Internet hast, sprich sie nicht die offizielle IP besitzt, kann es vorkommen, dass dir Dead Peer Detection in die Suppe spuckt und dein Tunnel unter umständen nicht richtig abgebaut beziehungsweise es ewig Dauert, bis der Tunnel wieder richtig aufgebaut wird. (Bei längerer Nutzung)
In dem Fall schalte DPD sowohl in der Pfsense als auch in der FB ab. Und achte darauf, das die Uhrzeiten stimmen. NTP bei IPsec ist Pflicht ;)

Änderung der FB VPN CFG…
"always_renew = no"

Ahoi JH,

Das ganze Problem: Wenn du dir die Infos speicherst um Abmahn Sicherheit zu erreichen, musst du dann im Zweifel alle Mails aufheben und dem Anwalt übergeben.

Wenn es mir um Abmahnsicherheit geht, bin ich eh gezwungen (nicht nur) E-Mails aufzubewahren, sondern auch andere Daten vorzuhalten. Und ein E-Mail Label oder Ordner einzurichten und die Mails via Filter da reinzuleiten ist kein großer Akt. Mache ich bspw. mit einem GApps Account via Label oder einem IMAP Account mit extra Ordner und Filterregel. Geht somit automatisch und ich muss nichts dran schrauben. Der Vorteil der Mailvariante: Da ich Mails eh aufbewahren muss im Geschäftsverkehr, kann ich mit einer Mail-Archiv Lösung (z.B. Mailstore Home/Corporate) das gleich mit sichern.

Ich nutze das ganze eigentlich um meinen (eigenen) dynDNS Server anzusteuern (…)

Für deinen eigenen DNS Server: Warum überhaupt via DynDNS und nicht via RFC2136 dynamic DNS und shared Key protected Zone?

Aber prinzipiell finde ich es immer schön, wenn es zum gleichen Problem mehrere Möglichkeiten gibt und man die Freiheit der Wahl hat :)

Hallo Otto,

das Backup sichert auch Zertifikate, die in der Zertifikatsverwaltung von pfSense hinterlegt sind vollständig mit. Hierzu muss nichts eingerichtet werden.

Gruß
Jens

So ganz trivial kinderleicht, einfach und spielend ist es dann doch nicht. Da sollte man dann auch rechtlich ein zwei Gedanken rein investieren. Denn wenn beide Firmen, egal wie gut sie sich jetzt verstehen, über das gleiche Gateway ins Internet gehen, ist das ein Zugriffspunkt, an dem potentiell die Daten zusammenlaufen "können"! Das kann - je nach Aufgabengebiet der beiden Firmen - durchaus rechtlich nicht unwichtig sein (bspw. für diverse ISO Zertifizierungen, Datenschutz etc. blafasel). Noch dazu kommt, dass eine Mißkonfiguration an diesem Punkt dazu führen kann, dass bspw. Daten aus dem einen Netz in das andere sickern und umgekehrt - auch das kann unschön sein. Schlußendlich könnten Daten den falschen Weg nach draußen nehmen. Da meistens Anschlüsse inzwischen Flat sind, ist das nicht mehr soo wichtig, sofern aber eine Firma später mal bspw. ne Glasanbindung hat und Traffic zahlt kann das nicht unwichtig sein.

Dann kommt letztlich nocht dazu, WER administriert den Kram (auch wegen dem Traffic den man abgreifen könnte) und ein "einfacher PC" sollte das Ding aus offensichtlichen Gründen auch nicht sein, denn wenn für beide Firmen auf einmal das Netz weg bricht, ist das für keinen schön, da sollte die Hardware schon was taugen und nicht einfach nur ein aufgepimpter PC sein.

Das sind mal meine "Senioren" 0,02€ dazu ;)

Müsste ich das umsetzen würde ich folgenden Weg einschlagen (wenn es schon wirklich EIN Gerät sein muss):

Gerät mit mind. 4 (eher 5-6) Netzwerkports anschaffen (mit entsprechendem Service Level) Switche überprüfen ob VLAN fähig und ggf. neue Switche anschaffen. Uplink von Switchen zur pfSense Instanz für jede Firma ein eigenes VLAN konfigurieren, jeden der zwei Switche auf eigenem Port auf pfSense VLAN 10 (bspw.) und VLAN 20 (für 2. Firma) jeweils auf das entsprechende Gateway mappen klare Regeln und Verträge ggf. Datenschutzerklärungen etc. vereinbaren.

Wenn ichs RICHTIG GUT machen dürfte und beide Anschlüsse nicht größer als 50MBit/s sind:

ZWEI APUs kaufen (bspw.), passt von der Hardware gut. JEDEM Anschluß EINE APU zuweisen (Port 0) sowie den Switch der Firma (Port 2) APUs miteinander verbinden (Port 1) Firmen fragen, ob sie ggf. ihre APU und ihr Internet "teilen" würden gegenseitig die APUs als zweites WAN defnieren (vereinfacht ausgrdrückt) Fallback Plan definieren, dass die APU von Firma 2 bspw. Fallback von Firma 1 ist.

Damit erreicht: Im Normalbetrieb geht der Traffic von jedem über seine APU und ist getrennt (mit VLANs, Routing etc.)
Fällt Line 1 oder APU1 aus, wird via Fallback Line auf APU2 dessen Netzverbindung auch für Firma 1 genutzt und umgekehrt. Damit wird nur dann Traffic zwischen den Firmen geroutet wenn deren Internet oder Router/APU ausfällt, ansonsten ists getrennt. Damit hätten auch beide ein Hardwarefallback beim anderen für den Fall eines defektes.

Das ganze würde dann Netzwerk-Plan mäßig wie ein Doppel H hintereinander aussehen ;)

Grüße
Jens

Embedded/non-embedded unterscheidet sich im Installations-Image, nicht in der Konfiguration. Einzig Dinge wie bspw. Speichern von RRD Graphen im RAM statt auf Karte können da noch für bessere Performance eingestellt werden. Ansonsten hängt auch viel von der Performance der Karte selbst ab. Da gab es auch schon Unterschiede.

Grüße

So Kinder,

kaum schau ich ein paar Tage nicht, bricht hier das Chaos aus ;)

Ernst beiseite, es gibt hier einiges übereinander was total chaotisch ist:

@jhochwald:

Somit sage ich mal: Zu jeder vollen Stunde (genau genommen immer eine Minute danach).
Wenn du es öffter haben willst/musst, kannst du gefahrlos einen zusätzlichen Cron Job etablieren. Ich mache den Check auf den meisten Systemen alle 10 Minuten. Auf solchen die oft/viel von extern zugegriffen werden sogar alle 5 Minuten.

Das stimmt so nicht ganz. Der DynDNS Service ist in mehrere Prozesse eingeschleift, bspw. Interface up/down, Dial-Ins etc. so dass bei vermutetem IP Wechsel ebenfalls nochmal "schnell" die externe IP geprüft wird und ggf. geändert. Der Cronjob ist nur als Fallback Line vorhanden, sollte sich was ändern und die pfSense es gar nicht mitbekommen, was aber selten der Fall ist (wenn man bspw. ein sinnvolles ext. Gateway zur Prüfung einträgt).

@blessing:

Die zielt darauf ab: Wie lang muss ich nach einem Reconnect warten, bis der Dyn DNS Dienst das Binding aktualisiert?

Siehe oben, sofern die pfSense den reconnect mitbekommt, wird binnen kürzester Zeit die IP auch beim DynDNS Host eingetragen. Dazu macht es ggf. Sinn, als Monitor-Gateway nicht den Telekom Router, sondern einen anderen Hop einzutragen (bspw. einen externen DNS Server wie den von Google der immer erreichbar sein sollte). Damit wird dann nicht nur der Telekom GW überprüft (ob er down ist bzw. rebootet, die Verbindung neu aufbaut, etc.), sondern die ganze Leitung.

@Sunshine:

Ich hab mich bissl vertan. Sorry für meinen verwirrenden Post zuvor :)

Unter System –> Gerneral Setup

Richtig heißt es:

Allow DNS Server List To be overriden by DHCP/PPP on WAN

Dieser Punkt muss aktiviert sein.
Schau mal ob das bei dir so ist.

Gruß

Der Punkt hier hat allerdings mal so gar nichts mit der Problematik DynDNS zu tun, bei dem geht es lediglich darum, dass bspw. Telekom DSL Anschlüsse die geographisch näcshten DNSe bei der Einwahl gepusht bekommen. Wenn der Punkt gesetzt ist, werden diese genutzt an statt der DNS Server, die man unter "General" eingetragen hat (als Fallback). Wie gesagt mit DynDNS hat das nichts zu tun.

@blessing:

Eigentlich - so war mein Verständnis von diesen DynDNS-Anbietern bisher - sagt der Client dem DNS-Server, welche IP an den DNS eingetrag gebunden werden soll. Zumindest hab ich schon einige durch und da war es dann immer Sache des Clients zu sagen, welche IP gerade aktuell ist und nicht Sache des DNS-Anbieters, es anhand der Absenderadresse festzulegen.

Es gibt sogar DynDNS Tools, die per SNMP die öffentliche IP des Internetgateways abfragen können.

Hierzu kurz: Jein. Einige DynDNS Dienste erwarten die Übergabe der IP vom Client oder per URL, andere stellen diese automatisch auf die IP ein, von der der Request kommt. Das hängt vom Dienst ab, hier reagieren viele Dienste unterschiedlich. Bei afraid.org bspw. kann das per URL, Client oder per Erkennung mit Token sein (bei Connect mit Token wird die IP des Zugriffs mit dem Account des Tokens verknüpft, es muss keine IP übergeben werden). So kann man auf verschiedene Bedürfnisse reagieren.

Anders ist der DynDNS Abgleich via RFC2136 (im entsprechenden Tab) wenn man einen Anbieter hat, der dies unterstützt bzw. es selbst betreibt. Hier kann per Schalter (auf meinen damaligen Bugreport) eingestellt werden, wie sich pfSense verhält. Standardmäßig wurde einfach die IP des WAN Interfaces übertragen, was in meinem Fall eine private war. Per Schalter wurde hier das selbe Verfahren wie für die DynDNS Anbieter eingebaut, so dass man bei privater IP am WAN einen Check auf eine Webseite macht und die externe Adresse ausliest und diese dann an den DNS Server übergibt.

Ich hoffe, das klärt alle technischen Detailfragen :D

Grüße
Jens

Danke euch, dass ihr das mit dem [Gelöst] Tag so schön weiter macht. Freut sich mein Moderatorenherz, dass ich nicht mehr so viel Arbeit habe :)

Hallo…

Danke, die Checkbox kannte ich noch nicht. Werde das mal die Tage beobachten.

Danke,
Markus

7500 kbit/s und je nach Sync + - 20 bit mehr oder weniger.

Hallo..

Ok danke für die Info…

Gibt es eigendlich eine Möglichkeit den "Interface Statistics" auf dem Dashboard die Interfaces auf 0 zusetzten? Am besten per Script mit Cron.

lg, markus

Ich denke es liegt eher an der OpenSwan Konfiguration. Kennt sich eventuell jemand mit dieser Konstellation aus? Die Lifetime Phase 2 muss ich dem Client ja eigentlich nicht mitgeben?

Aber natürlich musst du die Phase 2 auch auf dem Client konfigurieren. Das ist ja kein OpenVPN Tunnel mit dediziertem Server/Client Anteil. IPSec verhandelt jede Phase einzeln, dazu müssen aber trotzdem beide konfiguriert sein. Wenn die Phase 2 bspw. nicht übereinstimmt, kann es genau zu solchen seltsamen Phänomenen kommen. In dem REst deiner Konfiguration oben kann ich aber weder die komplette P1 noch die Werte der P2 ersehen. Lediglich die Crypto Werte sind eingestellt und die IKE Lifetime. Da fehlt aber noch der Rest.

Hört sich lustig an. Ggf. könntest du einen Teil auch per time-based Rules abwickeln (also quasi Grundzeiten definieren, wo Junior und Töchterchen ins Internet dürfen), und die sonstigen Zeiten über ne Zusatzregel an und abschalten.
Wäre sicher nicht optimal und das CP oder ein anderes Modul ggf. sinnvoller. Du könntest bei entsprechendem Switch auch die Kids in ein eigenes VLAN hängen (was dann ein extra Interface auf der pfSense wäre und damit wären wieder Interface Regeln möglich, CP etc.).

Was hat es denn noch mit dem Firewall Auszug auf sich? Und den Ports? Den letzten Teil hatte ich nicht ganz im Zusammenhang verstanden.

Ich verstehe leider das neue Schaubild nicht. Sind da jetzt plötzlich 2 pfSense am Start?
Warum? Der oben geschilderte Fall funktioniert bei korrektem Setup ohne Probleme. Verstehe die neuerliche Umgestaltung nicht. Wenn ständig was umgebaut wird, kann es ja nicht funktionieren.

Du hast leider überhaupt nichts angemerkt, ob du Änderungen vorgenommen hast, wie ich sie im letzten Post vorgeschlagen habe.
Ich kann also kaum was dazu sagen, dass das Problem noch besteht, wenn ich nicht weiß ob du was verändert hast…

Hat die pfSense hinter der FB jetzt eine statische Adresse oder immer noch dynamisch (weil du hier mit dhclient rumkasperst)? Wenn nein, warum? Ich habe oben weitschweifig genug (so hoffe ich) ausgeführt, dass es quatsch ist, Router hinter Router zu betreiben, wenn der zweite Router dann auch noch die Adresse dynamisch bekommt und ggf. wechselt. Das ist Unfug! Nein, du hast kein Skript zu schreiben. Das ist genauso Unfug, denn dein geschilderter Fall würde überhaupt nicht mehr passieren, wenn du dem Folgen würdest, was wir dir hier die ganze Zeit schon raten...

Gruß

Du bist schon richtig gut. Es handelt sich um einen Hetzner-Server.

Naah, ich kenne nur meine Pappenheimer aus langer Erfahrung ;)

Aber in ein paar Schritten was muss dann getan werden?

Nunja, die Bridge muss wieder weg. Auf Nummer sicher gehen würde ich indem ich auf dem WAN der pfSense VM den Zugriff per tcp/80,443,22 von deiner IP aus erlaubst (für die Umbauarbeiten), dass für den Fall der Fälle du dich aussperrst du entweder mit vClient oder auf externem WAN wieder auf die Kiste kommst.

Ansonsten klassisches Setup.

Erfragen auf welche IP das Netz geroutet wird Erfragen ob dazu ggf. eine bestimmte MAC benötigt wird diese IP/MAC auf WAN Seite der pfSense konfigurieren LAN Seite mit privatem Netz (oder Netzen - ggf. mit mehreren VLANs) einrichten andere VMs an vSwitch1 hängen, der seinerseits an LAN der pfSense hängen sollte (und an keiner physikalischen NIC des vmware Hosts) 1:1 NAT einrichten mit externer IP aus dem /29er auf die private IP der VM die du ins Netz bringen willst.

So würde ichs machen. Durch die 1:1 NAT hast du den Vorteil, dass du nicht noch die IP fürs Routing verlierst (die die pfSense selbst dann bräuchte) und du ggf. sogar die Netz- oder Broadcast Adresse für Outbound NAT verwenden kannst (spart noch ne IP Adresse).

Grüße
Jens

(der Admin, der für die Beinchen des "fremden" Netzwerkes in unserer DMZ verantwortlich ist, kann dazu nur sagen, dass sein Dienstleister, der die FW für ihn wartet "irgendwas mit failover" auf einer Cisco-Maschine macht …)

Auweia, sowas von einem "Admin-Kollegen" lesen zu müssen, ist schon gemein - als Admin sollte man wissen, was in seinem Netz los ist ;) Aber schön, dass das Problem tatsächlich so leicht zu finden war. Und IMF (irgendwas mit Failover) bei Cisco heißt im Normalfall mind. HSRP oder sogar VRRP. Dann ist es kein Wunder.

Grüße

Das Problem war, dass die pfSense dann NICHT nattet, wenn ein Gateway eingetragen ist. Für meine nachgelagerten Netze habe ich ein Gateway gebraucht und das bei der LAN Schnittstelle angelegt - dadurch wird es auch ausgewählt und dann nattet er nicht.

Ich hab mal ein Bild der betreffenden Stelle angefügt.