Hallo, zusammen,
ich habe mal wieder ein ominöses Problem :shock: :
Nach dem wir das hier beschrieben Problem ja recht einfach in den Griff bekommen haben, kam vor einiger Zeit foldende Situation auf:
Unser Supporter konnte "plötzlich" nicht mehr auf unser Netzwerk zugreifen, ein Kooperationspartner, der ebenfalls mit einem so aufgebauten IPSec-Tunnel (IPSec/IKE1/PSK/DeadPeerDetection an) zur Verfügung gestellt bekam hatte ab dem selben Zeitpunkt keinen Zugriff mehr. Vor besagtem Zeitpunk gab es keinerlei Probleme!
Das Problem ließ sich durch eine Teststellung nachvollziehen und konnt wie folgt eingegrenzt werden:
Wenn in einem erfolgreich aufgebauten IPSec-Tunnel eine gewisse Zeit keine Daten mehr von internen Netz ins peer-Netz gegangen sind, bricht die Verbindung einseitig, also vom peer aus, ein, der Tunnel selber ist aber noch aktiv! Von internen System aus kommt man jederzeit(!) in das peer-Netz.
Fließt jetzt irgendein Datenstrom/-paket von irgendeinem Host des internen Netzes zu irgendeinem Host des peer-Netzes ist die Verbindung des peer-Netzes zum internen Netz sofort wieder hergestellt, als ob nichts geschehen wäre!
Unterbleibt ein weiterer Datenstrom von Innen bricht der Tunnel wieder wie beschrieben ein.
Kennt jemand das Problem?
Wir fahren zur Zeit die 10.6.4, die ich gestern von der 10.6.3 upgedatet habe (leider ohne Erfolg bei meienm Problem).
Es scheint so, als ob das Problem nach dem Update von 10.6.2 auf 10.6.3 gekommen zu sein, leider können wir das erste Auftauchen nicht mehr genau festmachen.
viele Grüße aus FFM,
E.Kelm
IPSec Site-to-Site bricht einseitig nach einer gewissen Zeit ab
Moderator: Securepoint
IPSec Site-to-Site bricht einseitig nach einer gewissen Zeit ab
Zuletzt geändert von rkkh-ffm am Di 05.02.2013, 13:25, insgesamt 1-mal geändert.
Understanding is a three edged sword.
Meines Wissens nach nicht.
Die Gateway-IPs der Peer-Systeme lassen auf eine direkten Internetanbindung schließen.
Unsere Maschine ist mit einem CompanyConncet-Anschluss der T-Com verbunden.
Dieser hat eine Abschluss-Router, der unser Default-Gateway ist. Diese Konstellation haben wir jetzt schon ca. 1 Jahr, also schon vor auftreten des Fehlers... :?
Witzigerweise kommen die ESP-Pakete ja an der Securepoint an (tcpdump geprüft).
Nur: warum hatte es schon mal funktioniert?
Die Teststellung war übrigens ein Border-Router auf Linuxbasis (Kernel 2.6.32.45) mit StrongSwan (V. 4.6.4) mit direktem Anschluss an einem Kabelnetzmodem.
Der Router hat auf der "Außenseite" eine öffntliche IP des Kabelnetzproviders.
Die Gateway-IPs der Peer-Systeme lassen auf eine direkten Internetanbindung schließen.
Unsere Maschine ist mit einem CompanyConncet-Anschluss der T-Com verbunden.
Dieser hat eine Abschluss-Router, der unser Default-Gateway ist. Diese Konstellation haben wir jetzt schon ca. 1 Jahr, also schon vor auftreten des Fehlers... :?
Witzigerweise kommen die ESP-Pakete ja an der Securepoint an (tcpdump geprüft).
Nur: warum hatte es schon mal funktioniert?
Die Teststellung war übrigens ein Border-Router auf Linuxbasis (Kernel 2.6.32.45) mit StrongSwan (V. 4.6.4) mit direktem Anschluss an einem Kabelnetzmodem.
Der Router hat auf der "Außenseite" eine öffntliche IP des Kabelnetzproviders.
Understanding is a three edged sword.
Ja da sind in der Tat einige verworfene ESP-Pakete, vorgestern (zwischen 6:00 und 6:00) allerdings nur 14, gestern 1, heute (bis 22:00 GMT+1) insges. 37 Stück von den 2 regulären Peers und dem Test-Peer.
Anmerkung: Ich habe heute ab ca 10:00 Uhr einen Workaround in Form eines Dauerpings auf die jeweiligen Zielsysteme eingerichtet. Nichts desto Trotz möchte ich das Problem aber greifen können :-)
Anmerkung: Ich habe heute ab ca 10:00 Uhr einen Workaround in Form eines Dauerpings auf die jeweiligen Zielsysteme eingerichtet. Nichts desto Trotz möchte ich das Problem aber greifen können :-)
Zuletzt geändert von rkkh-ffm am Di 05.02.2013, 23:07, insgesamt 1-mal geändert.
Understanding is a three edged sword.
Ich habe mir die DROPs mal genauer angesehen und heute noch einen Test gemacht:
Die Gegenstelle verliert nach spätestens 875s (eher weniger, genauer konnte ich nicht testen :? ) die Verbindung , ein DROP ist aber in der Zeit nicht zu verzeichnen!
Habt Ihr noch eine Idee? :shock:
Die Gegenstelle verliert nach spätestens 875s (eher weniger, genauer konnte ich nicht testen :? ) die Verbindung , ein DROP ist aber in der Zeit nicht zu verzeichnen!
Habt Ihr noch eine Idee? :shock:
Understanding is a three edged sword.
Und Sie sagen, dass die Dead Peer Detection auf beiden Seiten aktiviert ist? So wie Sie das Verhalten beschreiben, scheinen da zumindest die Keep-Alive-Pakete unterwegs zu verschwinden - wodurch dann nach einer Weile ohne Traffic die Verbindung als "tot" deklariert wird.
Und zwar nicht unbedingt vom IPSec-Server, sondern vom Paketfilter. Deswegen funktioniert es dann auch, wenn Sie einen Dauerping durch den Tunnel setzen.
Und zwar nicht unbedingt vom IPSec-Server, sondern vom Paketfilter. Deswegen funktioniert es dann auch, wenn Sie einen Dauerping durch den Tunnel setzen.
Zumindes bei dem Test-Tunnel habe ich die DeadPeerDetection ausdrücklich gesetzt und geprüft. Auch habe ich bei den Tests sowohl die DPD als auch die Parameter PFS und Strict auf beide Systemen, jeweils korrespndierend, gesetzt und abgeschaltet. Jeweils mit dem Ergebnis, dass die Verbindung nach ein paar Minuten... 
naja...
Kennen Sie eine Möglichkeit, das Vorhandensein der Keepalivepakete zu nachweisen zu können?
Die ISAKMP-Pakete gehen auf beiden Systemen auf den externen Nics sauber alle 10 Sekunden ein und aus, ungeachtet des Eingangs vom peer-Netz.
Auf der Securepoint habe ich die iptables-Tabellen mal quergelesen: da wird alles erlaubt, was unter die Verbindung IPSec gehört, ob das jetzt so definiert war oder nicht:
iptables -S sagt u.a.:
und später
Viel mehr ist da nicht zu sehen, was das IPSec betrifft.
Soweit für den Moment...
naja...Kennen Sie eine Möglichkeit, das Vorhandensein der Keepalivepakete zu nachweisen zu können?
Die ISAKMP-Pakete gehen auf beiden Systemen auf den externen Nics sauber alle 10 Sekunden ein und aus, ungeachtet des Eingangs vom peer-Netz.
Auf der Securepoint habe ich die iptables-Tabellen mal quergelesen: da wird alles erlaubt, was unter die Verbindung IPSec gehört, ob das jetzt so definiert war oder nicht:
iptables -S sagt u.a.:
Code: Alles auswählen
-A FORWARD -s <fernesnetz> -d <lokalesnetz> -i eth0 -m policy --dir in --pol ipsec --reqid <reqid> --proto esp -j STRONGSWAN_ACCEPT
-A FORWARD -s <lokalesnetz> -d <fernesnetz> -i eth0 -m policy --dir out --pol ipsec --reqid <reqid> --proto esp -j STRONGSWAN_ACCEPTCode: Alles auswählen
-A STRONGSWAN_ACCEPT -j ACCEPT
Soweit für den Moment...
Understanding is a three edged sword.
Wenn man nur weit genug in die Tiefe geht...
Ich habe mal den Datenverkehr eine Zeit lang mit TCP-Dump mitgeschnitten und folgende Auffälligkeit gefunden.
Bei einem ISAKMP Identity Protection Paket(?) werden scheinbar fehlerhafte Daten an den Peer versendet.
Der Mitschnitt mit Wireshark betrachtet förtert folgendes zu Tage:
(Die graphische Aufbereitung der Daten im Wireshark geben ich mal per ASCII-Art wieder)
Ich bin nicht der große Protokollkenner, aber diese vorletzte Zeile sieht in meinen AUgen fehlerhaft aus, ich wirde da ein erwarten...
Der weiter Identity-Protection-Handshake verläuft scheinbar glatt, aber ab diesem Zeitpunkt ist der Datenverkehr vom Peer zur Securepoint unterbrochen!
( Wenn das kein Hinweis ist
)
Ich habe mal den Datenverkehr eine Zeit lang mit TCP-Dump mitgeschnitten und folgende Auffälligkeit gefunden.
Bei einem ISAKMP Identity Protection Paket(?) werden scheinbar fehlerhafte Daten an den Peer versendet.
Der Mitschnitt mit Wireshark betrachtet förtert folgendes zu Tage:
(Die graphische Aufbereitung der Daten im Wireshark geben ich mal per ASCII-Art wieder)
Code: Alles auswählen
+ User Datagram Protocol, Src Port: 500 (500), Dst Port: 500 (500)
-Internet Security Association and Key Management Protocol
Initiator cookie: 123456789ABCDEF
Responder cookie: 0000000000000000
Next Payload: Security Association (1)
Version: 1.0
Exchange type: Identity Protection (Main Mode) (2)
+Flags: 0X00
Message ID: 0X00000000
Length: 236
+TypePayload: Security Association (1)
+Type Payload: Vendor ID (13) : strongSwan
+Type Payload: Vendor ID (13) : XAUTH
+Type Payload: Vendor ID (13) : RFC 3706 DPD (Dead Peer Detection)
+Type Payload: Vendor ID (13) : RFC 3947 Negotiation of NAT-Traversal in IKE
+Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-03
+Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-02
+Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-02\\n
+Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-00
Code: Alles auswählen
+Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-02\\nCode: Alles auswählen
+Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-01Der weiter Identity-Protection-Handshake verläuft scheinbar glatt, aber ab diesem Zeitpunkt ist der Datenverkehr vom Peer zur Securepoint unterbrochen!
( Wenn das kein Hinweis ist
)Understanding is a three edged sword.
Die Daten in dem Paket sind erstmal ok. Dort findet nur die Aushandlung des NAT-T statt. Und dabei kann die selbe Version auch mehrfach auftauchen (3.2).
Was interessant ist, ist die Formulierung dafür in dem Draft: "in case of
multiple interfaces, and implementation don't know which is used to
route the packet out".
Stellen Sie in den Phase1-Einstellungen doch bitte mal ein festes Routing für die Pakete ein. Das sind die Felder "Lokales Gateway", "Lokale Gateway-ID" und "Route über". Bei den beiden ersteren wählen Sie das externe Interface aus, bei letzterem den Router vor diesem Interface.
Was interessant ist, ist die Formulierung dafür in dem Draft: "in case of
multiple interfaces, and implementation don't know which is used to
route the packet out".
Stellen Sie in den Phase1-Einstellungen doch bitte mal ein festes Routing für die Pakete ein. Das sind die Felder "Lokales Gateway", "Lokale Gateway-ID" und "Route über". Bei den beiden ersteren wählen Sie das externe Interface aus, bei letzterem den Router vor diesem Interface.
Mit Router meinen Sie wahrscheinlich das Default-Gateway der Securepoint im Internet, oder?
Der Test ist allerdings wieder so verlaufen wie bisher: Kein connect mehr vom peer-Netzwerk nach 600s... :roll:
Der Test ist allerdings wieder so verlaufen wie bisher: Kein connect mehr vom peer-Netzwerk nach 600s... :roll:
Understanding is a three edged sword.