VPN Verbindung klappt nur sporadisch (zur Zeit nicht mehr)

Dr.Wackelzahn · Beitrag von **Dr.Wackelzahn** » 14 Sep 2008, 12:49

Hallo,
ich habe folgendes Problem: Gelegentlich funktioniert die VPN Verbindung problemlos und dann funktioniert sie wieder gar nicht obwohl sich nichts an der Konfiguration (Hardware sowie Software) ändert. Ich finde das Problem einfach nicht.

Mein 1821 bietet über einen Dyndns Accout seine IP an über welche dann mittels dem Advanced VPN Client eine Verbindung aufgebaut wird.

Zurzeit kommt aber statt einer Verbindung folgendes zurück:
A-VPN-Client: IKE-Fehler (Phase 1)

14.09.2008 12:35:45 IPSDIALCHAN::start building connection
14.09.2008 12:35:45 IPSDIAL::DNSREQ: resolving dnserver over lan: xxx.DYNDNS.INFO
14.09.2008 12:35:45 IPSDIAL->DNSREQ: resolved ipadr: xxx.xxx.xxx.012
14.09.2008 12:35:45 NCPIKE-phase1:name(xxx) - outgoing connect request - aggressive mode.
14.09.2008 12:35:45 XMIT_MSG1_AGGRESSIVE - xxx
14.09.2008 12:36:15 NCPIKE-phase1:name(xxx) - error - retry timeout - max retries
14.09.2008 12:36:15 IPSDIAL - disconnected from xxx on channel 1.

Parallel dazu habe ich mittels putty auf dem Lancom eingwählt und einen Trace auf "VPN-Status" laufen lassen. Dieser meldet:

[VPN-Status] 2008/09/14 12:35:47,380
IKE info: The remote server xxx.xxx.xxx.107:500 peer def-aggr-peer id <no_id> supports draft-ietf-ipsec-isakmp-xauth
IKE info: The remote server xxx.xxx.xxx.107:500 peer def-aggr-peer id <no_id> negotiated rfc-3706-dead-peer-detection
IKE info: The remote client xxx.xxx.xxx.107:500 peer def-aggr-peer id <no_id> is NCP LANCOM Serial Number Protocol 1.0 with serial number 21xxxxx1

[VPN-Status] 2008/09/14 12:35:47,390
IKE info: phase-1 proposal failed: remote No 1 hash algorithm = SHA <-> local No 1 hash algorithm = MD5
IKE info: Phase-1 remote proposal 1 for peer def-aggr-peer matched with local proposal 2

Da ich ja über die bei Dyndns.org hinterlegte IP-Adresse eine SSH Verbindung aufbauen kann, kann es nicht am Dyndns liegen.
Da es gelegentlich funktioniert, kann es auch nicht an der Client Einstellung liegen.

Woran kann es liegen?

Dr.Wackelzahn · Beitrag von **Dr.Wackelzahn** » 15 Sep 2008, 20:21

So, jetzt habe ich über den Assistenten einen Einwahlzugang über VPN erstellt und das INI-File in meinen Advanced VPN Client importiert.

Trotzdem erscheint beim Trace folgende Meldung:

IKE info: phase-1 proposal failed: remote No 1 hash algorithm = SHA <-> local No 1 hash algorithm = MD5

Das verstehe ich nicht, wenn schon der Assistent genutzt wird, so sollte man meinen, dass er für beide Seiten die gleiche Einstellung verwendet. Aber wieso lokal MD5 und im Lancom SHA - Das verstehe ich nicht!

Welcher Trace könnte noch hilfreich sein um mein Problem zu analysieren?
Das Logbuch sagt:

15.09.2008 20:12:26 NCPIKE-phase1:name(LANCOM1821-TEST) - outgoing connect request - aggressive mode.
15.09.2008 20:12:26 XMIT_MSG1_AGGRESSIVE - LANCOM1821-TEST
15.09.2008 20:12:56 NCPIKE-phase1:name(LANCOM1821-TEST) - error - retry timeout - max retries
15.09.2008 20:12:56 IPSDIAL - disconnected from LANCOM1821-TEST on channel 1.

und der Tracer sagt:

