bmitsol
Nov 21, 2021
view4149
view24
0
Goto Top

PfSense - IPSec-VPN Connection Fail nach ISP-Zwangstrennung

GermanQuestionRouters, RoutingNetworks
Hallo zusammen,

nach dem Update auf 2.5.2 habe ich das Problem, dass die PfSense immer nach der mitternächtlichen Zwangstrennung des ISP die entsprechenden IPSEC-P1-Tunnel nicht mehr aufbaut. Der Status steht dann hier auf "Connecting...".

Das LOG sagt nur:
05[NET] error writing to socket: Can't assign requested address

Wenn ich über das Webinterface den IPSEC-Service stoppe und wieder starte (ein restart geht nicht!) verbindet sich die VPN wieder ohne Probleme-

Systemaufbau:

PfSense (im RZ; 2.5.2) mit fester IP

--> IPSEC (v2) zu Standort 1 (pfsense 2.5.2)
--> IPSEC (v2) zu Standort 2 (pfsense 2.5.2)

Das Problem besteht bei beiden VPNs zu beiden Standorten.


Danke im Vorraus
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 1536016153

Url: https://administrator.de/contentid/1536016153

Printed on: April 27, 2024 at 14:04 o'clock

24 Comments
Latest comment
Goto Top
Member: chgorges
chgorges Nov 21, 2021 at 10:54:52 (UTC)
Goto Top
Moin, ich kenne das von OpenVPN Site2Site Tunneln, wenn man auf der jeweiligen Seite als localhost-Adresse die statische IP des Providers setzt.
Dann versucht der VPN-Dienst während der Zwangstrennung die Tunnel zu initiieren, kann die IP aber nicht verschwinden und endet dann im Nirvana-Zustand.

Wie sehen deine Configs denn aus?

VG
Member: bmitsol
bmitsol Nov 21, 2021, updated at Apr 21, 2022 at 14:53:14 (UTC)
Goto Top
Moin face-smile

ich habe lediglich die Auswahl des Interfaces und des Remote Gateways:

screenshot 2021-11-21 120854
Member: ChriBo
ChriBo Nov 21, 2021 at 11:29:05 (UTC)
Goto Top
Hi,
IPsec Probleme, besser Reconnect Probleme nach einem Update auf 2.5.2 hatte ich auch auf einer Installation.
In diesem Forum wurde auch schon mal vor ein oder zwei Monaten das Problem angesprochen.
Wahrscheinlich ist der Updateprozess fehlehaft bzw. es werden Reste der alten Installation nicht entfernt oder übernommen.
Bei mir hat erst eine Neuinstallation von 2.5.2 das Problem behoben.

Gruß
CH
Member: bmitsol
bmitsol Nov 21, 2021 at 11:38:35 (UTC)
Goto Top
Zitat von @ChriBo:

Bei mir hat erst eine Neuinstallation von 2.5.2 das Problem behoben.


Na großartig... Wenn niemand sonst eine Idee hat hätte ich das wohl ohnehin versucht. Danke
Member: aqui
aqui Nov 21, 2021 updated at 12:39:44 (UTC)
Goto Top
Kann das sein das du DPD (Dead Peer Detection) deaktiviert hast ?!
Wenn DPD beidseitig aktiv ist sollte der Tunnel sofort wieder neu aufgebaut werden. Wie der Name der Funktion es ja schon sagt... face-wink
dpd
Alternativ kannst du auch einen Keepalive Ping setzen der den Tunnel immer wieder neu triggert nach Ausfall.
ich habe lediglich die Auswahl des Interfaces und des Remote Gateways:
Das ist falsch, denn im Phase 2 Setup des Tunnels gibt es weitere Optionen !
Member: bmitsol
bmitsol Nov 21, 2021 at 13:17:33 (UTC)
Goto Top
Hi aqui,

danke für deine Antwort (habe fast darauf gewartet ;)).

DPD: Ist aktiv, an allen drei pfSensen

Keepaliveping & Optionen in P2:
Nützt mir das etwas wenn der P1-Tunnel schon garnicht zustande kommt?


