IPsec-Fehlermeldungen erklärt - Teil 2
Veröffentlicht am 18 Dec 2005 um 10:45 pm.
Keine Kommentare.
Gespeichert unter Tutorials, Tips & Tricks.
23:58:40 "abc" #1: initiating Main Mode
23:58:40 "abc" #1: STATE_MAIN_I1: initiate
23:58:40 "abc" #1: STATE_MAIN_I1: retransmission; will wait 20s for response
23:59:00 "abc" #1: STATE_MAIN_I1: retransmission; will wait 40s for response
23:59:20 "abc" #1: max number of retransmissions (2) reached STATE_MAIN_I1.
23:59:20 No acceptable response to our first IKE message
Was hier passiert, ist ein Verbindungsversuch, bei dem die andere Seite den Versuch abblockt, oder gar nicht erst zu sehen bekommt. Das kann verschiedene Ursachen haben.
Das Naheliegendste ist es, zuerst mit Ping die Erreichbarkeit des Partners zu testen, um Routingprobleme auszuschliessen. Am Besten verbindet man mit SSH auf den ersten IPCop und macht dann ein Ping auf RED des anderen IPCop. Der Test sollte unbedingt auch vom anderen IPCop aus durchgeführt werden, um sicherzustellen, dass das Routing auch von der Gegenseite aus funktioniert. Mittels Ping auf den DNS-Namen kann dann ebenfalls auf beiden IPCop’s die Namensauflösung getestet werden.
Der nächste Test hat zum Ziel, festzustellen, ob der zweite IPCop die Verbindungsanfrage überhaupt zu sehen bekommt. Mit tcpdump –i ppp0 kann der gesamte Datenverkehr (In und Out) beobachtet werden, wobei angenommen wird, dass RED ppp0 ist. Dies sollte vorgängig in der Web-GUI unter “Status” -> “Netzwerk-Status” überprüft werden und das Kommando falls nötig auf das richtige Interface angepasst werden.
Für den Fall, dass zu viel Verkehr mitgeloggt wird, kann die Anzeige auch gefiltert werden. Die Eingabe folgenden Kommandos tcpdump host w.x.y.z zeigt nur Pakete vom und zum Host w.x.y.z an. Da IKE UDP-Port 500 verwendet, kann der Filter mit tcpdump host w.x.y.z and udp port 500 noch weiter verfeinert werden.
Wärend das SSH-Fenster des Remote-IPCop geöffnet ist, sollte nun das VPN mit Hilfe dieses Buttons 
neu gestartet werden. Es müssten dann sofort Pakete auf der anderen Firewall im Log (tcpdump Konsole) erscheinen. Tut sich nichts, werden die IKE-Anfragen offensichtlich geblockt.
Nun heisst es herauszufinden, wo die Pakete hängenbleiben.
Ein iptables -L -n -v auf dem Remote-IPCop (nicht dem, auf dem der Fehler geloggt wird) zeigt, ob die UDP-Ports 500 und 4500 geöffnet sind. Wenn diese Ports nicht geöffnet sind, ist vermutlich das Häkchen bei “Aktivieren” auf der VPN Konfigurationsseite für das entsprechende Interface (RED, oder BLUE) nicht gesetzt. Das sollte dann unverzüglich nachgeholt werden. Wenn die Ports 500 und 4500 erlaubt sind, kann in seltenen Fällen (unbewusste Fehlkonfiguration, etc.) auch Port 500 UDP explizit gedroppt werden. In so einem Fall müsste sich eine Regel nach dem Schema
DROP upd — anywhere w.x.y.z upd dpt:500 finden. Diese Regel müsste dann in der /etc/rc.d/rc.firewall.local, oder der /etc/rc.d/rc.local wieder entfernt, oder zumindest auskommentiert werden.
Wenn diese Option richtig konfiguriert ist und der Fehler nicht verschwindet, sollte der Status der Netzwerkkarte überprüft werden, entweder über die GUI unter “Status” -> “Netzwerk-Status” oder auf der Konsole mit
ifconfig ethx.
Hier dürfen keine, oder kaum Errors, Drops, Overruns oder Frames zu finden sein. Bei höheren Werten (>1% der RX/TX packets) sollte die Karte ausgetauscht werden.
Viel Spass bei der Fehlersuche 
To be continued…
Gruss
Ecki
Kommentar/Ergänzungen schreiben
(wird nicht veröffentlicht)
