9
PfSense 2.4 IPSec VPN mobile Clients Phase 2 wird plötzlich nicht mehr aufgebaut - So einfach war die Lösung
Moinsen!
Nachdem ich mir hierbei nen Wolf gesucht habe, möchte ich doch die Welt an dieser simplen Lösung teilhaben lassen...
Nach einer Telekom-Umstellung (evtl. irrelevant, sehe eigentlich nur eine zeitliche Verbindung) kam es auf der PfSense eines Kunden zu folgendem seltsamen Verhalten beim IPSec-VPN:
Die statische Verbindung zum 2 Standort ist auf Anhieb wieder stabil.
Die mobile Einwahl mit dem Shrew Client zickt aber. Identische Konfiguration geht offenbar abhängig vom einwählenden Standort mal doch und mal nicht. Dabei wird die Phase 1 aufgebaut, ein Versuch, auch die Phase 2 zu etablieren findet aber einfach nicht statt. Nach Abschluss der Phase 1 kommt statt und dem Aufbau der Phase 2 nur ein lapidares und danach ausschliesslich Dead Peer Detection Traffic. (Shrew-Log)
Exakt dieselbe Konfiguration funktioniert aber auf 2 anderen Rechnern in anderen Netzen fehlerfrei. Auf einem weiteren Mitarbeiterlaptop aber auch nicht.
Der Shrew funktioniert, alle anderen PfSense mit vergleichbarer Konfiguration lassen sich verbinden. Warum nur diese eine Verbindung nicht. Wo ist der relevante Unterschied?
Nach Stunden kam ich nun irgendwann auf den Gedanken, dass die PfSense je mobilem Client immer wieder dieselbe virtuelle IP vergibt. Client A x.x.x.1 konnte sich nicht einwählen, Client B mit x.x.x.2 konnte. C mit x.x.x.3 ging auch nicht.Sollte es mit diesen virtuellen IP's zusammenhängen?
Tat es. IP-Range umgestellt von 192.168.40.0 /24 auf 192.168.41.0 /24 und die Phase 2 will wieder. Zurückgestellt auf die 40.0 und wieder der Fehler.
Sieht mir nach einem kleinen Bug in der PfSense aus, dass da wahrscheinlich irgendein Eintrag irgendwo hängenbeibt, was dann eine erneute Phase 2 für diesen Client (User?) verhindert. Oder doch irgenwas auf Clientseite? Ich weiss es nicht.
Möge sich der eine oder andere bei diesem wohl extrem seltenen Fehler ein paar graue Haare ersparen.
Buc
Nachdem ich mir hierbei nen Wolf gesucht habe, möchte ich doch die Welt an dieser simplen Lösung teilhaben lassen...
Nach einer Telekom-Umstellung (evtl. irrelevant, sehe eigentlich nur eine zeitliche Verbindung) kam es auf der PfSense eines Kunden zu folgendem seltsamen Verhalten beim IPSec-VPN:
Die statische Verbindung zum 2 Standort ist auf Anhieb wieder stabil.
Die mobile Einwahl mit dem Shrew Client zickt aber. Identische Konfiguration geht offenbar abhängig vom einwählenden Standort mal doch und mal nicht. Dabei wird die Phase 1 aufgebaut, ein Versuch, auch die Phase 2 zu etablieren findet aber einfach nicht statt. Nach Abschluss der Phase 1 kommt statt
processing phase2 packet processing informational packet ( 92 bytes )Exakt dieselbe Konfiguration funktioniert aber auf 2 anderen Rechnern in anderen Netzen fehlerfrei. Auf einem weiteren Mitarbeiterlaptop aber auch nicht.
Der Shrew funktioniert, alle anderen PfSense mit vergleichbarer Konfiguration lassen sich verbinden. Warum nur diese eine Verbindung nicht. Wo ist der relevante Unterschied?
Nach Stunden kam ich nun irgendwann auf den Gedanken, dass die PfSense je mobilem Client immer wieder dieselbe virtuelle IP vergibt. Client A x.x.x.1 konnte sich nicht einwählen, Client B mit x.x.x.2 konnte. C mit x.x.x.3 ging auch nicht.Sollte es mit diesen virtuellen IP's zusammenhängen?
Tat es. IP-Range umgestellt von 192.168.40.0 /24 auf 192.168.41.0 /24 und die Phase 2 will wieder. Zurückgestellt auf die 40.0 und wieder der Fehler.
Sieht mir nach einem kleinen Bug in der PfSense aus, dass da wahrscheinlich irgendein Eintrag irgendwo hängenbeibt, was dann eine erneute Phase 2 für diesen Client (User?) verhindert. Oder doch irgenwas auf Clientseite? Ich weiss es nicht.
Möge sich der eine oder andere bei diesem wohl extrem seltenen Fehler ein paar graue Haare ersparen.
Buc
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 546855
Url: https://administrator.de/tutorial/pfsense-2-4-ipsec-vpn-mobile-clients-phase-2-wird-ploetzlich-nicht-mehr-aufgebaut-so-einfach-war-die-loesung-546855.html
Ausgedruckt am: 22.12.2024 um 05:12 Uhr
9 Kommentare
Neuester Kommentar
Die mobile Einwahl mit dem Shrew Client zickt aber.
Warum Shrew Client wenn alles viel einfacher mit dem bordeigenen_VPN_Client zu erledigen ist ?!Normal sollten die Clients nicht immer eine feste IP bekommen. Wie auch, denn der Pool vergibt nach dem Motto first come first serve genau wie bei DHCP. Er kann ja niemals den Client eindeutig identifizieren wenn du mit PSK arbeitest und nicht mit Zertifikaten.
Wenn wäre der Fehler also hier zu sehen. Ist mir bis dato aber auch noch nicht untergekommen was vielleicht daran liegt das hier schon länger keine 3rd Party VPN Clientsoftware mehr verwendet wird sondern nur noch bordeigene.
Hallo,
ich habe schon diverse derartige Ungereimtheiten und Bugs in der pfSense gefunden, halte mich hier zwecks Stressvermeidung aber eher zurück, da man sonst ja eh immer von der gleichen Seite angezickt wird
Man kann auch irgendwo Bug Reports schreiben. Aber leider nur in englisch.
Gruß,
Jörg
ich habe schon diverse derartige Ungereimtheiten und Bugs in der pfSense gefunden, halte mich hier zwecks Stressvermeidung aber eher zurück, da man sonst ja eh immer von der gleichen Seite angezickt wird
Man kann auch irgendwo Bug Reports schreiben. Aber leider nur in englisch.
Gruß,
Jörg
Was heisst leider..? Die IT ist ja nun mal englisch dominiert und zudem ist der Maintainer NetGate (us)englisch und da wäre es sicher etwas vermessen zu fordern das die Deutsch können.
Spannend wäre mal ob das Verhalten beim OPNsense Fork reproduzierbar ist. Deren Maintainer sind m.W. Deutsche so das man da eher Chancen hat. Wie gesagt...wenn es da reproduzierbar ist.
Es ist aber auch nicht 100% auszuschliessen das der Fehler ggf. im Shrew liegt oder einer Wechselwirkung mit Shrew und dem OS liegt. Um das sicher beurteilen zu können müsste man nochmal detailierter debuggen und sich das Verhalten auch mal mit einem anderen OS wie Mac oder Linux ansehen. Das würde dann eine Einschätzung wer der böse Buhmann ist etwas wasserdichter und vor allem fairer machen, denn mit anzicken sollte das nichts zu tun haben. Bug ist Bug, keinen Frage. Keine Software ist vollkommen fehlerfrei wie wir alle wissen.
Spannend wäre mal ob das Verhalten beim OPNsense Fork reproduzierbar ist. Deren Maintainer sind m.W. Deutsche so das man da eher Chancen hat. Wie gesagt...wenn es da reproduzierbar ist.
Es ist aber auch nicht 100% auszuschliessen das der Fehler ggf. im Shrew liegt oder einer Wechselwirkung mit Shrew und dem OS liegt. Um das sicher beurteilen zu können müsste man nochmal detailierter debuggen und sich das Verhalten auch mal mit einem anderen OS wie Mac oder Linux ansehen. Das würde dann eine Einschätzung wer der böse Buhmann ist etwas wasserdichter und vor allem fairer machen, denn mit anzicken sollte das nichts zu tun haben. Bug ist Bug, keinen Frage. Keine Software ist vollkommen fehlerfrei wie wir alle wissen.
Hallo,
„leider“ insofern, dass ich mich seinerzeit gerne eingebracht hätte, was aber aufgrund der Sprachbarriere nicht möglich war.
Bei der OpnSense findet man z.B. wesentlich mehr deutschsprachige Ressourcen.
Gruß,
Jörg
„leider“ insofern, dass ich mich seinerzeit gerne eingebracht hätte, was aber aufgrund der Sprachbarriere nicht möglich war.
Bei der OpnSense findet man z.B. wesentlich mehr deutschsprachige Ressourcen.
Gruß,
Jörg
Hi..
Dann stell' doch auf OPN um.. wo ist Dein Problem ?
Ich hatte bei PFSense am Anfang nen Premium-Account.. der zahlte sich auch aus... Zugriff auf Haufenweise Video-Tut's etc...
Nach dem "Streit" damals mit PFSense bin ich auf OPN umgestiegen (bei Kleinzeuchs)... passt prima...
Gruss Globe!
Dann stell' doch auf OPN um.. wo ist Dein Problem ?
Ich hatte bei PFSense am Anfang nen Premium-Account.. der zahlte sich auch aus... Zugriff auf Haufenweise Video-Tut's etc...
Nach dem "Streit" damals mit PFSense bin ich auf OPN umgestiegen (bei Kleinzeuchs)... passt prima...
Gruss Globe!
Hallo,
hab' ich ja. Zumindest bei den letzten 700 Geräten
Gruß,
Jörg
hab' ich ja. Zumindest bei den letzten 700 Geräten
Gruß,
Jörg
Zitat von @aqui:
Die mobile Einwahl mit dem Shrew Client zickt aber.
Warum Shrew Client wenn alles viel einfacher mit dem bordeigenen_VPN_Client zu erledigen ist ?!geht aber nur mit Zertifikaten und die und ich, das ist keine harmonische Beziehung...
Normal sollten die Clients nicht immer eine feste IP bekommen. Wie auch, denn der Pool vergibt nach dem Motto first come first serve genau wie bei DHCP. Er kann ja niemals den Client eindeutig identifizieren wenn du mit PSK arbeitest und nicht mit Zertifikaten.
Ist aber so: Es wird immer dieselbe IP zugewiesen.
Wenn wäre der Fehler also hier zu sehen. Ist mir bis dato aber auch noch nicht untergekommen was vielleicht daran liegt das hier schon länger keine 3rd Party VPN Clientsoftware mehr verwendet wird sondern nur noch bordeigene.
Kämpft man halt mit anderen Fehlern... Ich bin schon aus prinzipiellen Gründen sehr für Vielfalt im Softwarebereich und hasse dieses ausufernde totalitäre Gehabe der Big Player wie die Pest...
Das Problem ist aber das diese Clients immer sehr eng in das Betriebssystem eingebunden sind. 3rd Party Clients hinken dann immer hinterher. Klar schränkt das die Vielfalt ein ist aber oft eben auf lange Sicht stressfreier, da nicht bei jedem OS Update wieder Funktionslosigkeit droht. Es ist also immer Ermessensache...
Und vor Zertifikaten musst du nun wirklich keine Angst haben. Zumal es ja nur ein einziges, einmaliges Server Zertifikat ist bei IKEv2 und mit 3560 Tagen Gültigkeit hast du da für die Laufzeit der Client Hardware Ruhe. Davon sind ja die User bei Preshared Keys keineswegs betroffen. Also nur Mut !!!
Und vor Zertifikaten musst du nun wirklich keine Angst haben. Zumal es ja nur ein einziges, einmaliges Server Zertifikat ist bei IKEv2 und mit 3560 Tagen Gültigkeit hast du da für die Laufzeit der Client Hardware Ruhe. Davon sind ja die User bei Preshared Keys keineswegs betroffen. Also nur Mut !!!
Zitat von @aqui:
Das Problem ist aber das diese Clients immer sehr eng in das Betriebssystem eingebunden sind. 3rd Party Clients hinken dann immer hinterher. Klar schränkt das die Vielfalt ein ist aber oft eben auf lange Sicht stressfreier, da nicht bei jedem OS Update wieder Funktionslosigkeit droht. Es ist also immer Ermessensache...
Das Problem ist aber das diese Clients immer sehr eng in das Betriebssystem eingebunden sind. 3rd Party Clients hinken dann immer hinterher. Klar schränkt das die Vielfalt ein ist aber oft eben auf lange Sicht stressfreier, da nicht bei jedem OS Update wieder Funktionslosigkeit droht. Es ist also immer Ermessensache...
Scheint mir extrem abhängig von der Philosophie der 3rd Party Entwickler zu liegen. Es gibt Tools die laufen seit Vista stressfrei auch auf Win 10 wie zB. der Shrew. Und das, obwohl er Treiber einbindet. Die scheinen anständig geschrieben zu sein.
Und vor Zertifikaten musst du nun wirklich keine Angst haben. Zumal es ja nur ein einziges, einmaliges Server Zertifikat ist bei IKEv2 und mit 3560 Tagen Gültigkeit hast du da für die Laufzeit der Client Hardware Ruhe. Davon sind ja die User bei Preshared Keys keineswegs betroffen. Also nur Mut !!!
Die haben Angst vor mir.
Um die Fehlerbeschreibung etwas zu komplettieren:
Ich hatte sowohl auf der PfSense eine neue Phase 1 und 2 für die mobilen Clients eingerichtet, als auch den Shrew neu installiert mit entsprechenden Neustarts. Beides blieb erfolglos. Interessant war, dass ein Häkchen bei "Maintain Persistent Security Associations" zwar zum Aufbau derselben führte, aber kein Traffic durchging... Sei's drum. Wenn ich mal Lust und Zeit habe, sehe ich mir natürlich gerne die Win10 Lösung an, aber die Mikrotik ist auch immer noch in der OVP...