VG
Member: aqui
aqui Nov 21, 2021 updated at 14:03:23 (UTC)
Goto Top
Mmmhhh komisch... rennt hier auf diversen 2.5.2ern ohne jegliche Probleme.
Wenn P1 schon gar nicht zustande kommt, dann hast du aber schon ganz andere Probleme als DPD. Da stimmt dann grundsätzlich an deinem Setup etwas nicht.
Member: bmitsol
bmitsol Nov 21, 2021 at 20:06:33 (UTC)
Goto Top
Bei allen anderen ist das auch kein Problem... Nur bei diesem einen Netzwerk.

Die Verbindung kommt auch nicht zustande, wenn ich manuell auf "Verbinden" drücke, dann steht da nur "Connecting".

Vor dem Update hat alles durchgehend funktioniert.

Ebenfalls interessant ist, dass wenn ich einen "restart" des VPN-Services mache es weiterhin nicht funktioniert... Erst das stoppen und wieder starten behebt den Fehler. Bis zur nächsten Zwangstrennung...
Member: aqui
aqui Nov 22, 2021 at 09:47:30 (UTC)
Goto Top
dass wenn ich einen "restart" des VPN-Services mache es weiterhin nicht funktioniert...
Mmmhhh...das lässt aber den Verdacht aufkommen das es nichts mit dem VPN selber zu tun hat sondern eher mit dem PPPoE bzw. etwas was die Internet Anbindung per se betrifft. Das ggf. der PPPoE Tunnel gar nicht erst zum Laufen kommt und deshalb auch das VPN scheitert.
Dadurch das es nur bei einem passiert spricht das für ein spezifisches Provider Problem.
Im Zeofel musst du mit einem Script ein Keepalive Check machen und wenn der 3mal fehlschägt den Prozess neu starten. Ist zwar nicht so toll aber ein Workaround wenn es anders nicht zu fixen ist.
Member: bmitsol
bmitsol Nov 22, 2021, updated at Apr 21, 2022 at 15:09:53 (UTC)
Goto Top
Dagegen würde sprechen, dass die Internetverbindung ja funktioniert. Das Webinterface ist über WAN erreichbar, den Restart des VPN-Services (bzw. stop und start) mache ich also quasi über die PPPoE-Leitung.


Hier ein Screenshot wie das dann aussieht:

admin

post scriptum:
Mit "Stoppen und Starten" meinte ich tatsächlich den VPN-Service, nicht die PfSense

admin2
Member: aqui
aqui Nov 22, 2021 at 13:36:00 (UTC)
Goto Top
Mmmhhh diverse Provider übergreifende IKEv2 Tunnel zeigen hier die Problematik mit 2.5.2 nicht. Mehrfach den WAN Port gezogen oder mal, um keinen Link down zu provozieren, nur den Router ausgeschaltet bzw. rebootet brachte den Link immer wieder auf die Füße.
  • Hängen die FWs direkt am Internet (PPPoE) oder gehst du über eine Kaskade mit einem NAT Router davor ?
  • Stimmen die FW Regeln die IPsec (UDP 500, 4500 und ESP) durchlassen ?
  • Hast du testweise eine Site mal nur als reinen Responder und den anderen als Initiator laufen lassen um ggf. dediziert mal einen Tiebreak zu verhinden ?
Member: bmitsol
bmitsol Nov 23, 2021 at 02:29:51 (UTC)
Goto Top
Mmmhhh diverse Provider übergreifende IKEv2 Tunnel zeigen hier die Problematik mit 2.5.2 nicht. Mehrfach den WAN Port gezogen oder mal, um keinen Link down zu provozieren, nur den Router ausgeschaltet bzw. rebootet brachte den Link immer wieder auf die Füße.
So auch hier - ein Reboot des ganzen Routers bringt die VPN auch wieder auf die Beine... Aber eine Zeitschaltuhr, welche den Router täglich um 3 Uhr für 5 Min vom Strom nimmt finde ich wenig elegant.

* Hängen die FWs direkt am Internet (PPPoE) oder gehst du über eine Kaskade mit einem NAT Router davor ?
Die PfSense macht das VLAN(7) Tagging & PoE Einwahl. Davor hängt ein Allnet BM-200 bzw. ZTE H186 Modem als "Medienkonverter".

