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.
