Traces - VPN-Status-Trace aufgeschlüsselt

Traces - allgemein:

Die LANCOM-Router bieten zur Fehlerdiagnose die Möglichkeit, interne Abläufe mitzuprotokollieren.
Diese Trace-Funktion erreichen sie über die Telnet-Konsole. Mehr über die umfangreichen Trace-Funktionen im LANCOM-Router finden sie hier.

Nachfolgend finden sie einen VPN-Trace nach Bedeutung jeder Meldung aufgeschlüsselt.

Anwendung:

Der VPN-Trace wird verwendet, um das ordnungsgemäße Zustandekommen einer VPN-Verbindung zu überwachen.
Dies gilt sowohl für VPN-LAN-LAN-Verbindungen als auch für VPN-Client-Einwahlen.

Geben sie hierzu in der Telnet-Konsole den Befehl "trace + vpn-status" ein

VPN-Trace im Detail:

2004/01/20 15:18:34,500	Zeitstempel, wird jeder Ausgabe vorangestellt
VPN: connecting to BUGFIX (213.23.254.24)	erste VPN-Meldung: Die Verbindung zur Gegenstelle "BUGFIX" wird aufgebaut. BUGFIX hat die IP: 213.23.254.24

2004/01/20 15:18:34,510 VPN: start dynamic VPN negotiation for BUGFIX (213.23.254.24) via ICMP/UDP	Um den Tunnel aufzubauen wird nun ein ICMP-Paket gesendet, um die eigene IP der Gegenstelle zu übermitteln.

2004/01/20 15:18:34,510 VPN: create authentication packet for BUGFIX (213.23.254.24) DNS: 10.98.0.241, 0.0.0.0 NBNS: 10.98.0.241, 0.0.0.0	Nun wird ein Authentifizierungspaket für diese Gegenstelle generiert. incl. Übermittlung der lokalen DNS und NBNS-Server

2004/01/20 15:18:34,510 VPN: installing ruleset for BUGFIX (213.23.254.24)	Zur Gegenstelle Bugfix werden die VPN-Regeln generiert.

2004/01/20 15:18:34,520 VPN: ruleset installed for BUGFIX (213.23.254.24)	DIe VPN-Regeln sind erstellt

2004/01/20 15:18:34,520 VPN: start IKE negotiation for BUGFIX (213.23.254.24)	Das lokale Gerät startet die IKE-Aushandlung

2004/01/20 15:18:34,530 VPN: installed rulesets	Die VPN-Regelerstellung ist abgeschlossen

2004/01/20 15:18:34,530 VpnIpm: info; phase-1 negotiation started for peer isakmp-peer-BUGFIX	Die Phase 1 der VPN-Aushandlung wurde gestartet

2004/01/20 15:18:34,530 VpnIpm: info; Phase-1 negotiation started for peer BUGFIX rule isakmp-peer-BUGFIX using MAIN mode	Es wird Main Mode verwendet

2004/01/20 15:18:34,740 VPN: received authentication packet from BUGFIX (213.23.254.24) DNS: 192.168.2.1, 0.0.0.0 NBNS: 192.168.2.1, 0.0.0.0	Ein Authentifizierungspaket von BUGFIX wurde empfangen, die dortigen DNS und NBNS-Server wurden mitgeteilt

2004/01/20 15:18:34,800 VpnIpm: info; The remote server 213.23.254.24:500 id <no_id> is Enigmatec IPSEC version 1.4.0	Der Remote Server (anderer Router) verwendet einen Enigmatec IPsec-Stack Wird der Agressive-Mode verwendet, wird statt <no_id> die Identität angezeigt.

2004/01/20 15:18:34,800 VpnIpm: info; phase-1 proposal failed; remote No 1 encryption algorithm = BLOWFISH_CBC <-> local No 1 encryption algorithm = AES_CBC	Das erste Proposal der Verhandlung stimmt nicht überein. Die Gegenstelle wünscht als erste Verschlüsselung Blowfish-CBC, wir wollen AES-CBC verwenden

2004/01/20 15:18:34,800 VpnIpm: info; phase-1 proposal failed; remote No 1 encryption algorithm = BLOWFISH_CBC <-> local No 2 encryption algorithm = AES_CBC	Das zweite Proposal der Verhandlung stimmt nicht überein. Lokal ist auch auf dem 2. Proposal AES-CBC konfiguriert

2004/01/20 15:18:34,810 VpnIpm: info; Phase-1 remote proposal 1 matched with local proposal 3	Das 1. Proposal der Gegenstelle stimmt mit dem 3. lokalen Proposal überein.