* Stimmen die FW Regeln die IPsec (UDP 500, 4500 und ESP) durchlassen ?
Si

* Hast du testweise eine Site mal nur als reinen Responder und den anderen als Initiator laufen lassen um ggf. dediziert mal einen Tiebreak zu verhinden ?
Nein, konfiguriere ich aber gerne gleich mal. Ich nehme jetzt die PfSense in der Site als Initiator und im RZ als Responder. Melde mich morgen um die Zeit mit dem Ergebnis.
Member: aqui
aqui Nov 23, 2021 updated at 14:44:56 (UTC)
Goto Top
So auch hier - ein Reboot des ganzen Routers
Das hast du missverstanden. Mit Router war ein davorliegenr Router in eine NAT Kaskade gemeint. Die pfSense wurde defacto NICHT rebootet und trotzdem kam der Tunnel wieder auf die Füße !
Tip:
Teste doch rein spaßeshalber ggf. mal IKEv1 ob das Verhalten da identisch oder ggf. anders ist ?!
Member: bmitsol
bmitsol Nov 23, 2021 at 15:04:12 (UTC)
Goto Top
Moin,

stimmt, jetzt ergibt es aber Sinn.

Ich warte heute Nacht mal das Ergebnis von "Responder only" ab - wenn der Fehler weiter besteht versuche ich IKEv1... Wenn dir (oder jemandem anderen) dann nichts mehr einfällt werde ich das Ding mal formatieren und frisch installieren - vlt. ja doch was mit dem Update.
Member: bmitsol
bmitsol Nov 24, 2021 at 02:46:01 (UTC)
Goto Top
@aqui

Vielen Dank - Der Tipp mit dem Responder only war die Lösung - zumindest scheint es so, heute Nacht hat er wieder aufgebaut.

Der zweite Tunnel zu einem anderen Standort hatte ich zum testen nicht umkonfiguriert, dieser hat den Fehler weiterhin.


Für alle die also die Lösung zum Anfangsthread suchen: Bei mit hat es geholfen die PfSense am Standort mit der wechselnden IP als Initiator und die pfSense im RZ als Repsonder Only zu konfigurieren.
Member: aqui
aqui Nov 24, 2021 at 09:12:10 (UTC)
Goto Top
Der Tipp mit dem Responder only war die Lösung
👍
Member: bmitsol
bmitsol Nov 25, 2021 at 16:50:51 (UTC)
Goto Top
Kommando zurück - nachdem es jetzt zwei Tage ging haben wir den selben Fehler wieder.

05[NET] error writing to socket: Can't assign requested address

Was mir außerdem aufgefallen ist: Wenn ich eine Änderung am WAN-Interface vornehme, habe ich das selbe Problem wie bei der Zwangstrennung... Auch dann muss ich den Service Stoppen und wieder starten.
Member: aqui
aqui Nov 25, 2021 updated at 17:00:53 (UTC)
Goto Top
Was für ein WAN Design nutzt du ? Direkt DHCP oder PPPoE von der FW mit nur Modem oder Kaskade mit NAT Router ?
Member: bmitsol
bmitsol Nov 25, 2021 at 19:39:38 (UTC)
Goto Top
DSL (VDSL) --> Allnet BM200 --> PfSense --> VLAN7 --> PPPoE

Die PfSense übernimmt also die PPPoE Einwahl inkl. VLAN-(7)-Tagging
Member: bmitsol
bmitsol Nov 25, 2021 at 23:03:09 (UTC)
Goto Top
Update: Ich habe die Zwangstrennung mal in der PfSense auf 21 * * * * gelegt. Diese wurde dann um 23.00 durchgeführt (ich nehme mal an das 21 ist UTC). Und außerdem das VPN komplett gelöscht und neu angelegt.

Die VPNs haben sich richtig verbunden.

Dann habe ich im Adapter etwas geändert und die Settings "Applied".