IpsDialChan::s_conreq
Mon Sep 15 20:17:08 2008:ChanConReq( Exit Okey )
mif32_UpdMib(0040,00000000,00224)
Mon Sep 15 20:17:08 2008:PthruAddVpnPort port=500
IPSEC:UpdateSpd - 1
Mon Sep 15 20:17:08 2008:CreateSpdEntry:Adapter-0,Name-LANCOM1821-TEST,Count-1
Mon Sep 15 20:17:08 2008:NcpUser::Adding LwsGateway
SYSTEM->IPS: ConnectPhaseII (00000001)
IKE->IPS:IpsDelIkeSa - 0
IKE->IPS: phase I SA(00000031) is gone
Mon Sep 15 20:17:37 2008:RemoveSpdEntry:Adapter-0,Name-LANCOM1821-TEST,Count-0
(42689):IpsDial:linkdown(id = 1)
Lcp::linkdown(1a2a520)
BaseCp::enter_closed_state(c021)
Lcp::linkdown exit(1a2a520)
Mon Sep 15 20:17

Vielen Dank im Voraus für Eure Hilfe!

froeschi62 · Beitrag von **froeschi62** » 16 Sep 2008, 09:58

Hi,

Dr.Wackelzahn hat geschrieben:[VPN-Status] 2008/09/14 12:35:47,390
IKE info: Phase-1 remote proposal 1 for peer def-aggr-peer matched with local proposal 2[/list]

Hier sagt er doch ganz klar, dass er letztendlich ein Proposal gefunden hat, was übereinstimmt. In Deiner Liste stehen vermutlich mehrere Proposals, die er solange durchgeht bis er auf ein Proposal mit gleichen Parametern stößt. Das ist soweit absolut ok.

Gruß
Dietmar

froeschi62 · Beitrag von **froeschi62** » 16 Sep 2008, 10:05

Hi,

du solltest grundsätzlich bei VPN Verbindungen immer auf folgendes achten, was der Assistent nicht einrichtet.

1. Im Router NAT-T einschalten
2. Auf der Clientfirewall die UDP Ports 500 und 4500 freischalten.

Gruß
Dietmar

Dr.Wackelzahn · Beitrag von **Dr.Wackelzahn** » 16 Sep 2008, 12:12

Hallo Dietmar,
vielen Dank für die Hinweise.
- NAT-T hatte ich bereits aktiviert
- Auf "meiner" (Client) Seite hatte ich zeitweise die FW ganz abgeschaltet

Dennoch keine Besserung.

Mich irritiert, dass ich keine aussagekräftige Fehlermeldung bekomme.

Gibt es irgendetwas das ich vielleicht tracen könnte um etwas mehr Infos zu meinem Problem zu bekommen.

Ach ja, FW Update etc. ist auch schon erfolgt.

Vielen Dank!
Gruß,
Alex

froeschi62 · Beitrag von **froeschi62** » 16 Sep 2008, 14:21

Hi,

hast Du jetzt die Ports bei aktivierter Firewall freigeschaltet? Nicht vergessen, ebenfalls ICMP (Echoanforderung) einzuschalten. Bitte trotzdem probieren.
Ansonsten *komplette* Anmeldevorgang Traces vom Router und VPN Client. Hier hast Du nur Aussschnitte präsentiert.

Gruß
Dietmar

Dr.Wackelzahn · Beitrag von **Dr.Wackelzahn** » 16 Sep 2008, 14:29

Nein, nein nur vor lauter Verzweiflung hatte ich die Firewall deaktiviert um nicht irgendeinen Port oder eine falsche Einstellung im Weg zu haben.

So jetzt meine Frage:
komplette Anmeldevorgang Traces

Was muss ich nach "tr #" angeben um diese zubekommen.
Gibt's zu der Shell eigentlich eine Übersicht außer der Hilfe.

Vielen Dank!

froeschi62 · Beitrag von **froeschi62** » 16 Sep 2008, 15:06

Hi,

im Lanmonitor, mit rechter Maustaste auf deinen Router klicken, Trace und hier VPN-Status.

Gruß
Dietmar

Dr.Wackelzahn · Beitrag von **Dr.Wackelzahn** » 16 Sep 2008, 15:52

Ist dies das Gleiche wie in der SSH-Sitzung "tr # vpn"?

Dr.Wackelzahn · Beitrag von **Dr.Wackelzahn** » 16 Sep 2008, 21:00