2004/01/20 15:18:37,530 VpnIpm: info; Phase-1 [inititiator] between initiator id 213.54.81.158, responder id 213.23.254.24 done	Die Phase 1 der Verbindung zwischen den aktuellen öffentlichen Adressen wurde vollständig verhandelt

2004/01/20 15:18:37,530 VpnIpm: info; SA ISAKMP for peer BUGFIX encryption blowfish-cbc authentication md5	Die ausgehandelte Verschlüsselung der Phase 1 wird angezeigt

2004/01/20 15:18:37,530 VpnIpm: info; life time ( 108000 sec/ 0 kb)	Die Lifetime für die Phase 1 der Verbindung wurde auf 108000 Sekunden festgelegt.

2004/01/20 15:18:40,190 VpnIpm: info; Phase-2 [inititiator] done with 2 SAS for peer BUGFIX rule ipsec-0-BUGFIX-pr0-l0-r0	Initiierung der Phase 2 für die Gegenstelle BUGFIX

2004/01/20 15:18:40,190 VpnIpm: info; rule:' ipsec 10.98.0.240/255.255.255.240 <-> 192.168.2.0/255.255.255.0 '	Die IP-Sec-Regel für die Kommunikation der beiden loaklen Netze untereinander wird erstellt

2004/01/20 15:18:40,190 VpnIpm: info; SA ESP [0x6cfe59fb] alg BLOWFISH keylength 128 +hmac HMAC_SHA outgoing	die ausgehandelte ausgehende Paketverschlüsselung wird angezeigt

2004/01/20 15:18:40,190 VpnIpm: info; SA ESP [0x3444a4b9] alg BLOWFISH keylength 128 +hmac HMAC_SHA incoming	die ausgehandelte eingehende Paketverschlüsselung wird angezeigt

2004/01/20 15:18:40,200 VpnIpm: info; life soft( 1800 sec/180000 kb) hard (2000 sec/200000 kb)	Hier werden die Lifetimes für Phase zwei erstellt.

2004/01/20 15:18:40,200 VpnIpm: info; tunnel between src: 213.54.81.158 dst: 213.23.254.24	Der Tunnel der Phase 2 steht zwischen den öffentlichen IP-Adressen.

2004/01/20 15:18:41,360 VPN: BUGFIX (213.23.254.24) connected, set poll timer to 30 sec	Die VPN-Aushandlung ist beendet, die Verbindung ist aufgebaut. Der Timer zur regelmäßigen Überwachnung der Verbindung wird gesetzt.

Häufige Fehlermeldungen und Ihre Bedeutung im VPN-Trace:

Fehlermeldung: Gegenstelle antwortet nicht:

[VPN-Status] 2007/12/04 14:37:57,210 VPN: connection for BUGFIX (213.23.254.24) timed out: no response	Diese Meldung zeigt an, das die Gegenseite auf den Verbindungsrequest nicht geantwortet hat. Sie erscheint 30 Sekunden nach Beginn des Aufbauversuchs.

[VPN-Status] 2007/12/04 14:37:57,210 VPN: Error: IFC-I-Connection-timeout-IKE-IPSEC (0x1106) for BUGFIX (213.23.254.24)	Die interne Fehlermeldung hierzu wird generiert und z.B. an den LANmonitor gemeldet. Die Gegenstelle hat nicht geantwortet.

Bedeutung:
Die Gegenseite reagiert nicht auf die Verbindungsanfrage des LANCOM. Er erhält keine Antwort

Mögliche Ursachen:
- Die Gateway-Adresse ist nicht korrekt. Ein DynDNS-Name der Gegenseite ist nicht aktualisiert oder die eingegebene IP ist nicht korrekt.
- Die Gegenseite ist für diese Verbindung nicht konfiguriert, und kann die Verbindungsanfrage nicht zuordnen. Daher antwortet sie nicht.
- Eine Firewall verhindert, das die Anfragepakete den LANCOM der Gegenseite erreichen.

Weiteres Vorgehen:
- auf der Gegenstelle einen VPN-Trace ausführen, um dort festzustellen welche Ursache vorliegt.

Fehlermeldung: Line-Polling fehlgeschlagen:

[VPN-Status] 2007/12/04 01:24:43,710 VPN: poll timeout for BUGFIX (213.23.254.24) remote site did not answer during interval	Für die Gegenstelle BUGFIX hat es ein Timeout im Polling gegeben, ein Poll-Paket wurde nicht fristgerecht beantwortet.
setting poll time to 1 sec.	Als Reaktion darauf setzt der LANCOM den Pollingzähler auf eine Sekunde. Nun wird jede Sekunde gepollt.
(5 retries left)	Dies wird nun fünf mal versucht. Scheitert dies, wird die Verbindung abgebaut.
send poll frame to 192.168.3.254	Es wird ein Pollpaket an diese Adresse abgeschickt.

[VPN-Status] 2007/12/04 01:24:44,710 VPN: poll timeout for BUGFIX (213.23.254.24) remote site did not answer during interval (4 retries left) send poll frame to 192.168.3.254 [VPN-Status] 2007/12/04 01:24:45,710 VPN: poll timeout for BUGFIX (213.23.254.24) remote site did not answer during interval (3 retries left) send poll frame to 192.168.3.254 [VPN-Status] 2007/12/04 01:24:46,710 VPN: poll timeout for BUGFIX (213.23.254.24) remote site did not answer during interval (2 retries left) send poll frame to 192.168.3.254 [VPN-Status] 2007/12/04 01:24:47,710 VPN: poll timeout for BUGFIX (213.23.254.24) remote site did not answer during interval (1 retries left) send poll frame to 192.168.3.254	Dies wird nun noch vier mal wiederholt

[VPN-Status] 2007/12/04 01:24:48,710 VPN: poll timeout for BUGFIX (213.23.254.24) remote site did not answer during interval no retries left, disconnect channel	Die fünf Versuche waren nicht erfolgreich, die Gegenstelle hat nicht geantwortet. Daher wird die Verbindung nun abgebaut

[VPN-Status] 2007/12/04 01:24:48,720 VPN: Error: IFC-X-Line-polling-failed (0x1307) for BUGFIX (213.23.254.24)	Hierzu wird nun die offizielle Fehlermeldung erzeugt.

[VPN-Status] 2007/12/04 01:24:48,720 VPN: disconnecting BUGFIX (213.23.254.24)	Der Verbindungsabbau wird eingeleitet

Bedeutung:
Die Gegenseite reagiert nicht auf die Verbindungsüberwachung. Da diese Pakete nicht beantwortet werden, wird die Verbindung abgebaut.

Mögliche Ursachen:
- Die Polling-Adresse ist nicht korrekt. Daher wird die falsche Adresse angesprochen und diese antwortet nicht
- Die VPN-Verbindung ist aufgebaut, funktioniert aber nicht korrekt, z.B. weil eine Firewall die korrekte Kommunikation unterbindet
- Es wird die öffentliche IP des gegenüberliegenden LANCOM angesprochen, und dieser hat die Option "Ping blockieren" aktiviert und antwortet daher nicht.

Weiteres Vorgehen:
- prüfen der Polling-Einstellungen in der Polling-Tabelle und der PPP-Liste
- ggf. prüfen durch ICMP-Trace auf der Gegenseite, ob Polling-Pakete dort eintreffen.
- Polling-Ziel ist idealerweise die LAN-IP-Adresse des entfernten LANCOMs. Ist dies nicht möglich, verwenden Sie eine andere Adresse im LAN, welche IMMER erreichbar sein muss. Ist diese Adresse nicht erreichbar, wird die Verbindung nicht funktionieren.

Fehlermeldung: Kein Eintrag in Polling-Tabelle und KeepAlive ist eingestellt:

[VPN-Status] 2007/12/04 01:24:48,720
VPN: Error: IFC-I-No-poll-table-entry-matched (0x1108) for BUGFIX (213.23.254.24)

Erzeugung der Fehlermeldung "Kein Eintrag in Polling-Tabelle und KeepAlive ist eingestellt".

Bedeutung:
Es ist für diese Verbindung ein KeepAlive eingestellt (Haltezeit "9999" in der VPN-Verbindungsliste), es existiert jedoch kein Polling-Eintrag in der Polling-Tabelle

Ursache:
- Es ist für diese Verbindung ein KeepAlive eingestellt (Haltezeit "9999" in der VPN-Verbindungsliste), es existiert jedoch kein Polling-Eintrag in der Polling-Tabelle

Weiteres Vorgehen:
- Einrichtung eines Polling-Eintrags in der Polling-Tabelle für diese Gegenstelle. Beachten Sie das die Polling-Adresse immer antworten muss, sonst kann die Verbindung nicht aufgebaut werden.

Service & Support

Links