IPSec-Verbindungsabbrüche

[RoyalKnight]

Meine IPSec-Verbindungen werden hin und wieder terminiert. Im Syslog des LANCOM finde ich dann folgende Einträge:

Code: Alles auswählen

27	02.02.2014 11:39:04	LOCAL3	Alarm	last message repeated 1 time
28	02.02.2014 11:38:03	LOCAL3	Alarm	Dst: $routerip:54746 {$routername}, Src: $remoteip:4500 (UDP): connection refused
29	02.02.2014 11:37:00	LOCAL3	Alarm	Dst: xxx:123, Src: yyy:1029 {switchee1542} (UDP): connection refused
30	02.02.2014 11:35:59	LOCAL3	Alarm	Dst: $routerip:54746 {$routername}, Src: $remoteip:4500 (UDP): connection refused
31	02.02.2014 11:34:58	LOCAL3	Alarm	Dst: $remoteip:4500, Src: $localip:4500 {$localname} (UDP): connection refused

Es sieht also so aus, dass ein ausgehendes Paket UDP/4500 verworfen wird, obwohl auf der Firewall erlaubt (sonst wäre gar kein Verbindungsaufbau möglich).

Am Client stehen folgende Meldungen im Log:

Code: Alles auswählen

02.02.14 11:31:22,245 racoon[330]: IPSec Phase 2 started (Initiated by me).
02.02.14 11:31:22,254 racoon[330]: >>>>> phase change status = Phase 2 started
02.02.14 11:31:22,263 racoon[330]: IKE Packet: transmit success. (Initiator, Quick-Mode message 1).
02.02.14 11:31:22,306 racoon[330]: attribute has been modified.
02.02.14 11:31:22,307 racoon[330]: IKE Packet: receive success. (Initiator, Quick-Mode message 2).
02.02.14 11:31:22,307 racoon[330]: IKE Packet: transmit success. (Initiator, Quick-Mode message 3).
02.02.14 11:31:22,308 racoon[330]: IKEv1 Phase 2 Initiator: success. (Initiator, Quick-Mode).
02.02.14 11:31:22,308 racoon[330]: IPSec Phase 2 established (Initiated by me).
02.02.14 11:31:22,308 racoon[330]: >>>>> phase change status = Phase 2 established
02.02.14 11:31:22,371 racoon[330]: IKE Packet: receive success. (Information message).
02.02.14 11:35:14,846 racoon[330]: IKE Packet: transmit success. (Information message).
02.02.14 11:35:14,846 racoon[330]: IKEv1 Information-Notice: transmit success. (R-U-THERE?).
02.02.14 11:35:14,846 racoon[330]: IKEv1 Dead-Peer-Detection: request transmitted. (Initiator DPD Request).
02.02.14 11:35:20,339 racoon[330]: IKE Packet: transmit success. (Information message).
02.02.14 11:35:20,339 racoon[330]: IKEv1 Information-Notice: transmit success. (R-U-THERE?).
02.02.14 11:35:20,340 racoon[330]: IKEv1 Dead-Peer-Detection: request retransmitted. (Initiator DPD Request).
02.02.14 11:35:25,798 racoon[330]: IKE Packet: transmit success. (Information message).
02.02.14 11:35:25,798 racoon[330]: IKEv1 Information-Notice: transmit success. (R-U-THERE?).
02.02.14 11:35:25,799 racoon[330]: IKEv1 Dead-Peer-Detection: request retransmitted. (Initiator DPD Request).
02.02.14 11:35:30,799 racoon[330]: IKE Packet: transmit success. (Information message).
02.02.14 11:35:30,799 racoon[330]: IKEv1 Information-Notice: transmit success. (R-U-THERE?).
02.02.14 11:35:30,800 racoon[330]: IKEv1 Dead-Peer-Detection: request retransmitted. (Initiator DPD Request).
02.02.14 11:35:36,285 racoon[330]: IKE Packet: transmit success. (Information message).
02.02.14 11:35:36,285 racoon[330]: IKEv1 Information-Notice: transmit success. (R-U-THERE?).
02.02.14 11:35:36,285 racoon[330]: IKEv1 Dead-Peer-Detection: request retransmitted. (Initiator DPD Request).
02.02.14 11:35:41,781 racoon[330]: IKEv1 Dead-Peer-Detection: maximum retransmits. (DPD maximum retransmits).
02.02.14 11:35:41,783 configd[19]: IPSec Controller: IKE FAILED. phase 6, assert 0
02.02.14 11:35:41,789 configd[19]: IPSec disconnecting from server $remoteip
02.02.14 11:35:41,789 racoon[330]: IPSec disconnecting from server $remoteip
02.02.14 11:35:41,790 racoon[330]: IKE Packet: transmit failed. (Information message).
02.02.14 11:35:41,790 racoon[330]: IKEv1 Information-Notice: transmit failed. (Delete IPSEC-SA).

