wir verwenden seit einem halben Jahr den Lancom VPN 1721 und sind mit dem Router sehr zufrieden. Die Einrichtung einer VPN-Verbindung mit unserer Niederlassung in den USA jedoch bereitet seit geraumer Zeit Kopfschmerzen: die Verbindung kommt nich zustande.
Auf der Gegenseite befindet sich ein Linksys WRVS4400N mit fester IP.
IKE Einstellungen:
Encryption: 3DES
Authentication: MD5
PFS: OFF
Key Exchange: Auto
Die Verbindung scheitert bereits in Phase 1 - Fehlermeldung auf der Lancom Seite:
unexpected cleartext message received from peer WRVS4400N and dropped
in phase-1
IKE log: 004043 Default dropped message from 67.88.5.98 port 500 due to notifica
tion type INVALID_FLAGS
Fehlermeldung auf der Linksys Seite:
Mon, 2006-12-11 05:48:08 - [VPN Log]: packet from 217.7.199.231:500: ignoring informational payload, type INVALID_FLAGS
Der Linksys verwendet intern wohl OpenSwan. Kann mir jemand einen Tip geben, was ich hier falsch mache? Die LOGS sind im Attachement!
Lancom 1721: Verbindung mit Linksys WRVS4400N
Moderator: Lancom-Systems Moderatoren
Lancom 1721: Verbindung mit Linksys WRVS4400N
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Lancom 1721: Verbindung mit Linksys WRVS4400N
Hallo Backslash,
sorry, wollte den Text nicht einfügen - sonst wird der Post immer sehr lang und wenig übersichtlich. Der Vollständigkeit halber hier die Logs:
LANCOM
[VPN-Status] 1900/04/14 00:40:43,200
IKE info: The remote server 67.88.5.98:500 peer WRVS4400N id <no_id> negotiated rfc-3706-dead-peer-detection
IKE info: The remote server 67.88.5.98:500 peer WRVS4400N id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 67.88.5.98:500 peer WRVS4400N id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 67.88.5.98:500 peer WRVS4400N id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 67.88.5.98:500 peer WRVS4400N id <no_id> supports NAT-T in mode rfc
[VPN-Status] 1900/04/14 00:40:43,210
IKE info: Phase-1 remote proposal 1 for peer WRVS4400N matched with local proposal 1
[VPN-Status] 1900/04/14 00:40:43,550
IKE info: unexpected cleartext message received from peer WRVS4400N and dropped in phase-1
[VPN-Status] 1900/04/14 00:40:43,550
IKE log: 004043 Default dropped message from 67.88.5.98 port 500 due to notification type INVALID_FLAGS
[VPN-Status] 1900/04/14 00:40:43,550
IKE info: dropped message from peer unknown 67.88.5.98 port 500 due to notificat ion type INVALID_FLAGS
LINKSYS
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: initiating Main Mode
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: ignoring unknown Vendor ID payload [eeefa37809e32ad4de4f6b010c26a640]
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: received Vendor ID payload [Dead Peer Detection]
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: STATE_MAIN_I2: sent MI2, expecting MR2
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: message ignored because it contains an unknown or unexpected payload type (ISAKMP_NEXT_NAT-D) at the outermost level
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: sending notification INVALID_PAYLOAD_TYPE to 217.7.199.231:500
Mon, 2006-12-11 05:48:08 - [VPN Log]: packet from 217.7.199.231:500: ignoring informational payload, type INVALID_FLAGS
Mon, 2006-12-11 05:48:08 - [VPN Log]: packet from 217.7.199.231:500: received and ignored informational message
Was heisst denn 'rfc mode' und hat die Abschaltung von "NAT-T" im Lancom Auswirkungen auf andere/bestehende VPN-Verbindungen?
Danke für die Hilfe, Backslash
Olrando78
sorry, wollte den Text nicht einfügen - sonst wird der Post immer sehr lang und wenig übersichtlich. Der Vollständigkeit halber hier die Logs:
LANCOM
[VPN-Status] 1900/04/14 00:40:43,200
IKE info: The remote server 67.88.5.98:500 peer WRVS4400N id <no_id> negotiated rfc-3706-dead-peer-detection
IKE info: The remote server 67.88.5.98:500 peer WRVS4400N id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 67.88.5.98:500 peer WRVS4400N id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 67.88.5.98:500 peer WRVS4400N id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 67.88.5.98:500 peer WRVS4400N id <no_id> supports NAT-T in mode rfc
[VPN-Status] 1900/04/14 00:40:43,210
IKE info: Phase-1 remote proposal 1 for peer WRVS4400N matched with local proposal 1
[VPN-Status] 1900/04/14 00:40:43,550
IKE info: unexpected cleartext message received from peer WRVS4400N and dropped in phase-1
[VPN-Status] 1900/04/14 00:40:43,550
IKE log: 004043 Default dropped message from 67.88.5.98 port 500 due to notification type INVALID_FLAGS
[VPN-Status] 1900/04/14 00:40:43,550
IKE info: dropped message from peer unknown 67.88.5.98 port 500 due to notificat ion type INVALID_FLAGS
LINKSYS
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: initiating Main Mode
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: ignoring unknown Vendor ID payload [eeefa37809e32ad4de4f6b010c26a640]
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: received Vendor ID payload [Dead Peer Detection]
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: STATE_MAIN_I2: sent MI2, expecting MR2
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: message ignored because it contains an unknown or unexpected payload type (ISAKMP_NEXT_NAT-D) at the outermost level
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: sending notification INVALID_PAYLOAD_TYPE to 217.7.199.231:500
Mon, 2006-12-11 05:48:08 - [VPN Log]: packet from 217.7.199.231:500: ignoring informational payload, type INVALID_FLAGS
Mon, 2006-12-11 05:48:08 - [VPN Log]: packet from 217.7.199.231:500: received and ignored informational message
Was heisst denn 'rfc mode' und hat die Abschaltung von "NAT-T" im Lancom Auswirkungen auf andere/bestehende VPN-Verbindungen?
Danke für die Hilfe, Backslash
Olrando78
Hi Orlando78
Das Problem ist halt, daß der Linksys irgendetwas am NAT-T nicht mag und das meldet:
Gruß
Backslash
wenn du den Text in eine code-Umgebung stellst, dann kommt da ein Ausklappbarer Rahmen drum und das ganze bleibt übersichtlich...sorry, wollte den Text nicht einfügen - sonst wird der Post immer sehr lang und wenig übersichtlich. Der Vollständigkeit halber hier die Logs:
zum NAT-T gibt es verschiedene Drafts und halt den RFC 3947. "rfc mode" heißt daß die Gegenstelle behauptet, sie würde NAT-T nach RFC 3947 machen...Was heisst denn 'rfc mode' und
ja, der Schalter ist global, also entweder NAT-T oder halt nicht. Solange beide Seiten nicht hinter einem NAT-Router stehen, kann NAT-T deaktiviert bleiben.hat die Abschaltung von "NAT-T" im Lancom Auswirkungen auf andere/bestehende VPN-Verbindungen?
Das Problem ist halt, daß der Linksys irgendetwas am NAT-T nicht mag und das meldet:
Code: Alles auswählen
Mon, 2006-12-11 05:48:08 - [VPN Log]: "TeachSCRN" #5: message ignored because it contains an unknown or unexpected payload type (ISAKMP_NEXT_NAT-D) at the outermost level Backslash
Lancom 1721: Verbindung mit Linksys WRVS4400N
Hallo Backslash,
Danke - Dein Tip hat geholfen. NAT traversal war in meinem Fall aus, jetzt hab' ich's aktiviert ohne dass andere VPN-Verbindungen dadruch beinflusst wurden.
Super!
Ein Problem folgt aber meist auf's andere:
Nun steht zwar laut dem Linksys auf der Gegenseite die Verbindung - trotzdem versucht der Lancom weiterhin eine Verbindung zur Gegenseite aufzubauen.
Die IP der Gegenseite hab ich in der VPN-Verbindung definiert. Wenn ich die auf 0.0.0.0 kann ich auch vom Linksys (Gegenseite) nicht auf den Lancom verbinden. Unter 'Monitor Device' sehe ich, dass die Verbindung in den Protokollverhandlungen hängt:
State: Protocol Negotiation
Danke - Dein Tip hat geholfen. NAT traversal war in meinem Fall aus, jetzt hab' ich's aktiviert ohne dass andere VPN-Verbindungen dadruch beinflusst wurden.
Super!
Ein Problem folgt aber meist auf's andere:
Nun steht zwar laut dem Linksys auf der Gegenseite die Verbindung - trotzdem versucht der Lancom weiterhin eine Verbindung zur Gegenseite aufzubauen.
Die IP der Gegenseite hab ich in der VPN-Verbindung definiert. Wenn ich die auf 0.0.0.0 kann ich auch vom Linksys (Gegenseite) nicht auf den Lancom verbinden. Unter 'Monitor Device' sehe ich, dass die Verbindung in den Protokollverhandlungen hängt:
State: Protocol Negotiation