Hatte jahrelang IPsec Tunnel, auch mit ADSL mit Zwangstrennung, mit pfSense und mit anderen, da hat es nie Probleme mit dem reconnect gegeben. Vielleicht pennt der DynDNS Anbieter und braucht zu lange, bis er die neue IP verteilt?

Quatsch, probier mal:

In Phase 1 DPD raus (kein Haken)

In Phase 2 unter Advanced Options (ganz unten) bei "Automatically ping host" eine IP im Netz auf der anderen Seite eintragen (auf beiden Seiten des Tunnels)

Interfaces -> WAN-Interface -> IPv4 Configuration Type "Static IPV4"

Static IPv4 configuration -> "IP-Adresse"

Du kannst aber auch temporär das LAN-Interface zum Einrichten des VPN-Servers nutzen. Dann musst du aber, wenn der Server produktiv geht, das Interface wieder umswitchen (Was eine aktive Internetverbindung voraussetzt)

Diese Restriktion ist etwas unglücklich gewählt, da es das Anlegen eines VPN-Dienstes bei einer nicht produktiven Pfsense verkompliziert wird. Aber vielleicht gibt es einen Grund warum das gemacht wurde.

Danke für die Rückmeldung und schön das die Ursache gefunden wurde.

Ich habe das neue ntopng ausprobiert und es funktioniert ohne Probleme.

Genau soetwas habe ich gesucht. Besten Dank.

Gruß
Jan

Hi,

Did you find any solution to this issue?

I'm experiencing the same issue.

Sorry to reply in English.

Thanks.

Guten Morgen,

hat denn die virtuelle IP den 192.168.1.1 als Gateway hinterlegt?

Ich habe das Script nun ausgelagert auf eine andere Maschine und hole mir die Log-File über einen symbolischen Link ;-)
ist mir zwar ein bisschen unlieb da die Access.log dann offen liegt, aber das Netz hängt eh nur intern.

Danke.

LG
Chris

Hallo,
um nochmal auf die Routingtabelle zurück zukommen.

Wenn ich das richtig verstanden habe, resultiert das Geheimnis des "merkwürdigen" Eintrages der Netzwerkmaske 128..0.0.0 in meiner
Routingtabelle aus der Festlegung der bestmöglichen Route (in diesem Fall durch den Tunnel).

Das Verfahren nennt sich "Longest Prefix Match".
D.h., mit diesem Verfahren wird ein Paket nur über die Schnittstelle weitergeleitet, die eine maximale Übereinstimmung mit der Zieladresse hat.

Also:
Netzwerkziel    Netzwerkmaske    Gateway              Schnittstelle        Metrik
0.0.0.0            0.0.0.0                192.168.77.254  192.168.77.116    10
0.0.0.0        128.0.0.0                192.168.200.5    192.168.200.6      25

Hier wird die Route nicht aufgrund des Metric Wertes festgelegt, sondern anhand der der Netzwerkmaske (eben der maximale Übereinstimmung mit der Zieladresse).
Somit gehen die Datenpakete über die 2. Route (Tunnel).

Dann wäre nur noch eine Frage offen:

Mir ist aufgefallen, dass in der Routingtabelle auf dem OpenVPN Server neben der eigentlichen
openvpn Schnittstelle 192.168.200.1 noch eine weitere IP-Adresse 192.168.200.2 auftaucht.
Diese 192.168.200.2 ist aber nicht erreichbar.

Auf dem OpenVPN Client (Windows 7) wird neben der Zuweisung der Client IP 192.168.200.6
dann auf einmal ein Gateway mit der IP 192.168.200.5 zugewiesen.
Die IP-Adresse 192.168.200.5 ist nicht erreichbar.

Die Verbindung geht aber über das richtige GW 192.168.200.1 (z. B. mit Tracert getestet).

Was hat das zu bedeuten?

Gruß
Peter

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