So, bin jetzt wieder soweit und habe also den Trace ausgeführt:

[TraceStarted] 2008/09/16 20:55:37,000
Used config:
# Trace config
trace + VPN-Status

# Show commands
show bootlog

[ShowCmd] 2008/09/16 20:55:38,000
Result of command: "show bootlog "
Boot log (807 Bytes):

****

1/1/1900 0:00:01 System boot after power on

DEVICE: LANCOM 1821 Wireless ADSL (Ann.B)
HW-RELEASE: C
VERSION: 5.02.0020 / 27.07.2005 / 2.73/a27.4.11

****

8/1/2008 10:45:31 System boot after manual boot request

DEVICE: LANCOM 1821 Wireless ADSL (Ann.B)
HW-RELEASE: C
VERSION: 5.02.0020 / 27.07.2005 / 2.73/a27.4.11

****

9/14/2008 19:17:00 System boot after manual boot request

DEVICE: LANCOM 1821 Wireless ADSL (Ann.B)
HW-RELEASE: C
VERSION: 5.02.0020 / 27.07.2005 / 2.73/a27.4.11

****

09/15/2008 08:30:41 System boot after firmware upload

DEVICE: LANCOM 1821 Wireless ADSL (Ann.B)
HW-RELEASE: C
VERSION: 7.56.0046 / 20.08.2008 / 6.26/E74.02.50.2-PM

[Sysinfo] 2008/09/16 20:55:38,000
Result of command: "sysinfo"

DEVICE: LANCOM 1821 Wireless ADSL (Ann.B)
HW-RELEASE: C
SERIAL-NUMBER: 02xxxxxxxxxx9
MAC-ADDRESS: 00xxxxxxxxx85
IP-ADDRESS: 88.xx.xx.47
IP-NETMASK: 0.0.0.0
INTRANET-ADDRESS: 0.0.0.0
INTRANETMASK: 0.0.0.0
VERSION: 7.56.0046 / 20.08.2008 / 6.26/E74.02.50.2-PM
NAME: LANCOM1821
CONFIG-STATUS: 1056;0
FIRMWARE-STATUS: 0;0.4;0.1;7.56.20082008.4;5.02.27072005.3
LANCAPI-PORT: 75
HW-MASK: 00001100000000000000000000100011
FEATUREWORD: 00000000000000000100000100011101
REGISTERED-WORD: 00000000000000000100000100010101
FEATURE-LIST: 00/F/00000000
FEATURE-LIST: 02/F/00000000
FEATURE-LIST: 03/F/00000000
FEATURE-LIST: 04/F/00000000
FEATURE-LIST: 08/F/00000000
FEATURE-LIST: 0e/F/00000000
TIME: 20553916092008
HTTP-PORT: 80
HTTPS-PORT: 443
Compatible-IDs: 14:30:31;10:26:31

[VPN-Status] 2008/09/16 20:55:46,750
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports draft-ietf-ipsec-isakmp-xauth
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> negotiated rfc-3706-dead-peer-detection
IKE info: The remote client 88.xx.xx255:500 peer def-aggr-peer id <no_id> is NCP LANCOM Serial Number Protocol 1.0 with serial number 2xxxxxxxx1
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc

[VPN-Status] 2008/09/16 20:55:46,760
IKE info: phase-1 proposal failed: remote No 1 hash algorithm = SHA <-> local No 1 hash algorithm = MD5
IKE info: Phase-1 remote proposal 1 for peer def-aggr-peer matched with local proposal 2

Mehr kommt da nicht....

