Site to Site VPN Tunnel bricht ab, baut nicht von allein wieder auf
Hallo zusammen,
Danke erst einmal für die vielen tollen Beiträge auf ADMINISTRATOR! Hierdurch konnte ich viel dazulernen und bin meinem Ziel der Standortvernetzung einen riesigen Schritt näher gekommen.
Ich habe es nach wochenlangem studieren und probieren endlich hinbekommen ein Site-To-Site VPN mit IPSec aufzubauen. Auf der einen Seite eine feste IP mit einem LANCOM Business R800+ Router Telekom Anschluss und auf der anderen Seite eine pfSense hinter einer Vodafone EasyBox (mit DynDNS) LTE Zugang. Da auf der pfSense und dem LANCOM die Begrifflichkeiten besonders im Bereich der IPSec Phase1 und Phase 2 nicht ganz identisch sind, war das für einen Neuling wie mich in Sachen Netzwerke/VPN gar nicht so einfach. Aber seit gestern habe ich einen funktionierenden Tunnel *freu freu freu*.
Leider bricht der Tunnel nach einer gewissen Zeit ab, ich würde sagen, nach ca. einer halben Stunde. Dann steht in der pfSense unter Status-IPSec "Disconnected". Der Tunnel baut sich erst wieder auf, nachdem ich IPSec "stoppe" und wieder "starte". Aus den IPSec Logs auf der pfSense werde ich nicht schlau, zumindest erscheinen dort keine "Errors" und "unable to" oder irgendwas in der Art. Auf dem Lancom habe ich es noch nicht geschafft überhaupt ein Log zu finden.
Hat jemand für mich einen Tipp wo ich als erstes suchen sollte? Kann es was mit den Angaben zur "Lifetime" zu tun haben?
Wie gesagt pfSense und Lancom sprechen im Webinterface nicht unbedingt die gleiche Sprache, das erschwert das Ganze. Nur ein Beispiel, beim Konfigurieren der Site-To-Site Verbindung auf dem Lancom wird neben dem PSK auch noch ein Passwort für die Übermittlung der IP-Adresse der Gegenstelle erwartet, ich muss eins angeben... Eine derartige Einstellung finde ich auf der pfSense nicht. Es klappt ja zum Glück trotzdem.
Ich werde auf jeden Fall weiter am Ball bleiben um noch mehr Licht in den VPN-Djungle zu bekommen.
Vielen Dank im Voraus!!!
Danycode
Danke erst einmal für die vielen tollen Beiträge auf ADMINISTRATOR! Hierdurch konnte ich viel dazulernen und bin meinem Ziel der Standortvernetzung einen riesigen Schritt näher gekommen.
Ich habe es nach wochenlangem studieren und probieren endlich hinbekommen ein Site-To-Site VPN mit IPSec aufzubauen. Auf der einen Seite eine feste IP mit einem LANCOM Business R800+ Router Telekom Anschluss und auf der anderen Seite eine pfSense hinter einer Vodafone EasyBox (mit DynDNS) LTE Zugang. Da auf der pfSense und dem LANCOM die Begrifflichkeiten besonders im Bereich der IPSec Phase1 und Phase 2 nicht ganz identisch sind, war das für einen Neuling wie mich in Sachen Netzwerke/VPN gar nicht so einfach. Aber seit gestern habe ich einen funktionierenden Tunnel *freu freu freu*.
Leider bricht der Tunnel nach einer gewissen Zeit ab, ich würde sagen, nach ca. einer halben Stunde. Dann steht in der pfSense unter Status-IPSec "Disconnected". Der Tunnel baut sich erst wieder auf, nachdem ich IPSec "stoppe" und wieder "starte". Aus den IPSec Logs auf der pfSense werde ich nicht schlau, zumindest erscheinen dort keine "Errors" und "unable to" oder irgendwas in der Art. Auf dem Lancom habe ich es noch nicht geschafft überhaupt ein Log zu finden.
Hat jemand für mich einen Tipp wo ich als erstes suchen sollte? Kann es was mit den Angaben zur "Lifetime" zu tun haben?Wie gesagt pfSense und Lancom sprechen im Webinterface nicht unbedingt die gleiche Sprache, das erschwert das Ganze. Nur ein Beispiel, beim Konfigurieren der Site-To-Site Verbindung auf dem Lancom wird neben dem PSK auch noch ein Passwort für die Übermittlung der IP-Adresse der Gegenstelle erwartet, ich muss eins angeben... Eine derartige Einstellung finde ich auf der pfSense nicht. Es klappt ja zum Glück trotzdem.
Ich werde auf jeden Fall weiter am Ball bleiben um noch mehr Licht in den VPN-Djungle zu bekommen.
Vielen Dank im Voraus!!!
Danycode
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 273867
Url: https://administrator.de/forum/site-to-site-vpn-tunnel-bricht-ab-baut-nicht-von-allein-wieder-auf-273867.html
Ausgedruckt am: 28.04.2025 um 10:04 Uhr
8 Kommentare
Neuester Kommentar
Ich habe es nach wochenlangem studieren und probieren endlich hinbekommen ein Site-To-Site VPN mit IPSec aufzubauen.
Mit dem hiesigen IPsec Grundlagentutorial ist das eine Sache von 10 Minuten....IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Leider bricht der Tunnel nach einer gewissen Zeit ab, ich würde sagen, nach ca. einer halben Stunde.
Das liegt vermutlich an den Keepalive Timern die auf beiden Seiten unterschiedlich sind.Auch können die Key LifeTimer unterschiedlich sein. Beide Parameter müssen auf beiden Seiten identisch sein. Zu 90% ist das der Fehler.
Checke also die Timer Settings dann bleibt die Session auch bestehen.
Der Tunnel baut sich erst wieder auf, nachdem ich IPSec "stoppe" und wieder "starte"
Auch da gibt es einen Timeout Timer. Spätestens aber nach 5 oder 10 Minuten sollte der Tunnel wieder da sein !Aus den IPSec Logs auf der pfSense werde ich nicht schlau, zumindest erscheinen dort keine "Errors" und "unable to" oder irgendwas in der Art
Mit den laienhaften Aussagen kann man natürlich nichts anfangen hier zu einer zielführenden Hilfe.Warum bist du nicht auf die Idee gekommen das Log mal zu posten hier ??
Lösche es vorher wegen der Übersichtlichkeit und logge dann mal einen Abbruch mit.
Hat jemand für mich einen Tipp wo ich als erstes suchen sollte?
Immer im Log auf beiden Seiten also pfSense und Lancom !Wie gesagt pfSense und Lancom sprechen im Webinterface nicht unbedingt die gleiche Sprache
BMW und Mercedes haben auch andere Lenkräder und Motoren.... !das erschwert das Ganze.
Nein, nicht wenn man weiss WAS man macht !Lancom wird neben dem PSK auch noch ein Passwort für die Übermittlung der IP-Adresse der Gegenstelle erwartet, ich muss eins angeben...
Eigentlich Unsinn, denn das erledigt IPsec von sich aus. Gerade wenn man den Aggressive Mode verwendet wie in deinem Szenario ! Vermutlich verwechselst du hier was, aber egal...das es geht zeigt schonmal das du (fast) alles richtig gemacht hast ! 
http://www.duden.de/rechtschreibung/Dschungel
Zitat von @aqui:
> Ich habe es nach wochenlangem studieren und probieren endlich hinbekommen ein Site-To-Site VPN mit IPSec aufzubauen.
Mit dem hiesigen IPsec Grundlagentutorial ist das eine Sache von 10 Minuten....
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Habe ich gelesen. Wochenlang ist auch ehrlich gesagt übertrieben, zusammengefasst habe ich mich aber viele Stunden damit auseinandergesetzt, ich bin jemand, der gerne versucht zu verstehen, warum ich was wie zu machen habe. Manche Dinge versteht man aber auch nicht auf anhieb. Aber egal!> Ich habe es nach wochenlangem studieren und probieren endlich hinbekommen ein Site-To-Site VPN mit IPSec aufzubauen.
Mit dem hiesigen IPsec Grundlagentutorial ist das eine Sache von 10 Minuten....
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Checke also die Timer Settings dann bleibt die Session auch bestehen.
Vielen Dank! Das werde ich gleich mal ausprobieren/nachsehen!Mit den laienhaften Aussagen kann man natürlich nichts anfangen hier zu einer zielführenden Hilfe.
Warum bist du nicht auf die Idee gekommen das Log mal zu posten hier ??
Lösche es vorher wegen der Übersichtlichkeit und logge dann mal einen Abbruch mit.
Der Tunnel lief heute irgendwie "besser"? Ich war zu ungeduldig, wollte meine Frage posten, im Log war einfach noch nichts! Ich gelobe Besserung!Warum bist du nicht auf die Idee gekommen das Log mal zu posten hier ??
Lösche es vorher wegen der Übersichtlichkeit und logge dann mal einen Abbruch mit.
> Wie gesagt pfSense und Lancom sprechen im Webinterface nicht unbedingt die gleiche Sprache
BMW und Mercedes haben auch andere Lenkräder und Motoren.... !
> das erschwert das Ganze.
Nein, nicht wenn man weiss WAS man macht !
Lass ich mal so stehen! Behaupte aber auch, das mir dieses Thema beim nächsten Mal schon leichter fällt. Für das "erste Mal" hat es mich jedenfalls hier und da irritiert.BMW und Mercedes haben auch andere Lenkräder und Motoren.... !
> das erschwert das Ganze.
Nein, nicht wenn man weiss WAS man macht !
> Lancom wird neben dem PSK auch noch ein Passwort für die Übermittlung der IP-Adresse der Gegenstelle erwartet, ich
muss eins angeben...
Eigentlich Unsinn, denn das erledigt IPsec von sich aus.
Gut zu wissen. Danke!muss eins angeben...
Eigentlich Unsinn, denn das erledigt IPsec von sich aus.
Vermutlich verwechselst du hier was, aber egal...
Beides steht wirklich im LANCOM Webinterface auf einer Seite und lässt sich nur speichern wenn ich dort auch 2 mal ein Passwort eingebe.Schande über mich! Danke Dir!
Melde mich wieder, wenn ich die Timer überprüft habe.
Moin,
ergänzend zu Kollege @aqui wäre noch zuprüfen, ob die Physik (Kupferleitung, APL, DSL-Port, etc...) sauber laufen.
Ich habe hier zwei DSL-Anschlüsse, die das normale Arbeiten aushalten. Sobald nur etwas mehr Last auf der Leitung ist, bricht diese zusammen und ist nicht mehr syncron.
Gruß,
Dani
ergänzend zu Kollege @aqui wäre noch zuprüfen, ob die Physik (Kupferleitung, APL, DSL-Port, etc...) sauber laufen.
Ich habe hier zwei DSL-Anschlüsse, die das normale Arbeiten aushalten. Sobald nur etwas mehr Last auf der Leitung ist, bricht diese zusammen und ist nicht mehr syncron.
Gruß,
Dani
Hallo, ich habe nun die Einstellungen abgeglichen und für mich sieht es so aus, als sei alles korrekt. Der Tunnel steht mitlerweile über 100 Minuten am Stück. Irgendwann der Abbruch für ca. 10 Minuten.
Während ich hier am posten bin, wird die Verbindung gerade wieder aufgebaut. Hier mal zwei Auszüge aus dem Log der pfSense. Geht hieraus was verdächtiges hervor?
Ich habe unsere IP Adresse durch my.ip.addr.ess hier im Log ersetzt.
Jun 16 11:04:44 charon: 15[IKE] <con1000|46> sending retransmit 1 of response message ID 0, seq 1
Jun 16 11:04:44 charon: 15[NET] <con1000|46> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:04:44 charon: 15[CFG] ignoring acquire, connection attempt pending
Jun 16 11:04:48 charon: 12[IKE] <con1000|44> sending retransmit 3 of request message ID 0, seq 1
Jun 16 11:04:48 charon: 12[IKE] <con1000|44> sending retransmit 3 of request message ID 0, seq 1
Jun 16 11:04:48 charon: 12[NET] <con1000|44> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (376 bytes)
Jun 16 11:04:49 charon: 12[IKE] <con1000|45> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:04:49 charon: 12[IKE] <con1000|45> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:04:49 charon: 12[NET] <con1000|45> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:04:51 charon: 12[IKE] <con1000|46> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:04:51 charon: 12[IKE] <con1000|46> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:04:51 charon: 12[NET] <con1000|46> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:04:55 charon: 12[JOB] <con1000|45> deleting half open IKE_SA after timeout
Jun 16 11:05:04 charon: 12[IKE] <con1000|46> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:04 charon: 12[IKE] <con1000|46> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:04 charon: 12[NET] <con1000|46> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:10 charon: 12[JOB] <con1000|46> deleting half open IKE_SA after timeout
Jun 16 11:05:11 charon: 12[NET] <47> received packet: from my.ip.addr.ess[500] to 192.168.2.20[500] (356 bytes)
Jun 16 11:05:11 charon: 12[ENC] <47> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V ]
Jun 16 11:05:11 charon: 12[ENC] <47> received unknown vendor ID: ee:ef:a3:78:09:e3:2a:d4:de:4f:6b:01:0c:26:a6:40
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received NAT-T (RFC 3947) vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received NAT-T (RFC 3947) vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received XAuth vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received XAuth vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received DPD vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received DPD vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> my.ip.addr.ess is initiating a Aggressive Mode IKE_SA
Jun 16 11:05:11 charon: 12[IKE] <47> my.ip.addr.ess is initiating a Aggressive Mode IKE_SA
Jun 16 11:05:11 charon: 12[CFG] <47> looking for pre-shared key peer configs matching 192.168.2.20...my.ip.addr.ess[my.ip.addr.ess]
Jun 16 11:05:11 charon: 12[CFG] <47> selected peer config "con1000"
Jun 16 11:05:11 charon: 12[ENC] <con1000|47> generating AGGRESSIVE response 0 [ SA KE No ID NAT-D NAT-D HASH V V V V ]
Jun 16 11:05:11 charon: 12[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:11 charon: 12[IKE] <con1000|44> sending retransmit 4 of request message ID 0, seq 1
Jun 16 11:05:11 charon: 12[IKE] <con1000|44> sending retransmit 4 of request message ID 0, seq 1
Jun 16 11:05:11 charon: 12[NET] <con1000|44> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (376 bytes)
Jun 16 11:05:15 charon: 12[IKE] <con1000|47> sending retransmit 1 of response message ID 0, seq 1
Jun 16 11:05:15 charon: 12[IKE] <con1000|47> sending retransmit 1 of response message ID 0, seq 1
Jun 16 11:05:15 charon: 12[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:22 charon: 12[IKE] <con1000|47> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:05:22 charon: 12[IKE] <con1000|47> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:05:22 charon: 12[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:29 charon: 13[KNL] creating acquire job for policy 192.168.2.20/32|/0 === my.ip.addr.ess/32|/0 with reqid {1}
Jun 16 11:05:29 charon: 15[CFG] ignoring acquire, connection attempt pending
Jun 16 11:05:35 charon: 15[IKE] <con1000|47> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:35 charon: 15[IKE] <con1000|47> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:35 charon: 15[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Kurz darauf ging es wieder
Jun 16 11:04:44 charon: 15[IKE] <con1000|46> sending retransmit 1 of response message ID 0, seq 1
Jun 16 11:04:44 charon: 15[NET] <con1000|46> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:04:44 charon: 15[CFG] ignoring acquire, connection attempt pending
Jun 16 11:04:48 charon: 12[IKE] <con1000|44> sending retransmit 3 of request message ID 0, seq 1
Jun 16 11:04:48 charon: 12[IKE] <con1000|44> sending retransmit 3 of request message ID 0, seq 1
Jun 16 11:04:48 charon: 12[NET] <con1000|44> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (376 bytes)
Jun 16 11:04:49 charon: 12[IKE] <con1000|45> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:04:49 charon: 12[IKE] <con1000|45> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:04:49 charon: 12[NET] <con1000|45> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:04:51 charon: 12[IKE] <con1000|46> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:04:51 charon: 12[IKE] <con1000|46> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:04:51 charon: 12[NET] <con1000|46> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:04:55 charon: 12[JOB] <con1000|45> deleting half open IKE_SA after timeout
Jun 16 11:05:04 charon: 12[IKE] <con1000|46> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:04 charon: 12[IKE] <con1000|46> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:04 charon: 12[NET] <con1000|46> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:10 charon: 12[JOB] <con1000|46> deleting half open IKE_SA after timeout
Jun 16 11:05:11 charon: 12[NET] <47> received packet: from my.ip.addr.ess[500] to 192.168.2.20[500] (356 bytes)
Jun 16 11:05:11 charon: 12[ENC] <47> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V ]
Jun 16 11:05:11 charon: 12[ENC] <47> received unknown vendor ID: ee:ef:a3:78:09:e3:2a:d4:de:4f:6b:01:0c:26:a6:40
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received NAT-T (RFC 3947) vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received NAT-T (RFC 3947) vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received XAuth vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received XAuth vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received DPD vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received DPD vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> my.ip.addr.ess is initiating a Aggressive Mode IKE_SA
Jun 16 11:05:11 charon: 12[IKE] <47> my.ip.addr.ess is initiating a Aggressive Mode IKE_SA
Jun 16 11:05:11 charon: 12[CFG] <47> looking for pre-shared key peer configs matching 192.168.2.20...my.ip.addr.ess[my.ip.addr.ess]
Jun 16 11:05:11 charon: 12[CFG] <47> selected peer config "con1000"
Jun 16 11:05:11 charon: 12[ENC] <con1000|47> generating AGGRESSIVE response 0 [ SA KE No ID NAT-D NAT-D HASH V V V V ]
Jun 16 11:05:11 charon: 12[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:11 charon: 12[IKE] <con1000|44> sending retransmit 4 of request message ID 0, seq 1
Jun 16 11:05:11 charon: 12[IKE] <con1000|44> sending retransmit 4 of request message ID 0, seq 1
Jun 16 11:05:11 charon: 12[NET] <con1000|44> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (376 bytes)
Jun 16 11:05:15 charon: 12[IKE] <con1000|47> sending retransmit 1 of response message ID 0, seq 1
Jun 16 11:05:15 charon: 12[IKE] <con1000|47> sending retransmit 1 of response message ID 0, seq 1
Jun 16 11:05:15 charon: 12[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:22 charon: 12[IKE] <con1000|47> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:05:22 charon: 12[IKE] <con1000|47> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:05:22 charon: 12[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:29 charon: 13[KNL] creating acquire job for policy 192.168.2.20/32|/0 === my.ip.addr.ess/32|/0 with reqid {1}
Jun 16 11:05:29 charon: 15[CFG] ignoring acquire, connection attempt pending
Jun 16 11:05:35 charon: 15[IKE] <con1000|47> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:35 charon: 15[IKE] <con1000|47> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:35 charon: 15[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Während ich hier am posten bin, wird die Verbindung gerade wieder aufgebaut. Hier mal zwei Auszüge aus dem Log der pfSense. Geht hieraus was verdächtiges hervor?
Ich habe unsere IP Adresse durch my.ip.addr.ess hier im Log ersetzt.
Jun 16 11:04:44 charon: 15[IKE] <con1000|46> sending retransmit 1 of response message ID 0, seq 1
Jun 16 11:04:44 charon: 15[NET] <con1000|46> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:04:44 charon: 15[CFG] ignoring acquire, connection attempt pending
Jun 16 11:04:48 charon: 12[IKE] <con1000|44> sending retransmit 3 of request message ID 0, seq 1
Jun 16 11:04:48 charon: 12[IKE] <con1000|44> sending retransmit 3 of request message ID 0, seq 1
Jun 16 11:04:48 charon: 12[NET] <con1000|44> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (376 bytes)
Jun 16 11:04:49 charon: 12[IKE] <con1000|45> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:04:49 charon: 12[IKE] <con1000|45> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:04:49 charon: 12[NET] <con1000|45> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:04:51 charon: 12[IKE] <con1000|46> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:04:51 charon: 12[IKE] <con1000|46> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:04:51 charon: 12[NET] <con1000|46> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:04:55 charon: 12[JOB] <con1000|45> deleting half open IKE_SA after timeout
Jun 16 11:05:04 charon: 12[IKE] <con1000|46> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:04 charon: 12[IKE] <con1000|46> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:04 charon: 12[NET] <con1000|46> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:10 charon: 12[JOB] <con1000|46> deleting half open IKE_SA after timeout
Jun 16 11:05:11 charon: 12[NET] <47> received packet: from my.ip.addr.ess[500] to 192.168.2.20[500] (356 bytes)
Jun 16 11:05:11 charon: 12[ENC] <47> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V ]
Jun 16 11:05:11 charon: 12[ENC] <47> received unknown vendor ID: ee:ef:a3:78:09:e3:2a:d4:de:4f:6b:01:0c:26:a6:40
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received NAT-T (RFC 3947) vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received NAT-T (RFC 3947) vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received XAuth vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received XAuth vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received DPD vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received DPD vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> my.ip.addr.ess is initiating a Aggressive Mode IKE_SA
Jun 16 11:05:11 charon: 12[IKE] <47> my.ip.addr.ess is initiating a Aggressive Mode IKE_SA
Jun 16 11:05:11 charon: 12[CFG] <47> looking for pre-shared key peer configs matching 192.168.2.20...my.ip.addr.ess[my.ip.addr.ess]
Jun 16 11:05:11 charon: 12[CFG] <47> selected peer config "con1000"
Jun 16 11:05:11 charon: 12[ENC] <con1000|47> generating AGGRESSIVE response 0 [ SA KE No ID NAT-D NAT-D HASH V V V V ]
Jun 16 11:05:11 charon: 12[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:11 charon: 12[IKE] <con1000|44> sending retransmit 4 of request message ID 0, seq 1
Jun 16 11:05:11 charon: 12[IKE] <con1000|44> sending retransmit 4 of request message ID 0, seq 1
Jun 16 11:05:11 charon: 12[NET] <con1000|44> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (376 bytes)
Jun 16 11:05:15 charon: 12[IKE] <con1000|47> sending retransmit 1 of response message ID 0, seq 1
Jun 16 11:05:15 charon: 12[IKE] <con1000|47> sending retransmit 1 of response message ID 0, seq 1
Jun 16 11:05:15 charon: 12[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:22 charon: 12[IKE] <con1000|47> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:05:22 charon: 12[IKE] <con1000|47> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:05:22 charon: 12[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:29 charon: 13[KNL] creating acquire job for policy 192.168.2.20/32|/0 === my.ip.addr.ess/32|/0 with reqid {1}
Jun 16 11:05:29 charon: 15[CFG] ignoring acquire, connection attempt pending
Jun 16 11:05:35 charon: 15[IKE] <con1000|47> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:35 charon: 15[IKE] <con1000|47> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:35 charon: 15[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Kurz darauf ging es wieder
Jun 16 11:04:44 charon: 15[IKE] <con1000|46> sending retransmit 1 of response message ID 0, seq 1
Jun 16 11:04:44 charon: 15[NET] <con1000|46> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:04:44 charon: 15[CFG] ignoring acquire, connection attempt pending
Jun 16 11:04:48 charon: 12[IKE] <con1000|44> sending retransmit 3 of request message ID 0, seq 1
Jun 16 11:04:48 charon: 12[IKE] <con1000|44> sending retransmit 3 of request message ID 0, seq 1
Jun 16 11:04:48 charon: 12[NET] <con1000|44> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (376 bytes)
Jun 16 11:04:49 charon: 12[IKE] <con1000|45> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:04:49 charon: 12[IKE] <con1000|45> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:04:49 charon: 12[NET] <con1000|45> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:04:51 charon: 12[IKE] <con1000|46> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:04:51 charon: 12[IKE] <con1000|46> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:04:51 charon: 12[NET] <con1000|46> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:04:55 charon: 12[JOB] <con1000|45> deleting half open IKE_SA after timeout
Jun 16 11:05:04 charon: 12[IKE] <con1000|46> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:04 charon: 12[IKE] <con1000|46> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:04 charon: 12[NET] <con1000|46> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:10 charon: 12[JOB] <con1000|46> deleting half open IKE_SA after timeout
Jun 16 11:05:11 charon: 12[NET] <47> received packet: from my.ip.addr.ess[500] to 192.168.2.20[500] (356 bytes)
Jun 16 11:05:11 charon: 12[ENC] <47> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V ]
Jun 16 11:05:11 charon: 12[ENC] <47> received unknown vendor ID: ee:ef:a3:78:09:e3:2a:d4:de:4f:6b:01:0c:26:a6:40
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received NAT-T (RFC 3947) vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received NAT-T (RFC 3947) vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received XAuth vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received XAuth vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received DPD vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> received DPD vendor ID
Jun 16 11:05:11 charon: 12[IKE] <47> my.ip.addr.ess is initiating a Aggressive Mode IKE_SA
Jun 16 11:05:11 charon: 12[IKE] <47> my.ip.addr.ess is initiating a Aggressive Mode IKE_SA
Jun 16 11:05:11 charon: 12[CFG] <47> looking for pre-shared key peer configs matching 192.168.2.20...my.ip.addr.ess[my.ip.addr.ess]
Jun 16 11:05:11 charon: 12[CFG] <47> selected peer config "con1000"
Jun 16 11:05:11 charon: 12[ENC] <con1000|47> generating AGGRESSIVE response 0 [ SA KE No ID NAT-D NAT-D HASH V V V V ]
Jun 16 11:05:11 charon: 12[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:11 charon: 12[IKE] <con1000|44> sending retransmit 4 of request message ID 0, seq 1
Jun 16 11:05:11 charon: 12[IKE] <con1000|44> sending retransmit 4 of request message ID 0, seq 1
Jun 16 11:05:11 charon: 12[NET] <con1000|44> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (376 bytes)
Jun 16 11:05:15 charon: 12[IKE] <con1000|47> sending retransmit 1 of response message ID 0, seq 1
Jun 16 11:05:15 charon: 12[IKE] <con1000|47> sending retransmit 1 of response message ID 0, seq 1
Jun 16 11:05:15 charon: 12[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:22 charon: 12[IKE] <con1000|47> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:05:22 charon: 12[IKE] <con1000|47> sending retransmit 2 of response message ID 0, seq 1
Jun 16 11:05:22 charon: 12[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
Jun 16 11:05:29 charon: 13[KNL] creating acquire job for policy 192.168.2.20/32|/0 === my.ip.addr.ess/32|/0 with reqid {1}
Jun 16 11:05:29 charon: 15[CFG] ignoring acquire, connection attempt pending
Jun 16 11:05:35 charon: 15[IKE] <con1000|47> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:35 charon: 15[IKE] <con1000|47> sending retransmit 3 of response message ID 0, seq 1
Jun 16 11:05:35 charon: 15[NET] <con1000|47> sending packet: from 192.168.2.20[500] to my.ip.addr.ess[500] (404 bytes)
@Dani
Danke für den Hinweis, aber ich vermute, dass es an etwas anderem liegt, denn wenn der Tunnel steht, dann kann ich ihn richtig belasten, mit reichlich Traffic, ohne das er zusammenbricht. Bin hier ja noch in einer Art Testumgebung und die Verbindung wird ansonsten nicht beansprucht, wenn nich zwischendurch mal einen PING absetze, sehe ich, dass der Tunnel irgendwann nicht mehr steht.
Danke für den Hinweis, aber ich vermute, dass es an etwas anderem liegt, denn wenn der Tunnel steht, dann kann ich ihn richtig belasten, mit reichlich Traffic, ohne das er zusammenbricht. Bin hier ja noch in einer Art Testumgebung und die Verbindung wird ansonsten nicht beansprucht, wenn nich zwischendurch mal einen PING absetze, sehe ich, dass der Tunnel irgendwann nicht mehr steht.
Die Retransmits sind etwas kritisch... Hier antwortet die Gegenstelle schlicht und einfach nicht und die pfSense versucht es immer wieder.
Irgendwann gibt sie in der Session mit "deleting half open IKE_SA after timeout" auf weil die Gegenstelle nicht antwortet.
Danach startet sie dann wie sie soll wieder eine IKE Phase 1 und irgendwan antwortet dann die Gegenstelle wieder und es geht weiter.
Der Verdacht liegt also ziemlich nahe das die Gegenstelle der Buhmann ist !
Irgendwann gibt sie in der Session mit "deleting half open IKE_SA after timeout" auf weil die Gegenstelle nicht antwortet.
Danach startet sie dann wie sie soll wieder eine IKE Phase 1 und irgendwan antwortet dann die Gegenstelle wieder und es geht weiter.
Der Verdacht liegt also ziemlich nahe das die Gegenstelle der Buhmann ist !
Gelöst?
Interessanter Fehler, da offenbar neuere PfSense mit StrongSwan.
Wenn nicht: Versuche mal alternative Einstellungen in der Phase 1. (Was ist da bei "Identifier" gesetzt?)
In der alten (2.1) PfSense gab es unter advanced Settings eine Einstellung für "Prefer older SA's" Sollte default nicht aktiviert sein, kann aber helfen, wenn die Gegenseite wg. Timings im Zweifel die älteren bevorzugt.
Warum versucht die Lancom nicht, die Verbindung aufzubauen? Tut sie das? Ich werde aus den Logs nicht ganz schlau. ("Sending Packet from 192.xxx.xxx.xxx" müsste doch "receiving Packet" sein?)
Alternativ kann ich dir Hilfe anbieten, die 2.1er einzurichten mit dem ollen racoon, der mir etwas vertrauter ist, aber das ist ja nicht Sinn der Sache...
Also: Bitte Erfolgsmeldung.
Buc
Interessanter Fehler, da offenbar neuere PfSense mit StrongSwan.
Wenn nicht: Versuche mal alternative Einstellungen in der Phase 1. (Was ist da bei "Identifier" gesetzt?)
In der alten (2.1) PfSense gab es unter advanced Settings eine Einstellung für "Prefer older SA's" Sollte default nicht aktiviert sein, kann aber helfen, wenn die Gegenseite wg. Timings im Zweifel die älteren bevorzugt.
Warum versucht die Lancom nicht, die Verbindung aufzubauen? Tut sie das? Ich werde aus den Logs nicht ganz schlau. ("Sending Packet from 192.xxx.xxx.xxx" müsste doch "receiving Packet" sein?)
Alternativ kann ich dir Hilfe anbieten, die 2.1er einzurichten mit dem ollen racoon, der mir etwas vertrauter ist, aber das ist ja nicht Sinn der Sache...
Also: Bitte Erfolgsmeldung.
Buc
Hallo Leute,
entschuldigt bitte meine hohe Latenz was das Antworten auf meinen eigenen Thread angeht.
Bin halt nur nebenbei der Admin in unserem Kinderglücklichheim und da war in den letzten Monaten lediglich Zeit sich um die Backups zu kümmern.
Es lag tatsächlich an den eingestellten Timings. Habe das ganze angepasst und seit knapp 3 Wochen läuft alles problemlos und zur vollster Zufriedenheit im Echtbetrieb.
Herzlichen Dank an alle!
Viele Grüße
Danycode
entschuldigt bitte meine hohe Latenz was das Antworten auf meinen eigenen Thread angeht.
Bin halt nur nebenbei der Admin in unserem Kinderglücklichheim und da war in den letzten Monaten lediglich Zeit sich um die Backups zu kümmern.
Es lag tatsächlich an den eingestellten Timings. Habe das ganze angepasst und seit knapp 3 Wochen läuft alles problemlos und zur vollster Zufriedenheit im Echtbetrieb.
Herzlichen Dank an alle!
Viele Grüße
Danycode