Ein erneuter Verbindungsaufbau ist erst wieder nach etwa einer Minute möglich (mal früher, mal später).

In den Firewall-Ereignissen des LANmonitor finde ich allerdings keinen Eintrag, daher ist mir auch der Grund nicht klar, weshalb dies passiert.
An welcher Einstellung könnte ich drehen, damit das Problem nicht mehr auftritt bzw. wie könnte ich das debuggen?

[backslash]

Hi RoyalKnight,

für mich sieht das so aus, als ob der VPN-Tunnel nicht auf dem LANCOM endet, sondern auf einem eigenen VPN-Server in deinem LAN. In diesem Fall solltest du tunlichst die UDP-Ports 500 und 4500 weiterleiten, denn selbst, wenn der Verbindungsaufbau von innen nach aussen noch funktioniert, wirft die Firewall und das NAT die UDP-Session nach Ablauf des UDP-Timeouts (Default 20 Sekunden) weg, wenn keinen Daten übertragen werden, so daß ein einkommende DPD-Poll-Paket mangels zuordbarer Session abgelehnt wird.

Oder aber du schaltest NAT-T auf dem VPN-Server ab, dann versucht sich das NAT des LANCOMs in Kaffeesatzlesen und Kristallkugelschauen und hält die VPN-Session nach... (dazu muß aber auch der Client hinter einem Router stehen, der IKE NATten kann)

Gruß
Backslash

[RoyalKnight]

für mich sieht das so aus, als ob der VPN-Tunnel nicht auf dem LANCOM endet, sondern auf einem eigenen VPN-Server in deinem LAN. In diesem Fall solltest du tunlichst die UDP-Ports 500 und 4500 weiterleiten[...]

Ich hätte die Netzwerktopologie schematisch darstellen sollen - es geht in die andere Richtung - der VPN-Server (ASA) ist extern.
Ich verbinde mich also mit meinem Client (Log) über den LANCOM-Router (Log) zu einer ASA:
Client (Log) <=> LANCOM (Log) <=> Internet <=> ASA

Auf die ASA-Logs habe ich leider keinen Zugriff, schließe hier aber ein Fehlverhalten aus, da mit mobiler Datenverbindung (ohne LANCOM) die Verbindung stundenlang hält.
Mit UDP-Timeouts, DoS- und IDS-Parametern habe ich mich schon gespielt, brachte aber keine merkbare Verbesserung.

[backslash]

Hi RoyalKnight,

diese Ausgaben hier:

Code: Alles auswählen

27   02.02.2014 11:39:04   LOCAL3   Alarm   last message repeated 1 time
28   02.02.2014 11:38:03   LOCAL3   Alarm   Dst: $routerip:54746 {$routername}, Src: $remoteip:4500 (UDP): connection refused
29   02.02.2014 11:37:00   LOCAL3   Alarm   Dst: xxx:123, Src: yyy:1029 {switchee1542} (UDP): connection refused
30   02.02.2014 11:35:59   LOCAL3   Alarm   Dst: $routerip:54746 {$routername}, Src: $remoteip:4500 (UDP): connection refused
31   02.02.2014 11:34:58   LOCAL3   Alarm   Dst: $remoteip:4500, Src: $localip:4500 {$localname} (UDP): connection refused

zeigen eindeutig, daß die Session aus dem NAT herausgealtert ist. Dir bleibt also nichts anderes übrig, als im Client den Timeout für DPD herabzusetzen (sinnvoll sind z.B. 30 Sekunen, die von deinem Client offenbar verwendeten 4 Minuten erscheinen mir doch recht lange) *und* den UDP-Timeout im LANCOM entsprechend hochzusetzen (der default von 20 Sekunden ist auch für ein DPD-Intervall von 30 Sekunden zu kurz).

Wenn du den DPD-Timeout im Client nicht herabsetzen kannst, dann mußt du wohl oder übel den UDP-Timeout richtig hochsetzen, was dann aber dazu führen kann, daß die Maskierungstabelle volläuft - insbesondere wenn du irgendwelche Onlinespiele spielst, die ständig tausende Server anfragen...

Gruß
Backslash

[RoyalKnight]

Wenn du den DPD-Timeout im Client nicht herabsetzen kannst, dann mußt du wohl oder übel den UDP-Timeout richtig hochsetzen, was dann aber dazu führen kann, daß die Maskierungstabelle volläuft - insbesondere wenn du irgendwelche Onlinespiele spielst, die ständig tausende Server anfragen...

Danke für deine hilfreiche Antwort. Den Timeout beim Built-In Mac-Client kann ich vermutlich nicht hochsetzen, d.h. ich werde den Timeout am LANCOM hochsetzen müssen. Mal sehen was passiert...