-> VPN ist immernoch verbunden mit der alten Lease (PPPoE-Session ist 1.30min alt; VPN ist connected seit 4.45min) "steht", d.h. im Status läuft die "Verbundenzeit" nicht weiter. Nochmal eine Minute später trennt er die Verbindung (denke DPD) und ist jetzt wieder soweit, dass er sich nicht verbindet (Altes Problem).

Wenn ich das LOG (siehe unten) richtig lese, lehnt er Verbindungen ab weil er selbst noch versucht eine Verbindung aufzubauen... Ich werde also mal Responder Only auf die andere Seite bauen... Interessant ist aber, dass die ursprüngliche Fehlermeldung garnicht auftaucht...

Simuliere ich eine Zwangstrennung über eine Änderung im WAN-Interface und "Apply Changes" dann baut er wieder keine Verbindung auf... Selber Fehler wie vorher. Er versucht auch weiter zu verbinden, obwohl ich "Child SA Start Action" entsprechend auf Responder Only gestellt habe... Wie der Name aber schon sagt, gilt das für P2, für P1 finde ich keine Einstellung...

Alles in allem echt komisch.

Hier das LOG:
Nov 25 22:10:13 	charon 	44206 	06[IKE] <con2000|40> IKE_SA con2000[40] state change: CONNECTING => DESTROYING
Nov 25 22:10:13 	charon 	44206 	06[IKE] <con2000|40> establishing IKE_SA failed, peer not responding
Nov 25 22:10:13 	charon 	44206 	06[IKE] <con2000|40> giving up after 5 retransmits
Nov 25 22:10:11 	charon 	44206 	08[CFG] ignoring acquire, connection attempt pending
Nov 25 22:10:11 	charon 	44206 	06[KNL] creating acquire job for policy 85.XXX.XXX.XXX/32|/0 === 148.XXX.XXX.XXX/32|/0 with reqid {2}
Nov 25 22:10:07 	charon 	44206 	06[CFG] ignoring acquire, connection attempt pending
Nov 25 22:10:07 	charon 	44206 	12[KNL] creating acquire job for policy 85.XXX.XXX.XXX/32|/0 === 148.XXX.XXX.XXX/32|/0 with reqid {2}
Nov 25 22:10:04 	charon 	44206 	12[CFG] ignoring acquire, connection attempt pending
Nov 25 22:10:04 	charon 	44206 	06[KNL] creating acquire job for policy 85.XXX.XXX.XXX/32|/0 === 148.XXX.XXX.XXX/32|/0 with reqid {2}
Nov 25 22:10:00 	charon 	44206 	13[CFG] vici client 227 disconnected
Nov 25 22:10:00 	charon 	44206 	13[CFG] vici client 227 requests: list-sas
Nov 25 22:10:00 	charon 	44206 	06[CFG] vici client 227 registered for: list-sa
Nov 25 22:10:00 	charon 	44206 	13[CFG] vici client 227 connected
Nov 25 22:10:00 	charon 	44206 	11[CFG] ignoring acquire, connection attempt pending
Nov 25 22:10:00 	charon 	44206 	13[KNL] creating acquire job for policy 85.XXX.XXX.XXX/32|/0 === 79.140.184.112/32|/0 with reqid {1}
Nov 25 22:09:58 	charon 	44206 	13[CFG] ignoring acquire, connection attempt pending
Nov 25 22:09:58 	charon 	44206 	11[KNL] creating acquire job for policy 85.XXX.XXX.XXX/32|/0 === 148.XXX.XXX.XXX/32|/0 with reqid {2}
Nov 25 22:09:57 	charon 	44206 	11[CFG] vici client 226 disconnected
Nov 25 22:09:57 	charon 	44206 	13[CFG] vici client 226 requests: list-sas
Nov 25 22:09:57 	charon 	44206 	13[CFG] vici client 226 registered for: list-sa
Nov 25 22:09:57 	charon 	44206 	14[CFG] vici client 226 connected
Nov 25 22:09:54 	charon 	44206 	10[CFG] ignoring acquire, connection attempt pending
Nov 25 22:09:54 	charon 	44206 	07[KNL] creating acquire job for policy 85.XXX.XXX.XXX/32|/0 === 148.XXX.XXX.XXX/32|/0 with reqid {2}
Nov 25 22:09:52 	charon 	44206 	01[CFG] ignoring acquire, connection attempt pending
Nov 25 22:09:52 	charon 	44206 	07[KNL] creating acquire job for policy 85.XXX.XXX.XXX/32|/0 === 148.XXX.XXX.XXX/32|/0 with reqid {2}
Nov 25 22:09:46 	charon 	44206 	09[CFG] ignoring acquire, connection attempt pending
Nov 25 22:09:46 	charon 	44206 	07[KNL] creating acquire job for policy 85.XXX.XXX.XXX/32|/0 === 148.XXX.XXX.XXX/32|/0 with reqid {2}
Nov 25 22:09:45 	charon 	44206 	07[CFG] vici client 225 disconnected
Nov 25 22:09:45 	charon 	44206 	09[CFG] vici client 225 requests: list-sas
Nov 25 22:09:45 	charon 	44206 	07[CFG] vici client 225 registered for: list-sa
Nov 25 22:09:45 	charon 	44206 	15[CFG] vici client 225 connected
Nov 25 22:09:43 	charon 	44206 	09[CFG] ignoring acquire, connection attempt pending
Nov 25 22:09:43 	charon 	44206 	15[KNL] creating acquire job for policy 85.XXX.XXX.XXX/32|/0 === 148.XXX.XXX.XXX/32|/0 with reqid {2}
Nov 25 22:09:40 	charon 	44206 	15[CFG] ignoring acquire, connection attempt pending
Nov 25 22:09:40 	charon 	44206 	08[KNL] creating acquire job for policy 85.XXX.XXX.XXX/32|/0 === 148.XXX.XXX.XXX/32|/0 with reqid {2}
Nov 25 22:09:40 	charon 	44206 	08[CFG] vici client 224 disconnected
Nov 25 22:09:40 	charon 	44206 	15[CFG] vici client 224 requests: list-sas
Nov 25 22:09:40 	charon 	44206 	08[CFG] vici client 224 registered for: list-sa
Nov 25 22:09:40 	charon 	44206 	15[CFG] vici client 224 connected
Member: chgorges
chgorges Dec 01, 2021 at 09:21:44 (UTC)
Goto Top
Moin,