(

froeschi62 · Beitrag von **froeschi62** » 16 Sep 2008, 22:57

Hi,

tja, eigentlich bleibt er ohne wirkliche Fehlermeldung stehen, sehr seltsam. Nimm beim nächsten Trace "VPN-Packet" dazu. Was sagt das Trace des AVC-Clients? In welcher Client/Netz Umgebung nimmst Du die VPN Verbindung auf?

Gruß
Dietmar

Dr.Wackelzahn · Beitrag von **Dr.Wackelzahn** » 16 Sep 2008, 23:10

Also das AVC Log schreibt:

16.09.2008 23:02:59 IPSDIALCHAN::start building connection
16.09.2008 23:02:59 IPSDIAL::DNSREQ: resolving dnserver over lan: xxx.DYNDNS.INFO
16.09.2008 23:02:59 IPSDIAL->DNSREQ: resolved ipadr: 088.xx.xx.047
16.09.2008 23:02:59 NCPIKE-phase1:name(LANCOM1821-ALEX) - outgoing connect request - aggressive mode.
16.09.2008 23:02:59 XMIT_MSG1_AGGRESSIVE - LANCOM1821-ALEX
16.09.2008 23:03:02 NCPIKE-phase1:name() - incoming connect request.
16.09.2008 23:03:02 RECV_MSG1_AGGRESSIVE -
16.09.2008 23:03:02 NCPIKE-phase1:name() - error - ATTRIBUTES_NOT_SUPPORTED
16.09.2008 23:03:28 NCPIKE-phase1:name(LANCOM1821-ALEX) - error - retry timeout - max retries
16.09.2008 23:03:28 IPSDIAL - disconnected from LANCOM1821-ALEX on channel 1.

Trace VPN-Status + VPN-Packet:

[VPN-Status] 2008/09/16 23:03:00,830
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports draft-ietf-ipsec-isakmp-xauth
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> negotiated rfc-3706-dead-peer-detection
IKE info: The remote client 88.xx.xx.255:500 peer def-aggr-peer id <no_id> is NCP LANCOM Serial Number Protocol 1.0 with serial number 2xxxxxx1
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 88.xx.xx.255:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc

[VPN-Status] 2008/09/16 23:03:00,840
IKE info: phase-1 proposal failed: remote No 1 hash algorithm = SHA <-> local No 1 hash algorithm = MD5
IKE info: Phase-1 remote proposal 1 for peer def-aggr-peer matched with local proposal 2

[VPN-Status] 2008/09/16 23:03:04,000
IKE log: 230304 Default message_recv: invalid cookie(s) 7ad44dd72ae0b2c8 9193166a6de69751

[VPN-Status] 2008/09/16 23:03:04,000
IKE log: 230304 Default dropped message from 88.xx.xx.255 port 500 due to notification type INVALID_COOKIE

[VPN-Status] 2008/09/16 23:03:04,000
IKE info: dropped message from peer unknown 88.xx.xx.255 port 500 due to notification type INVALID_COOKIE

"INVALID_COOKIE" was soll das heißen?

Ich gehe über einen Router ins Netz, falls Du das meinst.
Vielen Dank,
Dietmar!

froeschi62 · Beitrag von **froeschi62** » 17 Sep 2008, 00:38

Hi,

INVALID_COOKIE ist eigentlich keine Meldung, die auf Inkompatibilitäten hindeutet. Meistens versucht eine der Tunnelendpunkte eine SA zu benutzen, die abgelaufen ist. Das passiert z. B. wenn auf einer Seite ein VPN Tunnel abbricht, ohne dass die andere Seite dieses bemerkt hat. Entsprechende Seite versucht dann immer wieder den Tunnel aufzubauen, eben mit dieser Meldung.

Viele Grüße
Dietmar

Dr.Wackelzahn · Beitrag von **Dr.Wackelzahn** » 17 Sep 2008, 08:55

Es ist schon irgendwie seltsam.
Etwas ungeschickt finde ich die AVC Fehlermeldung "IKE-Fehler (Phase 1)".
Mal ganz ehrlich, diese Meldung findet man hier im Forum zu den unterschiedlichsten Fehlern.
Ich werde jedenfalls nicht schlau aus dem Ganzen. Zu dumm nur dass die bisherige ISDN-Verbdinung nicht mehr möglich ist, keine ISDN Karte -> keine Verbindung

.

froeschi62 · Beitrag von **froeschi62** » 17 Sep 2008, 09:28

Hi,

Prüfe mal, ob der Identitätstyp und die Identität im Advanced Client identisch mit den Einträgen bei der Remote-Identität im Lancom (IKE-Schlüssel und Identitäten) ist. Da Du den aggressive Mode einsetzt, schaue bitte noch nach ob die PSK's im Lancom und AVC Client übereinstimmen.

Gruß
Dietmar

LANCOM-Forum.de

VPN Verbindung klappt nur sporadisch (zur Zeit nicht mehr)

VPN Verbindung klappt nur sporadisch (zur Zeit nicht mehr)

Re: VPN Verbindung klappt nur sporadisch (zur Zeit nicht meh