hast du den "My Indentifier" in Phase 1 mal rausgenommen? Das ist das, was ich eingangs geschrieben habe, das Gateway muss nicht wirklich wissen, wer er ist, weil es das automatisch weiß.

VG
Member: bmitsol
bmitsol Dec 01, 2021 at 10:00:48 (UTC)
Goto Top
Hi chgorges,

meinem Verständnis nach sollte das nur ein "Problem" darstellen können wenn der Identifer "My IP" ist, oder? Ich hatte hier aber einen Distinguished Name hinterlegt - dieser ist also static.

Allerdings: Nach meinem letzten Post gab es noch einen Absturz - seitdem (ohne dass ich etwas angefasst habe) läuft das Ding...

Ich möchte es daher ehrlich gesagt grade nicht anfassen - sollten die Probleme erneut auftreten würde ich das aber als erstes probieren.
Member: chgorges
chgorges Dec 01, 2021 at 10:18:15 (UTC)
Goto Top
meinem Verständnis nach sollte das nur ein "Problem" darstellen können wenn der Identifer "My IP" ist, oder? Ich hatte hier aber einen Distinguished Name hinterlegt - dieser ist also static.

Genau das kann aber zum Verhängnis werden, wenn die PFsense im Moment der Zwangstrennung versucht, die DynDNS-Adresse zu aktualisieren.
IdR wird es nach dem dritten Versuch dann sein gelassen -> Fehlerhafte/keine DynDNS-Adresse -> nicht funktionierende Phase 1 und keine automatische Korrektur des Problems sondern nur behebbar durch manuelles Eingreifen, was du jetzt als Workaround eingerichtet hast.
Member: aqui
aqui Dec 01, 2021 at 10:57:46 (UTC)
Goto Top
seitdem (ohne dass ich etwas angefasst habe) läuft das Ding...
Bitte dann auch diesen Thread als erledigt markieren !
How can I mark a post as solved?
GermanQuestionRouters, RoutingNetworks